I Cut My WordPress Theme's Load Time by 68% — Here's the Exact Process

Last October, a client sent me a GTmetrix report for his business site. Fully loaded time: 5.8 seconds. LCP: 4.2 seconds. His PageSpeed score was 38 on mobile. Thirty-eight.

He was using a popular premium theme — one that gets recommended in almost every "best WordPress themes" article online. Great demo. Beautiful screenshots. And an absolute slug in production.

Six hours of work later, the same site loaded in 1.9 seconds. LCP dropped to 1.4 seconds. Mobile PageSpeed jumped to 91. The month after, his contact form submissions went up 34%. Same content, same design, same traffic source. Just faster.

This is what I did, in order, with the exact reasoning behind each step.

The Audit: Finding What's Actually Slow

Before you touch anything, you need to know where the time goes. Not guesses. Data.

I use three tools for this: GTmetrix (for waterfall charts), PageSpeed Insights (for Core Web Vitals), and the browser's Network tab in DevTools. GTmetrix shows you the waterfall — every single file loaded, in what order, and how long each one took. That's where the answers live.

On this particular site, the waterfall told a clear story. The theme loaded 14 CSS files and 11 JavaScript files on every page. The hero image was a 2.4MB PNG. Three Google Fonts were being fetched from fonts.googleapis.com (three separate HTTP requests). And the site was on shared hosting with a 680ms TTFB (Time to First Byte) before anything even started loading.

So four distinct problems: too many files, oversized images, external font requests, and slow server response.

Step 1: Fix the Server (TTFB Under 400ms)

Cheap shared hosting is the silent killer of WordPress performance. You can optimize everything else perfectly, and if your server takes 800ms to start responding, you're cooked.

This client was on a $5/month shared host. I migrated him to Cloudways (DigitalOcean, 2GB RAM, Amsterdam server) for $28/month. TTFB dropped from 680ms to 190ms. That alone cut nearly half a second off every page load.

Is $28/month expensive? Not if your website generates business. A real estate agent spending $200/month on Google Ads but $5/month on hosting is making a weird bet.

Quick test: Open GTmetrix, test your site, and look at the TTFB number. If it's above 400ms, your hosting is the bottleneck. Fix that before optimizing anything else — otherwise you're polishing a car with a flat tire.

Step 2: Kill Unnecessary CSS and JavaScript

14 CSS files. On a page that needed maybe three.

The theme shipped with Font Awesome (140KB), Animate.css (80KB), a lightbox library, a slider library, and three different grid systems. Plus WooCommerce styles were loading on every page even though the site only had a single "Shop" page.

Here's what I did:

First, I identified which CSS and JS files actually fired on the homepage. DevTools → Coverage tab → reload page. This shows you exactly how much of each file is actually used. The result was ugly: 78% of loaded CSS was unused. Seventy-eight percent.

Then I used Asset CleanUp Pro ($39 one-time) to selectively disable scripts and styles on pages that don't need them. WooCommerce styles → only load on /shop/ and /cart/. Contact Form 7 scripts → only load on /contact/. Slider library → only load on homepage.

I also swapped Font Awesome for a custom SVG icon set with just the 8 icons the site actually used. Went from 140KB to 3KB. That trade takes about 20 minutes and makes a noticeable difference.

After this step: 14 CSS files became 4. 11 JS files became 3. Total page weight dropped from 3.2MB to 1.1MB.

Step 3: Fix the Images (the Biggest Win)

That 2.4MB hero image? It was a PNG screenshot of a city skyline, displayed at 1200px wide. The original file was 4800px wide. Nobody's monitor needs 4800 pixels for a background image that gets overlaid with text.

Three changes made the biggest impact of the entire optimization:

Resize before upload. No image on the site needed to be wider than 1600px. I batch-resized everything in the media library using a quick PHP script. Saved about 40% right there.

Convert to WebP. WebP gives you the same visual quality at roughly 25-35% the file size of JPEG. ShortPixel's WordPress plugin handles the conversion automatically — upload a JPEG, it creates a WebP version and serves it to browsers that support it. Which is all of them in 2026.

Lazy load everything below the fold. WordPress 5.5+ has native lazy loading for images, but some themes override it. Check your page source — every img tag except the hero should have loading="lazy". If it doesn't, the theme is fighting you.

That hero image went from 2.4MB to 89KB. Same visual quality. Let that sink in.

Step 4: Fix the Fonts

Google Fonts are great. Loading them from Google's CDN is not.

