Read and reduce time to first byte on WordPress

What the checker measures

The time from sending the request to the first byte of the answer, on the final hop after any redirects, from the checker's server. Under 300 ms is fine, up to 800 ms is a warning and anything slower is a problem. The distance between the checker and your host is part of the number, so a site hosted far away reads slower here than it does for nearby visitors.

Time it yourself

curl -o /dev/null -s -w "dns %{time_namelookup}\nconnect %{time_connect}\ntls %{time_appconnect}\nfirst byte %{time_starttransfer}\ntotal %{time_total}\n" https://example.com/

Each figure is cumulative, in seconds. If the gap between tls and first byte is large, the server is thinking. If connect is already slow, it is distance or the network.

Redirect chains

More than one redirect before the page gets a warning. The usual chain is http://www. to https://www. to https:// without www: two round trips before anything loads. List the hops:

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

Fix it with one rule that sends every variant straight to the final address, at the CDN or the server, and make sure the WordPress Address and Site Address settings already use that final form.

Where slow first bytes come from

• No page cache, so every visit runs PHP and MySQL. This is the most common cause; see the page cache guide.
• Slow database queries from a plugin or a large wp_options table. The Query Monitor plugin lists the slow queries on each page.
• Too much autoloaded data: options WordPress loads on every request whether the page needs them or not.
• A plugin calling an outside API while the page is being built.
• Busy PHP workers on a small plan: requests queue before PHP even starts.

Check the fix

Rerun the check, and time the page with the curl command above from a machine near your visitors. A cached page from a nearby server usually answers in well under 300 ms.