How Speed Affects SEO
By Matthew Edgar · Last Updated: June 16, 2023
On websites, faster is better. Faster pages tend to rank better in search results. Along with higher rankings, people also engage and convert more on faster pages.
This means each page of your website should load into the visitor’s browser as quickly as possible. That way as people navigate through your website, they don’t spend too much time waiting. Similarly, any features on your website—like videos, images, calculators, or search forms—should load quickly.
How do you measure speed on your website, including Google’s Core Web Vitals? How fast should your website load?
Table of Contents
- Metrics to Use When Measuring Speed
- How Fast Should My Website Load?
- Measuring Speed
- Additional Resources
Related reading: How to Decrease Your Website’s Load Time
Metrics to Use When Measuring Speed
The first step to addressing your website’s speed is knowing how long it currently takes for your website to load. There are many speed-test tools available that, for free, will tell you about your website’s load time. We’ll discuss those tools later in this guide but for now, let’s discuss the most important metrics you’ll see when reviewing these tools.
You don’t need to track each metric. Each metric matters only in specific circumstances so you can focus on a limited set of metrics and still make progress in improving your website’s performance. To begin, you should pay attention to and work to optimize a few key metrics:
- Time to First Byte (TTFB). TTFB measures how long it takes from when a URL is requested to when the first bit of information is returned from the server. If TTFB is high, that indicates problems with your website server and hosting configuration. This metric is also highly correlated with organic search rankings.
- Start Render. Start Render looks at how long it takes between the request of the URL and when you start to see something load into the browser. If this metric is high, that indicates your website is loading too much stuff (images, JavaScript, CSS, etc.) to the browser. This is similar to a metric called First Contentful Paint, which is measured in Google’s PageSpeed Insights tool.
- Total Load or Fully Loaded Time. This metric tells you how long it takes between the request of the URL and when everything has finished loading into the browser. Sometimes this is referred to as DOM Complete, DOM Content Loaded, or Document Complete.
- Total Bytes. This metric tells you the file size of the website’s page. You can look at total bytes overall (for all items loaded) or total bytes for specific elements. Google limits its crawl to the first 15MB of content on a page (though most websites fall well below this level).
Google’s Core Web Vitals
Those metrics are closely related to the speed metrics Google uses in its Core Web Vitals report. In Core Web Vitals, Google reports on:
- First Input Delay (FID). FID measures the time between a visitor first interacting with a page and the time the browser responds to that interaction. This is similar to another metric Google reports on in their tools (though not a Core Web Vital metric): Total Blocking Time (TBT). TBT looks at the time between when the page starts to render and the time when the page can be interacted with by a visitor. What these metrics get at is that your website should respond quickly to visitor requests so that visitors spend less time waiting and more time interacting.
- Interaction to Next Paint (INP). INP is a pending Core Web Vitals metric. Google plans to replace FID with INP in March of 2024. INP measures the time in between a user interacting with a webpage (like clicking a button or a link) and the result of that interaction appears on the user’s screen. For Core Web Vitals, Google will observe all interactions with a webpage but will only take the longest INP observed into consideration.
- Largest Contentful Paint (LCP). LCP measures when the largest element on any page of your website is rendered (displayed) in the browser. LCP is not a measure of total load time. Instead, LCP measures how long a visitor to your website must wait before they can see the main content of the page above the first scroll on their screen. The longer people must wait the worse the experience.
Note: Google also includes Cumulative Layout Shift (CLS) as a Core Web Vital metric along with FID and LCP. While related to speed, CLS is a measure of visual shifting and not a precise measure of website speed. As a result, it is not covered in detail here.
Learn more about Google’s Core Website Vitals
How Speed Metrics Work Together
When reviewing all these metrics, it is important to remember some metrics tell us information about what happens earlier in the load and others tell us about what happens later in the load order. If you optimize metrics earlier in the website’s load, you create a cascading effect that positively influences all other speed metrics. That can make a meaningful impact on how fast the website loads for all users.
How Fast Should My Website Load?
Naturally, the first question becomes how fast should your website load. What are the benchmarks? What does Google require?
General Guidelines
TTFB should be as quick as you can possibly make it. As mentioned above, TTFB is correlated with search rankings and that study found ranking differences on TTFB greater than half a second. Along the same lines, KeyCDN recommends notes that the average is typically 200-500 ms (.2 to .5 seconds) and that anything over half a second is considered slow.
How fast your start render (or FCP) needs to be varies depending on the visitor’s device. Typically, a website is considered fast if it begins showing content (or painting content) to the browser in under one second, though Web.dev recommends FCP is less than 1.8 seconds.
What about the total load time? That is the time between requesting a page and the completion of the page loading into the browser. According to ToolTester’s 2023 study, websites load, on average, in 2.5 seconds on desktop and load in 8.6 seconds on mobile devices. The best practice is to at least match these averages.
At Elementive, we recommend websites should have:
- Time to First Byte (TTFB) under half a second.
- Start Render/First Contentful Paint (FCP) at one second or less.
- Total load time no greater than three seconds on desktop and no greater than eight seconds on mobile.
Again, those are general recommendations. With all of these metrics, it depends on exactly how the website’s speed is affecting visitors as to whether or not load times greater than these recommendations really present a critical problem for your website. As well, the more competitive your search rankings, the faster all of these metrics should be.
Google’s Requirements
In 2010, Google made speed a factor they use to help determine where a website should rank in search results. As of the summer of 2018, Google incorporated this same speed factor into its mobile search algorithm. As of 2020, Google has incorporated those speed requirements into Core Web Vital metrics. These requirements can influence your search rankings and you want to make sure you are as close to these requirements as possible.
- First Input Delay (FID). FID should be 100 ms or less. Anything greater than 300 ms is cause for greater concern. If you have a fast server (measured by TTFB) and if the code is light (measured by, among other things, Start Render), then your server should hopefully be able to respond quickly to visitor interactions.
- Interaction to Next Paint (INP). The longest INP observed should be under 200ms to be considered Good. Only click, tap, and key press interactions are observed. Scrolling and hovering interactions are not observed (currently). Similar to FID, you can improve INP by ensuring the server responds quickly and that the code is optimized to respond quickly to a visitor’s interactions.
- Largest Contentful Paint (LCP). The largest item on the page should load in 2.5 seconds or less. Anything greater than 4 seconds is a cause for concern. If you size images appropriately, reduce your JavaScript and CSS as much as possible, reduce third-party scripts, and other similar actions, that should help improve LCP. Improving LCP also means you are improving your website’s total load time as well.
Core Web Vitals operates as a ranking boost if the website already ranks in search results. This means Google will not rank a website highly in results simply because it loads fast. As well, this means Google will not remove an otherwise helpful and high-quality website from search results because it loads slowly.
Check out my page about Core Web Vitals to learn more.
Speed’s Impact on User Experience & Conversions
Speed also affects your user experience and conversions. Several studies have found that the faster the website loads, the higher the overall conversion rate, with websites loading in under three seconds reporting the highest conversion rates. As with SEO, while speed is important, it isn’t everything and there can be other (sometimes more important) factors that will do more to improve your conversion and engagement rates.
You can measure this on your website using correlations. Start by measuring the metrics discussed above for various pages on your website. Once measured, compare those metrics to the page’s performance metrics. Do pages with faster TTFB or Start Render times have higher engagement rates or higher conversion rates? Are conversions concentrated around pages with lower LCP times?
Another way to measure the impact of faster or slower speeds on user experience and conversions is by measuring how speed is perceived. Our research into how users perceive speed has found that people using a website may be less sensitive to small changes in speed. That means if your website currently loads in five seconds, making a large investment to reduce the speed to four seconds might not have a measurable impact. However, reducing the speed from five to two seconds could have a bigger impact. When it comes to speed improvements, the bigger the change, the bigger the impact.
Measuring Speed
Google PageSpeed Insights
The first tool we’ll look at in this guide is Google’s PageSpeed Insights. Once you arrive on the PageSpeed Insights main page, enter a URL to a page on your website then click Analyze.
We’ll use Amazon as an example. Once you click the Analyze button, the test will run then you’ll see the results page, which will look something like this. Note that you can toggle between Mobile and Desktop results. The report will default to Mobile results.
PageSpeed Insights provides two types of data: lab data and field data. The first set of results shown is field data (shown in the screenshot above). Field data is a historical look at real users and is based on visitors who came to the website in Chrome. It reports on how those visitors were able to load the website over the last 28 days. Because the field data comes from real users, this information wouldn’t be available for a new page and it typically isn’t available for websites or pages with low traffic volumes.
Below the data about real users, PageSpeed Insights presents lab data, called performance diagnostics. This data comes from Lighthouse and provides a real-time analysis of how quickly the website loads.
The first piece of information presented in the lab data is a gauge showing the website’s performance score. In Amazon’s case, their score is 52 on mobile. Along with the gauge, the lab data shows various speed metrics, including LCP, CLS, and TBT (which is the proxy for FID). PageSpeed Insights also shows a timeline of how the page loaded which can help diagnose any issues that might be present on the website.
Scrolling down the page, Google provides opportunities and diagnostics. These sections provide ideas about how to improve the website’s speed. Although these recommendations are provided by Google’s tool, that does not mean that correcting these specific issues will help improve Google’s assessment of your website or that fixing these specific issues will directly improve your website’s ranking position in search results. Instead, these are ideas about how you may be able to improve your website’s speed. Helpfully, diagnostics and opportunities can be filtered by a particular metric by clicking on the links to the right of Opportunities (“Show audits relevant to”).
WebPageTest
Google PageSpeed Insights is a beneficial tool but it helps to get another look at how a website loads. That is why I recommend using WebPageTest along with PageSpeed Insights.
From the home page, enter the URL to the page you want to test. In this case, we’ll test Elementive’s home page. One nice feature offered by WebPageTest is that you can select different locations and devices. You want to pick a location near where your visitors are located and select the browser/device your visitors are most likely to use. WebPageTest provides simple configurations with devices and locations present or custom configurations can be made under the Advanced Configuration area. In our case, we’ll test from Salt Lake City, Utah using a Chrome browser on a desktop computer.
Once the configurations are in place, click Start Test. By default, WebPageTest will run three separate tests of the website’s speed. That way, WebPageTest will not be negatively affected if something weird occurs in during one of the tests (such as trouble loading a third-party script causing the speed metrics to look higher than they really are). After the there tests have finished running, you’ll be taken to the results page.
The Observed Metrics section shows the median of each metric across three runs. This provides a high-level overview of the website’s speed. In this test of Elementive’s home page, our First Byte (TTFB) is .286 seconds and our start render time is .6 seconds, meaning both of those metrics as within an acceptable range. LCP is a bit higher than it should be at 3.128 seconds.
Scrolling down below the Observed Metrics, WebPageTest provides details about each of the individual tests that were run. From here, you can click on the waterfall images to be taken to a new report providing detail about each specific test run. Along with seeing the Observed Metrics for this specific test, WebPageTest will also show a waterfall view, which provides a visual representation of what is loaded on the website. This can be helpful when decreasing your website’s load time.
Generally speaking, the items with the longest bars are the items that are slowing down your website’s load time. Everything is color-coded so that you can see which items are taking the longest to load (the key is directly above the waterfall). For instance, we have a long purple bar toward the end of our waterfall report and red relates to the banner image. To improve our speed, we may want to investigate the need for that banner image.
WebPageTest provides other details about the website’s speed. These can be accessed toward the top of the report in the View dropdown. This includes a report providing details about the content types loaded, the domains connected to while loading the website, a detailed assessment of images, and recommendations to improve the website’s speed. I highly recommend spending time with each of these reports to understand your website’s speed and find ways to make your website load faster.
Chrome Dev Tools
You can also use Chrome Dev Tools to understand more about the files that are loaded to your website, which can help you optimize your website’s speed. One of the more helpful metrics to review is the website’s transfer size. Transfer size refers to the amount of data that needs to be transmitted from a web server to a browser (or a robot) when loading a web page. The smaller the transfer size, the faster your website will load.
To access Dev Tools, begin by opening the Google Chrome browser. Before opening a webpage, right click in Chrome and click “Inspect”. Once the Dev Tools area opens, click “Network” in the top bar. (Note that this may be hidden from view and you’ll find Network by clicking “>>”.)
After opening up Network, load the webpage in Chrome. You will see all of the resources needed for your page to load listed in the Network area. Once everything is loaded, at the bottom of the Network panel you will see the transfer size.
In the screenshot provided, the transfer size is 1.0MB. That means, there are 1MB worth of files (such as HTML, CSS, JavaScript, images, videos, etc.) required to be downloaded from the server in order to render my website’s homepage properly.
The other number listed is the uncompressed size of all the resources that have been loaded. In the screenshot, the uncompressed size is 1.6MB. When files like HTML, CSS, JavaScript, images, or other assets are sent over the internet, they are often compressed using techniques such as Gzip or Brotli compression. This compression reduces the file sizes, making them faster to transfer over the network but the browser has to uncompress those.
You can also filter this list of files to specific types of files using the filters above the resource list. The screenshot shows how to filter the Network list to images. With the filter in place, you can see all of the images that are required to load this page. However, you can also filter to JavaScript files (JS), CSS files, videos (Media), font files, and more.
Once filtered, at the bottom, we can get more information about the impact those specific files have on the website’s load. In the example screenshot, 21 of the 34 files requested to load this page are images. Those images consumed 497KB of the total 1MB transfer size (the total size of the website sent from the server to the browser). Based on these numbers, optimizing images would likely help improve this webpage’s speed.
Additional Speed Test Tools
Other tools we’d recommend are listed below. We recommend using several tools to test your website’s speed. Within each tool, test from different locations and, as available, devices. Each tool loads the website and tests the speed slightly differently, so using multiple tools can give you a more balanced look at your website’s speed and the work you need to do to decrease the website’s load time.
- GT Metrix
- Uptrends
- Pingdom
- ByteCheck – great for measuring time to first byte
- SpeedVitals TTFB – another great tool for measuring time to first byte
- Batch Speed – great for measuring multiple pages at once
- PageSize Checker – great tool to quickly see total bytes
Additional Resources
- How do you decrease your website’s load time?
- Speed Becomes a Ranking Factor – 2010
- Mobile Speed Algorithm Update – 2018
- How Fast Is Fast Enough?
- Mobile Page Speed Benchmarks
- Comparing JPG, PNG, and GIF
Need Help?
Contact me today if you need help improving your website’s speed or other technical SEO factors.