Google PageSpeed ​​Insights has been radically updated, what will change?


    On November 12, Google quietly updated PageSpeed ​​Insights , changing almost everything in it. This will be a big change for the entire site building industry. It looks like there will be some wave of panic and hyip around this event. The article analyzes the changes and what they bring to us.

    What is PageSpeed ​​Insights

    Just a few words for those who do not know. For the past 8 years, PageSpeed ​​Insights has been the main speed of websites, you can enter the page address and find out its rating on a scale from 0 to 100, along with recommendations for improvement.

    Of course, there are many other good tools for checking speed. But since this one is from Google, and they stated that the speed of the site affects the ranking of the results, for the majority this rating seems to be the most important. Especially for customers and bosses, and as a result - almost everyone is trying to raise the PageSpeed ​​Score of their projects, and the metric has become almost the most important in the industry.

    What changed?

    In short - everything. The old PageSpeed ​​was set aside, replacing it with Lighthouse’s ratings and analytics , an open-source site audit tool that is also integrated into Google Chrome.

    The cardinal difference of the approach is that points are now awarded not for following the rules, but for speed . The page load is estimated by several time characteristics - after how much time after the start of loading something is already visible, when you can already click, everything slows down, while loading, and when everything is loaded. These characteristics are compared with the indicators of the best sites and turn into points. Below we analyze it in detail, now the principle itself is important.

    Recommendations are, as before - but now they bear a completely different load.Recommendations are not directly related to the points , and it’s absolutely not a fact that their implementation will improve the situation (but can easily worsen if it is thoughtlessly implemented).

    Panic is imminent

    It is the night of the 13th, and everything is relatively quiet. Only a couple of specialized resources posted short notes about the update, only a couple of customers wrote excited letters about the strange behavior of PageSpeed ​​Insights. It seems to be the calm before the storm.

    Right now it can be seen that the tool behaves unstably - the estimates for the same page fluctuate within 20 points, sometimes there are complaints about the inability to get the page of the evaluated site. Some sites in general, in his opinion, are inaccessible - although they really feel great.

    It is obvious that soon a lot of people will rush to watch the evaluation of their projects, covering the service with an international habr effect. Everything will work through the stump-deck, buggy and frightening jump estimates.

    This is not easy, but try to relax and remain calm. The first thing to remember is that updating PageSpeed ​​Insights does not affect the ranking principles in search results. The second is that it will take at least two weeks for the update to be rolled in, corrected and it has started to work stably. Do not make sudden movements , you may have to roll back later.

    Reflections and forecasts

    In these changes, a lot of positive. The rule of the old PageSpeed ​​Insights with its compulsory recommendations caused a lot of trouble. First, any recommendation may be close to useless in your particular situation. Secondly, it can be implemented to the detriment of more important things, such as the time it takes to generate a page. But there was no choice - I had to do all this in order to get a beautiful assessment.

    For example, what is the recommendation about the minification of html page code? On average, this operation takes about 100 ms, and this delay covers tens of times any potential benefit from reducing the page size. The only option where it can be profitable is if you issue ready pre-minified pages from the cache.

    In any project of recent years, a lot of effort was spent on optimizing images, minifying and grouping resources, delayed launch of JavaScript, which would not break anything. Most often, this diverted the focus from the essence - the speed of the site for visitors. The Internet was full of examples of brake sites with excellent ratings, and fast sites that were rated poorly.

    Now this tinsel will gradually fall off. In the first tests, the estimates with and without minifikation-resource grouping are almost the same. Really important things become important - how quickly the server responds and how much heavy material is on the page. All whistles - social networking widgets, interactive maps, chat rooms and luxurious pop-ups will beat relentlessly by assessing how not to wrap them.

    It is likely that this will all lead to really fast sites and understanding how to do them. At least, I really want to believe in it.

    New metrics

    And for the most persistent - a detailed analysis of new metrics that affect the assessment. There are 6 of them, and they have different weight in the formation of the final assessment. Go through them in order of decreasing significance.


    1. Load time for interaction

    This is the most important feature - and the hardest. The timestamp when the page becomes fully ready to interact with the user. This moment comes when:

    • page is displayed
    • event handlers registered for most visible items
    • user response is less than 50 ms

    In fact, the page should appear, not slow down and be ready to respond to actions.

    2. Download speed index

    Shows how quickly page content becomes available for viewing. Speedline module is used for evaluation .

    This is the time when the page in the browser stops changing visually. For definition, use frame by frame comparison of the page view.

    3. Download time of the first content

    A measure that determines the time interval between the beginning of the page loading and the appearance of the first image or block of text.

    4. The end time of the CPU

    This parameter indicates the time at which the main page stream becomes sufficiently free to process manual input. This moment comes when:

    • most of the elements on the page are already interactive
    • page responds to user actions in reasonable time
    • user response is less than 50 ms

    The Russian translation of this metric loses a bit of substance. In the original, it sounds First CPU Idle - the first simple processor. But this is not entirely true. This implies a moment in the loading of the page, when it can already mainly respond to actions, although it continues to load.

    5. Download time for sufficient content.

    This parameter indicates the time after which the main content of the page becomes visible. This moment comes when:

    • happened the greatest change in the appearance of the page
    • the fonts were loaded

    6. Approximate delay time for input.

    This is the least significant feature. Shows the time in milliseconds that the page takes to respond to the user's actions during the busiest 5 seconds to load the page. If this time exceeds 50 ms, it may seem to users that your site is slowing down.

    Each metric is compared with the performance of all evaluated sites. If you have it better than 98% of the sites, you get 100 points. If it is better than 75% of the sites - you get 50 points.

    At first glance, these metrics are very vital and it will be almost impossible to deceive them with dirty manipulations that do not really speed up the site.

    So far, the principle of assessing the mobile version of the site remains a mystery. Rather, the principle is the same, but often the points are significantly lower. It is not clear on which virtual configuration of the mobile device they are being run.

    Also popular now: