PageSpeed: Optimization of the Page Loading Speed & Core Web Vitals

PageSpeed ​​optimization makes websites better. Because it lets people and crawlers see what they are looking for more quickly. This will ensure that your website serves its purpose better and you may also get a benevolent assessment by an impatient Google bot. In 2021 there will be a big update at Google – it’s called Page Experience Update. Why should you care so far in advance? Because you should urgently prepare yourself and your website for this update to avoid ranking losses. The Page Experience combines UX signals and the core web vitals. In this article, we want to show you the basics of optimizing page load speed. We explain what important definitions and metrics such as requests, round trips, FID, TTI, CLS or LCP mean. We’ll show you what essential steps are in optimizing your page loading speed and which page speed tools are helpful to make better analyzes. What are important aspects of the upcoming Google’s Page Experience update?

PageSpeed is a crucial factor to rank higher in the search engines. check other factors here.

Optimize Your Own Website Yourself – with Your Own Initiative and the Help of Google, Tools, Bloggers and Forums

SEO: How to Prepare for Google’s Page Experience Update

In 2021, Google’s search results page will undergo a major update – it’s called the Page Experience Update. Why should you care so far in advance? Because you should urgently prepare yourself and your website for this update to avoid ranking losses. The Page Experience combines UX signals and the core web vitals. Blast Analytics explains what is important  :

  • Mobile friendliness:  Make sure that your website text can also be read on the smartphone, links and buttons can be clicked easily and images fit on the display.
  • Safe Browsing:  Take great care that your website is safe. Try not to deceive your users in order to get their personal data and make sure that downloads do not contain viruses.
  • HTTPS security:  Your website urgently needs a current security certificate.
  • Intrusive Interstitial Guidelines:  Only use pop-ups when it is unlikely that they will disturb the user.
  • Largest Contentful Paint:  The time it takes for the main content of the page to load. With regard to the loading speed, for example, make sure that the images you use are as small as possible.
  • First Input Delay:  The time that elapses before the user can interact with the website.
  • Cumulative Layout Shift:  The size of the space in which an element of the website shifts again during the loading process.

What now?

In order to meet the new Google criteria with your website, you should take various steps:

  • Analyze the satisfaction of your website users by looking at your bounce rates, pages per session and session duration in Google Analytics.
  • Use Google’s  PageSpeed ​​Insights Tool and Lighthouse to test your website for Core Web Vitals, get accurate recommendations, and spot bugs.
  • The Google Search Console and SEO tools like the Screaming Frog now also have a Core Web Vitals report.
  • Try to understand Google’s criteria exactly.
  • Talk to your developers so they can optimize your website based on Google’s recommendations.

Video: Website Speed Optimization MAXIMUM BOOST– Did it improve Google rankings?

Analyze Core Web Vitals in the Google Search Console

There are various tools that we have also listed below to analyze the page loading speed. But in the new Search Console under the menu item Improvements -> Core Web Vitals you will find an overview of your URLs where there are problems depending on the device category (mobile / desktop). Below you can see a screenshot of the report in the Google Search Console

Also new:

In the course of the Page Experience Update, there will most likely be another change: Web Stories will also be possible for non-AMP pages. AMP stands for Accelerated Mobile Pages. This is a Google platform for publisher pages that load extremely quickly on mobile devices. Google then enables so-called web stories for such pages – the articles are displayed with an image and a heading as small tiles in the top stories at the beginning of the search results page.

In this article I will therefore explain to you how you can keep loading times as short as possible with page speed optimization.

The first step: Know where page speed optimization is possible

To check the status quo, Google provides you with its own tool: PageSpeed ​​Insights.

Google provides optimization options in this tool that will help you to significantly improve the loading speed of your website. Particularly good: Google already shows different optimization suggestions for mobile and desktop – if you have already optimized your website for mobile users, you will get further useful tips for the desktop here. Furthermore, Google differentiates between so-called field data and lab data.

What is the difference between field and lab data in PageSpeed ​​Insights?

