Chapter 4 - Core Web Vitals and Page Experience Optimization

Core Web Vitals is not just about page speed!

It is a combination of page speed optimization, safe-browsing, adoption of proper monetization policies and ad placements within the context of the Page Experience algorithm and score. 

Core Web Vitals has different thresholds to pass in each of these areas in order to get a passing grade from the Page Experience Algorithm.

A page optimized for Core Web Vitals can be effectively ‘labelled’ as providing a “Good Experience” within the scope of Google’s Page Experience algorithm and help it to get a better ranking for competitive queries.

In this article, definitions of Core Web Vitals elements, optimization methods, and instructions for preparing a website for the Page Experience algorithm will be explained.

Core Web Vitals Representation and Thresholds

1. What are the Core Web Vitals Elements?

Core Web Vitals elements that need to be optimized within the scope of the Page Experience Algorithm of Google are listed below.

  1. Largest Contentful Paint (Perceived Page Speed)
  2. First Input Delay (Loading Responsiveness)
  3. Cumulative Layout Shift (Visual Stability)
  4. HTTPS (Safe Browsing)
  5. Responsive Design (Mobile-friendliness)
  6. Interstitials (User Experience)

2. How to Optimize Core Web Vitals?

To optimize Core Web Vitals, Pagespeed, User Experience, and Web Security should also be optimized. In this section, advice for optimizing for Core Web Vitals also includes these three different aspects (Pagespeed, Safe Browsing, and User Experience) and their related sub-sections.

2.1. Optimize Largest Contentful Paint (Perceived Page Speed)

A Core Web Vitals metric that measures the occurrence of the largest content elements in the viewport is the Largest Contentful Paint (LCP). This can be used to determine when all the content of the page has been rendered. Slow server response times are the most common cause of poor LCP.


Koray Tuğberk GÜBÜR

Technical SEO Executive at Vinterior

During the pandemic, Koray Tuğberk GÜBÜR created his own company, learned Python and ReactJS (Beginning Level), published Semantic SEO Case Studies, performed a webinar with RankSense, hired two employees and launched 9 SEO Projects. Koray believes that SEO is the intersection of Marketing and Coding with a creative mind and growth hacking love. Therefore his symbol is “” which means “Marketing” as a web component with HTML Tags. He spends his time learning new things and methods, working on his coding skills, attending meetings, and educating his team. In the future, he will be publishing a new SEO Case Studies with the things he loves most about SEO! He has been chosen as a finalist for European Search Awards, included in the Top 202 SEO Experts list of SEJ, and Aleyda’s curation. There have been plenty of good things keeping Koray busy during this tricky time.

Watch our Tea Time SEO session here:

Table of Contents

2.1.1. Which Other Pagespeed Metrics are Related to the Largest Contentful Paint?

To optimize Largest Contentful Paint (LCP), the related page speed metrics should be optimized too, such as First Paint, First Meaningful-Significant Paint, or Time to First Byte. 

A page speed metric might not be included in the Core Web Vitals directly, but in an indirect way, they can affect the direct Core Web Vitals signals such as User Experience. Every page speed metric is connected to another one in terms of page loading performance, thus the Largest Contentful Paint optimization in the scope of Core Web Vitals should be evaluated with related page speed metrics and not in isolation

2.1.2. What is the Weight of the Largest Contentful Paint for the Lighthouse Pagespeed Audits?

The largest Contentful Paint has 25% weight for the end score of the Lighthouse Pagespeed Test in the v7.

2.1.3. Why is Largest Contentful Paint Included into the Core Web Vitals?

  1. The Largest Contentful Paint is included in the Core Web Vitals because it is a central page speed metric, in other words, a page with a good LCP Score should also have a good First Contentful Paint, Speed Index, and Time to First Byte score.
  2. The largest Contentful Paint has a 25% weight on the Lighthouse Pagespeed Test Results.
  3. The largest Contentful Paint can be measured with the lab tests.

