Imagine you’ve made the most beautiful website this side of Mikiyako Kobayashi art gallery, but now that you did it, it lags so damn much! And despite the awesome design, the user experience is absolute hell. If that’s what happened — it’s time to do something about it, because according to Amazon, Walmart, Akamai and Aberdeen Group each 1% of website’s loading speed yields at least 1% of conversions.
1. HTTP-requests are evil
An outline of the HTTP request. Browser requests the data, server processes the request and sends the data back.
Think about it. Each time a user loads your website, besides the page itself, they end up requesting every media file (picture, animation, audio, etc.) on it. Even if the file is minute, it takes time for the request to get to the server, and for the server to process it. Of course, some of this may be alleviated by using cache and GZip compression — and we will discuss this option later — but right now let’s ask a different question. Why do you need all these media files?
And if you have no idea — that’s where you should start.
- Cut down on the images. Unless you are running some sort of image gallery, which is a whole different beast, the number of high-resolution images on your webpage should be as low as possible. Еven the galleries tend to use compressed miniatures as long as they can get away with it and load the full-resolution image only when it is the only notable thing on the page.
- Are you using some simple graphics? Transform them into CSS whenever possible. Also, about CSS — try to combine them whenever you can. A single stylesheet always loads faster, than two similar ones. There is one caveat to that, but we will discuss it a bit lower.
- Reduce scripts. And if you need them — put them at the bottom of the page, so that the user can get at least the web page itself loaded, showing them the progress is being made, while they are waiting for the script to do its magic.
And if you are still making new pages for your website — make these rules your design guidelines. Trust me, it’s better to do something well at the beginning, than try to optimize an already published page.
2. Gotta cache them all!
An outline of the HTTP request with eTags. Each time browser requests a new element, it checks its eTag and downloads it only if it has changed.
Caching is a great thing, because it allows your users’ browsers to load only the parts of the web page that changed since their last visit. Well, ideally. In practice, it is you who determines what parts of the webpage should be marked as cacheable and how long will the cache last. Overextensive caching may break the website’s functionality, but concurrently, usage of cache files will let you shave a couple of seconds from every loading of your website after the first one.
There are a couple of ways to make sure, that the cached files will not interfere with the new ones. The best method is by using ETags, which makes sure that the user always has the most relevant version of the cached file, but it is definitely not the most optimized one.
An outline of the HTTP request with cache expiration dates set up. Each time browser requests a new element, it checks the expiration date and loads the element from cache if it is within it.
Most of the time you can get by with more efficient max-age variables that determine how long the user is allowed to keep his cache. Do not set it too high, since they will still take some space on the user’s hard drive, but do not set it too low either. Preferable settings are 1 week for the high-resolution content and 1 year for the CSS, low-res pictures, etc. And if you want to use caching on the files that may change in the future — that’s when you break out the ETags.
3. GZip it up!
An outline of the HTTP request with GZip compression. Each time browser requests a new page, the server compresses the page using GZIP before sending it to the browser.
Let’s face it, HTML is redundant. Every html-tag has a closing argument that looks almost the same. Thus, the symbols combinations repeat throughout the document constantly. Same thing with content — a vocabulary of any text is usually much smaller than the overall word count.
Which means that those (hyper)texts can be optimized with modern compression techniques. For example, GZip. While it doesn’t work with images, audio and other media — they are usually already compressed with far more efficient, specially developed algorithms — this compression can drastically reduce the size of the page itself.
All computers released in the last 15 years, can compress and decompress GZip on the go, which means that you should use it. 90% of the Internet traffic is compressed with GZip and the number will only grow as we continue to hit the limits of the bandwidth. So enabling this feature on your server/hosting is a must. You can do this easily from cPanel or any other control panel you use.
And if you do not use any panels and prefer to use the console — look up the wiki for your server system for terms like GZip or HTTP Compression. Chances are, you’ll find it — for example, it is definitely supported in Apache, IIS and NGINX. Apache even has a pre-compression mode which allows you to save up on the server resources.
4. Know your PNGs
Comparison between JPG and WEBM. Notice the smaller filesize on the right picture.
GZip is a great tool for compressing HTML, but as we mentioned earlier, media is much trickier. There’s no single magic format efficient in transferring media across the web — instead, it is a choice between a couple of compromises.
For images, the longest still standing standard is JPEG. It is crappy, because you end up with a lot of artifacts (distortions) in the image, but at the same time it is highly efficient when it comes to filesizes.
PNG is yet another popular option, because while it is less efficient than JPEG, it leaves less artifacts and has some direct advantages for web-design, like an ability to have transparency in the image.
Since 2010, Google has been pushing to replace both PNG and JPEG with their own WebP standard, and to be fair — it is pretty impressive both in quality and efficiency sides. I wouldn’t recommend using it in the mobile versions of your website, since not all mobiles have the ability to decode WebP with hardware acceleration and may end up slowing down a lot, but for a desktop version WebP is a great choice. Especially if your website is using only primary colors.
Also, keep in mind the resolution of the image. Basically, the higher the resolution — the better the result, but at the same time the size of the image grows exponentially with its resolution. The best choice would be to make the images Retina-ready. Which means, upload them in two times the size you intend them to be viewed at.
You can also try to decrease the color depth for the simple images, although this might not always pay off. As for photos and other art — that’s completely up to you, but 4096×3072 is a good landmark, if you make sure that there’s only one full-sized image on the given page.
Finally, learn HTML. We will elaborate on this in the next paragraph, but for now — make sure to fill in the img src tags. If you don’t — the page will lag or maybe even break.
As for the audio, if you intend to have one on your website, nothing has changed in the last decade. MP3 is the king of the actual streamable music, while audio effects are better signed off to OGG.
5. Code, do you speak it?
WYSIWYG-editors are an amazing tool for HTML, in fact, I’m writing this article with one such tool called Remarkable. But I will be the first one to say — they are not that great. They considerably simplify the life of a coder, and allow someone who has no idea how to code produce commendable results. But their markdown is far from perfect or even simply efficient.
There are some tools that will help you with optimizing the code provided by your editor — PageSpeed Insights for Chrome will help with HTML, CSS Compressor will be of great help with CSS and Closure Compiler is a must for JavaScript — but the results they produce still far too often fall short from what a skilled coder can do. So while you can definitely get by using them, you also should invest in getting at least some experience in coding. Trust me, it will pay off.
One important thing often forgotten even by experienced web-designers is inline CSS. It’s a faux pas for a reason. Keeping all the CSS-markdown in one external stylesheet and simply calling its parts when they are needed will greatly decrease the size of the page and its overall stability. Also, it will make your HTML code much easier to read.
6. OMG, look, it’s the header!
You won’t see anything like this on Unihost, but that’s how we would do it if we had to.
Sometimes, it is impossible to do something fast. For example, it may be a huge page with a lot of stuff going on, and you just cannot make it load in 2 seconds. Well, here’s a tip — fake it till you make it.
By using a second (although, technically it will be first) external stylesheet that contains only the contents of the top of your page, you will show your user that at least something is happening and they just have to wait a little, until their browser processes the rest. Even if the problem is not with a browser at all, and it is your media-heavy page still transfers its data. It’s the same principle as with making the scripts load last, to be honest — the page is still not ready to be used, but at least it looks like it can, and that’s all that matters.
7. Re-re-re-redirection
An example of the redirect to the mobile website, set up in the hosting dashboard.
How did you implement the mobile version of your website? If it is a responsive CSS design or a dynamic serving system that feeds the users different HTML and CSS depending on their browser — you did well. But if it is a completely separate mobile URL to which your desktop site redirects mobile customers — that was not a good decision.
Basically, a redirect is a yet another series of requests that slow down the experience tremendously. Thankfully, if you are still using them, you will not have to redo your whole website — although, honestly, maybe you should, since responsive design is amazing. Anyway, you can alleviate at least some of the situation with a Googlebot that automatically redirects the mobile visitors using an HTTP-redirect, which is much more efficient than a traditional one. It will require some changes to markup, but nothing too severe.
8. Just change a server
There’s a lot you can do, but sometimes it is not enough. Then, the only way to continue growing is to start somewhere else. I ran into this at one point, when despite all my efforts, I simply couldn’t break a 3-second mark. So upgrading your server, or maybe even changing a hosting company might be what you will have to do.
9. HTTP/2 and the age of the new Web
Not so long ago, HTTP 2.0 (a.k.a. HTTP/2) has been released to the public. And, to be frank, it is a great improvement over the original protocol — even if it has some drawbacks, like mandatory encryption.
What is the most interesting in our case, is that HTTP-requests have become much more efficient in the new protocol — which means that the majority of aforementioned advices are no longer needed.
Unfortunately, some of the hosting companies do not support HTTP/2 at the moment. So until you can transfer, you are stuck with jumping through aforementioned hoops. But for those lucky ones, who have this option — we will review HTTP/2 next week and give you some pointers on to what changes you will have to make to your website.
It’s more what you’d call guidelines…
Do not take these points as the holy Grail of web-optimization. This was not the aim of this article and, frankly, I am way underqualified to write something like that.There definitely are solutions that completely defy my statements and still work.
But if you have zero clue on where to start with your website’s speed-up — I hope my guide have been useful to you.
![[:en] Damian [:ru] Демьян](https://unihost.com/blog/wp-content/uploads/2017/04/1-150x150.jpg){kind=avatar}
