Website speed and page experience: what actually matters for SEO

Written by
Anastasia Osypenko
Feb 26, 2021
21 min read

The time it takes for a web page to display its content plays a crucial role in how users will engage and interact with it. While page load speed is naturally connected to the user experience, how much does it really matter for search visibility and rankings? There hasn’t been much clarity from Google, as well as other search engines, in how they exactly measure speed parameters and how much of a ranking factor page speed is. 

But now we can say for sure that page experience is going to be an important ranking factor. It consists of several technical characteristics, including aspects of loading, interactivity, and visual stability known as Core Web Vitals. The main thing to understand here is that it’s not about how fast a web page loads but how fast it renders the first display area. 

In this article, we’ll cover all these terms and aspects in detail, discuss other website speed metrics, and explain how to improve your website’s speed and performance in order to positively impact your SEO.

User experience and speed: the balance between the two

Google first introduced the tool for website performance analysis in 2013: PageSpeed Insights tested a page and provided a score, giving recommendations on improvement. But as studies have shown, the score it had given was not extremely accurate for both speed assessment and SEO results. In 2018, Google’s PageSpeed Insights enhanced their algorithms with Lighthouse, providing speed testing which is more objective and more valuable to users because it takes into account rendering capabilities. 

More importantly, page experience metrics will become a true ranking signal soon. Core Web Vitals are also going to be a criteria for a web page to appear in the “Top stories” SERP feature.

With that in mind, we can say that improving your website’s speed alone won’t bring you to the top but you still need to work on guaranteeing your visitors a decent loading speed and seamless experience. Naturally, if your pages load very slow and prevent users from freely navigating the site, this will hurt your performance in search, as well as your CTR and conversion rates.

However, it’s important to note that improving website speed isn’t just about reducing load times. It’s also about optimizing the on-page SEO process, which includes factors such as optimizing title tags, meta descriptions, headers, and other HTML elements. By optimizing these on-page elements for better search engine visibility and user experience, you can strike a balance between speed and usability that will ultimately improve your search engine rankings and drive more traffic to your site.

Even though we don’t know much about how exactly other search engines evaluate such metrics as Google’s page experience signals, they all value UX. Bing Webmaster Guidelines claim that a “positive user experience” is more important than just faster page loads; Yahoo Developer Network also accentuates the significance of UX while talking about speed. 

How a web page is loaded

To understand website performance metrics, we need to know how the content on web pages is loaded and what factors influence this process.

What should happen within seconds is a multi-step technical process:

  • It starts from the initial request to the server when a user types a URL or clicks on a link.
  • The server processes the request and sends the HTML response to the user’s browser.
  • The browser builds the DOM tree (Document Object Model, a model of the page constructed from HTML objects) and parses CSS attributes to render the page.
  • The browser goes through the layout process, painting, and placing elements and styles in the right places on the page.
Web page rendering process

Parameters to analyze

Page experience signals evaluate how users perceive and interact with a given web page. Naturally, there are design and content-related factors that are also responsible for user experience but page experience concentrates on technical parameters which build the foundation for all other factors. 

Page experience signals include:

Google’s TestMySite tool allows analyzing a website’s load speed on mobile devices:

Google’s TestMySite tool
  • Safe browsing. The Safe Browsing algorithm checks for any malicious behavior that might be at work on a website.
  • HTTPS connection. Google perceives all HTTP websites as not secure since July 2018 so it’s in your best interest to switch to HTTPS if you haven’t already. Learn more about moving to HTTPS without losing traffic from our article.
  • Accessibility (no intrusive interstitials). Interstitials such as pop-ups will be penalized by Google unless they maintain a reasonable size and don’t appear as an unpleasant surprise for users. Non-publicly indexable login dialogs and pop-ups created in compliance to a law won’t be subject to penalization.

Let’s review Core Web Vitals metrics in detail.

Largest Contentful Paint

The major aspect about how search engines evaluate website speed is that they don’t care about how fast a whole page loads as much as they care about how fast the first render is presented. Same with real users: before anything else, you need to let them see and interact with the block of the page they first see in the viewport. This largest rendered image or text block is what LCP stands for.

Here’s how a page is rendered with elements progressively appearing on a mobile screen (here, the image is the LCP):

The following types of elements can be considered for the LCP:

  • <img>
  • <image> inside <svg>
  • <video> 
  • a background image element loaded via the url() function
  • block-level elements containing text nodes

