How to Speed Up WordPress on Hostinger

Hostinger runs LiteSpeed Web Server on every plan, so a WordPress site can be fast out of the box, but a stock install usually leaves half the speed on the table. Caching layers are off by default, PHP is not always on the latest version, image optimization requires a toggle, and the Hostinger CDN is a plan-tier feature most owners forget to enable. This guide walks through every speed lever on Hostinger in the order they pay off, with the exact hPanel path for each and a realistic estimate of how much each change moves the numbers.

What Speed Improvements Are Realistic on Hostinger?

The table below shows approximate TTFB reductions for each optimization step on a typical Hostinger Business plan running a standard WordPress site. Individual results vary depending on theme, plugin count, and database size, but these ranges are consistent across fresh installs with a lightweight theme and under 20 active plugins.

Step 1: Measure Before You Optimize

Optimization without a baseline is guessing. Before you toggle anything, run PageSpeed Insights or GTmetrix three times against your homepage and against your slowest inner page (usually a category archive or a WooCommerce shop). Save the median results. You want three numbers on the page:

• Time to First Byte (TTFB): under 500 ms on a shared plan. If your baseline is over 1,000 ms, caching alone will not fix it; the fix is upstream.
• Largest Contentful Paint (LCP): the Core Web Vital Google actually ranks on. Under 2.5 s is the target.
• Total page weight: a homepage over 3 MB is image-bound. Caching shaves milliseconds; deleting 2 MB of unused JavaScript shaves seconds.

Come back to these numbers after every change so you can tell what actually moved the needle.

Step 2: Turn On LiteSpeed Cache and Object Cache

The single biggest lift on Hostinger is enabling the two caching layers that ship with the LiteSpeed stack but sit off in fresh installs. LiteSpeed Cache stores fully-rendered HTML pages so guest visitors skip PHP entirely; Object Cache stores database query results so logged-in and dynamic pages skip the database. Together they typically cut TTFB by 60 to 80 percent on cacheable pages and 20 to 40 percent on dynamic pages.

Follow how to enable LiteSpeed Cache on Hostinger for the hPanel toggle and LSCWP plugin settings, then how to enable Object Cache on Hostinger for the Business-plan Memcached layer. Both are prerequisites for every step that follows, because the other optimizations either depend on LiteSpeed running or amplify its benefits.

Step 3: Upgrade PHP to the Latest Version

Every major PHP release ships with 10 to 20 percent throughput gains over the previous one. If your site is stuck on PHP 7.4 or 8.0, upgrading to 8.2 or 8.3 alone can drop TTFB by 100 to 200 ms with no other changes.

In hPanel, open Websites, select your site, and go to Advanced > PHP Configuration. Set PHP Version to the latest supported release (8.3 at the time of writing on most plans). Enable OPcache in the same panel if it is not already on; it caches compiled PHP bytecode in memory. Save and reload your site. If a plugin or theme is not compatible with the new PHP version, you will see a fatal error, roll back one version and update the offending plugin.

Step 4: Enable Brotli Compression

Brotli is a text compression algorithm that shaves 15 to 25 percent off transferred HTML, CSS, and JS versus the older gzip. It is off by default on some legacy Hostinger accounts. In hPanel, open Advanced > Cache Manager (or on newer accounts, WebSite > Performance) and confirm Brotli is set to ON. No plugin or code change is needed; the server negotiates it with browsers automatically.

Step 5: Turn On the Hostinger CDN

The Hostinger CDN caches static assets (images, CSS, JS) on Cloudflare-backed edge servers, so visitors do not hit your origin for every page load. Expect 30 to 60 percent faster asset delivery for international visitors and a modest drop in origin CPU load. It is included on Business, Cloud, and Agency plans; Single and Premium plans do not include it.

