How to Speed Up WordPress on Shared Hosting (Tested)

When you buy through links on our site, we may earn a commission at no extra cost to you. This never changes what we recommend. Read our affiliate disclosure

To speed up WordPress on shared hosting, measure first with PageSpeed Insights, then fix the big four: a working page cache (on Hostinger and other LiteSpeed servers, the free LiteSpeed Cache plugin), a current PHP version (WordPress recommends 8.3 or newer), fewer, lighter plugins, and right-sized images. Then trim heavy third-party scripts such as ads, chat widgets and embeds.

Change one thing at a time and re-test after each step, so you know what helped and what broke.

This site runs on Hostinger shared hosting with LiteSpeed Cache, so the concrete steps below use that setup. The ideas work on any shared host: if yours runs Apache or Nginx instead of LiteSpeed, use one well-known caching plugin in place of LiteSpeed Cache and the rest stays the same. For more guides like this, see our WordPress section.

Before you start

Take a full backup of files and database (see how to back up a WordPress site for free).
Use a staging copy if your plan includes one, so a bad setting doesn’t break the live site.
Write down your starting numbers for the home page and one typical post: PageSpeed mobile score, LCP and TTFB.
Update WordPress, your theme and plugins first. Old plugin versions are a common cause of slow pages and a security risk too (more in our security guides).

Step 1: Measure before you change anything

Open pagespeed.web.dev, paste a post URL and run the test. Look at the Mobile tab first; most visitors and Google’s ranking signals lean mobile.
Note Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) and, in the diagnostics, the server response time, which is your Time to First Byte (TTFB).
If your site gets enough visits, the top of the report also shows real-user data, including Interaction to Next Paint (INP). That field data is what Google uses, not the lab score.
Run each test three times and use the middle result. Lab scores vary from run to run, especially on shared servers.

Metric	What it measures	Good target
LCP	When the main content (usually the top image or headline) appears	2.5 seconds or less
INP	How quickly the page responds to taps and clicks	200 ms or less
CLS	How much the layout jumps while loading	0.1 or less
TTFB	How long the server takes to start sending the page	0.8 seconds or less

Targets from Google’s web.dev guidance, measured at the 75th percentile of real visits.

Read the numbers before acting on them. A high TTFB (well over a second) points at the server side: no page cache, old PHP or a heavy plugin. A good TTFB with a slow LCP points at the page itself: big images, render-blocking CSS and JavaScript, or third-party scripts.

Step 2: How to speed up WordPress with a page cache

A page cache serves a ready-made HTML copy of each page instead of running PHP and database queries on every visit. It’s the single biggest win on shared hosting, because it cuts the work your limited CPU share has to do. On a LiteSpeed server the right tool is the LiteSpeed Cache plugin, because it talks directly to the server’s built-in cache.

In WordPress, go to Plugins → Add New, search for LiteSpeed Cache, install and activate it. On Hostinger it’s often preinstalled.
Deactivate any other page caching plugin. Two caches fighting each other is a classic cause of broken or stale pages.
Go to LiteSpeed Cache → Cache and on the Cache tab make sure Enable Cache is On. Leave Cache Logged-in Users off unless you run a membership site.
On the Browser tab, turn on Browser Cache so returning visitors reuse images, CSS and fonts.
Optional: LiteSpeed Cache → Presets offers ready-made levels. Start with a basic or advanced preset rather than the most aggressive one.

Check that the cache actually works

Turning caching on isn’t the same as pages being cached. Open a post in a private window (logged-out visitors are the ones who get cached pages) and reload it once. Then open your browser’s developer tools (F12) → Network, click the page request at the top and look under Response Headers.

x-litespeed-cache: hit means the page came from the cache. This is what you want.
miss on the first load is normal. A miss on every reload means something stops the page being stored.
no-cache means the page is deliberately excluded, for example by an exclude rule or because you’re logged in.

If you never see a hit, check LiteSpeed Cache → Cache → Excludes for rules you didn’t mean to add, and look for a plugin that sets a cookie for every visitor (some consent, A/B testing and cart plugins do). The plugin’s debug log, under Toolbox, records why a page wasn’t cached.

Step 3: Switch to a current PHP version

Newer PHP versions run WordPress faster and still get security fixes. WordPress recommends PHP 8.3 or greater. On Hostinger, open Websites → Dashboard next to your site, search the sidebar for PHP Configuration, pick a version and click Update. Hostinger currently offers PHP 8.2 up to 8.5 for selection.

Hostinger’s own help page says the PHP version applies to every website on the plan, and downgrading to an older version is blocked. Check that your theme and plugins support the new version (their changelogs or support pages usually say), and test on staging before switching the live plan.

