Google Speed Metrics

Let’s start with Google speed test

While you read this article I will not remind you how important they are, you already know it as you have spent time on reading this. Instead of this, I want to stop on what each of them and how can you achieve a good result overall and in a specific state.

So let’s start from the beginning and go to the google speed test. There are two types of stats for mobile and for PC

In the current article, I will speak only about mobile as when you do all correctly on mobile you will have great results on PC too.

Need to mention that this test is based on inbuilt tool from Chrome browser called Lighthouse. This test consists of two parts, apper one stats based on real users experience which collect by Google. It is the most important part which impacts your ranking and visibility. But not always these stats are available, in case if you have not much traffic it will not show. Main your goal is this:

In Google Search Console you will be able to find how many pages passed it. Yes, every page on the website has its own test results so not only the homepage matter, even more, most of them matter much more, especially blogs.

Little bit more Metrics

Now let’s go to the second part of the Metrics. You will see 5 stats, half year before I wrote this article there were 6, it another one thing that you need to know about google metrics, it is not something which is one time defined and not changeable, it varies and often drastically.

On the right part of the screen above you will see the Expand view button, clicking on it you will be able to read a short or long version that explains each of these tasks. I will not repeat it, just will share my understanding and experience while I work to “green” them for the last 5 years. But first, let me give a general overview.

First of all, need to say that these stats mostly have a value for developers and if you are not one of them you can pass it. While building a page it allows them to check code performance. From my experience, this is not what you take care of after developing.

It is one of the first things which you have to take care when building your project architecture or picking tools for development.

For example, if you build your websites using page builders such as Elementor it is near impossible to reach a green score without black methods. Or if you use tons of plugins for every small thing on the website.

First Contentful Paint. It is what your user first to see, or even may to see as if your page is really fast he/she will even not mention this moment of first content paint. To make it green need allow browsers to concentrate on drawing this first screen without loading unnecessary resources. In most cases, your first screen consists of a header component with logo and website navigation and the next one with text, image CTA. Your code which browsers already receive and start rendering consists of HTML, CSS and JS. In case if you use one big CSS file for all the website browsers need to download it whole and main read and render each line of it to show you the result. The same is right for the js too. The right decision is only one inline CSS and js for these components, the wrong way is to put all of them above but this will cause drastically reduction for another stat – Cumulative Layout Shift(about this I will speak later). Let’s say that we pick styles and js which we need and inline them in the components. Let’s go further and check another page of your website and what we see? slider component on the top of the page. Let’s do another one css inlining? And next, next, next? Check every page and do it separately? In my mind, it hasn’t any reason best to have each component have its own CSS/JS included. Indeed is there a reason to include slider library if a page does not use it?

Largest Contentful Paint. In most cases it is your hero image, sometimes logo and even your title H1. Some advice to meet the best score – is not to use hero image on mobile view. In case if not possible, lazy load it. Don’t forget to make a background of your component in a color that leaves your text visible even when the image is not loaded. Sometimes design heavy use images here need to define what is more important for the project, visual or performing. Sometimes it is impossible to have both.

Total Blocking Time. Right answer here lay in connection of the 2 things:

correct code;
3rd party resources;

Write specific js code and newer make AJAX calls to show the first view, it always has to be pure HTML/CSS/JS. Remember most scripts you can lazy load. Even when Google says that you need to add GTM on the top you can hide it till the user does any interaction with the website. Some GTM data you will lose – people that close websites not doing any interactions, but does it really matter?

Cumulative Layout Shift. This is why we cannot load all CSS/JS after HTML will render. Do you sometimes see page jumping? When the image fully loads it changes the size of the component? It is not just visually bad but has a huge impact on your score. Same be careful with exotic fonts, after they load it can cause jumping too. Sometimes you haven’t another choice as just hardcode some values. And the last one, CSS styles can cause problems. One of the most painful days in my life was looking for the CLS issue. Nothing jumps, nothing rerenders on any browser with hundreds of tests but issues still present in the stats. I cut layouts and found a place where it was a logo image but nothing suspicious. I was near giving up till not doing what I never checked before – CSS styles and saw that for some reason for the image, we have inline-flex and not display block. The day was lost but green score was achieved.
Speed Index. From my experience and opinion, it is some sort of integration of all metrics above.

Why do test results and real-life scores differ?

After publishing a website, many are surprised by the significant differences between Lighthouse results and actual page performance. Everything looks perfect in the test: green indicators, minimal latency, and fast loading. But as soon as the site starts receiving live traffic, new factors emerge that cannot be fully simulated in a lab setting.

Performance is affected by the user’s device, mobile network quality, server geographic location, and even the number of simultaneously open browser tabs. One user accesses the site from a modern smartphone and stable Wi – Fi , while another — with old devices through mobile Internet for city . Google takes into account exactly averaged experience real visitors , therefore final Results may differ from local testing.

To minimize the gap between tests and reality, it’s important to pay attention not only to the code but also to the project’s infrastructure. In most cases, the following help:

Using CDN to speed up content loading;
High-quality hosting with fast server response;
Compress images without loss of quality;
Minimizing the number of third-party services;
Caching of pages and static files.

It’s also important to understand that a perfect 100/100 result isn’t always practical. Sometimes, trying to achieve the absolute maximum can lead to overcomplicated project architecture and poor website maintenance. Maintaining stable performance as traffic grows and content is updated is far more important than constantly chasing a few extra points.

How third-party services affect website performance

Almost every modern website uses external services: analytics, online chats , systems advertising , pixels social networks , maps , widgets , and feedback forms. The problem is that most of them load their own JS files , and Sometimes And whole libraries that directly influence on speed downloads pages .

Developers often optimize their code, minify CSS and images, but then add multiple marketing tools that completely negate the results. This is especially noticeable on mobile devices, where any additional script can significantly increase the overall blocking time and degrade the user experience.

, it is important to regularly audit connected services. If any tool is used rarely or Not brings real benefits business , perhaps from him costs refuse . Many widgets Can load only after the user interacts with the site, and some can be replaced with lighter solutions without losing functionality.

Why Optimization is an Ongoing Process

One of the biggest mistakes website owners make is treating optimization as a one-time task. They launch the site, get good test results, and then forget about performance. However, a few months later, new pages, plugins, advertising tools, and updates appear, which gradually degrade performance.

In addition to changes within the project itself, Google’s requirements are constantly evolving . Metrics are updated, algorithms are becoming stricter, and user expectations are rising. What was considered a fast site two years ago may now be perceived as slow, especially on mobile devices.

To maintain stable performance, it’s helpful to implement regular site maintenance. This typically includes:

Checking key pages after updates;
Monitoring Core Web Vitals in Google Search Console;
Optimization of new images and videos;
Removing unused plugins and scripts;
Periodic speed audit on mobile devices.

In the long run, the projects that win aren’t those that achieve a high test score once, but those that maintain stable performance regardless of the content volume and number of visitors. Website performance isn’t a separate task for the developer, but rather part of the ongoing process of improving product quality.

And finally

Let’s back from the development World to the real life when the website is built and has a green score in the performance test. You push your website live and obviously expect that will have a green score for your website, right? Live will be not so funny if will be all things such easy 🙂 So let’s check the case if not because if yes – nothing to check, you are the happy owner of the optimized website.