Slow by mistake vs slow by design
I usually distinguish between slow by mistake and slow by design. Learn how this can help you improve the core web vitals
Slow by mistake vs slow by design.
When you hire me to fix or talk about the Core Web Vitals, at some point, you will hear me talk about slow by mistake vs slow by design. I think it is an critical distinction to make and in this article I will explain how this will help you improve the Core Web Vitals.
Slow by mistake
I love 'slow by mistake' anti patterns. You did something that slowed down the page. You made a mistake. You did not know there is a much faster way of doing this. No worries, I can fix mistakes.
So categorizing these 'mistakes' makes sense. It will give me a list of easy to fix, high impact improvements that I can send to your devteam (or fix myself). There is usually very little discussion needed. Improving these anti-patterns just makes sense from all directions. Once they are fixed the Core Web Vitals will improve.
Here are a few examples of anti-patterns that I come across daily. When I explain what and why I usually get 'ohh , I did not know this would slow down the page'.
1. Non lazy images
The most common anti pattern is non-lazy images. Images that are not lazy loaded will be queued for downloading during the early stages of page loading. This will use network and CPU resources. It does not make sense to assign precious resources to images that are not even visible right?
2. Third party fonts
3. Third party Scripts
4. Background images
5. Large stylesheets
Slow by design
The problem with 'slow by design' is that it is not immediately fixable by making small changes. It requires more planning and rewriting some core site features.
The firs thing I need to do is figure out the intention: Why did you do this? What were the considerations and what exactly did you intend to achieve? And then within those parameters find a better alternative!
Here are some examples of the most common 'slow by design' mistakes.
The fun thing is: 9 times out 10 when I explain this, the site owner immediately suggests to to remove the slider. That is why it is important to ask about the intentions and considerations of these sliders. Usually they 'were just there'.
2. Product zoom
The difference with the slider is that no product owner will never say: "oh just remove this functionality". It is important and increases conversion.
The solution is the same as the slider fix. The zoom script should not hide the original images but extend the product image functionality. Unfortunately the zoom functionality is usually not easily fixed and will require some work to get it just right.
Inline jQuery is a problem that started out as a 'slow by mistake' but got worse over time. About 50% of the sites that I look at suffer from this issue. Because inline scripts depend on an earlier script (usually jQuery) you cannot defer jQuery anymore. This will delay all the paint metrics.
The fix is simple: Just move these scripts to an external script. Now you can defer both jQuery and the custom script.
4. Large (hero) images
Another slow by design problem is large images. Some sites just need to 'wow the audience' with lots of full size images. Imagine that you are selling posters. You would probably want to serve high quality, large images to your visitors. These images, no matter how much you optimize them, will always take a longer time to download then smaller images.
At this point (assuming that the images are all optimized) the only thing that I can do is to see if there is any wiggle room. Do we really need 4k images or would full-hd also suffice?
5. Interactive maps
Another issue that I come across frequently is interactive maps. When a page has an interactive map the whole intention of this page is to make the visitor interact with the map. Obviously it is going to take some time for that map to load.
6. Slow API's
It can de useful to distinguish between slow by mistake and slow by design when it comes to the Core Web Vitals. Slow by mistake is usually easily fixed while slow by design requires a more thorough multi dimensional approach.
I help teams pass the Core Web Vitals:
A slow website is likely to miss out on conversions and revenue. Nearly half of internet searchers don't wait three seconds for a page to load before going to another site. Ask yourself: "Is my site fast enough to convert visitors into customers?"