Every Google Fonts request means your browser has to: resolve fonts.googleapis.com DNS, connect to Google's server, download the CSS file, parse it, then connect to fonts.gstatic.com to download the actual font files. That's a lot of round trips, and each one adds latency.

The fix is stupid simple. Download the font files, put them in your theme directory, and load them from your own server. One DNS resolution instead of two. Faster loading, and as a bonus, you're not sending your visitors' data to Google (which matters for GDPR if you're in Europe — this client was in Germany, so it really mattered).

Google Webfonts Helper (google-webfonts-helper.herokuapp.com) generates the @font-face CSS and gives you the files to download. Copy, paste, done. Takes five minutes.

Time saved: roughly 200-400ms depending on the visitor's connection.

Step 5: Caching + CDN

With the heavy lifting done, caching becomes the cherry on top.

I set up WP Rocket ($59/year) with these settings: page caching on, browser caching on, minify + combine CSS (careful — "combine CSS" breaks some themes, test after enabling), defer JavaScript loading, and preload the critical CSS.

For the CDN, Cloudflare's free plan is good enough for most sites. It caches your static assets (images, CSS, JS) on edge servers worldwide, so visitors get files from a server near them instead of from your origin. Set it up in 15 minutes, forget about it.

One gotcha: if you use Cloudflare's "Rocket Loader" feature, test carefully. It rewrites how JavaScript loads and breaks some themes and plugins. I leave it off by default and only enable it if everything else is already optimized and I'm chasing the last few points on PageSpeed.

The Results

MetricBeforeAfterChange
Fully Loaded5.8s1.9s−68%
LCP4.2s1.4s−67%
PageSpeed (mobile)3891+53 points
Total Page Size3.2MB680KB−79%
HTTP Requests4714−70%
TTFB680ms190ms−72%

Six hours of work. $28/month extra for hosting, $59/year for WP Rocket, $39 one-time for Asset CleanUp Pro. Total investment under $200 for the first year.

Contact form submissions went up 34% the following month. That's not a typo. Faster site → less bounce → more conversions. Google has been saying this for years, and it's true.

What Matters Most (and What Doesn't)

After doing this across maybe 40-50 sites over the years, here's my hierarchy of what actually moves the needle:

Biggest impact: Image optimization. Every single time. I've never audited a slow WordPress site that didn't have image problems. Fix this first.

Second biggest: Server response time. If TTFB is above 400ms, nothing else you do will get you under 2 seconds total load. Move to better hosting.

Third: Removing unused CSS/JS. Most themes ship 60-80% more code than any single page needs. Asset CleanUp or Perfmatters can surgically remove what you don't need.

Fourth: Fonts. Self-host them. Always.

Barely matters: Minification. Yeah, shaving whitespace from CSS saves a few KB. But if your hero image is 2MB, minifying CSS is like bringing a cup to bail out a sinking ship.

Can actually hurt: "Optimize" plugins that promise one-click speed. Some of these inject their own JavaScript, create database bloat from their logs, and conflict with your caching plugin. I've seen "speed optimization" plugins that made sites slower. Not kidding.

Core Web Vitals in 2026: What Changed

Quick update for anyone reading older speed guides: First Input Delay (FID) was replaced by Interaction to Next Paint (INP) as a Core Web Vital in March 2024. INP measures how responsive your site feels across all interactions, not just the first click.

What this means in practice: heavy JavaScript is more punishing than before. A theme that loads a massive JS bundle will tank your INP score even if it technically loads fast. Another reason to prefer lightweight themes like GeneratePress and Kadence over the "200 features included" multipurpose monsters.

The three Core Web Vitals you need to pass in 2026:

LCP (Largest Contentful Paint): under 2.5 seconds. This is usually your hero image or headline. Fix: optimize images, preload the LCP image, fast server.

INP (Interaction to Next Paint): under 200ms. This is about JavaScript efficiency. Fix: remove unused JS, defer non-critical scripts, avoid themes with heavy client-side rendering.

CLS (Cumulative Layout Shift): under 0.1. This is about elements jumping around as the page loads. Fix: set explicit width/height on images, avoid injecting content above the fold after load, use font-display: swap for web fonts.

Check your numbers at pagespeed.web.dev and in Google Search Console under "Core Web Vitals." If you're green across all three — you're in better shape than 80% of WordPress sites.


TR

Thomas Richter

WordPress developer since 2008. Obsessed with making themes load faster. Full bio →