Field data: With field data, average values ​​from real users are cumulated. Circumstances such as: lost TCP / IP packets due to entering the subway tunnel or changing to different (cellular) network areas are also taken into account; Different browser versions with different extensions on different end devices.

Lab data: For lab data, the page loading speed is executed on a preconfigured machine. These results are easy to compare because the conditions always remain the same. Improvements / deteriorations can easily be recognized during development.

You can use the results of PageSpeed ​​Insights free of charge either via the website or via a browser add-on (Firefox / Chrome).

PageSpeed ​​analysis definition and metrics

Page load speed is important, that is out of the question. But how exactly do you answer the question about the speed of an app or site? Is my page loading fast or not? What does “fast” mean anyway? We show you measured values ​​that focus on the user, because in the end it comes down to when they perceive an app or website to be fast.

On the Google Developers blog, Philip Walton shows that the common statement “My app loads in X.XX seconds” hardly reflects reality. Rather, the loading time depends on very individual factors, such as the device or the Internet connection. On the other hand, the loading time does not describe a single moment, but should be viewed in a much more differentiated manner. The following questions clarify which different levels are registered by a user when loading a page / app:

  • Is anything happening at all? Does the navigation start successfully? Does the server answer?
  • Is what is happening already usable? Has enough content been executed for users to engage with?
  • Can what is shown be used? Can users already interact with the page (links, text fields, etc.) or does it still have to be loaded?
  • Is it comfortable Are the interactions running smoothly and without delay?

Key figures and metrics in the analysis of page loading speed

First Contentful Paint (FCP)

With this measured value, it is already one step more concrete: It is no longer just about any color that appears on the screen, but about the first content, i.e. the first text or a first image. So how long does it take until the first textual / visual content is displayed?

What does the First Input Delay (FID) mean

The FID measures the time when the user tries to interact with the page for the first time. Interact can now mean, for example, that he tries to click a link or button. The First Input Delay (FID) measures the time it takes for the browser to actually react to this interaction. One could also speak of an “input delay” here.

What does Largest Contentful Paint (LCP) mean?