2.1.4. Why is Total Blocking Time not Included in the Core Web Vitals?

The second most important Lighthouse page speed metric is the Total Blocking Time with another 25% weight, but Total Blocking Time (TBT) is not included in the Core Web Vitals since it can’t be measured in page speed tests in a proper way. Total Blocking Time can be understood correctly via Real User Metrics (RUM), not with the lab data. Thus, unlike Largest Contentful Paint, it is not included in the Core Web Vitals. In this context, Largest Contentful Paint is included in the Page Experience Algorithm within the scope of Core Web Vitals (CWV), not just because it is effective, but also because it can be measured without the need of RUM. For a Search Engine, it is easier to measure, but also it has a contextual functionality for evaluating the web page.


2.1.5. How Largest Contentful Paint has a Context Signal for a Web Page?

Largest Contentful Paint is important for the initial contact section of a web page, and above the fold section of a document. The largest visible element of the initial contact section of a webpage also identifies the web page’s purpose, characteristics, and relevance for certain queries, or industries. So, in other words, LCP is a metric for page speed, but Largest Content (LC) is also a contextual signal for the search engines.


Also, the initial contact section of the web page communicates with the users to define the purpose of the web page. To understand the importance of web page layout and its meanings, signals for search engines you can read the related documentation. And, a slow LCP might dilute the context of the web page layout or the initial contact section for users’ perception, and indirectly search engines.

2.1.6. How is the LCP Element of the Web Page Determined?

To determine the LCP Element of the web page, the browser tries to choose the biggest “HTML div” element. But, also visual completeness and being visible are the most vital factors to determine the Largest Contentful Paint element. Knowing how the LCP Element has been chosen is helpful for optimizing LCP and understanding the browser’s working principles. 

  1. If an HTML Div element is selected as the LCP Element for a long time while the web page is loading, the browser may not be able to select a larger HTML Div Element that is loaded later as the LCP Element.
  2. An HTML Div Element that contains the three major HTML Div Elements cannot be an LCP Element versus a single element as big as one of each of the three parts.
  3. LCP Elements with an Image can be changed based on the image resizing during the web page loading. If the image is smaller than the other candidates, the LCP HTML Element can change too.
  4. If the Image Elements are resized, the smallest size will be considered for LCP Determination.

2.1.7. Which Elements can be chosen as an LCP Element?

LCP Elements can be chosen among the HTML Element types below.

  1. Image Elements
  2. Text Elements
  3. Video Poster Images
  4. HTML Elements with CSS Background Images

In the future, video and SVG elements will be accounted for in the LCP determination.

2.1.8. How to Optimize Largest Contentful Paint?

To optimize the Largest Contentful Paint, the methods below can be used.

  1. Use Critical CSS.
  2. Shorten the Critical Rendering Path.
  3. Use better technologies for server-side compressions, such as Brotli.
  4. Optimize your TCP Slow Start.
  5. Use Asynchronous CSS.
  6. Defer all of the non-content JS.
  7. Decrease the Layer Count to be rendered.
  8. Decrease the DOM Size.
  9. Use Shadow DOM.
  10. Use Service Worker.
  11. Optimize the HTTP Cache Strategy by using Browser-side Caching.
  12. Use Varnish-like layers.
  13. Clean all the unused CSS and JS codes.
  14. Reduce the Request Count by creating bundles.
  15. Use font-variables.
  16. Delay the rendering of the below the fold.
  17. Use HTTP 2.1 or HTTP QUIC for better RTT.
  18. Compress all of the images by cleaning unnecessary pixels.
  19. Compress and Minify the HTML, CSS, JS.
  20. Use AVIF, WebP, or JPEG XL for images.
  21. Compress videos, and do not use GIF.
  22. Use Adaptive Serving for the slow connections.
  23. Use browser hints such as preload, or preconnect.
  24. Decrease the DNS Resolution need by decreasing the size of the resource map.

