Tag: Google Pagespeed Insights

User Interaction is one of the critical aspects you need to concentrate on if you want to deliver a welcoming user experience. Unfortunately, you can’t sit down in their place and see your site from your visitors’ point-of-view, so you need a way to figure out how your site responds to input.

Enter Google PageSpeed Insights. There are 3 metrics in Google PageSpeed Insights that will help you understand the user interaction experience so you can improve, Time to Interactive, Max First Input Delay, and First CPU idle.

In this post, we’re going to cover the metrics Google PageSpeed Insights uses to measure user interaction. I’m going to show you how to improve Time to Interactive, Max First Input Delay, and First CPU idle so you can deliver the best user experience for your visitors.

What is Interactive Design?

Tell me if this has ever happened to you. You go to a site and as the content is loading, you click on something, but nothing happens. So you click on it again and again and then when the page finally responds, you end up on some random advertisement landing page or somewhere else you didn’t want to be.

That my friends is a negative user interaction.

Interactive design focuses on allowing the user to achieve their goals, whether that’s purchasing a product or signing up for your newsletter, as easily as possible.

There are many dimensions to interactive design. What we’re most concerned with in this article is feedback and how long it takes to deliver, since it helps your visitors assess if their actions are effective.

If the response time between an action (like a click) and the response takes too long, your visitors will lose faith in your site and probably turn to your competitors.

To deliver a positive user interaction as your site loads, we need to focus on several metrics to give us a well-rounded idea of what the user is experiencing. Let’s look at what those are now.

Measuring User Interaction

Google PageSpeed Insights uses Lighthouse to analyze the performance of a web page for both mobile and desktop devices.

Lighthouse takes a user-centric approach and measures the following:

• First Contentful Paint
• First Meaningful Paint
• Speed Index
• First CPU Idle
• Time to Interactive
• Estimated Input Latency

Lighthouse collects lab data within a controlled environment with a predefined device and network settings and then assigns each metric a score. Scores in the ideal range are shown in green, while low scores are shown in red. Yellow scores fall in the average range.

These six metrics each tell you something different about what your user experiences as they’re waiting for your site to load and together they form a more complete picture.

First CPU Idle, Time to Interactive, and Estimated Input Latency are the three that will tell us about user interaction. For more about First Contentful Paint and First Meaningful Paint, and the Speed Index, check out those posts.

What is Lighthouse Time to Interactive?

The Time to Interactive metric, or TTI, measures how long it takes before the user can reliably interact with the content on the page by doing things like clicking links or entering text into input fields.

A TTI score of less than 100ms is ideal because when your visitor takes an action, the response feels almost instantaneous. Any longer than that and the user will perceive the lag as something wrong with your site.

While the ideal Time to Interactive in WordPress should be under 100ms, you do have some flexibility. On a landing page with a web form, the Time to Interactive benchmark would be very important. On a blog page, with only a couple of links, TTI would be less important than content visibility. Each site has different priorities, so you should only sacrifice content visibility for interactivity if it makes sense.

How is Time to Interactive Measured?

Time to Interactive is tricky to measure because there isn’t an exact and clearly defined point when the page is ready for interaction.

Think of it like measuring how long it takes to make stovetop popcorn. It’s impossible to say exactly how long it will take because you can’t see inside the pot and don’t know how many kernels still need to pop. So to make popcorn without burning it, you need to listen. When there’s a long enough delay of a few seconds between pops, you can safely assume that the popcorn is about ready.

Measuring Time to Interactive is a similar process. Lighthouse observes the main thread and network activity to figure out what is taking place. It is looking for a big enough time window on the browsing context event loop and a 5-second sub-window of network quiet where the probability of long tasks or heavy processing taking place are low.

It knows when to pay attention by looking for the First Contentful Paint and detecting when event handlers are registered for most visible page elements.

How to Improve Time to Interactive

To improve your TTI score, focus on improving your site’s JavaScript code. Downloading, parsing and executing JavaScript consumes more CPU than all other browser activities combined.

While mobile devices and computers now have more CPU, the amount of JavaScript on webpages has ballooned, increasing 3 fold in the last 6 years.

JavaScript operates in a single-threaded environment which forms a bottleneck when one process takes too long to perform. When one process blocks the single thread, everything else has to wait including other processes and user feedback.

This is even worse on mobile. Tasks can take 3-5x longer and the high CPU load drains batteries. Not to mention that the site will appear janky so it doesn’t make for the best user experience.

Tasks that take longer than 50ms are considered long tasks. To improve your TTI score, remove unnecessary JavaScript or defer it until the page is finished loading. You should also break up large files to prevent a bottleneck.

What is First Input Delay?

The Google First Input Delay metric measures how long it takes for the browser to respond to the user’s input, such as clicking a button. An ideal First Input Delay of 10ms is ideal.

