Hosting for WordPress speed: what to ask and test

What the host controls

The general hosting guide covers plan types and how to compare them. This guide is about what WordPress needs from a host.

The WordPress Advanced Administration Handbook lists the factors: the hosting environment, WordPress configuration, software versions, and the number and size of images. Of these, the host decides the environment and the software. It lists what matters in the environment as the number of processors, processor speed, memory, disk space and the type of disk, and says that providers generally give higher performance for a higher price. It also names distance to your visitors and the load on the server.

What to check

PHP: version and settings

The handbook says PHP's version and configuration have a large impact on how well, and whether, WordPress runs. Newer versions bring performance and security improvements. It also says to take care when upgrading, because older plugins and themes may not work with a newer version. Test on a staging copy first. The version numbers it names are tied to its writing date, so use the Site Health result and the PHP project's supported-versions list instead of any number printed here.

Two settings often matter:

• Memory. WordPress asks for 40 MB to build the front end of a site, and 64 MB on a Multisite network. For the admin it asks for 256 MB. These are the defaults named by the handbook, and a server setting higher than these is left alone. Large themes, page builders and stores may need more.
• Time limits. The handbook explains that PHP has a maximum execution time, and the web server has its own. Values need to work together, and on shared hosting they are often fixed, so ask the host.

Resource limits on shared hosting

On shared plans, the handbook says to look at the limits of the plan: disk input and output, IOPS, the number of processes and the total processes. A site that reaches one of these can slow down or fail, even if the server as a whole is fast. If your site slows only at busy times, or shows errors such as 503, ask the host which limit you reach.

What does not belong on the web server

The handbook's advice: do not run DNS on your WordPress server, use a commercial or registrar DNS service instead. Do not run a mail server on it either. For contact forms, use a form plugin with an external mailing service. Both free the web server for pages. The first also makes switching servers easier.

Step 1: read Site Health

Open Tools, then Site Health. The Status tab runs the checks. Note, in this order:

1. PHP version.
2. The database server.
3. Page cache.
4. Persistent object cache.
5. Opcode cache.
6. Loopback requests and scheduled events.
7. HTTPS.

Anything marked critical or recommended is a question for the host. Screenshots make support requests clearer.

Step 2: measure the server

Measure how long the server takes to answer, with and without a cache. The server response time guide shows a one-line measurement with curl. Take:

• one cached page, as a logged-out visitor;
• one page the cache skips, such as a search result page, or a page while logged in;
• the same two at a quiet hour and a busy one, if you can.

WordPress's own threshold in Site Health is a median of 600 milliseconds. That figure comes from web.dev's time-to-first-byte guidance, and it is also Lighthouse's limit for the server response. Aim well below it for cached pages.

Read the results like this:

Step 3: decide whether to upgrade or move

Upgrade the plan, or move, only after the cheaper fixes. The order that tends to pay off:

1. A page cache that works.
2. A current PHP version with the opcode cache on.
3. A persistent object cache, if your site is dynamic.
4. Fewer or lighter plugins and images.
5. A better plan or host.

Signs that the host is the limit: Site Health shows the right settings, the plugins are tidy, and uncached pages are still slow; the site slows or errors at busy times; or the host will not offer a current PHP version, a cache or a staging site.

Moving, in the handbook's order

The handbook's guide to moving WordPress to a new server begins with a backup of the files and the database. When the domain and addresses stay the same, moving is mostly copying the files and the database to the new server, and changing the database name and login in wp-config.php if they differ. To test before the switch, you can temporarily change the site address stored in the database. Redirect rules need care when you go live. If you ever need to replace the old domain in the database, use a tool made for it, because a plain search and replace can break stored data that contains the length of the address.

Practical rules:

• Move a copy first and test it, including forms, the cart and the admin.
• Lower the DNS record's time to live a day or two before the change. See DNS performance.
• Keep the old host running until the new one has passed your tests.
• Check the cache and PHP settings on the new host before you switch.

Mistakes to avoid

• Choosing by price alone. A cheap plan with no cache may cost more in lost visitors.
• Choosing by a word. "Managed WordPress hosting" varies. Ask for the list of what is included.
• Upgrading PHP without testing. Do it on staging.
• Moving before fixing the cache. A new server with no page cache can be as slow as the old one.
• Forgetting the CDN. After a move, clear its cache and update the origin.

Check your own page

Run the free audit and look at Document request latency. If the server response fails on a page that should be cached, fix the cache. If it passes on cached pages, test one that is not cached. A gap between the two is where the host's resources and your plugins show.

Sources

• Optimization, PHP and Migrating WordPress in the WordPress Advanced Administration Handbook: the factors, hardware, PHP, memory limits, what not to run on the web server, and moving to a new server.
• WordPress core: Site Health: the PHP, page cache, object cache, opcode cache, loopback and scheduled event tests, and the 600 millisecond threshold.