Google Pagespeed works: It boosts your page score and search engine ranking

• How Google Pagespeed works: It boosts your scores and search engine rankings
• By Ben Schwarz
• The Nuggets translation Project
• Permanent link to this article: github.com/xitu/gold-m…
• Translator: Jerry – FD
• Proofread by: Weberpan, Endone

In this article, we will uncover how PageSpeed’s most important PageSpeed score is calculated.

There is no doubt that page loading speed has become a key factor in improving page revenue and reducing churn. Now that Google has included page load speed in its search rankings, more businesses and organizations are focusing on improving page performance.

Last year Google made two major changes to their search ranking algorithm:

• In March, search results were ranked based on the mobile version of the page, replacing the previous desktop version.
• In July, the SEO ranking algorithm was updated to add page loading speed as a factor influencing its search ranking, such as mobile page ranking and AD ranking.

From these changes, we can draw two conclusions:

• The loading speed of mobile pages will affect your SEO ranking.
• If your page loads slowly, it will reduce your AD quality score, which in turn will make your AD more expensive.

Google says:

Faster loading doesn’t just improve our experience; Recent data suggest that faster page loading also lowers operating costs. Like us, our users value speed — which is why we decided to factor page speed into our search ranking calculations.

In order to understand how these changes affect us from a page performance perspective, we need to know the basics. PageSpeed 5.0 is a disruptive change from the previous version. It is now powered by Lighthouse and CrUX (Chrome User Experience Reporting).

This update uses a new scoring algorithm that will make it harder to get high PageSpeed scores.

What are the changes to PageSpeed 5.0?

Before 5.0, PageSpeed gives you a set of guidelines for testing pages. If a page has a large, uncompressed image, PageSpeed recommends compression. For example, if cache-headers is omitted, it is recommended to add it.

These suggestions correspond to guidelines that, if followed, are likely to improve your page performance, but they are superficial and do not analyze the user’s experience of loading and rendering a page in a real-world setting.

In PageSpeed 5.0, pages are loaded into the real Chrome browser under the control of Lighthouse. Lighthouse logs metrics from the browser, feeds them into a scoring model, and presents an overall performance score. According to the specific score index to give the optimization guidelines.

Like PageSpeed, Lighthouse has a performance score. In PageSpeed 5.0, performance scores are taken directly from Lighthouse. So now PageSpeed’s speed score is the same as Lighthouse’s performance score.

Now that we know where the PageSpeed score comes from, let’s take a closer look at how it’s calculated and how we can effectively improve page performance.

What is Google Lighthouse?

Lighthouse is an open source project run by a brilliant team from Google Chrome. Over the past few years, it has gradually become a free performance analysis tool.

Lighthouse uses Chrome’s remote debugging protocol to capture information about web requests, calculate the performance of JavaScript, assess accessibility levels, and calculate the time of day that users care about. Examples include First Contentful Paint, Time to Interactive, and speed metrics.

For a more in-depth look at Lighthouse’s overall architecture, check out the official tutorial.

How does Lighthouse calculate performance scores

For performance testing, Lighthouse focuses on what users can see and experience, documenting a number of metrics.

The following six metrics form the general part of the performance score. They are:

• Time to Interactive (TTI)
• Speed indicator Speed Index
• First Contentful Paint (FCP)
• First CPU Idle Time First CPU Idle
• First Meaningful Paint (FMP)
• Estimated Input Latency

Lighthouse uses a 0-100 score model for each of these metrics. This process collects HTTP files for the 75th and 90th percentiles on the mobile end and enters them into the log-positive distribution function. That way, any online mobile page with less than 25% performance (i.e., 75% ranking) gets 0 points, and any mobile page with more than 95% performance is given a full score.

Based on the algorithm and the interactive time calculated, we can see that if a page is “interactive” within 2.1 seconds, its interactive time score is 92/100.

After each index is scored, a weight will be assigned to calculate the overall performance score of the page after adjusting the weight. The weight rules are as follows:

These weights depend on the degree to which each indicator affects the mobile user experience.

In the future, these weights may be further optimized with reference to user observations from Chrome user experience reports.

You may be wondering exactly how the weight of each indicator affects the overall score. The Lighthouse team has built a useful Google spreadsheet calculator to illustrate the specifics:

Using the example above, if we change the interactive time from 5 seconds to 17 seconds (global average TTI), our score drops to 56% (56 out of 100).

However, if we had taken 17 seconds to draw the first content, our score would have been 62%.

Interaction time (TTI) is the metric that has the biggest impact on your performance score.

Therefore, to get a high PageSpeed score, the most you need is to lower the TTI.

The sword refers to TTI

Further, there are two important factors that greatly influence TTI:

• The total size of JavaScript code transferred to the page
• The running time of JavaScript on the main thread

Our interactive time article explains in detail how TTI works, but if you want some quick mindless optimizations, we suggest:

Reduce the total JavaScript size

If possible, remove useless JavaScript code, or transfer only code that will be executed on the current page. This might mean removing old Polyfills or moving to smaller, newer third-party libraries.

What you need to remember is that JavaScript takes more than the time it takes to download it. Browsers need to decompress, parse, compile, and then execute, all of which consume significant time, especially on mobile devices.

Effective measures to reduce the total size of your page scripts are:

• Check and remove polyfills that your users don’t need.
• Figure out how much time each third party JavaScript library takes. Visually analyze their size using webpack-bundle-analyser or source-map-Explorer.
• Modern JavaScript tools (such as Webpack) can break up large JavaScript applications into many small bundles that are loaded dynamically as the user browses. This is called code Splitting, and it greatly optimizes TTI.
• Service Workers caches the resulting bytecode after parsing and compiling. If you take advantage of this feature, the user will only have to spend time parsing and compiling the code once, and the results will be cache optimized after that.

Monitor available interaction time

To better demonstrate the difference in user experience, we recommend using a monitoring system such as Calibre, which tests the minimum score of a page on two different devices. A fast desktop device and a medium speed mobile device.

That way, you get the best and worst case data that your users are likely to experience. It’s time to realize that your users aren’t using devices as powerful as you are.

Depth profiling

To get the best results for profiling JavaScript performance, deliberately test your pages on a slower mobile device. If you have an old phone in your drawer, you may discover a new world.

Chrome DevTools’s hardware emulation module is a great substitute for testing on real devices, and we’ve written a detailed performance profiling guide to help you get started on analyzing runtime performance.

What about other indicators?

Speed metrics, first content rendering time, and first effective rendering are browser-based metrics. Their influence factors are similar and can often be optimized simultaneously.

Obviously, tuning these metrics is relatively easy because they are calculated by recording the rendering speed of the page. Careful compliance with Lighthouse’s performance metrics will optimize these metrics.

If you haven’t preloaded fonts or optimized those key requests, this is a good place to start. Our article, Critical Requests, details how browsers make requests and render critical resources for your page.

Track the process to optimize

Google’s recent updates to its search console, Lighthouse, and PageSpeed Insights are great for analyzing the performance of the first screen of your page, but for teams that need to keep track of pages to improve their performance, it’s a bit of a struggle.

Continuous performance monitoring ensures speed optimization, and the team knows when a page goes bad again. Artificial testing introduces a large number of unpredictable variables to the results, and testing in different areas and on different equipment is almost impossible without a professional laboratory environment.

Speed has become a key factor in SEO rankings, especially as around 50% of page traffic now comes from mobile devices.

To avoid falling down the rankings, make sure you’re using the latest performance analytics suite to track your key pages (ha, we built Calibre to be your performance booster partner. He’s based on Lighthouse. It is used every day by teams from all over the world.

Related articles

• About Time to Interactive
• How to optimise the performance of a JavaScript application
• Lighthouse Performance score Calculator

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.