2.1.9. What are the main causes of the slow LCP?

The main reasons for the slow LCP are listed below.

  1. Slow server connection.
  2. An excessive DOM Size.
  3. Unnecessarily big and prioritized non-content-related third-party scripts.
  4. Bad resource load order.

2.1.10. When the LCP is announced by Google?

The largest Contentful Paint (LCP) has been announced at the end of 2018 within the Github Lighthouse repository. But, it was not an official announcement. It has been used during the development process of these new concepts of page speed. 

The next sentences will include opinions about the process of the LCP announcement.

In 2019, Bartosz Goralewicz published a video and announced that LCP will change page speed optimization in the future. I was one of the first people who watched this video. And, I must thank him for publishing this awesome and brief video. During the coming weeks, I have researched the Lighthouse repository of Google on Github to learn more, and I have written an article called Advanced Page Speed Metrics, because “Core Web Vitals” was not a concept or term at this time. I think this was  one of the first articles about Largest Contentful Paint and other new and modern page speed metrics.


2.1.11. What are the LCP Thresholds for Core Web Vitals?

LCP Thresholds are listed below.

  1. Below 2.5 seconds is fast.
  2. Between 2.5 seconds and 4 seconds is average.
  3. Above 4 seconds is bad.

To have a passing score for the LCP, 75% of the users should experience a faster LCP than 2.5 seconds in the Chrome User Experience report.

2.1.12. What Can You Do If You Can’t Beat the LCP Threshold for Core Web Vitals?

Despite every page speed optimization methodology, if the LCP couldn’t be optimized, changing the LCP content can help. From an image to a text, or to another image the LCP scores can be optimized. And, sometimes changing the design, the layout, or removing some unnecessary web page weights can help to optimize LCP. So, if you can’t optimize LCP for an LCP Element, you can change the element itself to optimize it.

2.2. Optimize First Input Delay

First Input Delay (FID) is related to the load responsiveness. FID measures the time difference between the input of the user and the event that happens after the input. FID is important to diagnose the web pages that are not responsive during the web page loading process. A web page can be loaded fast, but still, it might not respond to the user’s interaction. In this context, loading the content fast wouldn’t have a meaningful impact on the user experience.


A representation of the first input delay

2.2.1. When Does the FID Happen?

During the web page loading process, many CPU bottlenecks can happen. If there is no proper compression, minifying, or resource load order optimization for a web page, the main thread of the browser can have bottlenecks. This situation prevents the web page from responding to user’s interactions.

If there are too many long tasks (tasks that are longer than 40ms), the first input delay can happen more. And, if the long tasks happen frequently during the web page loading process, the FID can happen continuously, and the web page might not be able to satisfy the visit intent of the user.

Note: The event itself is not included in the First Input Delay measurement. Only the input and reaction time difference is included for the FID measurement.


Even if there is no FID data within the lab tests, you can check the Long Tasks from a web page speed and loading performance test.

2.2.2. What Happens if there is no Input Event for the FID Measurement?

If there is no input on the web page, there is no measurement for the FID. Every input doesn’t create an input latency or input delay. And sometimes, users do not interact with the web page in terms of input events. In this context, if there is no input event, there is no input delay, and there is no FID Measurement.

Note: The sessions without an FID Measurement won’t be included in the FID Score calculation.

2.2.3. What are the Other Related Page Speed Metrics for FID?

The related page speed metrics for FID are listed below.

  1. Time To Interactive
  2. Total Blocking Time

Time to Interactive measures when the web page is fully responsive for any interaction from the users while Total Blocking Time is the sum of the Long Tasks during the web page loading process. TBT, FID, and TTI are the page speed metrics for the loading responsiveness and runtime responsiveness.

2.2.4. What are the FID Thresholds?

