How to score 100 on the Google Speed Test.How to create better web vitals with WordPress themes and plugins. ‘Checklist for developers’.

This post explains how to get a score of 100 on the google speed test.

1.Files

You need to check the files loaded on your site by the theme and plugins.To do this, go to Google Speed Test and check your site.

pagespeed.web.dev

PageSpeed Insights

https://pagespeed.web.dev

Click on the button ‘VIEW TREEMAP’.Click on the button to find the slowest file.

One of the most common things we see is icon fonts.Many developers do not want to create an optimised custom icon font library and use the FontAwesome library to the full.

FontAwesome icons are getting bigger and bigger with every version.So we created our own icon font bundle.The result was a reduction in size to about 1/5th.

2.Fonts and typography

This is the second most common reason for poor web vitality scores.Many themes use at least three custom fonts.This is too many.In our case we used Roboto fonts, but found that a combination of system fonts could be substituted.

Here are some examples.

body{font-family:Roboto,"Helvetica Neue",-apple-system,system-ui,BlinkMacSystemFont,"Segoe UI",Oxygen-Sans,sans-serif;}

Using this fallback font instead of an external Roboto font saves nearly 100 kb and requires only one external request.

※We have found that even the most popular page builder, Elementor, uses external Roboto fonts.Open the Global Font Options and disable Roboto fonts in all global font options.

3.CSS framework

Most themes use Bootstrap, Materialise, Foundary or other frameworks.It certainly makes sense, as the frameworks have all the useful styles and you don’t have to create new styles over and over again for new blocks.However, this comes at a cost: Bootstrap has a minimum of 200kb in basic styles.We considered using a customised Bootstrap, but instead of adding all the styles together, we only added the styles we currently need.

Example – Bootstrap has a number of styles for controlling mobile margins.For example, you can add a 10px right margin only on mobile, or a 10px right margin only on tablet.However, such styles are never used – 99.99% of the time, when building a mobile site, all elements are stacked at the bottom, with margins only at the bottom.So we have added styles to the mobile bottom margin only.

As a result, the general style framework has gone from 200kb to 20kb.At the same time, you are not restricted to using flexboxes or other common systems, and can use CSS grids and other experimental features without having to wait for updates to Bootstrap or other frameworks.

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  grid-gap: 10px;
}

This code takes all the internal blocks of the “grid” container, arranges them as columns with gaps, responsive style, and auto-fits them to the width of the blocks.

This is just an example, you can also find the latest one-line solution by css in the following video.

4.Conditional asset loading

99% of developers do not seem to care about this.Explain what conditional asset loading is.

Suppose a theme or plugin has a special block.Most developers create styles and scripts for this block and load them directly when the plugin is installed.This is a big mistake.Developers need to break everything down into logical blocks and create a file for each of these blocks.

Previously, before web vitals were required, google and gtmetrix reduced scores if the browser made too many requests to a file.All developers tried to add all scripts and files to one file.But now it is different. google wants to reduce the file size instead of reducing the number of requests.So we split all scripts and styles into logical parts and separate files.Even if it is just a few lines of code.We created separate styles and scripts for all blocks, widgets, modules, shortcodes and Gutenberg blocks, and only enabled them if the block was used on the page.This saved 120kb.

Here, one major issue needs to be discussed.What to do about conditional asset loading?The question is.

WordPress provides several functions for loading and registering styles and scripts (wp_enqueue…)..For conditional asset loading, there are the wp_add_inline_script and wp_add_inline_css functions.These are very useful, but need to be assigned to other files.This means that they cannot be used as stand-alone render functions.

Things get even worse if you use wp_enqueue_style in your template parts.The problem lies in where WordPress loads the style file when you request it in a template.They are loaded in the footer and cause huge CLS (layout shifting errors) in the web vitals.So, to avoid style glitches and misalignments, styles should be conditionally loaded before the content, without render blocking.

Unfortunately, the core of WordPress does not have such a function.We have created some of our own functions and use them appropriately in different places.Here is the logic

Inline styles

Many people write that inline styles should not be used, but we disagree.Inline styles are very fast and are the best way to go if you don’t have too much code.It is especially useful if there are options for simple customisation.The following code will do the trick.

<div style="background:red">Red bg</div>

Inline scope

Again, inline styles are used, but as a separate block.

<div class="red"><style scoped>.red{background:red}</style>My red block</div>

It may not be the best solution, but we use this option when we have a few lines of code that only need to be used for special blocks.It allows us to add conditional styles and prevents incompatibility with CLS and cache plugins.I try not to use this option too often, but if you need to create a custom template part with a custom style that is different from the global part, I have found this option to be the best option.

Using transients to store conditions

