How to fix a slow backend

Don’t rush on a more powerful server. A faster machine can surely help, but sometimes the slowness resides in a poorly written code, a request toward an external API or a database that does not scale well with the number of items it contains.

Caching is the key

I’ll tell you a secret: most of today’s backends are slow by nature. We ask them too much. This is why a vast majority of websites cheat with caching. Some companies even build 2, 3, 4 levels of cache to support their slow code.

But caching has one drawback: it eliminates real time changes. Let’s say you configured your cache with a TTL (Time To Live) of 2 hours, then any change in a page can take up to 2 hours to go live. Find the good balance between your need for reactivity and the number of users visiting your pages.

The subject of server-side caching would deserve a full article, but for now I’ll list here a few solutions:

  • Install a reverse proxy cache such as Nginx or Varnish (both free) on your server when most of your users are anonymous. The proxy will simply save the outputted HTML and send a copy of it in a fraction of time to the next user.
  • Use a CDN (Content Delivery Network). It acts like a reverse proxy but you don’t install anything on your server, plus it is built with geographical proximity on top. Cloudflare is probably one of the cheapest (starting at $20 per month).
  • For WordPress, the W3 Total Cache plugin is free but needs advanced skills. WP Rocket is much easier (but $49 per year). Both plugins can be combined with a CDN so you get 2 levels of cache. And they are good enough to clear the cache when an article is updated.

Let’s dive into the real problems

Sometimes, adding a cache is not a possibility. For example:

  • if the information needs to stay minute-fresh,
  • if page contents are personalized,
  • if most of your users are logged in,
  • if the shopping basket is handled server-side,

Then you have no other choice. You need to change things inside your application. Warning: it’s not for beginners. If you’re not familiar with your server technology, you’d better ask to an expert.

Profilers know everything

Roll up your sleeves, put your helmet on, we will now enter the machine!

Tron film poster

A profiler is a tool that instrumentalizes your server language to track and measure almost everything. It will point you the slowest functions, components, database queries, external queries and point you some server settings done wrong.

The NewRelic profiler interface

If you have a test server and it’s as slow as the production server, go for this one to avoid disturbing your website. If you do it on the production server, don’t forget to disable the profiler when you’re done optimizing, because it adds itself a little bit of slowness.

The biggest player in this industry is probably NewRelic. It handles dozens of languages and can almost do anything. With its 30 days free trial, you can have the time to diagnose problems, fix them and check again.

In the PHP world, BlackFire does a good job (15 days free trial). There is also Tideways that I’ve never tested (30 days free trial) and it’s open source version but it’s not as user-friendly.

JProfiler is quite popular for Java. Ruby’s Rack Mini Profiler looks interesting. Python includes its own profiler called cProfile as well as Node.js.

The goal of this article is not to list and resolve the different problems you will discover, it could require a full encyclopedia. But at least you’ll have clues what to search for in Google!

Caching inside the application

Caching is not only useful on the final HTML file, it can also help accelerating the language. Examples:

  • If every simple page load asks the database the total number of items in the shop or the total number of articles on the blog. Cache it to reduce the number of database requests.
  • If your navigation menu is complex and generated with database requests, cache the outputed HTML.
  • If your application often requests an external API for minute-fresh currency exchange rates, why not caching them, even for a minute?

Once you start caching, you can’t stop because it’s damn easy. If you don’t want to experiment the hell of debugging an application with too much caching, remember to create a “cache free” mode for development purpose, or at least a “clear all caches” button.

Last but not least, make sure your language-side cache is fast. Caching in a database is slow. In a file on the disk is 10 times faster. In the memory is 10 times faster than the disk. I personally like Memcached, simple and efficient, with connectors with almost every languages and frameworks.

Slowness related to user peaks

This subject will be treated in a different article. Here are some quick ideas in the meanwhile:

  • Cache things, of course.
  • Reduce the number of static requests that hit your origin server with the help of a properly configured proxy or CDN.
  • Increase your number of servers with the help of some load balancing technology.
  • Transform dynamic parts of your website into static ones. Many website use Ajax-based user sessions and e-commerce baskets for this reason.
  • Use Load Testing to simulate peaks on your development server. Or during the night on your production server.

