Hosting performance is the ability of the server and platform to deliver the website reliably under real traffic and administrative work. A fast homepage in an empty test does not prove that checkout, search, scheduled jobs, backups or the WordPress dashboard will perform when the business needs them.
Separate server work from browser work
| Layer | Examples |
|---|---|
| DNS and connection | Slow resolution, distance, TLS or network routing |
| Application/server | PHP work, database queries, uncached requests and external APIs |
| Cache/CDN | Misses, poor rules, stale content or geographic delivery |
| Front end | Images, fonts, CSS, JavaScript and third-party scripts |
| Business integration | Payment, booking, CRM, email and stock services |
Test representative page types
Measure the homepage, an article, a form, search, a logged-in administrative action and any checkout or booking journey. Cache can make public pages appear fast while uncached and logged-in workflows remain slow. Test at different times and use field data where enough traffic exists.
Assess the hosting environment
- Current supported PHP and database versions with a safe upgrade process
- Resource limits and behaviour during traffic or background-job spikes
- Server-side caching and the ability to exclude personalised pages
- Backup, staging, logs and restoration access
- Object cache or other persistent caching where the workload benefits
- Support response for application, database and network incidents
- Geographic location, CDN arrangement and data-processing implications
Profile before upgrading the plan
A larger hosting plan cannot repair an inefficient plugin query, a blocked external API or an oversized uncached page. Use server timing, application monitoring, query inspection and error logs to identify the bottleneck. Move hosting when the platform is the constraint, not as a substitute for diagnosis.
Protect dynamic pages from unsafe caching
Basket, checkout, customer account, personalised membership and administrator pages usually need different cache rules from public content. Test logged-in and logged-out users, stock changes, payment callbacks and form confirmations after cache configuration. A cached private response can be a security and privacy failure, not just a display bug.
Plan a hosting change as a migration
Record the server stack, scheduled jobs, DNS, email routes, certificates, cache rules and integrations. Create a complete backup, test the site at the destination before switching traffic and keep a rollback window. Do not cancel the old service until DNS, email, forms and monitoring are verified.
Use performance acceptance criteria
Agree observable results: response time for uncached pages, error rate, checkout reliability, backup duration, administrative responsiveness and recovery support. Core Web Vitals help assess the visitor experience, but they do not replace server and transaction monitoring.
Evidence to request from a host or developer
- Server response and error-rate data for representative uncached requests
- Resource-limit events, slow-query evidence and background-job failures
- Cache exclusions for personalised and transactional pages
- Backup and restoration results, not only marketing retention claims
- Clear escalation ownership when the host blames a plugin and the developer blames the host
The evidence should lead to a specific bottleneck and action rather than a generic recommendation to buy more resources.
Practical next step
List the five most important page or transaction types and measure each one with cache state and server response separated. Investigate the slowest layer before buying a larger plan.
Sources and date checked
This guide was checked on 21 July 2026. WordPress, plugins, hosting platforms and commercial terms change, so confirm the current documentation and licence details before making a material change.
Keep the decision under your control
Retain the relevant accounts, source material, supplier terms and recovery information. Recheck changing prices, interfaces and rules before acting.