LCP can be affected by:

  • Server response time. It depends on many factors including the hosting provider, CMS, databases, etc.
  • Render-blocking JavaScript and CSS. While processing HTML, the browser can stumble upon JS and CSS files that have to be downloaded from the server in order to be executed. JavaScript and CSS files are what makes the page interactive and visually appealing.
  • Resource loading metrics. The time it takes for each resource (be it code files, images, or videos) to load above the fold impacts the LCP.
  • Type of rendering. JavaScript rendering can be done on the server-side or client-side. In the latter option, rendering is performed directly in the browser and it’s the browser that executes the file. With server-side rendering, the browser gets all the content conveniently pre-rendered—from the HTML document requested from the server.

2.5 seconds or less is considered good for the LCP.

Such metrics as Time to First Byte (TTFB) and First Contentful Paint (FCP) are also useful in diagnosing your website’s LCP and overall performance. Actually, FCP was in use along with First Meaningful Paint (FMP) before, but Google has discovered that LCP is more accurate. FMP had shown inconsistent results and couldn’t be standardized for all browsers. 

Since it’s easy to confuse these metrics, we’ll illustrate their differences:

  • FCP is the first individual element
  • FMP is the largest layout change
  • LCP is the largest individual element in the first render
Differences between First Contentful Paint, First Meaningful Paint, Largest Contentful Paint

First Input Delay

FID measures how fast a page becomes interactive. When a user clicks on a site element, the browser processes this action and delivers a result, and the faster it does so the better. The speed here depends on internal and third-party code used for the page’s content triggered by a user action.

FID is a field metric that can’t be simulated in a lab environment: a user can click on any element on a page at any time and each element can have a specific delay. You can only measure FID with JavaScript using the Event Timing API, the web-vitals JavaScript library, or Google’s tracking library

Previously, the Lighthouse report would show MPFID (Max Potential First Input Delay), calculating the worst-case scenario by analyzing the main thread. Now, it includes other metrics that are connected to FID:

  • TTI (Time To Interactive) measures the time it takes for a page to become fully interactive.
  • TBT (Total Blocking Time) measures the time after the FCP (First Contentful Paint) is generated and before the page gets fully interactive (TTI). It’s similar to the FID metric but unlike the latter, it calculates the time without user input, just adding up the time for each long JS task that blocks the main thread. 
Time To Interactive and Total Blocking Time in the page loading process

It’s important to combine FID and TBT measurements to assess your website’s interactivity. You can see these parameters in the Lighthouse report:

Performance parameters in the Lighthouse report

Some things to note about FID measurements:

  • FID values vary depending on different page loads and users
  • FID won’t be recorded if a user doesn’t interact with the page
  • FID shouldn’t be measured if the page is loaded in a background tab because the first interaction happens not immediately after the page is loaded

FID of less than 100 milliseconds is considered a good score.

Cumulative Layout Shift

CLS shows how fast the content on a page becomes stable. When resources present on a page are loaded asynchronously or DOM elements are being dynamically added, some fragments of page content may move. According to Google, Core Web Vitals metrics help ensure that a web page is successfully navigated, usable, and delightful, with a low CLS being responsible for the delightful quality.

What elements can cause layout shifts:

  • Images and videos with unspecified dimensions
  • Fonts that differ in size from fallback fonts
  • Dynamically resizable third-party ads or widgets

When a user starts reading what is on a page and then the title or paragraph shifts, it disrupts the experience and might prevent a user from wanting to explore the site further. It gets even worse when links or buttons move after being loaded: a user might end up clicking on non-interactive space or an element different from the one they aimed for. 

Here’s an example of a third-party ad being the delayed content on a page that causes the shift:

The layout shift score is a product of the impact fraction and distance fraction. Impact fraction shows how much of the visible part of the page is occupied by unstable elements. It is calculated by dividing the area of all unstable elements by the viewport area. Distance fraction shows how far elements can shift within the visible part of the page. It is calculated by dividing the greatest distance of any element’s movement by the largest dimension of viewport. 

Calculating the Cumulative Layout Shift

Let’s do the math (based on the numbers above). The impact fraction is 0.375 and the distance fraction is 0.125, so the CLS is 0.046875.

A CLS below 0.1 is considered a good measurement, 0.1-0.25 would mean there’s room for improvement, and a CLS above 0.25 signals problems that need to be fixed.

There are online calculators to quickly evaluate any website’s CLS in desktop and mobile versions:

Cumulative Layout Shift calculator

Major suggestions for improving CLS:

  • Don’t intentionally put content above existing content.
  • Specify sizes of images and videos. With responsive images, the browser first downloads them and then allocates the space. To prevent shifts, use aspect ratios or include several sizes in the srcset attribute
  • For animations, use the CSS transform property to avoid layout changes.
  • For fonts, use font:display values or preload font files.
  • For ads, reserve a fixed size for a slot or choose ad units that come with a fixed size.

