For those willing to optimize Speed

This is my learning with my 2 years old site. With 5 different hosts, 5 different cache plugins, to move my REAL pagespeed from 5 / 6 with frequent higher daily peaks to an average and stable 3 / 3.5.

In 2 years, my website roughly stayed the same. Make it faster was and remains a kind of obsession, though my means are very limited, technically and financially.
About my site: 65% visits on mobile – 30% foreign visitors – 60% of visits on blog and 40% on store – store is my top priority.

In summary, and by priority, the best way to optimise speed:
1. correctly size photos.
2. simplify pages at the max
3. choose the right host, all the more if woocommerce matters
4. lighten the weight of the code to the max, ie eliminate what is useless + all dependencies … defer what it not critic… in js, css, libraries, fonts,
5. use cache plugin
6. use CDN if you can afford and have foreign visitors, it’s useless when free.

Preliminary points about speed tests
– basically, whether you have cable, adsl, 4g or 2g, speed is different. That’s reality
– whether you are local or international, whether your visits are more on mobile or pc, whether your material is new or old, it changes your reality
– You have the tests like pingdom, webpagetest, gtmetrix: they simulate reality with algorithms, without knowing the reality (see next), without entering into the quality of the code. The recommendations are always the same. Most often, you don’t really know what you have to concretely do. The interest is limited.
– google pagespeed is hard, and critized. Since almost everybody use Google analytics and tags, they have all measure on speed, they can make the best algorithms. Further, what Google want, indeed, when you read their guide for speed, you can only agree (ie load first what is visible by user, enable faster interaction with page, mobile first, etc). And since Google rules the world, deny is a non-sense.
– after you have all the tests which audit the code: dareboost, yellowlab.tools, etc. Those don’t measure speed, but tells you what slows down. Interesting, useful and giving insights on which you can easily act
– and then, you have reality, given by google analytics. This is the real speed of the pages for users. You may believe: it depends on mobile, browser, etc… correct, and that’s why you have to see different given pages, that did not change, on long periods. Again here, it’s reality, not algorithms.
– use tools like hotjar is also very helpful to see how people interact with your site, and understand what really matters for your users. And thus, what shall be eliminated
– I tried amp 2 years ago … technically, it’s too complicated for me, but on what I could see, results are amazing. Its loads immediately, the surf can’t be easier, a delight from user perspective.

Started with a basic shared host at 5 Euros per month. My site was slow. Very slow. CC. 6 / 7″ average page load but also incredibly variable.

First winners at this stage by far, by priority (the server / cache is discussed later)
1. correctly size photos. If possible, use webp, checking what shall be the right shrinking for your images (it can be too much, but it’s tuneable)
2. simplify each page to the max, withdraw what is not really necessary. Here, the judge shall not be you, but your visitors !
What means avoid special effects, sliders, special font libraries, icon libraries, … what most pagebuilder or sliders need to work is over-dimensioned compared to what users / visitors really want.
Here, the best way is to be objective and use google tags or hotjar or whatever to see what matters and what is superficial and not impacting
3. Use cache.
For sake of efficiency and simplicity, I would rather recommend wprocket. But wprocket will not help if you use woocommerce (see below) and if your store matters a lot for you.
In my case, the results of cache / wprocket proved visible on simulators like gtmetrix / pingdom … not in really in reality (real records by Google analytics / tags) but it’s hard to see when it’s a shared host.

But my purpose is to be at 3″, and even lower. So, decided to change host: I successively tried Kinsta, Scala, WPX, Cloudways. Proved interesting because they all prefer different caches, have different server config, so I have to learn autoptimize, litespeed cache and W3TC cache, and I could compare with WP rocket, on my own website, test the same pages on the same server with those caches. I did not stay in Kinsta, nor Scala nor WPX, which are more expensive than my original basic shared host, because 1. it did not prove faster with my already optimized website, and 2. there were issues with woocommerce. In short, woocommerce saturate their resources or demand a higher level of resource … which become very very expensive and sometimes not feasible. And this, whatever the cache. And when you enter in depth, or want to make your own server, virtual or not, you discover and learn the importance of server config, it’s about apache, nginx, varnish, memcached, litepeed, … + php workers, ram, cpu, etc.
My learning:
– woocommerce need a specific hosting to be fast. Very very few hosts are really appropriate for woo, that was a big surprise for me.
– the right server is dramatically more impacting than the cache plugin.
– more important than the cache plugin, it’s which cache matches best your server / host, which cache works best in synergy with server (think here about brotli, http/2, litespeed,
– when you go in depth, W3TC cache can be the most efficient but there is a learning curve. When you know how the server works, it’s obvious.
– when you enter in depth, speed optimisation is then about simplifying code.
– simplify code is about eliminating the maximum, and then deferring what is not critic while prioritizing what is critic for user … in fonts, js, css, … in all loaded libraries, … and about eliminating dependencies
– when you compare a simple instruction on a pagebuilder like wpbakery or elementor, vs what is needed with oxygen or livecanvas, well, it’s killing, even for a newbie.

About CDN … it works if you pay for priority. Otherwise, it becomes render-blocking during the most important moments of the day. Plus safety issues, it’s not an easy one.

Hope that it will help some

[Author]

Posts