Analyzing and optimizing performance of a WordPress website


Image compression

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.

losslessVsLossy Analyzing and optimizing performance of a WordPress website image

Compressed and uncompressed images compared

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. .

When looking at the images, it strikes me that, of the JavaScript files, the JQuery is particularly quite large. JQuery is kind of the Swiss army knife for interactive elements on websites, and therefore not easily discarded. In many cases JavaScript can be condensed using a tool such as minify. Unfortunately, in the case with JQuery, this is has already been done, so we cannot win much in terms of data reduction there. however, there is another strategy possible here, namely using the Jquery file hosted by Google as part of their Hosted Libraries. The file does not get smaller, but the delivery by the Google network is in general very fast . Also, because many other sites use Google Hosted JQuery, there is a good chance that the file is already cached in your browser.

Using the optimizations discussed together with a few other minor tweaks, we arrive at the results in the table below :

Original Optimized
HTML 6.15 k 5.86 k
images 776.08 k 374.24 k
Javascript 82.72 k 74.27 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 to further analyze the load-time of the 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!

waterfall 1 Amsterdam un optimized Analyzing and optimizing performance of a WordPress website image

Waterfall chart of loading times by unoptimized WordPress website

The Color coding in the waterfall charts is explained in the legend below
legenda Analyzing and optimizing performance of a WordPress website image

waterfall 1 Amsterdam optimized Analyzing and optimizing performance of a WordPress website image

Waterfall chart of loading times by optimized WordPress website

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.

waterfall 2 Amsterdam un optimized1 Analyzing and optimizing performance of a WordPress website image

Waterfall chart of loading times by optimized WordPress website when loaded for a second time

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 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.

Leave a Reply

Required fields are marked *.