Skip to content

Yuvraj Raulji | WordPress optimisation

A caching plugin makes a slow WordPress site look fast to anyone testing the homepage, which is why so many sites have one and are still slow. Underneath, the same page is being built from an options table nobody has cleaned, a theme loading assets it does not use, and plugins running on every request regardless of relevance.

How the work runs

Direct answer

In order of usual impact: get page caching and object caching configured properly rather than merely installed, clean the database, particularly autoloaded options and accumulated transients, cut the theme and plugin assets that load on every page whether or not they are used, size and convert images properly, and only then tune the host. A caching plugin makes an uncached site look fast in a test and does nothing for logged-in users, dynamic pages or the work happening behind the cache, which is why sites with one are still slow.

Best suited for

  • A site that is fast in tests and slow in use
  • Core Web Vitals failing in field data
  • A large content archive with slow queries
  • Admin and editing that has become painful

What this page is not

This page covers the site: caching, database, theme, assets and hosting. Cart, checkout and account pages are excluded from page caching by design and need commerce-specific work, so they belong to the store.

WooCommerce performance, for cart and checkout

The problem

The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.

  • There is a caching plugin and the site is still slow

    What it costs

    Installed and largely unconfigured, so it caches the homepage for logged-out visitors and little else. The test looks fine and the actual experience does not, which delays finding the real cause.

  • The options table has grown for years

    What it costs

    Autoloaded options are read on every single request, and plugins add to them and rarely clean up. It is invisible in every front-end tool and it is often the largest single cost on an older site.

  • Every plugin loads on every page

    What it costs

    Assets and queries run where they do nothing. The homepage carries the cost of a form plugin, a slider, and an analytics wrapper that only matter on three pages.

  • The admin is slower than the site

    What it costs

    Editors work around it and publishing slows down. It is also a reliable signal of database and query problems that the cache is hiding from visitors but not from the people using it.

Approach

In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.

  1. Measure the field, and measure logged in

    Real user data by template, plus the experience of an editor, who never benefits from page caching. Both matter, and only one of them shows up in the tools people usually run.

  2. Configure caching properly

    Page caching for anonymous traffic and object caching so uncached requests stop recomputing the same queries. Installed is not configured, and object caching is the layer most sites are missing entirely.

  3. Clean the database

    Autoloaded options, orphaned postmeta, accumulated transients and missing indexes on a large archive. Unglamorous, invisible to front-end tools, and frequently the biggest single gain available.

  4. Cut what loads on every page

    Theme assets, plugin scripts and styles restricted to where they do something. Removal beats deferral, and on most sites there is something to remove outright.

  5. Then images, fonts and hosting

    Sizing, modern formats, font loading and layout stability, and a hosting arrangement matched to the traffic. Hosting last, because moving unoptimised work to a faster server is a monthly cost rather than a fix.

Scope

  • Caching

    Page cache configurationObject cachingCDN setupCache exclusion rules

  • Database

    Autoload cleanupTransient hygieneQuery and index reviewArchive-scale tuning

  • Front end

    Conditional asset loadingTheme weightImage pipelineFont loadingLayout stability

  • Infrastructure

    Hosting fitPHP and OPcache tuningNginx configurationAWS provisioning

Proof

A content-led platform built for discovery, where page speed and technical SEO were part of the same brief.

  • Web platform · Manufacturing

    Engineering manufacturer platform

    A modern engineering brand platform built for discovery and enquiry.

    Web platformTechnical SEOContent

    3x traffic growth and 45% better engagement

Outcome

  • Fast without the cache, then cached

    The durable result is a site that does less work per request, so caching becomes an accelerator rather than a disguise. It is also what makes the admin and logged-in experience improve, which caching alone never does.

  • Core Web Vitals measured where they count

    Field data by template rather than a lab score, so the work targets the pages real visitors arrive on and the conditions they arrive under.

The 60% site speed figure published on this site came from caching, CDN and database work on a Magento platform and belongs to that page. No WordPress build on the record has a published measurement, so none is claimed here.

Questions

Why is my WordPress site still slow with a caching plugin?
Because page caching only helps anonymous visitors on cacheable pages. Logged-in users, dynamic pages and everything behind the cache still do the full work, and if that work is heavy the cache is hiding the problem rather than solving it. Object caching and database cleanup are usually what is missing.
What is autoloaded options bloat?
WordPress loads every option marked autoload on every single request. Plugins add to that table and frequently never clean up, so an older site can be reading a large amount of unnecessary data before it renders anything. It is invisible to front-end tools and is often the single largest cost on a mature site.
Will better hosting fix it?
It raises the floor and does not change the work. If the site is slow because of autoload bloat, unconditional asset loading and missing object caching, faster hardware does the same work more quickly and you pay for it every month. Fix the work first, then match the host to it.
How many plugins is too many for speed?
What matters is how many run on a given request. A plugin that only acts on its own template costs nothing elsewhere; one that loads scripts and queries globally costs on every page. The audit worth doing is per-page, not a count.
Does speed still matter for SEO?
It is a ranking input and a genuine one at the slow end, but the larger effect on a content site is usually engagement: people leave slow pages before they read them. Core Web Vitals from field data is the measure worth watching, because that is what Google uses and what visitors experience.

Next step

Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.

WordPress overview