The main culprit turns out to be the image at the top of the page, which is almost 0.5 MB large. I used the PNG file format because it lossless and not patented like the GIF format. Although the image is compressed, it uses the DEFLATE algorithm which works well, mainly for large areas of the same color. In our case, the image has too much detail to work well, when compared to JPG compression. When I use JPG compression and allow some loss of quality (quality=60%), the file size decreases to about 20% of the PNG, that is 90 KB. Unfortunately, this does come at a price, and if you look closely at the images a difference in quality can clearly be seen. Below you see a zoomed in part of the image before and after lossy JPG compression.
The edges you see are typical for sharp transitions in JPG images and have to do with the way that .jpg encrypts information. As the famous Dutch football player Johan Cruijf said “Je gaat het pas zien als je het door hebt.” If you pay attention to it, you will notice these artifacts everywhere on the internet (as well as in in PowerPoint presentations, local newspapers, etc).
In our image the artifacts are still fairly minor, but the following video demonstrates what the compounded error is, when you open and save a JPG file 600 with varying quality setting. .
Using the optimizations discussed together with a few other minor tweaks, we arrive at the results in the table below :
|HTML||6.15 k||5.86 k|
|images||776.08 k||374.24 k|
|CSS||9.31 k||9.31 k|
|Total||874.26 k||463.67 k|
The total amount of data traffic has now halved, and that’s almost fully due to the image compression. But does this really result in a aster loading website? The answer is clearly yes: I used the really nice service provided by Webpagetest.org to further analyze the load-time of the thijs.elenbaas.net frontpage, and the results shows that the old PNG file (thijs.elenbaas1.png in the waterfall below) took 5.5 sec to load, While the new JPG file (thijs.elenbaas.jpg in the the second waterfall chart) takes only 0.9 sec to load!
The Color coding in the waterfall charts is explained in the legend below
And here is our first real gain: the total loading time of the webpages and all elements went down from 9 sec to somewhat less than 5 sec! We should consider, though, that this is based on a single sample, and that due to many factors, both in the web-server and external, considerable variations can arise. But as we will be looking further at these kinds of waterfall charts, we will see that this trend persists. But first, let’s look at what happens when we load the page for a second time. The waterfall chart is looking a completely different. The reason is that most of the files in the Web browser are already cached, so loading is done locally. This makes the reduced file size of the image no longer relevant.
What stands out is that the HTML (item 1) is loaded quite quickly but takes almost 1 sec to be fully rendered. This can be due to the complexity of webpage or because the Webpagetest.org servers are strained, but I believe the most likely reason is that takes this time for all the HTML code to come in. We will get back to that in a minute. Another slow loader is the google-analytics…..gif image. This image is used by Google Analytics to keep track of site visits to site visits. Oddly enough, there seems to be excessive amount of time spend in the DNS resolution, that is translating domain name to IP address. We could try and see what happens if we directly use the IP address, but I decided against it because that would not work well with the dynamic load balancing stuff that Google may use.