
Google favours websites in its search engine results that it deems to be technically high-quality.
A website is of no use without appropriate content. Therefore, search engine optimisation has traditionally focused on the site's textual content.
However, in 2020, Google announced that it would begin to emphasise user experience in its search results. It justified this decision by noting that users prefer sites that load quickly and work well on mobile devices. Thus, Google has started measuring website performance when assessing its relevance in the search results.
The update focusing on the technical quality of websites has been in production since August. In the midst of these changes, one thing remains unchanged: Google is a monopoly, and the opinions of other search engines hold no practical significance from an optimisation perspective.
Therefore, by today, it's essential to do the homework that King Google has mandated.
Google openly shares how it measures the technical quality of your website
Google benefits from having a wealth of high-quality content online for search engine users to choose from. Thus, Google openly details how it assesses the technical quality of your content and offers correction suggestions specific to your website through the PageSpeed Insights test, which is part of the broader Lighthouse test.
A general practical rule of thumb is that a technically simpler user interface implementation is preferable to a complex one.
How can you test Google's perception of your website's technical quality?
Before delving into the metrics Google uses, it's a good time to set the PageSpeed Insights or the broader Lighthouse test running in the background.
If you want to run the Lighthouse test on your own Chrome browser, open the developer tools on your webpage, select the “Lighthouse” tab, and click “Generate report”. Note that the results of a Lighthouse test run on your own browser are dependent on your workstation's performance. Also, disable ad blockers to see the reality.
The core of technical quality assessment is Core Web Vitals
Core Web Vitals is Google's name for three calculated site metrics that visibly impact the end user's experience.
First, I will list the usual methods and tricks that I assume are already in use from the start:
The server is not a potato assumedly found in a Kyrgyz root cellar, nor is the potato subjected to endless loops of unoptimized database calls or other programming sins.
Appropriate caching solutions are employed for serving the document and its embedded media files.
CSS and JavaScript are minified.
Animations are implemented with CSS rather than with jQuery or similar inventions as was necessary in the past decade.
Your site does not mine cryptocurrency on the end user’s device.
Next, I will attempt to clearly explain what the Core Web Vitals metrics are and what typically hinders them. Although PageSpeed Insights offers direct suggestions such as “reduce unused JavaScript”, “remove render-blocking resources”, and “minimize main thread workload”, understanding what is meant by these and the methods to address the issues may sometimes be elusive.
LCP: Largest Contentful Paint
LCP measures the loading speed of a site. It identifies the largest content element visible on the end user's screen after it loads. Thus, LCP measures the time it takes from opening the site to the rendering of the largest content element on the initial screen view. The goal is 2.5 seconds or less.
Elements considered in LCP calculation include:
<img>
<image> inside an <svg> element
<video>
Elements with a background image
Any block-level element containing text directly or within inline elements.
Common pitfalls include:
An image carousel the size of Vantaa with 26 images that are not lazy-loaded.
A Titanic and Ben Hur mash-up as the site's hero video.
A stock photo of 9001 x 9001 pixel happy hand-wavers in a meeting room shown on a 400 x 800 screen.
How to fix LCP?
Use lazy loading for images that are not immediately visible.
Only load video content after user interaction and carefully consider if a drone-filmed video of your premises costing several thousand euros is a wise investment.
Serve image sizes appropriate for the screen size, for example using the <picture> element.
FID: First Input Delay
FID measures interactivity. Input delay refers to the time it takes from user interaction until the browser starts processing the response. Practically, input delay occurs when the browser has rendered an element but is not ready to handle interactions with it. The goal is 0.1 seconds or less.
In almost every case, it's because the browser is busy crunching through megabytes of JavaScript and cannot respond immediately to user input.
Common pitfalls include:
All JavaScript used on the site is handed to the browser to process, regardless of whether it's useful for that specific page load.
Reinventing browser's natively supported features with custom JavaScript.
Loading a third-party chat service on the site without any user interaction or other indication that it's needed.
Loading unwieldy third-party scripts synchronously in a way that your own site patiently waits its turn.
How to fix FID?
Dynamically include JavaScript on the site natively or using Webpack, for example.
This is almost always the single action that improves the site's performance the most.
Consider putting your site's JavaScript on a diet.
Utilise native browser features. Implement new interfaces for them as lightly as possible.
Carefully consider whether the site's chat tool is such a significant sales tool that it needs to be automatically included with every page load. Try to let the end user choose to use the chat and load the chat script only then.
If third-party scripts are needed, include them early in the HTML document but use the async or defer attribute.
This is also a good way to inadvertently ruin your site's analytics. Load analytics and other user tracking synchronously at the beginning of the HTML document.
If you use Tag Manager or an equivalent product, include the script immediately but take advantage of the above-mentioned attributes.
CLS: Cumulative Layout Shift
CLS measures visual stability of the site. Layout Shift or displacement occurs when elements like text, images, and buttons shift from their original placement as the site loads. The more elements shift, the higher the CLS score. The target is 0.1 or less. Since CLS is predictable and consistent, I don't find it beneficial to explain here how CLS is calculated, but you might want to read Google's description of it. The challenge is to consider CLS habitually before Google penalises it.
Common pitfalls include:
No preallocated space for image-containing elements.
Elements are added to the site only after their content has been fetched asynchronously from somewhere else.
How to fix CLS?
Preallocate space for images either by specifying the display size directly in the element or in CSS.
Include elements reliant on asynchronous content on the server-side and allocate appropriate space for the data to be fetched into them.
Debug CLS using Chrome's developer tools.
When you've configured Chrome to show layout shifts, they will flash blue during page load.
Google also uses other metrics beyond Core Web Vitals to judge your site's performance
FCP: First Contentful Paint
FCP measures how long it takes for the first content element to be rendered on screen. The target is under 1.8 seconds. The most common pitfall here is the slow loading of a font from a third-party service. By using the CSS rule font-display: swap; you notify the browser that it can use a system font while waiting for the final font to load.
On a general level, effectively serving fonts is not very easy. Tips on optimising the loading speed of a font from Google Fonts.
TTI: Time to Interactive
TTI measures how quickly the input delay is below 0.05 seconds. The target is under 3.8 seconds. As executable JavaScript decreases, TTI improves.
Speed Index
Speed Index measures how quickly content is visible. By optimising FCP and TTI, you've effectively optimised the Speed Index. The target is under 3.4 seconds.
TBT: Total Blocking Time
TBT measures the total time during which the site is unable to respond to user inputs. It accounts for all the time the site spends handling inputs lasting over 0.05 s. The target is under 0.2 seconds. Optimising and reducing JavaScript is one way to improve TBT.
PageSpeed Insight is not the only tool Google uses to assess quality
As I've mentioned before, PageSpeed Insight is just part of the broader Lighthouse testing. Lighthouse not only evaluates performance but also accessibility, best practices—practically security and error-free operation—and search-friendliness. Optimising site performance can therefore be packaged as part of broader updates made from a search engine perspective.
Optimising site performance might come at a cost
So why don't all sites deployed by Crasman achieve perfect scores in Google's performance tests? Simply because that's not what our clients purchase from us.
The platform used by the site may affect results
General website management systems like WordPress, Magento, and Hubspot include JavaScript for the site which, as providers, we cannot do anything about. Crasman Stage does not, as such, include JavaScript for the site; it is entirely within the developer's control—except for possible Tag Manager additions.
Ultimately, it's about priorities, finding a golden middle ground and effective use of funds
The pitfalls of modern web development regarding site performance have not arisen by themselves, but from endeavours to meet the needs of website clients and end users.
The budget for developing a large website project remains within the bounds of human comprehension and tolerance only by utilising existing open source code. Chat tools are understood to be beneficial as support for both customer service and sales work. The benefits are perceived to outweigh the drawbacks.
The visual impact of websites is a means to highlight one's brand and distinguish positively from competitors. Advertising on social media is extremely effective but requires various tracking scripts and pixels on your site to work.
It’s important to keep in mind that search engine visibility is only a small part of the overall picture of a website, and in turn, site performance is likewise a small part of that.
The most crucial aspect of all web-based business is ultimately to serve the customer as well as possible by providing them with the content they want. There's also no point in conducting business online if the costs become so high that the commerce it brings doesn't cover them.
PS: If you want to discuss the development of your own web service, click the button below!
{{cta('5da54e68-0866-4977-badb-9170077e3238')}}
Crasman Ltd
25 Nov 2021