In the past, Google mostly recommended metrics for optimization, such as the First Meaningful Paint (FMP). However, you can tell that Google is constantly trying to find out which metrics correspond to real user behavior or user expectations. On this basis, there has been a new metric in Core Web Vitale since 2020, the so-called Largest Contentful Paint (LCP). The LCP measures how long it takes to render the largest image or the largest text block in the so-called viewport of the user (the time until the browser has received and processed the data. The view port means the area of ​​the browser window that is used to display the content. If you analyze your URL in the Pagespeed Insight Tool, you can see which is the “LCP element” that Google uses for evaluation.

What does the cumulative layout shift (CLS) mean

The cumulative layout shift (CLS) sounds like a very complicated metric, but is very easy to understand in the user experience. If you have already landed on a page and at the moment when you might want to start reading the content, the layout “spreads”, that is, the text you want to read jumps down, for example, 250 pixels. This can happen, for example, if you are on a newspaper page and an advertisement is “reloaded. Below you can see a video from Google, how it looks from the user’s perspective.

What other PageSpeed ​​metrics are there?

What does the First Paint (FP) mean?

The measured value “First Paint” answers the user question “Has anything happened at all?”. It is about the first moment in which the first pixels appear on the screen and thus any color appears for the first time. So something is going on.

First Meaningful Paint (FMP) & Hero Element Timing

The question now is “Is it usable?” So is the content shown already useful? Every website contains different useful / important content. The most important contents of a page are also referred to as “hero content”. On a weather page, for example, this would be the current weather report for the specific location. If this hero content loads particularly quickly, the user will hardly notice that less important content is added gradually.

Long tasks

If a browser responds to a user request, it does so by processing tasks that are linked one after the other. Some of these tasks take a long time to complete. Subsequent tasks then have to wait, which the user perceives as a delay.

Time to Interactive (TTI)

The metric “Time to Interactive” now refers to the time until the page is not only visually visible, but also ready for user interactions.

The following classification by Philip Walton helps to better understand the measured values ​​shown:

  • Is anything happening at all?  First Paint (FP) / First Contentful Paint (FCP)
  • Is what is happening already usable? First Meaningful Paint (FMP) / Hero Element Timing
  • Can what is shown be used?  Time to Interactive (TTI)
  • Is it comfortable  The absence of long tasks

Source: Google Developers

The Google blog post explains in detail how you can measure the listed values ​​on the user devices.

More tools to optimize the loading time

Before I turn to the specific tips on page speed optimization, I would like to give you a few more online marketing tools that we use in our daily work:

Do you want more page speed right now?

First a note to all developers : Page speed optimization is not a project – it is a process. Every new extension, every new script and every change to the server requires a new test of the website performance. It is very important to check in advance on a test server what effect these changes will have on the live website later.

If you are a marketer, remember that any request you make to a developer can have an impact on the speed of your website. Even if Mark Zuckerberg personally writes the code for your project.

1. Page speed optimization via server caching

With caching you can protect your web server and your database, as less data has to be requested from the database and calculated by the server.

You can save resources with this method, since the result of the calls remains in the server memory after the first request.

If a page is called that is already in the server cache, the browser accesses the server cache and thus bypasses the complex and resource-consuming query of the page in the background.

The server cache should not be confused with the browser cache. The cached data is not stored on the device on which the browser is located, as is the case with browser caching, but, as I said, on the server.

Attention : If data is changed on your website, the server cache must also be deleted and rebuilt. Please do not cache your check-out forms either, this can lead to difficulties in the conversion process.

If you use WordPress, you can use the  WP Rocket plug-in to set up your caching quickly and easily.

2. Page speed optimization through browser caching

This method of caching has a particularly positive effect on the loading time of your website when visitors return.

With browser caching, elements of the website that do not change – usually images, JavaScript and CSS – are stored in the memory of the browser on the visitor’s device. They then do not have to be reloaded when you visit the website again. The waiting time is already a lot shorter.

You can activate browser caching by using an extension for your CMS or by activating it manually via your .htaccess file.

If you use WordPress, these plugins will help you:

Setting up browser caching manually is a bit more complex.

Browser caching and changes to your website

But what if you change something on your website, but it will be cached in your visitor’s browser for several weeks?

You can use the MD5 hash to work around the problem. A unique character string is appended to all files belonging to a type that is being cached. If such a file changes, a new hash is appended. As a result, this file is recognized as new and requested again from the server.

3. Page speed optimization by minimizing HTTP requests

When one of the visitors to your website visits one of your web pages, a request is made to the server. In response, the server delivers the HTML of your webpage. This again refers to individual files. Stylesheet (CSS), JavaScript (JS), images – all are accessed using the Hypertext Transfer Protocol (HTTP).

Browsers can execute between 2 and 8 queries simultaneously and per domain. So there is an upper limit. If this is exceeded, the remaining calls have to wait until the others have been dealt with. The longer this takes, the longer it will take to display the entire webpage. Here is some information about the background of requests. A completely underestimated topic in optimizing the page loading speed is the reduction of so-called round trips. To understand this, you have to dig deeper into the communication between the browser (client) and the server and know what limitations play a role.

Key Learnings – What does this mean for optimizing the loading time

  • HTTP requests (trucks) can only travel between the browser and the server at a certain maximum speed (the speed of light). You have no influence on this speed. A request from Germany to a server in Los Angeles even takes 100ms at the speed of light.
  • The information in the http requests is not really secure during the journey between the browser and the server. That is why there is a secure connection protocol called “https” – the truck drives through a tunnel. To establish the tunnel (the secure connection), significantly more time is required than if the truck were simply traveling on a normal road.
  • The shorter the distance an http or https request has to cover, the faster the website loads. One possibility to “shorten the distances” is the use of content delivery networks (CDNs) – a network of regionally distributed servers which, due to their geographical proximity, reduce the distance of the request and thus the page loading speed.
  • With the help of special browser instructions such as preload (the browser loads a resource, e.g. an image, before it has even been requested so that it is available afterwards without delay) and preconnect (the browser establishes a connection to link targets before a user clicked on the link), it is possible to reduce the waiting time of the requests. This means that there is no longer a long traffic jam and http (s) requests can be executed faster.
  • The larger a resource (HTML, JavaScript, CSS etc.), the longer it takes to load it. In order to optimize the page loading speed, it is therefore worthwhile to compress the resources.
  • Your website loads faster if the requests have to go back and forth between browser and server less often.

Reduce the number and distance of requests

  • Reduce the number of requests
  • Reduce the distance each request has to travel

How can you analyze the requests?

Do you want to analyze the requests for your important site? Then check out these pages in the Chrome Developer Tools. You go to the Chrome developer console and open the Network tab. Then you let your page run through. At the bottom left you can see the number of requests, like here with us 78 requests for the start page.

Task : Save your server requests per domain. So don’t provide your HTML with several small CSS files, but summarize what needs to be summarized. This also applies to JavaScript files.

But summarizing it also has disadvantages. When you summarize CSS, you need a clear plan. So if you only have to load a single CSS file, many files may have to be combined into one. But that also means that you then load the CSS from the FAQ page onto the team page. In the end, you may only have one file, but one with a lot of redundant information.

Of course there are conceptual workarounds here. So you could create CSS files that represent page types that are quite similar and that way avoid redundancies.

The subject of “request upper limit” will soon be obsolete, however, because HTTP / 2 is in the starting blocks. This means that it is no longer necessary to combine CSS and JavaScript files because the upper query limit is no longer relevant here. This turns the optimization approach outlined above into the opposite. In the best case scenario, your server should now provide smaller files, because these naturally contain much less redundant information. So only CSS that is actually used on this webpage.

To do this, your server and your website visitor’s browser must understand HTTP / 2. Modern browsers can do this in the latest versions. On the server side, this is currently only possible with a few hosters in Germany and some other European countries. This is also due to the fact that the final specification for HTTP / 2 is not yet available. In many places it is still said: wait and see.

Fortunately, Google already understands HTTP / 2. And for older browsers, HTTP / 2 is completely backwards compatible.

4. Avoid unnecessary redirects

We are talking about time savings in the millisecond and nanosecond range. But firstly we want to be as fast as possible and secondly, a lot of linked redirects can add up to a pretty penny, which our website visitors spoil the surfing.

5. Reload content via AJAX

When a long website is viewed, a lot of data is loaded. A request for the delivery of the page is sent to the server and the server replies dutifully with the entire page, i.e. all the data that make it up.

That can be a lot of code that comes back. 

Now there are people who don’t look at your website until the very end. Perhaps because they found the information they were looking for right from the start, because they made a purchase decision very early on, or even because they didn’t find what they were looking for.

In terms of page speed optimization, you could now only reload the content that should be displayed next via AJAX, depending on the scroll position.

The best known example and pioneer in this field was Pinterest. Here it was practically impossible to load all posts on a topic at once. So the following points were reloaded when the viewer scrolled a page to the very end. Buzzword: Infinite Scrolling.

The charging animation was practically part of the experience back then. Today you would save yourself by reloading parts of the page that are not yet in the user’s field of view.

By the way, reloading via AJAX is particularly worthwhile on smartphones. Even with normal long pages. Because the displays are so narrow that even short pages can quickly become very long pages.

6. Compress CSS and JavaScript

Every CSS, HTML or JS file that is called must be loaded. The smaller it is, the faster it goes. You can reduce the amount of data by compressing it.

The best way to do this is to save characters. Short code takes up less space than long code. Therefore, all comments, line breaks, and most spaces are removed in minified code.

Of course, nobody does this by hand. The resourceful front-end developer leaves that to a taskrunner. These toolsets such as  Grunt , Gulp  or Webpack  offer many possibilities to automate recurring tasks during development. Among other things, the compression of JavaScript and CSS.

You can also shorten variable names in JavaScript. The shortest name is of course a single digit. But programming is difficult with that. Talking variables are always a better choice.

The above-mentioned task runners therefore shorten the variables to the maximum after programming. This also saves data.

7. Use gzip compression

Gzip compresses files. So your file size will be reduced. This also enables these files to be transmitted more quickly.

The activation of Gzip on web servers is actually standard. However, it is a good idea to check whether the compression method is really activated and thus contributes to page speed optimization.

8. Page speed optimization through asynchronous loading

When loading a webpage, it is always loaded in the order in which the elements to be loaded appear in the code. If an element in this sequence has not yet been completely processed, the following element cannot be processed and therefore cannot be displayed.

The positioning of CSS and JS files in HTML was therefore long determined by the peculiarities of synchronous loading: CSS in the <head>, JS at the end of the <body>.

  • CSS is loaded at the beginning so that the browser knows how to display your website. If you were to link your CSS files in the lower part of your HTML, the HTML would first be loaded without styles, i.e. ugly as the dark of the night, and only then be styled.
  • It’s different with JavaScript. It supports the behavior of your website, not the look. Since the visitor first needs the information on the website in case of doubt, the JavaScript and with it the functionalities of the website are loaded at the end when loading synchronously.

You can also load Javascript and CSS asynchronously. But before we go into the depths of the Critical Rendering Path , I’ll briefly explain why you should load JavaScript asynchronously.

Asynchronous loading of JavaScript

When JavaScript is loaded asynchronously, it makes no difference whether your JS files are at the top or bottom of the HTML.

Why?

With asynchronous loading, the code is worked through from top to bottom and the components are loaded as usual in the order in which they can be found in the HTML file. The difference now is that a file that is being loaded does not have to be finished loading before the rest can be loaded. It starts the loading process and continues to load in the background while the next lines of code are processed bit by bit.

The advantage: some scripts – for example for tracking your website – should be loaded at the beginning for better functionality. Asynchronous loading allows you to prevent them from preventing your website from displaying.

9. Use subdomains to get more HTTP requests

Do you remember that a browser can only process up to 8 requests at the same time? You can get around the problem with a little trick. Because this restriction only applies at domain level. So if you can also load scripts and files from other domains, you can load 8 additional files per domain.

You could therefore have your CSS and JS files loaded from one or more subdomains. Why?

Let’s say your website consists of 28 files. HTML, CSS, JS and various images. For the sake of simplicity, let’s assume that these files are all the same size. For example 15 kb.

If all 28 files were on your main domain, then your visitor’s browser could load them in 4 steps: 8, 8, 8, 4.

If it took a total of 50 milliseconds to load a file, the files would theoretically be loaded within 200 milliseconds .

If all files were distributed over your main domain and 3 subdomains, your visitor’s browser could retrieve the 28 requests at the same time. The theoretical loading time for all 28 files now: 50 milliseconds.

This example is of course only intended to illustrate the relationships between browser, files and domains. Distributing a website with 100 files to be loaded to more than 12 subdomains in order to achieve the shortest possible loading times is not only cumbersome, but also much too time-consuming to administer.

Sometimes it helps to put all images on the domain pictures.yourdomain.com. In most cases, JavaScript and CSS should only be available as one file.

None of this is required with HTTP / 2. Because here the requests per domain are no longer limited.

10. Optimize your pagespeed by using a content delivery network (CDN)

A CDN lets you load elements of your website without burdening your own server. This is possible with scripts, images, CSS and all other elements that have to be loaded via HTTP request.

The advantage is on the one hand in the saving of HTTP requests on your own server. On the other hand, CDNs work regionally. So when a client in France loads items, they will be loaded from a location in France and not in the United States or the Philippines, for example. The speed increases even further through shorter transmission paths.

There are many CDN providers. For small and for huge projects. They are then correspondingly cheap or expensive.

  • Google offers its Google Cloud CDN.
  • If you use WordPress, you can use WP-Rocket to link your static files to your CDN provider.
  • Amazon also offers a CDN. It’s called CloudFront is part of Amazon Web Services (AWS).
  • If you have a really big website with a lot of content and lots of traffic, Akamai might be for you.

Leave a Reply