The thresholds for the FID are below.

  1. Below 100 MS is good.
  2. Between 100 MS and 300 MS are average.
  3. Over the 300 MS are bad.

To pass the FID Score threshold, 75% of the users should have a good FID experience in the context of Core Web Vitals.


2.2.5. What are the Input Elements?

The input elements are listed below.

  1. <input>
  2. <textarea>
  3. <option>
  4. <a>

Note: Scrolling and zooming are not measured in the FID. Because scrolling and zooming are not input events.

2.2.6. How to Optimize First Input Delay?

Methods to optimize First Input Delay have been listed below.

  1. Try to use advanced module bundlers such as Webpack.
  2. Decrease the third-party script count.
  3. Optimize the resource load order for giving the main thread idle times so that it can respond to the user.
  4. Optimize the server response timing
  5. Implement code-splitting for the assets.
  6. Use Javascript Tree Shaking for better loading responsiveness.

2.2.7. Why is FID important?

FID is an important user-centric web page loading performance metric because it measures the responsiveness of the web page. Every query has a need behind it. Every click on the SERP has a purpose. And, to satisfy the needs behind the query, and clicks on the SERP, a web page should be able to respond quickly. Even if the page is fast, the content is high quality and the source is reliable, it all counts for little if the web page cannot be used properly, as it cannot satisfy users.

FID is insurance for the Search Engines to keep the SERP full of high quality pages that can respond to the users. And, if a web page cannot respond to the users, its quality or reliability can be hindered in the eyes of the search engine, since it is not as useful to a user as it could be.


Paul Irish from Chrome Dev Summit 2018 while showing the concept of First Input Delay

2.3. Optimize Cumulative Layout Shift

Cumulative Layout Shift is to measure the layout shift of the web page elements during the lifespan of the webpage and a user’s session. Cumulative Layout shift is a user-centric web page loading performance metric that focuses on visual stability. And, any moving web page element after being loaded and being visible will be included in the Cumulative Layout Shift (CLS) measurement.

2.3.1. How to Measure Cumulative Layout Shift?

Cumulative Layout Shift can be measured by the Layout Installability API. Below, you can find the CLS Formula for measuring it.

layout shift score = impact fraction * distance fraction

To understand how to measure Cumulative Layout Shift, the Impact Fraction and the Distance Fraction terms should be defined.


A representation of the Cumulative Layout Shift

2.3.2. What is Impact Fraction in the Context of CLS?

CLS is a way to measure layout instability by looking at how much of a visual area of the screen is impacted as the page changes when loading.

It does this in 3 stages; firstly by measuring all elements that shift on the page; and secondly by measuring the Impact Region (comparing the visual area before and after) and finally by comparing this to the viewport.

Impact Region / Viewport = Impact Fraction

So, Impact Fraction measures how much the page moves in relation to the size of the screen that the website is being loaded on. This is important as a big movement on a small screen is far worse than a small movement on a big screen.

As an example calculation for the Impact Fraction, if a web page element covers 30% of the screen, after the layout shift event, the web page element’s new position and old position will be unified, and the screen coverage ratio will be measured again. In this context, the new and the old place for the same web page element can have 60% of the screen at the top. And, it means that the impact fraction is 0.75.

In this context, because of how big the web page element is, the layout shift will create greater Impact Fraction.


Impact Fraction Example from Google Devs

2.3.3. What is the Distance Fraction?

Distance fraction is not related to the size of the web page element or the area that it covers, but it is related to the distance from the web page element to the viewport’s edges according to its biggest dimension. For instance, if a web page element is higher than its width, its layout shift event’s distance fraction will be measured based on the vertical distance.

As an example calculation for the distance fraction, if a web page element is at the top section of the viewport, the web page element’s height is greater than its width, and if it moves 30% to down during a layout shift event, its’ Distance Fraction score will be 0.30.

In this context, if the Impact Fraction isr 0.75 and the Distance Fraction is 0.30, the layout shift score will be calculated as below.