While Time to Interactive, can be measured in a lab setting, First Input Delay or FID, requires users to be calculated accurately. A Google PageSpeed Insights test does include a metric for Max Potential First Input Delay, but an analytics tool, such as Google Analytics will give you more accurate results.

If you are collecting First Input Delay data from your analytics tool, then you’re capturing real user pain. If the wait time is long, then you know your visitors are probably frustrated because they have to wait every time they interact with the page. If that wait time is especially long and your bounce rate is high, then guess what? You’re losing visitors because of a poor site experience. Ouch.

What counts as a first input?

Let’s define the first input delay meaning because it doesn’t include all user interactions.

FID measures actions like clicks, key presses and entering text in fields. It does not include scrolling or zooming since they can be run on a separate thread by the browser.

This is why if your site doesn’t have any actions the user can take, other than scrolling or zooming, you won’t have a First Input Delay metric to deliver.

How to Fix First Input Delay

TTI and FID are closely related, so if you work on delivering your JavaScript more efficiently to improve your Time to Interactive, it will also improve First Input Delay.

If the browser’s main thread is busy then it won’t be able to respond to user input so you should work to split up long tasks or not run them on the main thread. This will keep the main thread open.

Third party ads and social widgets have a reputation for being greedy when it comes to consuming resources on their host pages so you should aim to include the fewest third-party iframes possible.

One approach to improve First Input Delay is by deferring non-critical tasks until they’re called for. This method is called “Idle Until Urgent” if you’d like to learn more about how to use it.

What is First CPU Idle in Lighthouse?

The First CPU Idle in Lighthouse measures when a page is minimally interactive and most but not all of the elements are ready for interaction. If you do interact with elements on the page, there may be a delay, but the page will respond.

First CPU Idle in PageSpeed Insights was originally called Time to First Interactive. It indicates when there is the first span of 5 seconds in the main thread when tasks so not take longer than 50ms after the First Contentful Paint.

The First CPU Idle is similar to Time to Interactive because both listen for JavaScript event handlers in order to return an accurate measurement, but First CPU Idle does not require the browser to respond to user input in less than 50 milliseconds.

A value of 2-4 seconds for the First CPU Idle in WordPress is about average.

How to Improve First CPU Idle?

An easy First CPU Idle fix is to minimize the number of resources that need to be executed before a page can load and reduce the size of the remaining resources.

These are the same strategies to improve TTI and FID, optimize the critical rendering path and optimize content efficiency.

User Experience Interaction Guidelines

Lighthouse does not assess your whole site. It audits one page at a time, so to understand how your site performs, you need to test a variety of page types on your site. Test a blog page, a product page, checkout, etc. Pay special attention to important conversion pages, like your landing pages and shopping cart.

Lighthouse evaluates six test metrics, but it doesn’t weigh them all the same when coming up with an overall score. Each is weighted differently.

The metric with the most weight is Time to Interactive because it has a greater impact on the page’s overall performance. This is followed by Speed Index, First Contentful Paint, First CPU Idle and First Meaningful Paint, in that order.

How to Improve Your Score

You may have noticed a pattern in the suggestions to improve Time to Interactive, First CPU Idle, and First Input Delay. Since these three metrics are closely related, you take a holistic approach to improving them. By improving your interactions for your users, you’ll improve all three.

Here are actions you can take to improve your scores:

• Optimize the Critical Rendering Path
  • Minimize or eliminate critical resources in the main thread.
  • Defer their download or load them asynchronously if you can.
  • Optimize the size of assets by compressing or minifying to reduce the download time.
  • Download all critical assets as soon as possible to shorten the critical path length.
• Lazy Load Your Images – If an image is below the fold, wait to load it until you need to. Prioritize loading the page first, then when you have idle time in the main thread, you can load the image once the visitor scrolls down the page.
• Enable browser caching – Caching files dramatically cuts down the loading time for additional pages by storing assets in a cache for faster retrieval. With HTTP caching, the browser stores a copy of assets downloaded via HTTP by the user in its cache so it will be able to retrieve them without making an additional trip to the server. We recently compared Hummingbird to other popular caching plugins and Hummingbird out optimized all of them.
• Use a CDN – Intermediary caches such as content delivery networks can help you serve assets faster from a closer data center to the user.
• Use JavaScript Wisely
  • Remove unnecessary JavaScript files and unused portions within files.
  • Split up large JavaScript files.
  • Defer loading of low-priority JavaScript files.
  • Minify and compress JavaScript files

Smush Pro has a CDN that can help you lazy load your images. Hummingbird can assist with enabling browser caching. You can get a free 30 trial for both right here to improve your Google PageSpeed Insights score.

Does your site load content steadily like the tortoise, or wait until the race is almost over before it kicks into high gear, like the hare? In the race to provide the best user experience, steady is best. That’s why Google PageSpeed Insights measures your WordPress Speed Index to determine how your site content loads over time.

The Speed Index can tell you if you’re providing enough visual feedback as your site loads. It’s an important metric for understanding what your visitors are experiencing.

In this post, I’ll show you how Speed Index is calculated, how to run a WordPress Speed Index test in Chrome and tell you what you should be aiming for. Then, we’ll cover some techniques you can use to improve your Speed Index.

What is Speed Index in Lighthouse?

Lighthouse is the open source tool Google PageSpeed Insights utilizes to analyze a webpage.

Lighthouse grades your webpage on the following criteria:

• Is it being served from a secure location?
• Is it accessible for all users?
• Are visitors who are on unreliable network connection (like those on mobile) able to reach it?
• Do users perceive your site as fast?

It’s in Google’s best interest to prioritize high-quality sites in search rankings in order to provide the best user experience. Speed Index is one metric used to assess how fast your site feels for users, in a way that captures how your site actually performs in real life.

How Google Speed Index is Measured

Here’s how Speed Index is defined in the Lighthouse documentation:

Speed Index is a page load performance metric that shows you how quickly the contents of a page are visibly populated.

Could that be any more vague? That doesn’t tell us a whole lot about how this information is captured so we could improve our scores, so I had to go to the source.

WebPagetest.org, in partnership with Google, introduced the Speed Index metric to their test in April 2012 and they fully break down how the Speed Index calculations work. Lighthouse uses a node module called Speedline whose current implementation is based on the Visual Progress from Video Capture method that was introduced by WebPagetest.org.

Even though it’s measured in milliseconds, Speed Index isn’t measured with a stopwatch like first paint; it’s calculated using a cumulative distribution function of a log-normal distribution. I know, huh?

Here’s how it works, when you perform a Google PageSpeed Insights audit, Lighthouse records a video of your web page loading. It only includes everything above the fold, which is why Speed Index will vary based on the viewport you’ve set for your test.

The video is how Lighthouse is able to “see” your site. It then breaks down the whole little video into frames. There are 10 frames per second. So if your site loads in 3 seconds, then there will be 30 frames, showing your site’s progress.

Lighthouse compares each frame to the final frame to determine how complete it is. Is it 5% loaded? 10%? 20%? 30%? etc.

Then it plots the completeness of your page on the y-axis and elapsed time on the x-axis so it can determine the average. The overall score is the sum of the individual intervals. The graph for the frames above would look something like this, with the blue area representing the Speed Index.

There is also the Visual Progress from Paint Events method for determining Speed Index WebKit browsers, that does not require capturing video and instead relies on collecting the timeline data such as paint events and other useful events. This isn’t supported on all browsers so it varies and isn’t as widely used so we won’t get into it in detail here.

How to Get Speed Index from Google Chrome

Now that you know how the Speed Index is being calculated, you should take the time to run your most popular pages through Google PageSpeed Insights.

If you’d like to do this directly in Google Chrome, hit Ctrl+Shift+i or right-click in the browser window and select Inspect

Go to the Audits tab. From there you’ll be able to select what kind of audit you want to run a test for mobile or desktop. Select the Performance checkbox to get the Speed Index, then push the blue Run Audits button to begin.

What Speed Index Score Should You Be Aiming for in Google?

Alright, so you’ve run your tests, but what’s a good score?

According to Paul Irish, who works on the Google Chrome team, the ideal Speed Index is less than 1000ms, which is equivalent to 1 second.

In order to improve, you need to get your Speed Index score as low as possible.

In March 2018, the NCC Group analyzed the home pages of 50 retailers in the UK and found that the average Speed Index score was between 3500-8000 ms. Dareboost did a similar analysis on European publishers and less than 5% of sites had a Speed Index score that was less than 1000 ms.

With that said, reducing your Speed Index to less than a second isn’t always feasible. In these cases, the best approach is simply to outperform your competitors.

We wrote a guide on how to get a 100 in Google PageSpeed Insights.

How to Improve WordPress Speed Index

Improving the Speed Index is a matter of improving the actual performance as well as the perceived performance of your site.

You can optimize performance by:

• Optimizing Content Efficiency
• Optimizing the Critical Rendering Path

To improve perception, there’s a wide variety of progressive loading techniques you can use.

If It Doesn’t Spark Conversions, Get Rid of It

The most effective way to improve both performance and perception is by eliminating unnecessary site assets. Your site gets cluttered too! Images, JavaScript files, CSS, etc. that don’t add a lot of value or are no longer being used, should be cut loose. You should repeat this process periodically, especially when you add new elements to your site.

Also, measure the value that new components add to your site. If that new resource-intensive image slider, video background or third font isn’t converting visitors then get rid of it.