Enable the CDN through hPanel and confirm no other CDN (like Cloudflare's own DNS-level setup) is fighting it for DNS. The full walkthrough with the DNS check and LSCWP settings collision fix is in how to enable Hostinger CDN on WordPress.

Step 6: Optimize Images

Images are the largest slice of page weight on almost every WordPress site. Two changes move the numbers most:

• Serve WebP versions. In WordPress admin, open LiteSpeed Cache > Image Optimization and click Send Optimization Request. The plugin uploads your media library to QUIC.cloud, receives WebP versions, and stores them alongside your originals. Modern browsers get the smaller WebP file automatically; older browsers fall back to the original.
• Enable lazy loading. WordPress core does lazy-loading for images by default since 5.5. LSCWP extends this to background images and iframes. In LiteSpeed Cache > Page Optimization > Media Settings, turn on Lazy Load Images and Lazy Load Iframes.

Image optimization is usually the single biggest LCP fix once caching is on. On image-heavy sites, this step alone can lift a mobile PageSpeed score from the 50s into the 80s.

Step 7: Clean Up Plugins, Themes, and Third-Party Scripts

Every active plugin adds PHP work, database queries, and often front-end CSS or JavaScript. Every third-party script (analytics, chat widgets, ad networks, tag manager) is a network request the browser has to make before the page paints. The rule of thumb: deactivate anything you cannot articulate a use for.

Run through this checklist:

• Deactivate and delete any plugin you have not used in 90 days.
• Replace bloated themes (Divi, Avada, some Elementor themes) with a lightweight builder-free theme like GeneratePress, Astra Free, or the default Twenty Twenty-Four if you can.
• Consolidate Google Analytics 4 into Google Tag Manager if you have both firing.
• Move chat widgets (Intercom, Drift, Zendesk) to load only after user interaction using a delay-scripts plugin, or defer them behind a click-to-load pattern.

Cutting plugin count by 30 percent commonly drops TTFB by 100 to 300 ms on a shared plan, because each plugin is running its own database queries on every request.

Step 8: Optimize the Database

WordPress accumulates cruft: post revisions, auto-drafts, spam comments, expired transients, deleted-plugin residue. Over a few years these add hundreds of MB and slow every query. Clean it up once, then set a schedule.

The simplest path uses LSCWP's own database tab. Open LiteSpeed Cache > Database and run Optimize All. It removes revisions, drafts, spam, trash, and expired transients in one pass. For a deeper clean including orphaned meta rows, install WP-Optimize and run its full clean once, then let LSCWP handle weekly maintenance. Expect a 5 to 15 percent query-time improvement on databases over 100 MB.

Two additional database tweaks that pay off on older sites:

• Limit post revisions: by default WordPress keeps unlimited revisions for every post. Add define( 'WP_POST_REVISIONS', 5 ); to your wp-config.php file (above the stop-editing comment) to cap revisions at 5 per post going forward. This does not delete existing revisions -- run LiteSpeed Cache's DB clean to remove the backlog.
• Audit the wp_options autoload table: WordPress loads every row flagged as autoloaded on every page request. Plugins often add autoloaded rows and never clean them up after deactivation. In LiteSpeed Cache > Database, check the Autoload Size line. If it is over 1 MB, look for rows from deactivated or deleted plugins and remove them. WP-Optimize shows a per-row breakdown.

Step 9: Control the WordPress Heartbeat API

WordPress fires a background AJAX request (admin-ajax.php) every 15 to 60 seconds for each logged-in session to power auto-save, browser notifications, and the dashboard activity feed. On a content team with multiple editors open at once, or a WooCommerce store where the shop manager refreshes the Orders screen repeatedly, these requests stack up and add measurable CPU load on a shared Hostinger plan.

The fix is to reduce the Heartbeat interval or disable it on pages where it is not useful (front end, non-editing admin screens). Use one of these two approaches:

• LiteSpeed Cache (no extra plugin needed): In LiteSpeed Cache > Page Optimization > Advanced, find the Heartbeat section. You can set separate intervals for the front end, post/page editor, and dashboard. Setting the dashboard interval to 120 seconds and disabling the front end entirely is a safe starting point for most sites.
• Heartbeat Control plugin (free): If you are not using LiteSpeed Cache, install the Heartbeat Control plugin by WP Rocket. It adds a simple settings screen (Settings > Heartbeat Control) where you can control the interval per location with a slider. Set the post editor to 60 seconds and everything else to 120 seconds.

This optimization has the most impact on shared plans with WooCommerce active or with several admin users logged in simultaneously. On a single-user blog, the default Heartbeat interval is rarely a meaningful performance issue.

Step 10: Find the Actual Bottleneck with Query Monitor

Every step above addresses known categories of slowness, but on sites with unusual plugin combinations or heavily customized themes, the actual bottleneck might be something more specific: a single plugin running 200 database queries per page load, a custom post type with an unindexed meta key search, or a poorly written shortcode firing an external API call on every page render.

Query Monitor (free, wordpress.org) surfaces exactly these issues without requiring server access or log parsing:

1. Install and activate Query Monitor.
2. Log in to WordPress and browse to your slowest page while still logged in.
3. The Query Monitor toolbar button shows total query count and total query time for that page load.
4. Click through to the Queries panel and sort by Query Time descending. The worst queries appear at the top.
5. The Caller column shows which plugin, theme, or function generated each query.

Common findings: a contact form plugin running queries on every page load even when no form is present, a SEO plugin scanning meta for every post on archive pages, or a woocommerce extension checking stock on pages that do not show products. In most cases, deactivating the offending plugin or updating to a newer version that caches its queries drops TTFB by 200 to 500 ms on its own.

Remove Query Monitor after your investigation. It adds a small overhead and is not needed for ongoing production monitoring.

When to Upgrade Your Plan

If you have done every step above and TTFB is still over 800 ms, or PageSpeed still flags server response time as an issue, hardware is now the ceiling. The Single and Premium shared plans oversell hardware more aggressively than Business and Cloud plans do, so a heavily loaded shared server can slow every request no matter how well-tuned your site is. Upgrading to a Business plan or above unlocks Object Cache, higher CPU allocation, and the built-in CDN, and typically drops TTFB by another 200 to 400 ms on top of the software fixes. The full stack picture, including when the ceiling is not the plan but the platform, is in the Hostinger WordPress Optimization Guide.