Layout shift score 0.225 = 0.30 (Distance Fraction) * 0.75 (Impact Fraction)

Cumulative Layout Shift Score is the sum of all of the layout shift scores.


Distance Fraction example from Google Devs

2.3.4. What are the CLS Thresholds?

The Cumulative Layout Shift Thresholds are listed below.

  1. Below 0.1 is good.
  2. Between 01 and 0.25 is average.
  3. Above 0.25 is bad.

Note: Cumulative Layout Shift can happen in the direction of vertical moves or horizontal moves.


Cumulative Layout Shift Thresholds from Google

2.3.5. Is Every Layout Shift Included in the CLS?

No, not every layout shift is not included in the CLS measurement. Only the unexpected layout shift events will be included in the CLS measurement. If there is a layout shift based on expected user behavior such as clicking, or hovering, it is an expected web page behaviour for the user interaction and therefore it doesn’t bother the user.

Thus, Layout Shift events can be categorized into two sections as unconditional layout shifts and conditional layout shifts. The conditional layout shifts happen after a certain user interaction within the scope of acceptable standard web behaviours. Even if a page speed measurement tool says that a conditional layout shift has been included in the CLS, the developer and the SEO should know that it is not a problem as long as it makes sense for the UX.


This is a conditional and expected CLS example

2.3.6. What causes a bad CLS score?

The reasons for CLS are listed below.

  1. Dynamic content injection.
  2. Ads that are loaded without explicit height or width.
  3. Browser image resizing
  4. FOUT (Flash of unstyled text) and FOIT (Flash of invisible text)
  5. Using page elements without explicit dimensions.

2.3.7. How to Improve CLS?

To improve the CLS score, the following methods below can be used.

  1. Use Font-face CSS Property with “optional” value to solve the FOIT.
  2. Preload the FONT Files to solve the FOIT.
  3. Use absolute width and height values for the ads as wrappers.
  4. Do not resize images on the browser side.
  5. Do not inject content dynamically.
  6. Try to improve the Layout Process of the web page.

To improve CLS you can check the Cumulative Layout Shift Guide.

2.3.8. How to Observe Cumulative Layout Shift?

To observe Cumulative Layout Shift, you can use Google Chrome’s Performance Tab and Experience sub-tab. When you click on the Experience tab, it will show all the Layout Shift, and Long Task or Input events. And, if you click one of the Layout Shift events, you will see that it shows the layout event’s position changes and it overlays the web page element that has shifted.


To observe the Layout Shift during the web page loading process, follow the steps below.

  1. Open the Chrome DevTools.
  2. Switch to the Performance Tab.
  3. Record a performance profile.
  4. Choose the experience tab.
  5. Examine the layout shift events.

2.3.9. Why is Cumulative Layout Shift Important?

Cumulative Layout Shift is important because it shows the visual stability of the web page elements during the web page loading process. CLS is not related to the page speed, but it is about the web page element’s position changes. Layout shift events can create stress for the user by resulting in the wrong and/or unwanted clicks or events. 

A high cumulative layout shift score signals to a search engine that even if the web page is fast, quality, reliable and responsive during the loading process, it can create stress and harm the users. Thus, a high and bad CLS score could result in a search engine ranking drop.

2.4. Use HTTPS

Hypertext Transfer Protocol Secure (HTTPS) is the secure version of HTTP. HTTPS provides a secure and encrypted data transfer. HTTPS is important to transfer data in a secure way, especially for e-Commerce sites, email services, banks and insurance providers. If a website uses login credentials, it should definitely use HTTPS. There are different types of SSL Certificates such as Company Level HTTPS, or regular SSL Certificates. On 7 August 2014, Google published a blog post and made it clear that HTTPS was a ranking signal.

Google also published a new tool for safe-browsing. And, if a website includes malicious code or malware, Google Chrome can flag the website, and Google can remove it from the SERP.