Need help convincing your clients to omit page elements? Run this mobile PageSpeed test. On the results page, scroll down to the bottom, and open the Evaluate the impact of a faster site section. The calculator will help you show how increasing site speed can improve annual revenue.

Use predefined heights and placeholders

Loading a framework for the rest of your content gives your user the impression that the site is loading in an organized and intentional way.

To create a framework, create a space for elements of your site that take longer to load, such as images and videos. You can do this by setting pre-defined heights for your containing elements in CSS, or loading placeholder images or icons.

Not only does this let the visitor know that more content is coming, so they can decide if they’d like to wait, but this prevents the site contents from shifting erratically as more elements fall into place.

Optimize Your Images

Images are one of the worst offenders when it comes to adding unnecessary weight to your webpages. The best way to cut down on page weight is by eliminating unnecessary images, then optimize what’s left by doing the following:

• Lazy loading images that are below the fold
• Using progressive images
• Using more efficient next-gen image file formats
• Resizing images that are too large for their container
• Compressing your images
• Use the right file type, for instance by replacing animated GIFs with video

A quick and easy way to optimize your images is by using a plugin like Smush Pro. Try Smush Pro free for 30 days.

Optimize Stylesheets, Scripts, and Fonts

When a browser is building your page, when it comes across a CSS file or a JavaScript file, it needs to execute those files before it continues to render the page. That’s why CSS and JavaScript files that reside in the head of your page are referred to as render-blocking resources. Since they’re blocking the rendering of your content, you must optimize them so they take the least time possible to load.

Fonts also add a lot of weight to webpages, since each font is an additional resource that the browser needs to spend time downloading. Some fonts may block the rendering of the page. By default, fonts don’t begin downloading until the DOM and CSSOM are constructed, which can result in delayed text rendering.

Here’s how to optimize the additional assets needed to build your page:

1. As I said earlier, the best way to optimize something is to flat-out delete it. Cut the weight and move on. For webfonts, reduce the number of font variants, so instead of three different bold weights, maybe use one or none if you can get by without it.
2. Don’t load one huge JavaScript file. Use code splitting to break up your file and load the scripts that aren’t critical to the rendering of the DOM to the bottom of your page.
3. Compress and minify your files so they take less time to download.

Want an easy all-in-one solution that was designed to help you improve your Google PageSpeed Insights score? Hummingbird can help.

Optimize the Critical Rendering Path

The critical rendering path refers to all of the assets the browser needs to render to respond to the visitor’s current request. You want to prioritize the assets above the fold that are most important right now and load them as quickly as possible.

This requires that you analyze the components in the critical rendering path and look for ways to improve, consolidate and organize the whole load. Think of it like running errands. If you map out your route ahead of time, you can get more done in less time than if you were zipping all over town doing things as you thought of them. The haphazard way will burn through resources running back and forth.

Here’s how Google recommends you optimize the critical rendering path:

• Analyze and characterize the elements in your critical path.
• Minimize number of critical resources. If you can, eliminate them. For the rest, defer their download or load them asynchronously.
• Optimize the size of assets by compressing or minifying to reduce the download time.
• Download all critical assets as soon as possible to shorten the critical path length.

 Utilize Caching

Once you have your new optimized page done, then you’re ready to utilize page caching.

Caching is a reliable way to improve site speed for your visitors by storing assets in a cache for faster retrieval. There are several kinds of caches.

With HTTP caching, the browser stores a copy of assets downloaded via HTTP by the user in its cache so it will be able to retrieve them without making an additional trip to the server. This dramatically improves performance for repeat visitors when done properly.

We recently compared Hummingbird to other popular caching plugins and Hummingbird out optimized all of them.

You should also use intermediary caches such as content delivery networks, or CDNs to serve assets from a closer data center to the user.

Speed Index Limitations

While Speed Index is better than timeline based metrics for helping us measure user experience, it’s not perfect.

If your site has movement, then the Speed Index won’t be accurate.

Here are some moving elements that might affect your score:

• Videos that autoplay
• Carousels
• GIFs

Additionally, if you do not create placeholders for the elements on your site and the contents of your page shift as the content loads, this layout instability will also return an inaccurate Speed Index.

Still, Speed Index is one of the best tools we have at the moment, so even with these limitations, it’s still useful. Used in combination with the other metrics provided in Google PageSpeed Insights, Speed Index helps you get a complete overview of what you need to work on to improve your site for your visitors.

How to Improve Speed Index with a WordPress Plugin

WordPress performance plugins have come a long way. You no longer need to use a set of different plugins to improve every aspect of your site’s performance. You can use an all-in-one plugin like Hummingbird, which was designed to help you pass all the audits in Google PageSpeed Insights.

We designed Hummingbird not only to help you increase your Speed Index score positively but to truly help you deliver a better user experience for your peeps. Combine Hummingbird with Smush to get the most of the WordPress speed optimization service WPMU DEV offers.