A few months ago I ran a speed test on my WordPress site and winced: Largest Contentful Paint over 4 seconds on mobile, and a Time to First Byte that made every page feel sluggish. The site is a download site — pages full of screenshots, version tables, and big download buttons — so visitors arrive impatient and leave fast if the page stalls.

This post walks through the exact steps I took to fix it, using my own site as the running example: https://pojavvlauncherapk.net/ — a WordPress site running the Kadence theme on LiteSpeed hosting. Nothing here is theory; every step below is something I changed and measured.

1. Measure first, optimize second

Before touching anything, I recorded baselines in PageSpeed Insights and GTmetrix: LCP, TTFB, total page weight, and request count. I re-ran the same tests after each change so I could tell which tweaks actually moved the needle and which were placebo. If you take one habit from this post, make it this one: never optimize blind.

2. Turn on real page caching with LiteSpeed Cache

Because the server runs LiteSpeed, the LiteSpeed Cache plugin can cache pages at the server level instead of in PHP — repeat visitors get served static HTML without WordPress even booting. In the plugin's Cache settings I enabled page caching, turned caching off for logged-in users (nearly all my traffic is guests, and caching logged-in pages adds invalidation headaches), and set a 30-day browser cache TTL for static assets.

One mistake I made early on: I had both a PHP-level cache plugin and LiteSpeed Cache active, and they fought over the same pages. Pick one caching layer. On LiteSpeed hosting, LiteSpeed Cache wins — it is the only one that hooks into the web server itself.

3. Add object caching so the database stops repeating itself

Page cache handles guests, but menus, widgets, and option lookups still query the database on cache misses. I enabled Redis object caching through the plugin's Object Cache setting, pointed at the Redis instance my host provides, so repeated queries are served from memory. The practical effect: TTFB on uncached pages dropped noticeably, and wp-admin felt snappier too. If your host does not offer Redis, Memcached does the same job — the point is to stop asking MySQL the same question on every single request.

4. Fix the images — the biggest win on a download site

Images were roughly 70 percent of my page weight. Screenshots and feature banners had been uploaded as full-resolution PNGs, some over a megabyte each. Three changes fixed it:

  • Bulk conversion to WebP. I used the image optimization feature inside LiteSpeed Cache, which serves WebP with the original as fallback. File sizes typically dropped 60 to 80 percent with no visible quality loss.
  • Lazy loading below the fold. Screenshots further down the page no longer compete with the hero content for bandwidth. I excluded the logo and the above-the-fold banner from lazy loading so LCP was not delayed by it.
  • Explicit width and height attributes on images to eliminate layout shift, which PageSpeed had been flagging under CLS.

Homepage weight fell from about 3.8 MB to under 1.2 MB. That single change did more for mobile LCP than everything else combined.

5. Put a CDN in front of static assets

Caching helps repeat visitors; a CDN helps everyone else by serving images, CSS, and JavaScript from a location near the visitor. I connected the QUIC.cloud CDN through the LiteSpeed Cache plugin — it integrates natively, just a DNS change and an API key, no extra plugin needed. Static assets now load from edge nodes instead of making a visitor on another continent wait on my single origin server for a stylesheet. Cloudflare works on the same principle if you prefer it; either way, do not serve static files from one box to the whole planet.

6. Trim the theme and plugin fat

Kadence is already a light theme, but I still audited everything:

  • Removed four plugins I was not actively using — an old slider, two analytics plugins, and a social widget. Each one had been adding a stylesheet or script to every page load.
  • Cut Google Fonts down to two weights of one family, loaded with display=swap.
  • Disabled WordPress emojis and embeds — small wins that remove render-blocking requests.
  • Deferred non-critical JavaScript in the plugin's Page Optimization settings, then tested every download button, because deferred scripts are the classic way to break interactive elements. Two scripts needed excluding from deferral.

7. Quiet the background noise: heartbeat, revisions, transients

The WordPress admin-ajax heartbeat, unlimited post revisions, and expired transients add database load that slows down even cached sites, because cache misses still happen. I capped revisions with WP_POST_REVISIONS, limited the heartbeat to post-edit screens, and scheduled a weekly database cleanup. None of this shows up directly in a speed test, but it keeps TTFB stable as the site grows instead of degrading month by month.

What actually changed

After working through this list on https://pojavvlauncherapk.net/, mobile LCP went from 4.2s to 1.7s, page weight dropped by roughly two-thirds, and the PageSpeed performance score moved from red to green. Ranked by impact: image optimization first, then page caching, then the CDN. Everything else was incremental — worth doing, but not where you should start.

Checklist if you are doing this today

  1. Record your baseline: LCP, TTFB, page weight, request count.
  2. Enable server-level page caching; remove competing cache plugins.
  3. Add object caching (Redis or Memcached).
  4. Convert images to WebP, lazy-load below the fold, set dimensions.
  5. Put static assets behind a CDN.
  6. Audit plugins and fonts; defer non-critical JavaScript and test interactions.
  7. Tame the heartbeat, revisions, and transients.
  8. Re-measure after every step.

Speed work is never finished — every new plugin and every uploaded image is a chance to regress. But with caching, optimized images, and a CDN in place, the site has headroom now instead of living on the edge of a timeout.