- Most 'speed up WordPress' lists are the same ten plugin recommendations in different order.
- Here are 12 fixes ranked by what actually moves the needle on shared hosting specifically.
A slow WordPress site on shared hosting usually has one of three root causes: an unoptimized theme or page builder shipping too much CSS/JS, unoptimized images, or no caching layer doing any work — and most "speed up WordPress" advice lists twenty tips without saying which three actually matter for a typical shared-hosting install. Here they are, roughly in order of impact.
The Fixes That Matter Most First
- Install a real caching plugin. If your host runs LiteSpeed, the free LiteSpeed Cache plugin caches at the server layer, meaningfully faster than a PHP-layer plugin like WP Super Cache because it skips invoking PHP entirely for cached requests. If your host runs Apache or Nginx, WP Rocket or W3 Total Cache are the standard picks.
- Compress and resize every image before upload, not after. A 4000px-wide photo displayed at 800px is wasted bandwidth on every single page load; resizing at upload time (or bulk-fixing existing media with a plugin like ShortPixel or Imagify) is usually the single biggest one-time speed win on a content-heavy site.
- Switch to a lightweight theme. Heavy page-builder themes (certain multipurpose themes especially) load megabytes of CSS and JS for features most sites never use. A theme built for speed (GeneratePress, Astra) paired with a simple block editor layout often outperforms a "feature-rich" theme by a wide margin.
- Audit your plugins and delete what's unused. Every active plugin adds database queries and asset loading, whether or not you're using its features today. A site with 40 plugins, half forgotten, is carrying real weight for nothing.
Database and Server-Level Fixes
- Clean up post revisions and spam comments. WordPress keeps every revision of every post by default, and years of them bloat the database table your homepage query touches. Limiting revisions in wp-config.php and running a database cleanup plugin periodically keeps queries fast.
- Enable object caching if your host offers it. Redis or Memcached caches database query results in memory, which matters most on sites with a lot of dynamic content (WooCommerce, membership sites, heavily customized queries).
- Check your PHP version. PHP 8.x is meaningfully faster than PHP 7.x for identical code; cPanel's MultiPHP Manager makes switching self-service on most hosts, and it's worth confirming you're actually on a current version rather than assuming.
- Use a CDN for static assets if your traffic includes international visitors, since serving images and scripts from an edge node near the visitor cuts Time to First Byte meaningfully compared to every request hitting Nepal-based origin servers.
Smaller Fixes That Still Add Up
- Lazy-load images below the fold so the browser doesn't download every image on a long page before the visible content finishes rendering.
- Minify and combine CSS/JS files to cut the number of separate requests a page needs, most caching plugins include this as a toggle.
- Disable emoji scripts and embeds you don't use — WordPress loads a script for emoji rendering on every page by default, easily disabled and rarely missed.
- Set a far-future cache expiry on static assets via .htaccess or your caching plugin, so returning visitors don't re-download unchanged files on every visit.
What Fixes Look Like Together
Applied together, these typically take a WordPress site from a 4-6 second load time down to under 2 seconds on decent shared hosting — a real, measurable difference in both visitor experience and Core Web Vitals scoring, which increasingly affects search rankings directly. The order matters: caching and image optimization alone often solve 70% of a slow site's problem, and it's worth measuring (Google PageSpeed Insights or GTmetrix) before and after each change rather than applying all twelve blind and hoping.
When Shared Hosting Itself Is the Ceiling
If every fix above is applied and the site is still slow specifically under real traffic (not just when tested alone), the bottleneck may genuinely be shared-hosting resource limits rather than WordPress configuration — at that point, moving to a hosting plan with more dedicated CPU/RAM or LiteSpeed's server-level caching (which WebsNP's hosting plans include) solves what no amount of plugin tuning can.