There are some shifts that won’t affect the CLS score:

  • Intentional layout changes—i.e. caused by a user
  • Movement of elements that are not visible in the viewport 
  • Shifts that occur after a new element is added to the DOM

Note that CLS measurements may differ from one tool to another: real user monitoring data will accumulate layout shifts only before the load, while synthetic monitoring tools will continue until the page is fully loaded. It’s best to combine two approaches to testing your website’s CLS.

Tools to measure Core Web Vitals

To get data on your website’s Core Web Vitals, you can use the Chrome User Experience Report or CrUX (that accumulates data only from Chrome users who’ve opted in), PageSpeed Insights (that incorporates data from CrUX), or Search Console’s Core Web Vitals report. You can also test these metrics in a lab environment using Chrome DevTools and Lighthouse.

Apart from that, numerous website monitoring solutions analyze Core Web Vitals.

Score your website in 2 minutes.

Enter any website URL to get a detailed report on tech issues and suggested solutions.

SE Ranking’s Website Audit has a dedicated Core Web Vitals section:

Core Web Vitals in SE Ranking's Website Audit

Improving your site’s speed

Since you’re aware of the parameters to focus on and how to identify your website’s weak points in terms of speed and performance, you may be wondering what to do to actually improve page experience signals.

The major factors you need to consider are:

  • code minifying
  • visual content optimization
  • hosting upgrade

However, in addition to these factors, it’s important to also consider on-page SEO as part of your website speed strategy.

An on-page SEO checkup can help you identify any issues on your website that may be slowing down your website speed. This includes optimizing your website’s title tags, meta descriptions, header tags and other on-page elements, as well as ensuring that your website’s content is properly structured and includes relevant keywords.

Let’s now examine the key factors that affect website speed, and scrutinize each of them in detail.

Optimizing JS, CSS, HTML

To optimize your code for the sake of SEO, you can identify unnecessary and render-blocking sources and remove them.


The most important thing is to minify the code, eliminating everything that is not in use. Minification implies removing unnecessary or redundant parts of the code such as comments or unused sources. It can be done manually, as well as with the help of automatic minifying tools. Google recommends using CSSNano and UglifyJS for this purpose. Note that a content delivery network (CDN) might provide automated minification and compress code files stored on its servers. 

Code magnification in UglifyJS

To learn about unused code that can be deleted, you can open Developer Tools in Chrome and go to the Sources tab and then to the Coverage tab. It gives actual statistics on JS and CSS files, showing how much of the code on the page is actually executed:

Stats on JS and CSS files in Developer Tools in Chrome

In SE Ranking’s Website Audit, you can check how much of your JS and CSS code isn’t minified in the Issue Report section:

JS and CSS issues in SE Ranking's Website Audit

You can also check your Text-to-HTML ratio, which isn’t an important ranking factor but if too low, it might signal about bloated HTML that slows pages down. A ratio of 20-70% is considered good.

Text to HTML ratio check in SE Ranking's Website Audit

Device-specific versions

Besides minifying, you can distribute the code, limiting sources depending on the type of device. The browser detects the type of device using a user agent and sends it to the server so that the server can respond with the corresponding version of the site. To enable this logic, the website’s code should include several versions suitable for different devices. This way, each individual website visit won’t request unnecessary code.

Inline CSS

Sometimes, it would make sense to use inline CSS if you don’t have much CSS code in general. This way, you’ll apply styles to each HTML element directly and the browser won’t need to download CSS files separately, which will make the first render faster. However, it’s harder to maintain such a code.

Progressive rendering

When the browser encounters CSS or JS before the first render, the process is paused because the browser needs to execute these files. To identify potentially render-blocking sources on a web page, you can run a test on WebPageTest. In the waterfall view, you’ll see the start render line and all the files that are being processed before and after the first render. If something before the render is unused or can be displayed later, it’s best to fix it. Naturally, if the code is responsible for the primary user experience on a page, you shouldn’t touch it. 

The render line in WebPageTest

What you can do for those elements that don’t need to be loaded right away (like social sharing buttons) is make JavaScript load asynchronous. There are two attributes that can help distribute the script load so that resources become available asynchronously: async and defer. They both reduce the time it takes for the browser to parse HTML without damaging how things are displayed on a page. You can apply these attributes to third-party JS as well.

Optimizing images and videos

