Everyone knows these things. It's common knowledge! But I'll bet you that more than half of us developers don't do it. We're lazy, especially when it comes to our own blogs.
Optimizing a static website. It's not rocket science, what I'm going to tell you. You already know it. But you'll read it anyway.
Nowadays static websites have grown in popularity once again. With a good reason, too. They are fast, easy to create, easy to deploy, easy to scale and easy to maintain (using tools like Hexo and Hugo). So if all you need is a blog or a simple website, you will be smart and create a static website. No need for PHP, no need for a database. Move along. Nothing for you to see here, WordPress.
So. I wanted to optimize my blog at petar.io, and I sat one lonely night to do it. It already loaded pretty fast, because there wasn't much to load. I aimed to make it lean, by not opting for Bootstrap and jQuery. But somewhere along the way I got lazy and it got a bit slow.
I throttled the network to Good 3G and started looking at Network tab in Chrome. DOM Content Loaded time was alright, about 2s. But the whole Load time itself was straight awful. 16s. To fix it up, I did 4 very obvious things.
Please tell me in the comments what else you would do, as long as it's super simple and super effective. 馃
After these optimizations I got the Page Load time from 16s to 3.5s. I know that 3.5s is not very impressive, but it works just fine for me, because the above the fold content is shown instantly. Again, this is all for Good 3G network config. In normal conditions it's around 1.2s. Lighthouse says 85/100.
I got a bit carried away with my image sizes, so first I resized them down to 800px wide, as that's as wide they get on any screen size. Then I passed them through an image optimizer (e.g. Kraken.io), and that shaved a lot of kilobytes. Finally I converted some pngs to jpegs and vice versa, as they are both good for a specific type of image (pngs are for diagrams, drawings, transparent images, etc, and jpegs are for photographs), and that saved some more space.
You know that social icons thing that everyone is using? Yes, you caught me, I have it on my website too. But, I used a Web font to show them. It's an additional HTTP request. But also, there were icons that I didn't use in that font. I only used like 5 icons. So I removed the font and inlined SVG code for each icon. Now when the user gets HTML, he gets the social icons in the same basket. No FOUT. The effect of this change is hugely noticeable, as the icons sit in the header of the site, above the fold, and they are among the first things that you see when you open the site. Back when I used a Web font, there was a flash until the font is loaded and applied. Now, they are instantly there. Like magic!
Oh, the notorious fold. At some point smart people realized that when you open a Web page, you only see it down to a certain point. The whole length of the page isn't visible on the screen right away, just the top part - the first 768px (depending on your screen). So they thought "To make the user think this site is fast, we should do everything we can to load the first visible part, like, really fast, and the rest can wait a bit, as it's not shown until later". So we started optimizing the above the fold content by inlining resources shown there into the HTML, most commonly CSS.
How? From your huge mess of a CSS file, how do you know which rules apply to the above the fold content? How does a browser know? It's a process that can be automated with plugins like Critical, but my CSS is really small, as this is a simple site, and it didn't benefit from this technique.
The inlining of SVG social icons that I did does fall into this category, and that did have a large impact on the perceived performance.
Another thing I did was inline the profile image that is shown in the header. Here's the story. At first it was a bloated transparent .png weighting 80 KB. Then I realized, damn, I don't need the transparency, I'll make it a .jpg and make it round using CSS border-radius! And after that, my profile image was 9 KB. Much, much better. But then I wanted the image to be shown instantly, like the icons. No progressive loading. So I converted it to Base64 string and used that as the img`'s src. Now remember, Base64 encoded string is usually about 30% larger than the original. For my pretty little image it was 13 KB. And also it added some overhead to the HTML that was transmitted. But the effect of loading the image instantly in one go is just plain awesome.
On the other hand, Base64 strings can't be cached by the browsers. Sad.
Even if it sounds like a scary little alien's name, Gzip is pretty nice and cuddly. Why? Because it's simple to setup and the compression shaves up to 50% of the size of transferred resources between your server and the browser. Neat! Here's a quick guide I wrote as a part of a past post - scroll to the bottom to find it - The Perfect Portfolio. If you need a more in depth guide, check this one out.
There. I told you that it was going to be really simple. But do you do it? Tell me in the comments. It's okay, we're all busy and sometimes forget to do the simple things. No judging here.
Happy coding and talk to you soon!
鉂わ笍,
Petar