Google has many products, but every product of Google represents its vision that every SEO should follow, learn and understand.

2.4.1. What is TLS?

TLS or Transport Layer Security is the formerly known Secure Sockets Layer (SSL). TLS ensures that the communication between the server and the user can happen via Private and Public Keys. The Public Key is open to anyone, and it is used to encrypt the information on the server, and the private key is controlled by the server, it is used to decrypt the information that has been encrypted by the public key.

2.4.2. Which TLS Version Should Be Used?

For Google Chrome, TLS 1.0 and 1.1 have been deprecated in 2019. A website should have a laterTLS version than 1.1 to be used within Google Chrome after version 72.

2.4.3. How to Check the TLS Version within a Browser?

To check the TLS Version for a website, you can follow the steps below.

  1. Open the Chrome Devtools.
  2. Choose More Tools.
  3. Choose the Security Tab.
  4. Check the Connection Section.

Below you can see an example of TLS version check with Google Chrome.


2.4.4. Why is HTTPS important?

HTTPS is important for secure and private browsing. HTTPS was announced by Google using the slogan of “HTTPS Everywhere”. As a ranking signal, HTTPS is increasing its importance every year. Using a fast and secure HTTPS will help websites to thrive on the SERP.  IT’s table stakes for all websites.

If a web page contains high quality content and is trustworthy, fast, responsive during the loading process and visually stable but it is not safe, Google won’t consider the web page as a proper candidate for the given query.

2.5. Use Mobile-friendly Design

To pass the Core Web Vitals assessments, websites should be mobile-friendly. A mobile-friendly design has three main components.

  1. Responsiveness for different viewports.
  2. Everything is crawlable.
  3. A great user experience.


A Mobile-Friendly Test Tool Result example from “Am I Responsive

2.5.1. What is Responsive Design for Different Viewports?

A web page can change its elements’ sizes according to the viewport width of the device or the browser. Responsive design is helpful to keep the content the same on different devices. To keep a web page responsive, different CSS properties can be used, such as “media queries” or “clamp”. But in terms of page speed, and usability, using a single line of CSS code for all of the layout is more useful in terms of visual responsiveness.


Responsive Web Design Announcement and Guideline from Google

2.5.2. What are the most used Viewport Widths?

To keep a website responsive, knowing the most used screen widths are important. The most used screen widths for desktop devices are below.

  • 1920×1080 (19.57%)
  • 1366×768 (14.88%)
  • 1440×900 (9.18%)
  • 1536×864 (7.22%)
  • 1024×768 (4.73%)

The most used screen widths for mobile devices are below.

  • 414×896 (19.44%)
  • 375×667 (13.67%)
  • 375×812 (12.3%)
  • 414×736 (8.91%)
  • 360×640 (8.21%)

Data Source: Statcounter

An SEO, UX Expert, or Developer should test all of these screen widths for responsiveness to pass the Core Web Vitals Assessments.

Lastly, responsive design is not just about viewport width!  I recommend you to watch Una Kravets from Google I/O 2021 Event.

2.5.3. What are the Common Mobile-Design and Usability Mistakes?

The common mobile design and mobile-friendliness mistakes are listed below. 

  1. Using interstitials.
  2. Using adaptive serving.
  3. Using different URLs for different devices.
  4. Using different content for different devices.
  5. Using different links for different devices.
  6. Keeping the clickable elements too close to each other.
  7. Using a fixed viewport for designing the website.
  8. Small font size.
  9. Redirecting a user to another page version according to the user-agent.
  10. Using non complying image and video extensions for mobile devices.
  11. Blocking the JS, CSS, Font, and Image files.

2.5.4. How to Test the Mobile Friendliness of a Web Page?

To test a web page’s mobile friendliness, the tools below can be used.

  1. Google Search Console URL Inspection Tool
  2. Google Mobile-Friendly Test Tool
  3. Bing Mobile Friendliness Test Tool
  4. Yandex Mobile-Compatibility Test Tool

