This redesign took forever. As far as I remember about two and a half years. The delay was dued to a lot of exciting things in the past that changed my life’s priorities. But the past couple of weeks I had some spare time to finish this redesign.
Nowadays we designers and developers know, a website redesign never is and never should be a self-contained nor finite project. The web and its technological capabilities are always evolving and so should our websites. It’s an infinite evolution and you want to stay on top of it. Who thought about responsive design ten years ago or about a CSS grid specification five years ago? I will write about redesigning websites and my experiences in an upcoming article as I’m working on a client’s website right now, again.
When I started this redesign I had three goals in mind that shaped this project’s scope: keep the site and code as simple as possible, optimize everything for speed and performance and start writing.
Keep it Simple
Thriving for simplicity is a tough job. Especially the moment you have to decide on which (content management) system you build your website.
I built my past version of this website on top of Kirby. Even though Kirby is a wonderful and pleasing CMS to work with I wanted to force myself to work on static sites, again. There are quite a few powerful static site builders out there. One that stands out due to its simplicity and popularity is Jekyll. I used this powerful blog-aware static website generator on a couple of projects and I never regretted the choice. Neither me nor the website and product owners I worked with. Its simplicity and the liquid syntax open up plenty of options to build great and performance driven websites. Small and big. Sure, it has its limitations. But for this site, my scope and my requirements it was my best choice.
Optimize for Performance
Performance is a important. You want your site to render as fast as possible on your visitor’s device and browser. Metrics like time to first byte, start render time, number of requests and other performance indicators play a huge role regarding the user experience.
Websites are getting bigger and bigger the past couple of years with an average size of more than 3000 kB per page. That is nearly 4 times the size a webpage had in 2010 (702 kB). For this relaunch I set a limit on Kilobytes for each page and that limit should not be exceeded. Therefor I set up a performance budget. My budget is 250 kB for pages without and 500 kB on pages with images. The load time (fully complete) should not exceed 4 seconds and the speed index should be below 2.500. I will cover the details and the ideas behind my limits in my next article.
This article’s performance budget is 177 kB, the load time 1.400 ms and the speed index 1.100.
|MIME Type||Requests||Size (Bytes)||%|
Even though the metrics are alright, the font stack I use is huge compared to the other assets. But I love fonts and for now it doesn’t hurt my performance budget nor the page speed significantly.
I want to write and publish on my own site. I wrote for third parties, agencies and companies in the past and I’m still doing that. But the past couple of years (reads: forever) I had this urge to write on my own site. A lot of my kind deal with this phenomenon. You want to write and contribute to the community. A community that shares so much stories, knowledge, experiences and insights. But you never get started with your own blog for different reasons. Not knowing where to start, what to write about on a long-term perspective or who to address. Let’s be brave and start.
I’ll write about my experiences on designing and coding for the web, performance and user experience. Besides those topics I’ll try to share my experiences on working in (agile) teams and with clients and stakeholders. My goal is to publish at least one article a month. I hope you enjoy reading them.
That said, my first post is done. I made a start and set the scope. Let’s see where this leads to.