Why WordPress sites get slow over time
A fresh WordPress install with a default theme loads in well under a second. The same site three years later, with 30 plugins, hundreds of media items, and a heavy theme, often takes 4-6 seconds — sometimes more on mobile. The decay is gradual and easy to miss.
Three things cause it: page weight grows (more scripts, more styles, more images), database overhead grows (post revisions, transients, options autoloading), and feature creep adds work to every request (more plugins hooking into wp_head, more analytics, more tracking pixels). None of these are bugs. They're the natural consequence of running WordPress for a while.
The good news: most of the slowdown is reversible without rewriting anything. The fixes are settings changes, not code changes.
Win 1: Lazy load every image and iframe
Lazy loading defers the load of offscreen images until the user scrolls near them. On image-heavy pages this can cut initial page weight by 60-80%. Browsers handle this natively when an image has the loading="lazy" attribute.
WordPress core added native lazy loading in version 5.5, but it only applies to images inserted via the editor — not to images output by themes, page builders, sliders, or background-image CSS. A speed plugin can extend coverage to those.
For background images set in CSS, you need an Intersection Observer approach with data-bg attributes. A. Smith Speed Optimizer includes this for free.
Quick win
Enable lazy loading first. It's the safest optimization — there's almost no scenario where it breaks a site, and the page weight reduction is measurable in the browser DevTools Network tab immediately.
Win 2: Defer non-critical JavaScript
JavaScript loaded in the <head> blocks rendering until the script downloads and executes. On a page with 12 scripts, that's 12 sequential round trips before the user sees anything. Adding the defer attribute tells the browser to download the script in parallel and execute it after the HTML has parsed.
Almost every script can be safely deferred except jQuery (when other scripts depend on it loading first) and any script that injects content above the fold. A. Smith Speed Optimizer always excludes jQuery by default and lets you add custom exclusions per-script for anything else that breaks.
The metric this improves most directly is Largest Contentful Paint (LCP) — Google's primary Core Web Vital for page load performance.
Win 3: Minify HTML output
HTML minification strips whitespace, comments, and unnecessary characters from the rendered HTML before it's sent to the browser. The savings per page are usually small in absolute terms (a few KB), but they're free — you're sending fewer bytes for identical output.
Done correctly, minification preserves anything inside <pre>, <script>, <textarea>, and <style> tags so it doesn't break code samples or formatted content. Done incorrectly, it can corrupt embedded JSON-LD or break inline JavaScript that depends on whitespace.
Most speed plugins handle this safely now, but it's still the optimization most likely to cause edge-case issues. Enable it after the others, and check your site after.
Win 4: Remove WordPress bloat features you don't use
WordPress ships with a long list of features that most sites don't need but loads code for them anyway. Common offenders:
- Emoji scripts and styles — useful only if your theme uses emoji glyphs that need cross-browser fallback. Most don't. Saves ~14 KB per page and one HTTP request.
- oEmbed/Embeds — only needed if you embed YouTube, Twitter, etc. via the WordPress editor. If you embed those manually or via a block, you can disable.
- XML-RPC and pingback — required only for the WordPress mobile app and accepting trackbacks from other blogs. Disable if you don't use either. Also reduces brute-force attack surface.
- Dashicons on the frontend — WordPress's built-in icon font. Used in admin, almost never on the frontend for non-admin users. Saves ~32 KB per page for visitors.
- Shortlinks, Windows Live Writer manifest, RSD link — legacy features that almost nothing uses anymore.
- Query strings on static resources — the ?ver=1.0 suffix on CSS and JS files prevents some CDNs from caching them. Removing it improves cacheability.
Win 5: Clean up your WordPress database
Every time you save a post, WordPress creates a revision. After three years of editing, your wp_posts table can have 10x more revision rows than actual posts. Same story for transients (cached values that should expire but don't always get cleaned up), spam comments (Akismet flags them but they sit there), and trashed posts.
On most sites, you can reclaim 10-50 MB from these by running a single cleanup. The bigger benefit is admin speed — every wp_posts query gets faster when there's less data to scan.
What's safe to clean: post revisions older than your WP_POST_REVISIONS setting, auto-drafts WordPress generated and abandoned, posts in the trash, expired transients, spam comments, and trashed comments. What's not safe: published posts, pages, custom post types, active comments, plugin options.
What about caching plugins?
Page caching is its own category and one of the highest-impact speed optimizations available. But it's usually best done by a dedicated caching plugin (WP Rocket, WP Super Cache, W3 Total Cache, LiteSpeed Cache) rather than bundled into a general speed plugin.
Most caching plugins also include a basic version of the optimizations above (lazy load, minify, defer). If your caching plugin already handles them, you don't need a separate speed plugin to do the same job — pick one and turn off the duplicate features in the other.
A. Smith Speed Optimizer is designed to complement page caching plugins, not replace them. The Pro version adds full page caching for sites that don't already have it.
What about Critical CSS and image conversion?
Critical CSS extracts only the styles needed to render the above-the-fold content and inlines them in the <head>, so the browser can render before the full stylesheet downloads. It's a noticeable LCP improvement on pages with large CSS files.
WebP/AVIF image conversion replaces JPEG and PNG images with modern formats that are typically 25-50% smaller at the same visual quality. Browsers that don't support the new format still get the original.
Both are heavier optimizations that require server-side processing (Critical CSS) or storage of converted images (WebP/AVIF). They're worth doing — they're in A. Smith Speed Optimizer Pro.
How to know if it actually worked
Don't trust the speed plugin's own score — measure with independent tools:
- Google PageSpeed Insights (pagespeed.web.dev) — runs Lighthouse on a real Chrome browser. Gives you Core Web Vitals scores plus specific recommendations.
- WebPageTest (webpagetest.org) — runs from physical machines in real-world locations. Better for understanding waterfall behavior and time-to-first-byte.
- Chrome DevTools Network tab — open the page, hit reload, look at total bytes transferred and request count. This is your most honest before/after measurement.
- Real-user monitoring — if you have Google Analytics 4 or Cloudflare's Web Analytics, look at the Web Vitals scores from your actual visitors over the past 28 days.
What I'd skip
Not every optimization is worth the complexity. Things that are usually overrated for the average WordPress site:
- Switching to a faster theme — sometimes worth it, but the theme is rarely the bottleneck after the optimizations above.
- Disabling Gutenberg — saves a few KB on the frontend at most. Not worth losing block functionality.
- Manual function.php edits to remove emoji scripts — every speed plugin does this with a checkbox. The manual route is fine but creates maintenance debt.
- Free CDN-as-an-afterthought — Cloudflare's free tier is great, but if your goal is speed, configure it intentionally rather than enabling random optimizations.