In the mobile-friendly test tools, a search engine can show a webmaster how it perceives a web page, and what it could crawl and digest from the webpage. Also, Google Analytics, or Adobe Analytics data can be used to examine the mobile-friendliness of a web page, by analyzing the audiences. Hotjar or Clarity can be used to record and watch the users’ sessions.


A Mobile-friendly design example from the Search Engine

2.5.5. What is the Mobile Traffic Percentage?

The mobile user and mobile traffic percentage change from year to year, but in 2018 desktop user and traffic percentage have been exceeded by the mobile user percentage. Today, mobile users and traffic percentage are 54%, according to Statistica. Based on Perficient’s data, the mobile user percentage is 68.1%. But, due to the pandemic conditions, the desktop user and traffic percentage have increased.


2.5.6. What is Mobile-only Indexing?

Google has switched to the mobile crawling scheme for all of the websites. In 2018, Google announced mobile-first indexing. In this concept, Google has given more weight to the mobile version of the web pages for ranking. In 2021, Google has switched to mobile-only indexing, in other words, if the content doesn’t exist within the mobile version, it won’t be evaluated by Google.

2.5.7. Why is Mobile-friendliness Important?

Mobile-friendliness is important because most of the users are using mobile devices for browsing on the web. And, if a website is not designed with the mobile-first design mentality, it might create a frustrating experience for most of the users. Even if a web page has good, quality content, and it is secure, fast, responsive during the loading, and visually stable, if it is not usable by the users, it won’t be considered as a quality web page by the Page Experience algorithm in the context of Core Web Vitals.

2.6. Use Proper Monetization Practices

To pass the core web vitals assessments, proper monetization is important. In 2021, Google started to publish “Monetization Policies” videos on YouTube. Monetization Policies include “invalid clicks and impressions”, “encouraging clicks or views from users”, “abusive experiences” and more. Most of these monetization policies are about ad publishers’ mentality and behaviour on the web. In the context of the Core Web Vitals, the proper ad experience for the users is important.  If you deceive users, then Google will discover this and penalise you.

2.6.1. How to Use Ads for a Web Page?

To use ads in a user-friendly way, ensure the ads do not cover all of the above-the-fold section of the page. Every screen of a web page during the scrolling shouldn’t have more ads than 30% of the web page. To keep the ad relevant to the web page, a website shouldn’t use interstitials or too many repetitive ads that are irrelevant to the topic.

Natural ad placement is important to keep a web page profitable and also user-friendly. In fact, banner blindness can happen in the case of an excessive amount of ad usage.

2.6.2. What is the Page Layout Algorithm?

Against aggressive monetization, Google has published the Page Layout Algorithm. The page layout algorithm of Google especially targets the excessive amount of ads on the above-the-fold section of the web pages.

And, today we have the Page Experience Algorithm, it is similar to the Page Layout Algorithm in the context of monetization. Google has improved its concepts and algorithms’ configuration to differentiate between the excessive amount of CTA Elements or Banners within a web page.


An announcement from Matt Cutts for the Page Layout Algorithm from 2012

To learn more about the Page Layout and the importance of context, you can read the importance of context for SEO Case Study.

2.6.3. How Ad Placement can Affect User Experience?

If a user can’t see the main content of the web page because of the excessive amount of ads, it means that the web page can’t perform its purpose in the context of the search intent of the user. If a web page doesn’t let the user interact with the main content by displaying a pop-up, or irrelevant ads, forms, and CTAs, it means that the web page is abusing the user and the search engine’s decision tree.

2.6.4. How Ad Placement Can Affect Search Engine’s Perception?

An excessive amount of ads on a web page can oppress the context of the main content, this situation can create a contextual dilution, and it can make a Search Engine think that the web page is actually about something else. Thus, using relevant ads with optimized placement is important to keep things consolidated and congruent.