Step 4: Remove plugins you don’t need

Deactivate and delete anything unused, and replace heavy all-in-one plugins with lighter single-purpose ones where you can. Plugin count matters less than what each one does: one plugin that runs slow database queries on every page can cost more than ten small ones.

If you don’t know what’s slow, install a diagnostic plugin such as Query Monitor, load a slow page while logged in and look at the queries by component. It points to the plugin or theme causing slow database queries. Remove the diagnostic plugin when you’re done.

Step 5: Fix images

Upload images close to the size they’re shown at. A 4,000-pixel photo in an 800-pixel content column wastes bandwidth on every visit.
Serve modern formats such as WebP. LiteSpeed Cache’s Image Optimization can convert your existing library, but it uses the QUIC.cloud service, which has free and paid tiers.
Keep WordPress’s built-in lazy loading for images further down the page. Recent WordPress versions already skip lazy loading on the first large image and mark it as high priority, so don’t force lazy loading on your featured image with another plugin.
Set width and height on images (WordPress does this for images added through the editor) so the layout doesn’t jump, which keeps CLS low.

Step 6: Turn on an object cache if your plan has one

An object cache keeps database results in memory. It mostly speeds up the admin area and pages that can’t be fully cached, such as carts and logged-in pages. Hostinger offers it on Business web hosting plans and above: open your site’s dashboard, go to WordPress → Overview and turn on Object Cache. Hostinger says it’s switched on automatically once LiteSpeed Cache is installed on supported plans. You can confirm the connection in LiteSpeed Cache → Cache → Object.

Step 7: Tame third-party scripts, CSS and JavaScript

Ads, chat widgets, social embeds, video players and tracking pixels often cost more than everything else combined, and no server setting can fix them. Remove what you don’t use, show YouTube videos as a click-to-play thumbnail, and load non-essential scripts later.

LiteSpeed Cache’s Page Optimization section can minify and combine CSS and JavaScript and delay scripts until the visitor interacts. Its Critical CSS and Unique CSS features also run through QUIC.cloud. These options give big gains on some sites and break others.

Turn on CSS and JavaScript options one at a time. “Remove unused CSS” and “delay JavaScript” options can break menus, forms, consent banners and ads. After each change, purge the cache and check the site logged out on a phone, including that ads and consent messages still appear.

Step 8: Clean up the database and background tasks

LiteSpeed Cache → Database can remove old post revisions, spam comments and expired transients. Back up first.
The WordPress Heartbeat (autosave and live notifications in the editor) can be slowed down under LiteSpeed Cache → Toolbox → Heartbeat if your host reports high CPU use from admin-ajax.php.
Scheduled tasks (WP-Cron) run when visitors load pages. On busy sites, a real server cron job is steadier; Hostinger has a Cron Jobs tool in hPanel.

Results on our site

Why is my WordPress site slow on shared hosting?

On shared hosting, your site shares a server’s CPU and memory with other accounts, and your plan caps how much of it you can use. Every uncached page view runs PHP and database queries, so traffic spikes, bots and heavy plugins push you into those limits. A page cache removes most of that work, which is why it comes first in this list.

The other common causes are on the page itself: large images, a heavy theme or page builder, and third-party scripts. Those slow the page in the visitor’s browser no matter how fast the server is.

If it still doesn’t work

Server response still slow with caching on: check the cache header. If it’s a miss, find the cookie or exclude rule that bypasses the cache. If it’s a hit and still slow, the delay may be network distance; a CDN can help.
Admin area slow but the public site fast: that’s normal, because admin pages are never page-cached. An object cache and removing heavy plugins help here.
Site looks broken after optimizing: undo the last setting you changed, purge all caches (LiteSpeed Cache → Toolbox → Purge) and test again.
Your host warns about resource limits: check the usage graphs in your hosting panel. If you’re at the limit even with caching working, it’s time to move up a plan.

FAQ

Is shared hosting too slow for WordPress?

Not for most blogs. With a working page cache, a current PHP version and light pages, a shared plan can serve a content site quickly. Upgrade when you keep hitting your plan’s resource limits, not before.

What are the best LiteSpeed Cache settings?

There’s no single best set. Turn on page caching and browser cache first, confirm you get cache hits, then add image and CSS/JS options one at a time and test after each.

Do I need a CDN?

It helps most when many readers are far from your server. Use one CDN at most, and make sure your page cache works first, since a CDN won’t fix a slow, uncached server.

Do more plugins always slow a site down?

Not always. One heavy plugin can cost more than ten small ones. Measure, and remove what you don’t use.

How often should I re-test my site speed?

After every theme change, new plugin or ad setup, and every few months otherwise. Search Console’s Core Web Vitals report will also flag pages that get slower.