Get NitroPack with up to 37% OFF
Once you start with NitroPack, you can freely choose your integration platform.
Everything you need to know about
NitroPack features and compatibilities.
Whether you run a blog or
an agency, we have a
partnership opportunity for you!
The place to learn how to
improve your web performance,
how to get the most out of
NitroPack, and what is coming
next to our product.
Your PageSpeed Insights (PSI) performance score measures three web performance aspects - Load Time, Responsiveness, and Visual Stability.
Each of these aspects is important to your visitors.
Even if they don’t realize it.
That’s why fixing page speed issues also tends to result in lower bounce rates and more conversions.
Now, before you get worried:
You don’t need to score a perfect 100.
(Although it’s a nice brag)
A good PageSpeed score is anything in the green zone (90+) or slightly below it. In case you haven't run a test using the PSI tool yet, I'd recommend you read our Beginner’s Guide to explore the updated look of the performance report.
And in this article, I’ll show you how to get there.
Here’s what you’ll learn in the next few minutes:
Since PSI is Google’s product, we should start with the link between page speed and SEO.
Let’s cut to the chase - PSI is not a ranking factor and your score does not have a direct impact on your website’s position in the SERP:
However, Google has repeatedly said that page speed is a ranking factor.
They confirmed that in an episode of SEO Mythbusting. And we don’t have a reason to doubt them on this one:
At the same time, some of the best SEOs in the game don’t find a connection between organic rankings and page speed.
So, what’s the deal here?
Well, two quotes from the episode of SEO Mythbusting sum it up better than I can:
But...
Put simply, page speed is a ranking factor but not as important as content quality or relevance.
Satisfying search intent, having solid on-page SEO fundamentals and quality backlinks is still the way to go if you want to improve your site’s organic rankings.
At the same time, research has always shown that users prefer to browse, read and buy from fast websites.
So, if fast websites make visitors happy, isn’t that enough reason to speed up yours?
Fixing page speed won't be the biggest SEO improvement you can make. But for most websites, it can be a massive UX advantage. That’s exactly what Google’s Core Web Vitals try to quantify.
In short:
It’s better to think of page speed as a way to delight your visitors, not strictly as an SEO booster.
PSI reports are separated into four main sections:
Field Data (CrUX);
Lab Data (Lighthouse);
Opportunities;
Diagnostics.
The Field and Lab Data sections are composed of different metrics.
Each metric represents one of the three aspects of web performance.
We’ll go over each metric in a bit.
For now, let’s go through the four sections of the PSI report.
The Chrome User Experience Report (CrUX) provides information for the Field Data section.
The CrUX is a massive data set filled with anonymous data collected from Chrome users. It tracks web performance across millions of websites.
This report compares your website’s performance to other real-world websites.
Based on the CrUX analysis, PSI classifies performance into three categories - Good, Needs Improvement, and Poor.
The Field Data doesn't affect your PSI score. However, if you have to focus on a single thing when optimizing your site’s performance it better be the field data. It shows how real people experience your site, which means it takes into account essential variables like their devices, network conditions, and geographic locations.
There’s a big drawback here, though:
Field data isn’t available for small websites. You need thousands of views so that the CrUX has enough information to make an accurate assessment. That’s why for most websites, lab data is the only option.
Lab data are provided by Lighthouse - an open-source tool used to audit performance, accessibility, SEO and more.
As opposed to the CrUX, Lighthouse collects data in a controlled environment on a predetermined device and network settings.
This makes it great for testing and debugging.
This report also includes six metrics instead of four.
Again, these Lab Data metrics determine your overall PSI score.
Again, while lab data doesn’t take into account real user experience, it’s still valuable.
Having green lab metrics and a high PSI score usually means that you’ve implemented best practices like getting a fast host server, optimizing images, reducing the impact of third-party code, and more. These optimizations usually have a positive impact on the user experience.
Just don’t make the mistake of using lab data as a proxy for your site’s real-world performance. There are still nuances that modern lab tools can’t capture. That’s why you want to focus on field metrics whenever they become available.
Both of these sections contain suggestions for improving your website’s performance.
Here are some of the most common Opportunities:
And some of the most common Diagnostics:
These sections are great places to start analyzing performance issues with your site.
And by implementing their suggestions, you’ll improve your PSI score indirectly.
Your performance score in PSI is a weighted average of the five lab metrics.
Metrics that have a larger impact on performance and user experience contribute more to the score and vice versa.
This is the weight of each metric in the latest version of Lighthouse (v10):
The major change that was introduced with Lighthouse v10 was the deprecation of Time to Interactive (TTI). TTI's 10% score weight was shifted to Cumulative Layout Shift (CLS), which now accounts for 25% of the overall performance score.
Now, let’s look at these metrics in pairs (except CLS) and suggest what you can do to improve them.
FCP measures the time it takes for the browser to visualize the first piece of DOM content on a page.
For example, a loading animation can trigger FCP:
Or your company logo:
According to PSI, FCP should occur in under 2 seconds.
On the other hand, LCP measures the time it takes for the largest above the fold content element to load.
Items that appear only when a user taps the screen or scrolls down don't affect LCP.
Your LCP should occur within 2.5 seconds.
Put simply:
FCP measures the beginning of the loading experience, while LCP measures its culmination. Both metrics can be measured in the lab and in the field and are crucial for making a great first impression.
Chrome’s DevTools can help you diagnose FCP and LCP problems.
Here’s how:
Open a page you want to examine in Chrome. Right-click and select "Inspect."
From there, go to "Performance." Click the “Reload” button:
Chrome will analyze the page for a few seconds and give you a report.
In the "Timings" section, you can see two small FCP and LCP icons.
If you hover over the LCP icon, it will highlight the largest visible element in blue.
Source: Yahoo News
This is the element that triggers the LCP metric.
You can also scroll into the other icon to see when your FCP occurs.
Now, let’s look at a few common ways to improve these two metrics.
Before we begin:
The techniques below will help most websites improve their PSI score.
They’re good practices that everyone can implement.
But:
You should always analyze your specific performance issues. Each site is different and no article can provide a general solution to all individual problems.
Don’t look at guides like this one as a one-size-fits-all fix.
There’s a small chance your performance is affected by factors that aren’t even included here.
Optimize Your Images
Image optimization is one of the best things you can do for site speed.
Unfortunately, it’s also quite complicated.
It includes things like compressing images and choosing the right image type.
The latter is a great place to start.
In general, you want to use WebP. It’s smaller, faster and overall better for web performance than the other options.
The only drawback is that it doesn’t have 100% browser support yet. That’s why you also need a fallback type - usually JPEG or PNG.
Next, you should also remove all unnecessary images from your website. Trust me, they’re there.
For a complete breakdown of all this topic, check out our image optimization guide.
Reduce server response times
A few factors can cause a slow server response time.
Most commonly, these are your:
Hosting plan
Caching policy (or lack of)
Bloated webpage
First, you should start with your hosting.
If you’re using a cheap, shared hosting plan, you need to upgrade. There’s no way around that.
In fact, upgrading your hosting plan can contribute more to your website’s performance than any other optimization.
Here’s a list of the top hosting companies you can choose from.
Only once the hosting is taken care of should you move to other potential problems.
Check out this article by KeyCDN for other tips on server response time.
Eliminate render-blocking CSS and JavaScript
Browsers must load, parse and execute all CSS and JS files referenced in a page’s head tag before rendering it.
That’s why these resources are render-blocking.
They stop the entire page from being visualized, even when the user only needs to see above the fold content.
A good way to solve this issue is to implement Critical CSS.
This means extracting the CSS needed to load above the fold elements and inlining it in the head tag.
Check out our In our article on 7 Ways to Minimize Main Thread Work to find several techniques that will help you deal with render-blocking resources.
Minify and combine CSS/JavaScript files
Minification means removing all the unnecessary parts of your code.
These include things like whitespace, line breaks and comments.
On the other hand, combining CSS/JavaScript into just one CSS/JavaScript file reduces the number of HTTP requests a browser has to make for your website.
There are tons of tools that can help you with both tasks. Some get the job done automatically and others require a bit of manual work.
Find one that fits your budget and use it. There’s no point in doing it by hand.
Now, let’s move on to the responsiveness metric.
TBT is the amount of time during which Long Tasks (all tasks longer than 50ms) block the main thread and affect page usability.
It shows how unresponsive a page is before it becomes fully interactive.
Put simply:
TBT tells you how severely page interactivity was affected by long tasks.
Because they’re so similar, both metrics are plagued by the same problems.
TBT gets seriously hurt by Long Tasks.
These tasks clog up the main thread and stop it from responding to user input in time (among other things).
To find Long Tasks, open Chrome and go to a page you want to analyze.
Right-click and select “Inspect”.
From there, go to "Performance." Click the “Reload” button:
You’ll get a detailed analysis of how the page performed.
In the “Main” section, you’ll see tasks painted in different colors. If you see a gray task with a small red overlay, you’ve found a Long Task.
When you hover over it, you’ll see how much time it takes up on the main thread.
You can also click on “Bottom-Up” to see a detailed description of each task.
From here, you can break down each activity and see what causes delays.
The main villain here is JavaScript.
That’s why improving your TBT requires more tech skills.
We won’t cover each technique in detail. However there are links to other useful resources below if you’re interested in digging around your website’s code.
Here’s what you can do to optimize your website’s JS:
Code Splitting. This means sending only the code that your visitors need at the very beginning, instead of overloading the browser with all the JS at once;
Preload Critical Assets. With preloading you tell the browser which resources to find and load first. You can do that by adding the link rel="preload" element;
Implement the PRPL Pattern. PRPL is a collection of techniques that involve strategically Pushing, Rendering, Pre-loading and Lazy loading specific resources;
Remove Unused Code. Pretty self-explanatory. Find the code files (or their parts) that aren’t used and remove them.
Some of the tips we talked about in the last paragraph (like minification) also help with JS optimization.
CLS measures how much unexpected layout shifts affect the user experience on a page.
Unexpected layout shifts occur when content on the page moves around without user input or prior notification.
For example, when an ad inserts itself over a button, you were trying to click.
CLS also marks an important shift (pun intended) in the way Google thinks about web performance. It’s the first PSI metric that has nothing to do with speed.
To fix your CLS score, you must first find out where layout shifts occur.
Again, we’re using Chrome's DevTools.
Right-click on a page you want to analyze and select “Inspect.”
Go to “More Tools” and select “Rendering.”
At the bottom, you’ll see a “Layout Shift Regions” option with a checkbox next to it. Select it.
Now every time a layout shift occurs, the shifted area will be highlighted.
Source: forbes.com
This won’t tell you if a layout shift is “good” or “bad”.
But it will help you find a few shifts you might’ve missed otherwise.
Again, the specifics here depend on your individual case.
Here we’ll cover a few good practices that will help you fix your CLS issues.
Include width and height attributes for images
Width and height attributes help the browser allocate the correct space on the page for each image.
This minimizes layout shifts by making the browser reserve enough space for the images.
Avoid placing ads near the top of the viewport
Ads inserted near the top push a lot of other content down, meaning they cause larger layout shifts.
Here’s an example from Forbes.com:
Avoid inserting content above other content
The same idea from the last paragraph applies here.
Unless a user initiates it, avoid inserting content above already existing content. This pushes a lot of elements down, resulting in a large layout shift.
For example, elements that often cause this issue are banners, forms and cookie consent pop-ups.
Optimize web fonts
Fonts are a bit tricky to get right.
The two main font problems lead to a bad CLS score are flash of unstyled text (FOUT) and flash of invisible text (FOIT).
The FOIT issue can be resolved by using the font-display: swap property.
This property tells the browser to use a fallback (swap) font until the custom font is ready.
The problem with this approach is that it can lead to other layout shifts.
A way to get around the issue is to use a combination of link rel="preload" and font-display: optional.
Check out this article for more information on how you can do that.
“Speed Index measures how quickly content is visually displayed during page load.”
That's the official definition of this metric.
It’s more broad and abstract than the other ones. That’s why most of the techniques I already discussed will also boost your Speed Index.
So, focus on implementing the tips from this article. As you do that, your Speed Index problems will go away.
All of the optimizations we just covered require time and effort to carry out manually.
But here’s the good news:
You don’t have to implement them on your own.
NitroPack can take care of everything we talked about for you.
With no coding and no complex setups, NitroPack can skyrocket your PageSpeed Insights score in less than 5 minutes.
But more importantly, NitroPack also has a huge impact on your visitors’ real-world experience with your website by boosting your Core Web Vitals results:
To achieve these results, NitroPack uses tons of built-in features like:
Advanced Caching;
Global CDN;
Complete Image Optimization Stack;
HTML, CSS and JavaScript Minification;
Critical CSS and more.
If you’re interested in solving all of your site speed issues once and for all, check out NitroPack. Our free plan doesn’t expire or require a credit card, so you can test it out risk-free.
Editor's note: This post was originally published in December 2020 and has been updated for comprehensiveness.
Evgeni writes about site speed and makes sure everything we publish is awesome.
