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

Arjen Karel - linkedin

Last update: 2024-07-13

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.

When someone asks me to consult and fix the Core Web Vitals there is always something wrong. Slowness always comes from anti-patterns. For example a 'Lazy Loaded Largest Contentful Paint image', 'Large, un-optimized Images', 'Sliders', 'blocking JavaScript' and so on.

It does not take much to introduce an anti-pattern. Sometimes all you need to do to create an anti pattern is install a plugin or forget about best practices for a short while.

Now I like to categorize these anti-patters into 'slow by mistake' and 'slow by design' because the way I go about fixing these is completely opposite.

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

Web-fonts are great. They will customize and enhance the look and feel of the page. Unfortunately using a third party provider like Google fonts will not optimize the fonts for your specific situation.

Third party fonts will require an extra render-blocking style-sheet, a new connection to a webserver (while you already have this really fast connection to your origin server) and probably will add more fonts to the browser than you actually use.

It would make more sense to self-host your fonts, preload them and assign a custom optimizations strategy to each font file. That is another quick win right there!

3. Third party Scripts

While there is nothing wrong with third party scripts they do cause a lot of issues because of the way they are added to pages. I come across unimportant third party scripts (like the facebook tracking pixels, social media buttons, rating widgets etc) that actually block the entire page.

It is relatively easy and makes sense to defer and schedule these scripts until the browser has done the more important work. In the end I did not really change anything critical to the site, it still looks the same and loads a lot faster. I just changed the order in which things are done.

4. Background images

From a Core Web Vitals perspective background images make little sense. Background images cannot be lazy loaded, they are not responsive and you have little control over their timing and priority.

With a few easy fixes we can transform these background images into normal images that we can lazy load, make responsive and adjust their priority. That will certainly improve the Largest Contentful Paint.

5. Large stylesheets

Stylesheets are render blocking. That means that while the browser is loading the stylesheets the page will remain blanc. There are many things you can do to fix this. For example, remove unused styles, split up the stylesheet, improve browser caching or add Critical CSS.

Once we have improved the stylesheets your Largest Contentful Paint and First Contenful Paint will improve dramatically!

Slow by design

Slow by design is the part that you should be worried about. You made structural choices that slowed down the page. They usually involve UX design choices or JavaScript code that modifies the visible part of the page to such an extent that there are no good workarounds.

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.

1. Sliders

Sliders usually work like this: When the page renders a JavaScript will inject the slider into the page. Without this JavaScript the page will look completely different. This will cause a longer Largest Contentful Paint, probably a Layout Shift and most likely issues with the First Input Delay.

There is no quick fix. Deferring the JavaScript will improve paint metrics but will delay the slider and cause a layout shift. Making the slider script critical will fix the Layout Shift but will slow down the paint metrics.

The solution is to progressively enhance the page. First make sure the slider renders without JavaScript and then enhance the page and transform the already present slider image into a full slider.

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

Product zoom works like this: on your average webshop hover over a product image and you can zoom in on a part of the product. 'Product zooms' usually has the same issue as sliders. A piece of JavaScript code will take your images, hide them, and the re-write them to the page as zoomable images. This will cause a longer Largest Contentful Paint, probably a Layout Shift and most likely issues with the First Input Delay.

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.

3. inline jQuery / inline JavaScript dependencies

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.

Then why did I place this in the 'slow by design' category? When I ask about intent and consideration I usually get 'oh, I don't know'. And that is the real problem. There is a lack of knowledge about how JavaScript works. I can be quite certain that this mistake will be repeated in the future. This means the solution is not the same as the fix. I will need to educate the devteam about JavaScript dependencies and timing.

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.

There is no way around this. We will have to accept some slowness. But there are things we can do. We can make sure the maps are loaded with the highest priority. Usually these pages are not optimized for early JavaScript execution. In this case that was the wrong choice. We need the script to download en execute as early as possible!

6. Slow API's

Slow by design problems that arise from slow API's can usually be found in SPA sites like REACT NextJS or Angular. Slow API's will usually cause large Layout Shifts because components render too late after user interaction. Issues like this usually require a multi team approach

Conclusion

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.