Visual content is responsible for 21% of a page weight on average, which makes it extremely important to optimize images and videos. Read our guide on image SEO to learn all the details and here, we’ll sum up the major actions you need to take regarding your visuals to improve page experience:

  • Use file formats available on all browsers. JPEG and PNG are the most common choice; WebP is a promising format but not yet supported by all browsers; GIFs might be okay but if they weigh too much, consider converting them to video files.
  • Compress images without significantly losing quality. There are image compression solutions built-in in CMSs.
  • Specify multiple ratios to make images look good on any device. Note that most popular CMSs will do this for you.
  • If you have a lot of images on a page, consider loading them asynchronously to speed up the first render. Lazy loading and decoding are two techniques used for this purpose.
  • Host large video files on third-party sites to reduce the weight of your website’s loading process.

You can check the sizes of your images and the time it takes for them to load in SE Ranking’s Website Audit tool, in the Found Resources section:

Checking image sizes and loading time in SE Ranking's Website Audit

Optimizing server hosting and resource delivery

Website Audit in SE Ranking lets you get a general picture of how fast the server responds across your website’s pages:

Server response time check in SE Ranking's Website Audit

Apart from what we’ve already mentioned, other things you can do to optimize the server response time are related to:

  • capacities of a device and network from the user’s side
  • a website’s amount of traffic
  • resources on each web page
  • chosen hosting solution
  • CMS and plugins

User’s hardware and network connection

How users interact with your website largely depends on what devices they use and what connection they have. For example, navigating a website from a smartphone with limited CPU power and memory is more difficult than doing so from a PC with a stable connection. It’s important to track which devices are common among your users and test the website’s load on these devices. While running various performance tests, you can simulate slower connections and less powerful devices. 

Hosting service and CDN

Even if you do your best optimizing the resources on your website, a shared cheap hosting service will still hurt the loading speed and user experience. There are many cost-effective solutions in the hosting market but most of them are unsuitable for websites that sell products or services, have a lot of multimedia content, or target users from many different locations.

It’s always better to choose a dedicated server which isn’t shared across different websites. If you’re on a tight budget but want to upgrade from shared hosting, you can opt for a virtual private server (VPS) that imitates a dedicated server within a shared hosting environment.

Another helpful thing is to use a content distribution network (CDN) that distributes the load across different data centers located in different places. It’s especially useful when your website targets audiences from various locations around the world.


With caching, you can instruct the server or browser to store the content that was previously shown not to load it every single time a user returns on the page. Loading content directly from cache reduces server resources and improves performance. Kinsta’s study showed that server-side caching can decrease load time by over 30%. To enable caching, you can write a code or use a plugin like WP Rocket or W3 Total Cache for WordPress. Some hosting providers automatically cache static content, optimizing server performance.


Each redirect to a page slows down the loading process so you need to reduce their number. Check up on your redirect patterns to make sure there are no redundant redirects that hurt the server response time. There are plenty of tools for checking and tracking individual and bulk redirects.

SE Ranking’s Website Audit allows you to check the redirects on your website, monitor their status codes, and identify potentially harmful issues with them:

Checking redirects in SE Ranking's Website Audit

Plugin audit

Plugins also significantly contribute to your website’s speed and performance. To avoid negative consequences, make sure you’re using a CMS and plugins for the most current version and based on the latest version of PHP. To identify plugins that can potentially slow down your website, use testing tools that provide information on a plugin’s environment and performance.

Plugin testing tool

Website speed optimization checklist

Let’s sum up the most important things about optimizing website speed and page performance to make your website attractive to users and search engines:

  • Slow website loading times damage your conversions but instead of focusing on speed optimization, you need to analyze and monitor user-centric performance metrics such as page experience signals. They are prioritized by Google and will have a direct impact on rankings starting from the new update in May 2021.
  • Good Core Web Vitals measurements include LCP within the first 2.5 seconds, FID of less than 100 milliseconds, and CLS of less than 0.1. These parameters evaluate how much time a web page needs to become accessible and interactive to users: it’s not about loading a whole page fast but about rendering content above the fold fast. Measure these signals both in a lab environment and with the help of real user monitoring.
  • Testing your website’s performance across page experience parameters, you’ll know what to focus on in speed improvement. Code minification, image optimization, and server hosting upgrade are among the major things you might want to consider. Regularly run a website audit to make sure nothing prevents your web pages from being fast and useful.
Subscribe to our blog!

Sign up for our newsletters and digests to get news, expert articles, and tips on SEO

Thank you!
You have been successfully subscribed to our blog!
Please check your email to confirm the subscription.