My website is too slow: the starter guide

Hi there! I am Gael Metais, a web performance expert and I will try in this article to guide you around accelerating your website. So you have probably bought a website from an agency or even created it yourself. You are proud of its content and you love its shiny design, but damn… it… is… slooooowwww…

[Drawing: somebody waiting in front of his screen]

Let’s see how to measure your website’s speed, decide if it is really slow, detect the faulty components and explore some ways to fix them.

[Table of Contents]

How to measure a website slowness?

First things first, you need to accurately measure the load time of your webpages. It will help you:

  • determine how slow the pages really are,
  • get a comparison point to check later improvements.

I don’t recommend measuring from your own computer because it is subject to many bias (browser caching, exceptionally good bandwidth compared to users, temporary bandwidth reduction…). You should rather use what we call Synthetic Testing, which means that all tests are performed from a distant server with a stabilized bandwidth.

My favorite tool for Synthetic Testing is WebPageTest (free and open source). Let’s use it. Choose a location that matches your users. Under the advanced settings section, select a DSL connection. And start the test.

Using WebPageTest to find why a website is slow

While you are waiting for the results, a real browser loads the page and measure everything that is measurable. Then your results page starts with a small sheet similar to this:

WebPageTest results summary

WebPageTest provides with a lot of information and can be complex for beginners, but here are probably the most important metrics and a quick explanation:

  • Start Render: when the first page elements appear.
  • Speed Index: the median appearance time of all elements on the page.
  • Document Complete Time: when the browser’s loading indicator stops spinning.

You can repeat the test on some other URLs, because the situation can be very different between pages.

How slow is too slow?

Remember that I told you to launch your test with a DSL simulated connection? Well, the following numbers are only relevant for that WebPageTest connectivity and should not be used in an other context.

User experience:excellentgoodokbadawful
Start Render< 1s1 – 2s2 – 3s3 – 4s> 4s
Speed Index< 2s2 – 4s4 – 6s6 – 9s> 9s
< 3s3 – 5s5 – 7s7 – 12s> 12s

If you wonder what occult science is behind these numbers, it is just my experience in website auditing. They are just here to give an idea. If you have great ambitions for your website and merciless competitors, you can divide these numbers by two.

Please also note that the Speed Index metric is not always reliable, especially if the tested page contains a carousel, a video or any kind of animations above the fold.

Identify problems

Now, obviously, your website is slow. Otherwise you would not be reading this chapter.

To be clear, there can be hundreds of reasons why a website is slow. Web performance specialists would not be so numerous if the subject was easy. But before paying an expert, you can probably fix some things by yourself even with a light technical knowledge.

Let’s start with a first diagnostic.

Backend Vs Frontend

We will check whether the backend or the frontend is slow.

The backend refers to the server-side system that produces and delivers the HTML code. It is handled by a server technology (Apache, Nginx and others) and a language (PHP, Python, Java…), on which there’s generally a framework (WordPress, Shopify, Laravel…) and a database (MySQL, Oracle, MongoDB…).

On the other side, the frontend refers to… almost all the rest: network configuration, weight of images/videos/fonts, lack of caching, sluggish JavaScript and so on.

Return to our previously used WebPageTest tool and click on the waterfall to zoom it. Now identify the line that refers to the HTML code. It is the first blue line you’ll meet. Here is a couple of examples:

WebPageTest identify the HTML request in the waterfall
WebPageTest example: identify the HTML request in the waterfall

Click on the line and read the Time to First Byte. It is the time taken by the server to analyse the request and build the appropriate HTML response.

This metric will tell you the backend time. The frontend time is all the rest, from zero to the vertical blue line (Document Complete Time). Generally, people get surprised when they discover that backend only represents 2 to 5% of the total loading time. But it’s not always the case.

Here’s comparison table to let you decide whether your backend has a problem or not:

Start Render< 0.1s0.1 – 0.3s0.3 – 0.6s0.6 – 1.2s> 1.2s

If you conclude that your backend is too slow, check this article: How to fix a slow backend.

Fix the problems yourself

Use automated optimizers

Contact an expert