Speed Optimisation: How to Improve on the Backend?

The backend plays a crucial role in web speed optimisation, as proper code and server optimisation can eliminate delays often encountered during request processing and content delivery.

This article is primarily aimed at backend developers or server infrastructure administrators.

The Impact of Backend on Speed Metrics#

Let's begin by acknowledging that speed metrics aren't just a front-end affair. The backend influences a plethora of metrics, including those from the Core Web Vitals suite.

Backend speed is measured using the Time To First Byte (TTFB) metric. The ideal TTFB value is under 0.8 seconds. TTFB has a direct impact on site loading speed, specifically affecting the Largest Contentful Paint (LCP), which measures the loading speed of the largest element on a page.

The following simplified graph illustrates this well. If TTFB takes 2.6 seconds, there's a problem, and you won’t meet the LCP metric limit of 2.5 seconds. At that point, even the best front-end optimisation won't save you, and you'll have to resort to backend optimisation.

Backend time and frontend time together form the LCP metric value.

Aside from LCP, the backend also affects one of the auxiliary Web Vitals metrics, which is First Contentful Paint (FCP), the speed at which any content is rendered.

Backend optimisation is the foundation upon which you can build, even if you are optimising WordPress, Shoptet, or another CMS system.

General Tips to Speed Up the Backend#

The potential spots for optimising TTFB time are endless. To the list previously mentioned, we can add a few “evergreen” points, including:

• Increase server performance (CPU, memory)
  Adequate server resources can process requests more swiftly.
• Optimise the database
  Fine-tune database settings, efficient queries, and use indexes.
• Use caching
  Implement caching at the database level, in-memory (e.g., Redis), or HTTP cache on frequently repeated queries or endpoints to eliminate the need for reloading data from the database.
• Beware of multiple redirects
  Lengthy roundtrips extend the overall page load time.
• Optimise DNS and network latency
  Set optimised DNS and cache it to ensure loading is as fast as possible. In some cases, moving servers closer to the target audience region can also help.

How Can a Backend Developer Help Improve Website Speed?#

The following tips are not directly aimed at optimising TTFB metrics but can generally help improve website speed.

Data Compression: Brotli, GZIP#

Brotli and GZIP are lossless compression methods that save data volume when downloading text files such as CSS or JS from the server to the browser. Few people realise that GZIP and Brotli have so-called compression levels. GZIP has 9, while Brotli has 11.

For compression, we generally recommend setting the level to 6. Higher levels than 6 do not bring significant differences in file size and the higher the compression degree, the greater the demand on server performance and time.

Do not use compression for fonts (WOFF and WOFF2), as they are already compressed by the nature of their format. If you lack experience in setting compression, first test the compression level. Services like Cloudflare can automatically solve good compression levels for you.

If bots, rather than humans, are draining your resources, it could be a problem for both speed and stability. Check out our AI bot strategy service.

Ignoring UTM Parameters#

It often happens that websites use cache invalidated by any parameter in the URL address. However, it's crucial to realise that UTM parameters do not imply any content change; they are used solely for analytical tools.

Ignoring UTM parameters in the cache can be a good optimisation step, as it can save you from double distribution on the TTFB metric, which is quite typical for the cached and non-cached version.

An exemplary example of two different user groups in the TTFB metric – green is cached, the other is not.

This format is also visible in the CrUX data histogram in the Domain report.

Upgrading the Backend Stack#

Maintaining and upgrading technology versions in the development environment is very important. New versions often enhance performance, which can help speed up your project and eliminate technological debt.

For instance, with PHP, you can compare individual versions using benchmarks. In the Laravel framework, increasing the version can lead to a noticeable rise in handled requests per second.

The performance and number of requests handled by PHP version 8.3 is higher than older versions.

New Image Formats (WebP, AVIF)#

Web image formats have undergone interesting developments in recent years, and we can now use two new formats, WebP and AVIF. Their main advantage is higher data efficiency. Both formats can now be used without concern, as they are supported by all modern browsers.

With the WebP format, you can work natively in PHP. Among the important parameters, we mention $quality, which sets the output quality of the image.

With the new WebP format, you can save up to tens of percent in image data size.

AVIF is natively available from PHP version 8.1 and upwards, and you can also set parameters like $quality and $speed.

The AVIF format is derived from the AV1 video format and unfortunately has one downside. Generating an AVIF image takes quite a long time. If you don't work with images directly, deploying new formats can be resolved by services like Cloudflare.

With the new AVIF format, you can save up to tens of percent in image data size.

A detailed guide on implementing AVIF, including our practical experiences, can be found in the AVIF format article. You’ll find more tips for optimising images on the web.

HTTP3#

Interesting developments and speed improvements are also seen in server-client communication. HTTP3 brings enhancements where the handshake doesn’t occur every time in communication, significantly speeding up the process.

HTTP3 significantly simplifies server-client communication processes.

Other advantages include better prioritisation of downloaded files (such as when using additional CDNs or subdomains alongside the main domain) and improved handling of unstable connections. Certainly an improvement worth considering.

Early Hints#

Further efficiency in server-client communication is brought by 103 Early Hints. Simply put, it involves even faster preload and preconnect, unlocking an earlier start to resource downloading for the web.

103 Early Hint
Link: </style.css>; rel=preload; as=style

We don't recommend using Early Hints for a large number of files, but they can serve their purpose when downloading resources that block the first render. A good example would be downloading CSS using Early Hints.

For easier understanding, an infographic showing server/client communication without and with Early Hints.

Speculation Rules API#

This year, Chrome introduced enhancements with the Speculation Rules API, allowing pages to be preloaded in advance. Currently, when implementing the Speculation Rules API, better selection can be made, for example using CSS selectors, allowing you to target a specific part of links easily. Particularly interesting is the prerender option, where the page loads into memory, making its click-through instantaneous.

<script type="speculationrules">
  {
    "prerender": [
      {
        "where": { "href_matches": "/next" },
        "eagerness": "eager"
      }
    ]
  }
</script>

Speculation Rules are usually defined in HTML, but if this is not possible in your project for some reason, you can also send them in HTTP headers:

Speculation-Rules: "/rules/prefetch.json","/rules/prerender.json"

Tools for Monitoring Metrics#

You can track backend speed time using specialised monitoring tools. In our practice, the most crucial data comes from users in the Chrome UX report (CrUX), where you'll find TTFB metric values.

These data can be monitored in the PageSpeed.ONE PLUS monitoring service, where they are displayed in a clear format on the Domain report. A tester's advantage is that it displays the evolution of metrics over time.

Track the historical evolution of the TTFB metric in a graph.

We've been dealing with optimisation topics for a long time and recommend reading our other texts as well:

• Testing Web Vitals in the browser
• BFcache: Speed up users' browsing history navigation