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. But it’s the balance between your site’s speed parameters and user experience metrics that will improve your rankings.
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.
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:
- Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID), and Cumulative Layout Shift (CLS). These metrics stand for loading performance, page interactivity, and visual stability respectively.
- Mobile-friendly design. Searches and website visits performed on mobile devices are growing in number, making mobile optimization one of the top priorities for Google.
Google’s TestMySite tool allows analyzing a website’s load speed on mobile devices:
- 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:
- <image> inside <svg>
- 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.
- 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.
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
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.
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.
It’s important to combine FID and TBT measurements to assess your website’s interactivity. You can see these 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.
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:
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.
SE Ranking’s Website Audit has a dedicated Core Web Vitals section:
Improving your site’s speed
Now, as you know what parameters to focus on and how to check your website’s weak spots regarding speed and performance, you’re 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
Let’s review 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.
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:
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:
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.
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.
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.
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.
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:
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:
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.
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.
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.