First of all, don’t look at Google Page Speed as the only true metric to measure your website’s load speed. The estimation of the download speed is influenced by many factors: the state of operator networks and inter-operator joints that are involved in data transmission; the state of resources and software of the server that processes the user’s request; the state of the software and the performance of the end-user device; end user’s speed and connection type (wired / wireless).
The Google Page Speed algorithm by default emulates interaction with the site from a mobile device that is not in the fastest network (for example, 3G), and possible CPU throttling is also taken into account. It also matters where the measurement is from: the further these locations are about the servers on which the infrastructure of the web resource is deployed, the smaller the final measurement result will be. That is, for the measurement, Google uses emulation of the average mobile device and the average speed of the Internet connection in the world.
To obtain an objective assessment, it is necessary to measure the speed directly in the browsers / applications of real users of the web resource. For example, we use Real User Monitoring (RUM) technology to measure speed: we place a small JS code on the pages of a web resource that loads a test object from servers connected to the Internet. The service can simultaneously measure the speed of data delivery from several sources.
There is a possibility that according to Google Page Speed it will not be possible to abandon those elements that slow down loading: in particular, the Google algorithm “does not like” Yandex.Metrics or Facebook pixels, the engines used also significantly affect – often the “boxed” Bitrix itself slows down and WordPress. However, you can do a bit of work on the backend optimizations to improve load times and get closer to the Google Page Speed green zone and positively impact your website’s search rankings.
Speed up delivery of objects to users’ devices
Modern sites contain many objects – images, fonts, and so on. By opening a web page, the user sends an HTTP request to the server, from which all requested objects are delivered to the user’s device. The more hops (reconnections between intermediate servers) have to be done to deliver the object from the origin server to the device, the greater the delay in processing the request at each point in the route and the longer the page is loaded on the user’s side. It is possible to accelerate the delivery of objects using a CDN network: the content delivery network caches and stores the requested objects on geographically distributed edge servers, and when requested, the user is given a cached version of the object located on the server closest to the user, so the latency is significantly reduced.
Images are some of the heaviest objects on a web page. If a user accesses a page that contains, say, several dozen JPEG images weighing 2MB each, the page may take a few seconds to load. The situation is aggravated if the user is viewing the web page from a mobile connection: the channel is limited by the capabilities of the cellular network, and the quality of the connection can degrade the download speed indicators. It would be nice to take care of the automatic conversion of images into the optimized WebP format from Google: the image will remain in a rather acceptable quality for mobile devices, but its weight will be reduced by tens of percent – this way you can win 20-40% in the speed of loading a web page. WebP is supported by most browsers, including the latest Safari – however, older versions of Apple’s browser do not support WebP – these devices need to serve images in their original format.
If we talk about mobile users, in some cases resizing images for a smaller screen size also allows you to reduce the size of objects.
Once you’ve figured out image optimization, you can tackle text content (.js, .css, etc.) by using the Brotli data compression algorithm, which is supported by Firefox, Chrome, and other Chromium-based browsers. It is capable of compressing text files 20% more efficiently than deflate.
Connect HTTP / 2 protocol
HTTP / 2 is a multithreaded protocol that allows parallel loading of multiple objects from one domain at the same time, while HTTP 1.1 has a limit on the number of connections (no more than six per domain). Parallel loading of objects can speed up the delivery of content and therefore speed up the loading of web pages.
Use distributed DNS
The user’s connection to the server opens faster if the server is located closer to the place where the request is sent from. Addressing a centralized DNS server located far from the user or in AWS (whose point of presence, for example, may be in Europe), lengthens the route and increases latency. If you use a geographically distributed infrastructure to host the DNS zone, then the domain name is resolved faster at the point of presence located closer to the source of the request, which can sometimes win up to several hundred milliseconds in the speed of request processing.