How to Optimize Your Web Hosting Performance

Buying a larger SiteGround or Kinsta plan to compensate for an uncached page builder is a donation. Optimization on the host side is version, workers, object cache, and geography. Optimization on the app side is queries and assets. Do them in that order and you will know when hardware is actually the bottleneck.

Current PHP is faster and patched. Shared panels at Bluehost, A2, and InMotion let you pick a version; do it on staging first. Workers (or PHP-FPM children) cap concurrency. WP Engine and Kinsta sell them as plan dimensions because WordPress is worker-hungry when cache misses. memory_limit errors look like white screens, not “slow.” Raise memory carefully; it is not a substitute for a leak. When the origin is on old PHP with two workers, Cloudflare will only hide it for cached GET requests. Logins, carts, and previews still hit PHP. Fix the runtime. Then put a CDN in front. The other order is how you pay for bandwidth to deliver a slow first byte.

Anonymous HTML should be served from page cache: host layer (SiteGround, WP Engine, Kinsta), LiteSpeed on A2 Turbo, or a well-configured plugin. Logged-in and cart traffic need Redis or equivalent object cache—Cloudways toggle, many VPS installs, some managed plans. The edge (Cloudflare) caches static files easily and HTML only when you understand cookies. Stacking three page caches without a plan creates mystery misses. Pick a primary HTML cache. Use Redis for the rest. Purge on publish. If you cannot explain which layer answered a request, you cannot optimize it. Edge is not a personality. It is a cache key.

Ten years of revisions, transients, and a stats plugin will make any DigitalOcean droplet look tired. Query the slow log if you have SSH (Cloudways, A2, DreamHost). Object cache reduces repeat hits; it does not fix a missing index on a poorly written plugin. Clean revisions, expire transients, and delete abandoned tables after plugin removals. WooCommerce especially accumulates. Managed hosts sometimes offer DB tools; use them. A bigger AWS instance will run a bad query faster and still be a bad query. Hosting performance includes saying no to plugins that write on every page view. MySQL is the quiet bottleneck behind “we need more RAM.”

Physics still applies. A SiteGround or Kinsta datacenter far from customers adds latency before PHP even runs. Cloudways and Kinsta make region a choice—use it. Cloudflare helps static assets and TLS; it does not move your MySQL to the visitor’s city. If your audience is split, you still usually pick one origin and an edge, not two writes. Multi-region WordPress is a project. For a national small business, one nearby region plus Cloudflare is the mature setup. Do not pick a region because the price was a dollar cheaper. TTFB is user-facing. Price is not.

After PHP is current, cache is sane, images are sized, and queries are not embarrassing, if workers are maxed during real traffic, buy more box. That might be A2 Turbo to VPS, SiteGround shared to cloud, Cloudways resize, or a Kinsta plan with more workers. It might not be a new page builder. Watch CPU and RAM graphs on Cloudways or the host dashboard. If they are idle and the site is slow, you still have an app problem. If they are pegged, stop blaming Elementor for physics. Vertical scale is cheaper than a replatform. Horizontal scale is a different article. Honesty about the bottleneck is the optimization.

Raise PHP, size workers, cache HTML and objects on purpose, clean the database, pick a nearby region, then resize. Cloudflare and Kinsta cannot diet a plugin you refuse to remove. When the graphs peg, pay for RAM. Until then, do not.