WordPress performance
Find the wait before changing hosts.
Smaller images cannot fix every wait.
You compress the pictures and remove an unused plugin. The page still pauses before anything useful appears. Another round of the same changes may leave the real delay untouched.
Hosting can be the constraint. So can a slow database query, an external request or a long connection. Start by finding where this page spends its time.
Choose a page that matters. Test the service page customers enter, the article they read or the shop action that feels slow.
Describe the symptom. Does the screen stay blank, does the main image arrive late, or does an action pause after the page appears?
Keep the context. Record the URL, time, device, location and whether the visitor was signed in. “The site is slow” is hard to investigate; a repeatable example is useful.
A page has more than one place to wait.
1. Reach the response
The browser follows redirects, finds the address and makes a connection. Distance and the network can affect this part before WordPress does its work.
2. Produce the page
A cache may supply a saved response. Otherwise, WordPress may need PHP, database queries and other work to generate it. A long wait here needs investigation at the server.
3. Show useful content
The browser still has to download resources and display the page. A quick initial response can be followed by a late image or heavy browser work.
Time to First Byte (TTFB) measures the wait until a response begins arriving, including connection stages. It is a useful clue, not a measurement of hosting quality alone. Check what the visitor sees as well.
Capture a comparison you can repeat.
- Open a private browser window, then Chrome DevTools and its Network panel.
- Reload the chosen page. Select the main document request and open Timing.
- Look at redirects, connection setup and waiting for the response. Also note when useful page content appears.
- Repeat under the same conditions and keep the range of results. One unusually fast or slow run is weak evidence.
Chrome’s timing reference explains the phases. Browser tools let you investigate locally without buying a testing service.
Separate the caches.
Disabling the browser cache does not establish that the hosting or CDN cache was bypassed. Ask the host how its response headers identify a cache hit or miss, and use its documented method to compare them.
For example, a saved public article may arrive promptly while an uncached request waits. That directs attention to generating the response. It does not yet tell you whether the cause is resource limits, application code or an external dependency.
Google’s TTFB diagnosis guide explains why cached results can hide slow origin responses.
Let the evidence choose the next check.
A long wait for the response
Compare cached and uncached requests. Ask for evidence of resource pressure, slow queries or slow outbound calls at the recorded time. A larger server may help a capacity limit; it will not remove every source of waiting.
A fast response, a late page
Inspect the resources and browser work that follow the document. Start with the delayed image, script or rendering step. A hosting move needs a reason tied to that delay.
Slow only in some conditions
Compare audience locations, busy periods and signed-in actions separately. A nearby cached page cannot stand in for an uncached checkout or a distant visitor.
Buy the service your site needs.
Managed WordPress hosting
Useful when you want a provider to take responsibility for agreed maintenance and support. Confirm what the plan actually includes: updates, backups, restore help, monitoring and investigation of slow requests.
The label does not define the service. Ask what the provider handles when your particular site is slow and which limits apply during busy periods.
A VPS or your own server
Useful when you need control and have someone to operate it. Check the allocated resources, any shared or burst capacity, and who handles security updates, monitoring, backups and incidents.
More control also gives you more work. Compare the complete service you need, including the person who maintains it.
A CDN is a separate decision. It can serve reusable content closer to visitors. It does not make every personalized or uncached request fast. Confirm what can be shared safely and how changed pages leave the cache.
The WordPress performance handbook covers both hosting and application work. Treat them as parts of the same investigation.
Make the provider answer the useful questions.
- Capacity: what CPU, memory and concurrent processing limits apply, and what happens when the site reaches them?
- Evidence: can the provider inspect a slow request at a supplied URL and timestamp?
- Audience: where will responses come from for your main visitors, including requests the cache cannot serve?
- Storage and database: what matters for this workload, beyond an SSD or NVMe label?
- Responsibility: who restores a backup, investigates an outage and maintains the software?
“Unlimited”, “enterprise” and “cloud” do not answer these questions. Compare written limits and responsibilities with the problem you measured.
Prove the improvement before the move.
If the evidence points to hosting, test a representative copy on the proposed setup. Use the same pages and conditions. Include both saved responses and the actions that require WordPress to do fresh work.
Rehearse the transfer with a usable backup. Check images, links, forms, sign-in and any order flow. Plan how new orders, uploads and edits will be handled during the change so they are not stranded on the old server. The WordPress migration guide explains the underlying transfer requirements.
A better hosting choice is one you can connect to a measured improvement and maintain afterward. Keep the before-and-after evidence. It gives you a firmer answer than another impressive plan name.