Core Web Vitals - Fundamental Internet Indicators LCP, FID, CLS
Core Web Vitals is a new Google ranking metric. It was announced in mid-2020 and is likely to have an impact on search results, just as Google's Penguin algorithm did in 2012 by removing spam from the web. Why do I make this reference? Because Core Web Vitals as a ranking factor appreciate high-quality websites: fast, efficient, secure, and stable. It will penalize those that are technically unoptimized, have poor UX, are overloaded with unnecessary code, and hosted on slow and unstable servers.
*To clarify, this mainly applies to large websites or extremely unoptimized pages. A typical site with a score of 60:80 on Page Speed, built on WordPress and indexed with site:100, is unlikely to experience any changes.
I believe it is the right moment to consider where your own domain and server are hosted (this was thoroughly explained in the article "How to Check Where a Domain is Registered and Who it Belongs to"). Why? Because a "slip-up" with an unpaid invoice is quite common. This can result in website downtime and, consequently, a sharp drop in rankings. As mentioned earlier, stability is one of the most crucial ranking factors for Google's algorithms.
Core Web Vitals - what is it?
Core Web Vitals largely consists of the following indicators:
- Loading: Largest Contentful Paint (LCP)
- Interactivity: First Input Delay (FID)
- Visual Stability: Cumulative Layout Shift (CLS)
Returning to the question of what CWV is: These are factors that combine user experience, proper and optimal website creation techniques, and improve browsing comfort by penalizing intrusive ads or "jumping" content. The pursuit of Core Web Vitals implementation should not come as a surprise, as the SEO industry has been talking about mobile-friendliness for years, which, in a broader sense, not only means responsiveness but also the use of optimal techniques to minimize loading time and save bandwidth. Why?
The internet on mobile phones is currently fast, and computing power is not at its lowest, but one crucial aspect must not be forgotten, which is the other side of the coin of CWV implementation - the Crawl Budget 🙂 Wondering what the connection is? Let me explain. We need to look at the network from a global perspective (as of January 2, 2021, there were over 1.83 billion websites). This will easily help us understand that a fast and optimized website is a favor to users, but Google, in its own way, seeks to reduce the burden on its servers, which process billions of data during the day. Assuming that 10% of the network optimizes its pages according to the guidelines, the savings for Google would be astronomical. It's worth mentioning that Core Web Vitals indicators are available in Google Search Console.
Search Page Experience - Summary
Largest Contentful Paint (LCP) - Key 2.5 seconds - Core Web Vitals indicators
In practice, LCP measures the time it takes for the largest element of the website to load. This could be an image, video, text, etc. The first 2.5 seconds are crucial; during this time, the website should be ready for the user without elements "jumping" around. The reasons for this have been mentioned above, but it's worth noting that these are just the most likely scenarios.
Largest Contentful Paint - Core Web Vitals factors
Some people might come up with the idea of buying a better hosting service instead of implementing expensive technical optimizations or commissioning a new website. Will such a solution work? Probably not, but at the time of writing this article, we have not conducted definitive tests yet. With a high degree of certainty, I can say that this approach may result in some improvements, but if the scripts are loaded from external sources with overloaded libraries, a fast server won't make much difference since an external factor comes into play. To put it in everyday terms, "putting a Maluch (small car) engine in a Porsche won't make the Porsche fast, despite its aerodynamic shape." Special attention should be paid to implementing whole libraries just to create a slider or a clickable (zoomable) image, or, in the case of WordPress, installing 20 or more plugins.
Impact of Server/Hosting on LCP
In the section directly related to LCP, I mentioned that a better server won't save a poorly designed website, and I stand by that with full responsibility. However, there are special cases where changing the server can significantly improve the situation. You might think, "How is that possible?" This mainly applies to websites that have been technically optimized correctly but still don't yield satisfying results. In such cases, attention should be paid to technical server solutions, and the question to ask is: am I using shared hosting or do I have a dedicated server? The answer is likely shared hosting. This is where the crux of the matter lies. If someone within the same server heavily utilizes their service, sends spam, etc., it will not only heavily burden the server but also provoke Google to impose penalties on the IP address, leading to sharp drops in rankings. The optimal solution is to use dedicated servers, but this comes with high costs - both in terms of purchase and maintenance.
Characteristics of a Good Hosting Service
Above all, it is essential to choose a hosting service with responsive customer support, backed by numerous positive reviews, capable of handling technical issues, and, most importantly, capable of mitigating DDoS-type hacker attacks. Hosting providers nowadays frequently perform data backups for their clients and have tools that speed up data loading, such as LiteSpeed or REDIS in WordPress, as well as the HTTP/2 protocol, which significantly accelerates website performance.
DDoS-type Attack
How to Optimize LCP:
- Fully optimize graphics, use modern and recommended formats such as WebP.
- Optimize server response time.
- Optimize and minify CSS styles and JS code.
First Input Delay (FID) - Action Reaction - Core Web Vitals indicators
First Input Delay, or first input delay. In practice, this means the time it takes for a page to respond after a user interaction, such as clicking on a URL. What is measured here is the time from interaction to full page load.
First Input Delay - Core Web Vitals factors
How to Measure FID:
- A good FID score is equal to or less than 100ms.
- A score needing improvement is between 101-300ms.
- A poor score requiring urgent attention is above 300ms.
According to Google data, poorly optimized and overloaded JavaScript code greatly affects the low FID score. This is mostly relevant to ready-made solutions where a whole library is used to implement a single feature. The browser is blocked while analysing JavaScript code, resulting in delays in responding to user interactions.
How to Optimize FID:
- Break down code into smaller actions, especially JavaScript code
- Use asynchronous loading
- Set and implement loading priority for content
- Move non-interface-related actions out of the main thread
Cumulative Layout Shift (CLS) - Visual Stability - Core Web Vitals Indicators
Cumulative Layout Shift (CLS) measures how much the page layout shifts on the screen due to unexpected events and behaviours. It refers to shifts not caused by user interactions but rather by programming issues.
Identifying what causes layout shift issues can often be done simply by refreshing the page. More detailed analysis can be performed using debugging tools.
Cumulative Layout Shift - Core Web Vitals factors
CLS is rated on a scale:
A score less than or equal to 0.1 is considered good, while a score above 0.25 is considered poor.
CLS view in Google Search Console panel
Most Common Causes of CLS Issues:
- Moving ads that are difficult to disable.
- Images without dimensions (width; height), which is a common programming conflict when current Responsive Web Design (RWD) standards use percentage-based grids, and images should fill a <div> element with a specified size in media queries or grids like Bootstrap. In my opinion, this is a step backwards,Google prefers linearly given sizes, because it does not have to analyze the image itself and CSS code - it has everything given 'on a platter',
- dynamic content, generated with JavaScript code
How to Optimize CLS:
- Avoid using inline styles.
- If your website contains ads, move them from the top of the page to the middle or bottom.
- Embed elements in iframes within <div> or sections with specified dimensions.
- Use images with dimensions specified in the code.
Core Web Vitals Simulator - Lighthouse Scoring Calculator
At this address, there is a tool called Lighthouse Scoring Calculator that allows the simulation of data related to page speed and Core Web Vitals.
Lighthouse Scoring Calculator
PageSpeed Insight
PageSpeed Insight measures the following data:
- PageSpeed Insight measurement data includes the following metrics:
- First Contentful Paint (FCP)
- Speed Index
- Largest Contentful Paint (LCP)
- Time to Interactive (TTI)
- Total Blocking Time (TBT)
- Cumulative Layout Shift (CLS)
PageSpeed Insight - Measurement Metrics
First Contentful Paint (First rendering of content) - FCP
FCP measures the time it takes for the browser to display the first piece of DOM content after a user enters a page. It includes:
- Server response time (TTFB)
- Content loading time and rendering time
Speed Index:
Speed Index is used to measure the visual stability of content while the page is loading. Lighthouse records a video of the page loading and calculates progress between frames.
Opportunities to Improve Speed Index:
- Optimizing JavaScript code
- Optimizing graphics and using "lazy loading"
- Utilizing caching
Time to Interactive (TTI):
TTI is the time it takes for the page to load to a point where users can interact with its visible elements.
Total Blocking Time (TBT):
TBT refers to the total time of blocking caused by loading resources. It has been replaced and replaced with First Input Delay (FID).
Time to First Byte (TTFB):
Time to First Byte is measured in microseconds and was intended to indicate the bottleneck in the page loading process. It measures the time from sending a request to the server until receiving the first byte of data. Although it is a popular way to measure page loading speed, it has nuances that can significantly slow down the process and are not necessarily caused by the server but by incorrect application/website architecture. TTFB is not a suitable way to measure server performance; it is more suitable as a tool to measure page optimization.
Opportunities for TTFB Improvement:
- Optimizing and shortening server response time (TTFB)
- Optimizing website architecture
- Implementing a Content Delivery Network (CDN)
- Avoiding multiple redirects
Tools for Measuring Core Web Vitals and Website Speed
- Google PageSpeed Insights - Paste the website URL and click "ANALYZE" to get a speed chart and technical issues related to code optimization.
- Test My Site with Think with Google - Analyses mobile website speed. Paste the link and click "enter." It also allows comparing the loading speed of your site with competitor sites.
- web.dev - Similar to Page Speed and Lighthouse, this tool checks interaction time, server response, and categories like 'Performance,' 'Accessibility,' 'Best Practices,' and 'SEO.' Web.dev also suggests how to speed up the website.
- WebPage Test - Allows you to choose the location and browser type for conducting tests.
- Pingdom Website Speed Test - A user-friendly tool that indicates loading time, blocking, DNS response, and provides location options.
- Load Impact - Allows you to test website speed depending on the number of visiting users.
- GTMetrix - A highly functional tool for performing significant analyses, including generating PDF reports.
- DotCom - Provides measurements for various locations.
- Monitoring combines data from Page Speed and Lighthouse.
- Sucuri Load Time Tester - Provides information about connection and first-byte download speed from various locations.
- Website Speed Test Uptrends - Presents general page loading time information.
Page Speed Insights - Typical Messages
- Remove unused CSS code
- Minify CSS
- Defer image loading offscreen
- Display images in new-generation formats
- Avoid using passive event listeners to improve scroll performance
- Resize images
- Avoid multiple redirects
- Eliminate render-blocking resources
- Remove unused JavaScript
- Avoid very large network payloads
- Use efficient image formats
- Minimize main-thread work
- Ensure text remains visible during webfont load
- Preload key requests
- Serve static resources with efficient caching policies
- Reduce JavaScript execution time
- Avoid an excessive DOM size
- Avoid chaining critical requests
- Keep the number of requests and transferred data small
- Minify JavaScript
- Enable text compression
- Preconnect to required origins
- Use video formats for animations
- Avoid using document.write().
Summary
Core Web Vitals provide clear signals to website owners on what needs improvement. By using measurement tools like Page Speed or Lighthouse, we get almost "ready-made" information. Google, in an implicit way, encourages website optimization by improving their code, optimizing images, and using only necessary scripts on the page. This will likely lead to greater involvement of SEO specialists in the website creation process. Currently, they are often overlooked, and developers prefer convenient and fast solutions, not necessarily optimal for search engines. As a result, clients receive websites that function but have optimization results like anchors holding the site in SERPs, usually outside the top 10. Of course, there may be underlying reasons; non-optimized websites may need to invest in Google Ads campaigns, which will likely cost more than the optimized competition (Quality Score factor). As a result, Google will compensate for the additional time spent on indexing. After all, websites created for clients are meant to sell, not just exist on the web. It's worth considering Core Web Vitals from the design stage if we aim for our business to be visible and conversion costs to be minimized.
[Update] The data regarding the scoring thresholds for Core Web Vitals indicators has been updated according to Google guidelines from February 17, 2021
Author: Łukasz Pietruszka