Page Layout Algorithm Announcement from Google in 2012

In the past, Google has published a tool to audit the web page layout to help webmasters to organize their web page layout for the benefit of the user experience in the context of ad placement. This tool basically says users prefer fewer ads and a greater distance between ads.

2.6.5. What is the Reliability of the Ad?

If a web page includes an ad for a harmful industry, brand, or non-reliable product or organisation, this situation can harm the web page’s performance. Ads are part of the web page’s content. They should be secure, logical, honest, and legitimate. In the Core Web Vitals assessments, you should also care about the ads’ content, along with their impact on the user experience.

2.6.6. Why is Proper Monetization Important?

In the context of Core Web Vitals, proper monetization is important because an ad can harm a user with its content or its effect on the web page layout. It can suppress the main content and prevent users from focusing on the main search intent. It can distract the audience, and delay their interaction with the web page.

Even if a web page is secure, fast, visually stable, responsive during the loading process and mobile-friendly, if the web page has a harmful ad or bad ad placements, the web page won’t let users perform their purpose during their session. Thus, a web page with bad monetization practices can be dropped from rankings in the context of Core Web Vitals.


Google’s Monetization Policy Starting for Content Publishers.

3. Last Thoughts on Core Web Vitals and Holistic SEO

Core Web Vitals is the conceptualized version of a Good Page Experience. A secure, fast, relevant, and responsive web page can satisfy a user, and Google tries to improve the SERP Quality with this conceptualization and Page Experience Algorithm. Also, Core Web Vitals heavily focus on web pages’ speed, and a faster web page means also a cheaper web page to be crawled. In both ways, Google improves its internal economics and SERP quality.


The Page Experience Algorithm is likely to change over time.   Its content, ranking signals, the weight of these signals over time, and all of these page speed metrics, or security measurements can change their definitions or measurement methodologies, so as SEOs we should all follow the state-of-art level information to keep SEO Projects ready for these future changes. 

Finally, I’m passionate about  Core Web Vitals as they are so closely connected to my day-to-day work at Holistic SEO, as it’s not just about page speed, it is related to the different verticals of SEO such as coding, user experience and security. And, anything that relates to the SERP and rankings is under the umbrella of SEO.

If you’ve got this far then you must also share my passion for technical SEO.  If so, come and join me and other fellow optimisers in our community for a chat about all things Core Web Vitals and tech SEO.

You can also reach me on email Koray Tuğberk GÜBÜR. I am happy to have contributed to the Authoritas’ Technical SEO Guide, and having my name side-by-side with the dear, departed Hamlet Batista who inspired me.

The latest posts on Technical SEO

Building your WordPress website with Core Web Vitals in mind

Technical SEO
Page Speed Test
All_Core_Web_Vitals_Data_Reports OK, by now, you know how important building a fast WordPress site is for users and search engines. In this post I share what I’ve done to try and establish a realistic goal for Core Web Vitals KPIs from my site without having to call on an engineer to…

Why Umbraco is the Best CMS – Lucy Pickering

Technical SEO
Bowl of raspberrys for Tea Time SEO where Lucy talks about Umbraco
There are many different content management systems in the market place so how do you know which one to choose? We invited three experts onto Tea Time SEO to discuss what cms they prefer. Niki Mosier, Marko Saric and Lucy Pickering shared their insights and Lucy expanded on why she…

How to Choose the best eCommerce CMS – Marco Bonomo

Technical SEO
Struggling with finding the best eCommerce CMS? You are lucky! Marco Bonomo and James Bavington joined us last week to share their opinion on the best eCommerce CMS with us. Read Marco’s summary now to get an insight into your best options. Where to start Picking the right CMS can be a daunting task.…

Can we help?

If you are looking for an easy way to automate much of the advice given in this guide, then please book a call with one of our platform experts to explore whether we have what you need.