Server Response Time Before Anything Loads

The white screen before anything

A visitor taps a link to your site. The tab shows a spinning circle and the screen stays white. Nothing has arrived yet: no text, no logo, no layout.

That pause is the server working out what to send. Until it starts sending, the browser has nothing to draw, however small the images and however tidy the code.

On a healthy site the wait is a fraction of a second. On a struggling one it can be several seconds, on every page.

What happens during the wait

First the browser looks up where your domain lives, opens a connection to the server and, on HTTPS, agrees on encryption. Each of those is a short trip there and back.

Then it asks for the page. On a WordPress site, the server starts PHP, loads WordPress, the theme and every active plugin, asks the database for the content and settings, and assembles the page.

Only then does the first byte leave. Time to first byte covers this wait, and most of the variation in it comes from the server's own work.

What slows the first response

• An old PHP version, still 5.6 on many hosting accounts.
• A crowded shared server, where neighbours compete for one machine.
• No page caching, so every visit rebuilds the page from nothing.
• Slow database queries, often from one plugin or one bloated table.
• Plugins doing work on every single request.
• Redirect chains that send the browser on before the real page.

The third makes the largest difference on most small sites. A cached page is a copy saved after it was last built, and handing over a copy skips PHP and the database entirely.

Measuring it yourself

In Chrome, open the page, right-click anywhere, choose Inspect and open the Network tab. Reload, click the first row, which is the page itself, and open Timing.

The line labelled Waiting (TTFB) is the wait for the first byte, and most of it is the server's work.

WebPageTest, a free testing site, reports a similar figure as First Byte and lets you test from a location near your customers. Google's PageSpeed Insights flags any server response slower than 200 milliseconds.

Test logged out, since logged-in pages are rarely cached, and test more than once, at different times of day, including a search results page or a cart.

Reading the numbers

The pattern says more than any single figure.

A fast home page with slow inner pages usually means caching covers the home page and little else, or that the inner pages run a heavy query.

Slow everywhere, even on the simplest page, points at PHP, the hosting or a plugin that runs on every request.

Rows marked 301 or 302 above the page itself in the Network tab are redirects, each sending the browser somewhere else first. Links that point straight at the final address avoid them.

A worked example

A sheet music store on a city side street sells most of its catalogue online: several thousand titles for piano, choir and band, searchable by instrument, level and composer.

The home page appeared quickly. A category page or a search sat blank for several seconds, and the dashboard was slower still.

Measured in the browser, nearly all of that time was the wait for the first byte. The images were not the problem; nothing had arrived yet to be an image.

The causes were layered. The store ran PHP 5.6 on a busy shared plan, only the home page was cached, and a filtering plugin ran several slow queries on every category page.

Whoever maintained the store tested it on PHP 7.2 on a copy, replaced the filter plugin, cleared years of expired session data and added an object cache. The store then moved to a plan with resources of its own.

The first byte is now measured again after every major update.

PHP and plugins

Moving from PHP 5.6 to PHP 7 roughly halves the time WordPress spends building a page, and version 5.6 stops being patched at the end of this year. On uncached pages, the move is often the largest single saving.

It needs testing on a copy first, since old plugins can fail on it in quiet ways.

Every active plugin loads on every request, and some do real work each time, such as counting visits. Switching them off one at a time on a copy, and measuring, shows which cost most.

The database

WordPress keeps the content, the settings and much of what plugins remember in a database, and some of its tables only ever grow.

Visit logs, expired temporary data, years of saved drafts and abandoned shop sessions all make it larger, and some queries slower.

A store filtering thousands of products by several attributes at once can be slow even when the database is tidy.

The fixes belong with a developer: clearing what is not needed, replacing the slowest queries, and adding an object cache, which keeps the results of common queries in memory instead of asking the database again.

Hosting with room to work

On shared hosting, hundreds of accounts can run on one machine, each with limits on how much processing and memory it may use.

When the neighbours are busy, your pages wait. The signs are slowness at predictable times, emails from the host about resource limits, and occasional errors under load.

Hosting that suits a busy site offers guaranteed resources, server caching, current PHP and a data centre near your customers. A good host will say which of those your plan includes.

The counter-case

Many small sites already respond quickly. A brochure site with page caching on a decent host may answer in a fraction of a second, and its remaining slowness lies in images and scripts.

Once the first byte arrives quickly, the rest of the page is where the time goes.

A site due for a move or a rebuild should still measure first, so the new hosting is chosen on figures rather than promises.

Measure the first byte, and fix the server's share before spending on anything else.

The check

1. Measure the first byte on three kinds of page.
2. Repeat the test at a busy time of day.
3. Find out which PHP version the site runs.
4. Ask whether page caching is switched on.
5. List the plugins that work on every page.
6. Check the database size and its largest tables.
7. Point every link at the final address.

Step one sorts the problem before anybody spends money. Slow inner pages point to caching or the database, slowness everywhere points to the server or PHP, and each has a different fix.

What arrives after that first byte, and how heavy it is, is covered in image compression before the upload.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.