{"id":3682,"date":"2021-05-28T14:24:12","date_gmt":"2021-05-28T12:24:12","guid":{"rendered":"https:\/\/green-fields.pl\/lv\/?p=3682"},"modified":"2021-05-28T14:24:12","modified_gmt":"2021-05-28T15:24:12","slug":"core-web-vitals-fundamental-internet-indicators","status":"publish","type":"post","link":"https:\/\/green-fields.pl\/lv\/blog\/core-web-vitals-fundamental-internet-indicators\/","title":{"rendered":"Core Web Vitals - Fundamental Internet Indicators LCP, FID, CLS"},"content":{"rendered":"
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. <\/span><\/p>\n *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.<\/span><\/em><\/p>\n 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<\/a>\"). 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.<\/span><\/p>\n Core Web Vitals largely consists of the following indicators:<\/span><\/p>\n 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? <\/span><\/p>\n 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 \ud83d\ude42 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.<\/span><\/p>\n Search Page Experience - Summary<\/p><\/div>\n 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.<\/span><\/p>\n Largest Contentful Paint - Core Web Vitals factors<\/p><\/div>\n 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.<\/span><\/p>\n 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.<\/span><\/p>\n Characteristics of a Good Hosting Service<\/p><\/div>\n 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.<\/span><\/p>\n DDoS-type Attack<\/p><\/div>\n 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.<\/span><\/p>\n First Input Delay - Core Web Vitals factors<\/p><\/div>\n 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.<\/span><\/p>\n 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.\u00a0<\/span><\/p>\n Identifying what causes layout shift issues can often be done simply by refreshing the page. More detailed analysis can be performed using debugging tools.<\/span><\/p>\n Cumulative Layout Shift - Core Web Vitals factors<\/p><\/div>\n A score less than or equal to 0.1 is considered good, while a score above 0.25 is considered poor.<\/span><\/p>\n CLS view in Google Search Console panel<\/p><\/div>\n At this address<\/a>, there is a tool called Lighthouse Scoring Calculator that allows the simulation of data related to page speed and Core Web Vitals.<\/span><\/p>\n Lighthouse Scoring Calculator<\/p><\/div>\n PageSpeed Insight measures the following data:<\/span><\/p>\n PageSpeed Insight - Measurement Metrics<\/p><\/div>\n 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:<\/span><\/p>\n 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.<\/span><\/p>\n TTI is the time it takes for the page to load to a point where users can interact with its visible elements.<\/span><\/p>\n TBT refers to the total time of blocking caused by loading resources. It has been replaced and replaced with First Input Delay (FID).<\/span><\/p>\n 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.<\/span><\/p>\nCore Web Vitals - what is it?<\/span><\/h2>\n
\n
<\/a>
Largest Contentful Paint (LCP) - Key 2.5 seconds - Core Web Vitals indicators<\/span><\/h2>\n
<\/a>
Impact of Server\/Hosting on LCP<\/span><\/h3>\n
<\/a>
<\/a>
How to Optimize LCP:<\/span><\/h3>\n
\n
First Input Delay (FID) - Action Reaction - Core Web Vitals indicators<\/span><\/h2>\n
<\/a>
How to Measure FID:<\/span><\/h3>\n
\n
How to Optimize FID:<\/span><\/h3>\n
\n
Cumulative Layout Shift (CLS) - Visual Stability - Core Web Vitals Indicators<\/span><\/h2>\n
<\/a>
CLS is rated on a scale:<\/span><\/h3>\n
<\/a>
Most Common Causes of CLS Issues:\u00a0<\/span><\/h3>\n
\n
How to Optimize CLS:<\/span><\/h3>\n
\n
Core Web Vitals Simulator - Lighthouse Scoring Calculator<\/span><\/h2>\n
<\/a>
PageSpeed Insight<\/span>\u00a0<\/span><\/h2>\n
\n
<\/a>
First Contentful Paint (First rendering of content) - FCP<\/span><\/h2>\n
\n
Speed Index:<\/span><\/h2>\n
Opportunities to Improve Speed Index:<\/span><\/h3>\n
\n
Time to Interactive (TTI):<\/span><\/h2>\n
Total Blocking Time (TBT):<\/span><\/h2>\n
Time to First Byte (TTFB):<\/span><\/h2>\n
Opportunities for TTFB Improvement:<\/span><\/h3>\n
\n
Tools for Measuring Core Web Vitals and Website Speed<\/span><\/h2>\n
\n
Page Speed Insights - Typical Messages<\/span><\/h2>\n
\n