Slow website? Time to first byte and how caching slashes it

When a site "feels slow", the culprit is often a number few people look at: time to first byte, or TTFB. It's the time between the browser requesting a page and the first piece of the answer arriving. Until it arrives, the visitor stares at a blank page.

What's inside time to first byte

TTFB adds up several waits:

1. DNS: finding the site's address;
2. connection: reaching the server, and the farther it is the longer it takes;
3. HTTPS: the key exchange for the encrypted connection;
4. server wait: the time the server takes to build the page. On a CMS that means starting PHP, loading plugins and querying the database.

The fourth item is almost always the largest, and it's where you can do the most.

How to measure it in a minute

From the terminal, with curl:

curl -o /dev/null -s -w "DNS %{time_namelookup}s\nConnect %{time_connect}s\nHTTPS %{time_appconnect}s\nFirst byte %{time_starttransfer}s\n" https://www.yoursite.com/

From the browser: open the developer tools (F12), Network tab, reload the page and click on the first request. Under Timing you'll find "Waiting for server response": that's the server wait.

As a rule of thumb:

Measure several times and from different places: the first request after a quiet period is often slower, because the server's caches are "cold".

Why your site is slow

• No page cache: every visit redoes all the work from scratch;
• heavy plugins or too many of them, adding database queries to every page;
• a slow database that has never been optimised;
• overcrowded hosting, where the CPU is shared with too many other sites;
• a server far from your audience;
• traffic spikes or bots eating up resources.

The most effective fix: caching

A cached page is ready-made: nobody has to build it. There are two levels.

Server cache. A caching plugin or your host's cache saves the finished page and hands it to subsequent visits. The server wait drops a lot, but the request still travels all the way to your server, maybe from far away.

CDN cache. Pages and files sit on the nodes, close to visitors. The request doesn't even reach your server: the node answers, in a few milliseconds.

A real case: Maremma24

Maremma24 is an online newspaper that uses 1PrimeCDN. We measured the site's server wait from the same points, with and without the CDN:

Maremma24's server was already fast; with the CDN the wait dropped about tenfold, because the node answers with the ready-made page. On sites with slower servers the difference is even larger. In the 1PrimeCDN panel, the Performance section runs the same measurement on your site, from all the nodes.

How to tell the CDN what to cache

The cleanest way is for the site to say so, with the Cache-Control header:

Cache-Control: public, max-age=300

means "this page can be cached for 5 minutes". For files whose name changes with every version (for example style.3f2a.css) you can go up to a year:

Cache-Control: public, max-age=31536000, immutable

Personal pages, on the other hand, must say they shouldn't be cached:

Cache-Control: private, no-store

On 1PrimeCDN you can let the site decide or set a duration for the whole zone. Either way, pages requested by logged-in users (with a session cookie) always go to the server, while images, CSS and JavaScript stay cached for everyone.

When something changes: purge the cache

If you publish an article or change a price and the page stays old, just purge the cache: the whole zone or only some URLs, from the panel or via API, so your CMS can do it automatically on every change. On 1PrimeCDN a purge only shows as completed once every node has confirmed it.

In short

• time to first byte is the time visitors spend in front of a blank page;
• the biggest part is almost always the server wait;
• caching is the most effective fix, and on a CDN it's even faster because a nearby node answers;
• let the site say what to cache, and purge it when something changes.

If the site is suddenly slow and you haven't changed anything, it might not be the server's fault: read how to tell if your site is under a DDoS attack.