This is a more elegant solution for conditional loading.For example, suppose you have a template part that renders a post-grid.However, you do not want to add the style of this block to the common styles.Maybe the user wants to display a list instead of a grid.

We will therefore create a transient.We will call this ‘condition_asset’.

In the template part, retrieve this conditional_asset transient and add the block name.

The wp_head hook then checks this transient and renders the style in the header if there is a block name in it.If you set the transient cache to 1 day, if you remove this block from the page, the transient will be deleted and not re-stored, so the style will not be loaded.

Checking by name for loading

Here are some great hacks we often use.If content blocks (gutenberg, shortcodes, page builder blocks, etc.) are stored in your content, you can easily check with the stripos php function.

global $post;
$postcontent = $post->post_content;
if(stripos($post_content, 'boxnumber') === 0){
echo '';
}

The code checks whether the page has a block with a class, id and word ‘boxnumber’ and, if OK, can load a conditional style.

5.Image loading

This is the weakest part of WordPress: it lacks a good resizer functionality.Therefore, as a theme or plugin developer, you have few options.

• You can use your own custom resizers (but this can cause problems for some CDNs and cache plugins).
• Custom size of images You can register add_image_size, which will generate a separate copy of all uploaded images, even if they are not used on the page.
• Customised delayed loading of images.

We eventually decided to adopt a hybrid approach.For small images and blocks that are not used much on the client’s site, we used our own resizer – even if it is incompatible with CDNs and plugins, there is little chance that the client will use this block on a site with a custom CDN, and if there are problems, they can use anotherwidget or block could be used.

For most common blocks and product loops, we created some predefined sizes for images, allowing us to add custom lazy loading for images, custom fallbacks for images, support for Ajaxed parts, normal WordPress functionsWe added a special wrapper around the

WordPress 5.5 and later allows delayed loading of internal images.

This fixes problems with various types of google warnings about image sizes.However, when using images on the first screen, google runs all scripts before checking the page on the first screen.This means that if you display a large, full width image at the top of the page, the LCP will become too large and can hardly cope.

So even if there is a delayed load, we recommend not using large images on the first screen.For this purpose, we have created a number of article layouts that display small feature images.We have also created special layouts that do not display any feature images and still look good.

6.Loading scripts on user interaction

We have found that some blocks have a greater impact on speed than others.For example, blocks with third-party libraries can significantly slow down a site.This is particularly problematic if the block does not have significant value on the page.For example, autoplay videos, lottie files or 3D objects.So we found a special option in javascript that allows us to load scripts only for user interactions.

When the user opens the page, this block is hidden and no script is loaded.However, when the user starts scrolling, the script is loaded in the background.When the user reaches this block, the script is fully loaded and available.

This is an example of such a function in Javascript.

        const body = document.body;
        var loadedtdel = false;
    
        const onInteraction = () => {
          if (loadedtdel === true) {
            return;
          }
          loadedtdel = true;
          const modelViewerScript = document.createElement("script"); 
          modelViewerScript.type = "module";
          modelViewerScript.src = "https://site.com/js/js/model-viewer.min.js"; 
          body.appendChild(modelViewerScript);
        };

        body.addEventListener("mouseover", onInteraction, {once:true});
        body.addEventListener("touchmove", onInteraction, {once:true});
        body.addEventListener("scroll", onInteraction, {once:true});
        body.addEventListener("keydown", onInteraction, {once:true});

Here, the script model-viewer.min.js is loaded only on scroll, touch and key press.

7.Optimization for animations

Most developers use CSS animation libraries or create their own CSS animations.Indeed, they are easy to use and good for development.However, it is not good in terms of speed, as additional styles (typically 50-150 kb) need to be loaded.We used GSAP instead, which is the most optimised animated JavaScript library.In some scenarios it is very powerful, even faster than CSS conversion.We have added the WOW animation framework and can see in the demo many powerful animations that are very smooth and without rendering blocks.

If you only need a few animations, css is fine, but if you want to create a complex theme with many different micro animations, try using GSAP, Anime.js or another javascript library.

8.Cache plugins

Finally, without a reasonable and good set-up cash system, it is impossible to score 100 points.We hope you understand this.

Conclusion

These are the methods we used to improve our web vitals with themes and plugins.However, themes and plugins are only 30-50% of the speed score.The other 50% is hosting and cache optimisation.One thing that needs to be checked in hosting is the TTFB – if it is more than 100 ms, you may want to change hosting or add Cloudflare.For example, if the server you are using is in Japan, the TTFB (Time To First Byte) will be too large for users from Europe.This is not a problem if your site is aimed at Japan, but a big problem if it is aimed at users from all over the world.We hope that the above will help improve your site’s web vitality.Thank you for reading to the end.