WordPress

Overview

WordPress runs a little over 40% of the web, and it earns that position for one reason: a marketing team can operate it without calling a developer for every change. That advantage is real, and it is also the thing most often destroyed by how a site gets assembled.

Almost every "WordPress is slow" or "WordPress is insecure" complaint we are asked to fix turns out to be a complaint about a specific build, not about WordPress. The pattern is nearly always the same: a purchased multipurpose theme carrying code for twenty layouts the site never uses, a page builder rendering nested div soup, thirty-odd plugins each loading its own CSS and JavaScript on every page, no object cache, and a database that has never been cleaned. WordPress core is not the bottleneck in that picture.

Default themes, purchased themes and custom themes

This choice determines more about the site's long-term speed and cost than any other decision, so it is worth being precise about the trade-offs.

Default themes (Twenty Twenty-Four, Twenty Twenty-Five)

Fast, accessible, well-tested and free. They are block themes, so they work with the Site Editor, and they receive core-level maintenance. The limitation is that they are designed to be generic. Pushing one into a distinctive brand design usually means a growing pile of overrides, and at that point you own a fork of someone else's theme with none of the benefits of either approach.

Purchased multipurpose themes

The apparent shortcut, and the most expensive option over three years. A theme sold to 40,000 buyers has to support every use case, so it ships demo importers, slider libraries, icon packs, its own page builder and a settings panel with hundreds of options. You use perhaps 10% of it and pay the download cost of all of it on every page load. Worse, the theme becomes a dependency you do not control: a major version can change markup and break your customisations, and an abandoned theme leaves you carrying unpatched code.

Custom themes

What we build by default. A theme written to your design contains only what your site actually uses. In practice that means a stylesheet measured in tens of kilobytes rather than hundreds, no unused JavaScript, markup that matches the design instead of fighting it, and full control over what loads on which template. Upgrades stay predictable because there is no third-party theme vendor in the chain.

We build custom themes as block themes where the client wants Site Editor control, and as classic themes with Advanced Custom Fields where editors prefer structured forms over free-form layout. Both are legitimate; the right answer depends on who edits the site and how much layout freedom they should have.

The plugin problem, and how we handle it

Every plugin is third-party code with database access, an update cadence you do not control and an author who may stop maintaining it. Plugins are not free, they are borrowed. We treat each one as a decision with a cost.

• Justify each plugin. If a plugin exists to add 30 lines of functionality, those 30 lines belong in the theme instead — no settings panel, no update risk, no asset loading.
• Audit before installing. Last update date, open support threads, active install count, and whether the author has a track record. An abandoned plugin is a scheduled security incident.
• Never stack overlapping plugins. Two caching plugins, or two SEO plugins, conflict in ways that are painful to diagnose.
• Dequeue what is not needed. A contact form plugin has no business loading its CSS and JavaScript on every page. We conditionally load plugin assets on the templates that use them, which alone often removes 200–400 KB from the homepage.
• Replace page builders where practical. Elementor and similar tools are genuinely useful for teams that need layout freedom, but they generate deeply nested markup and heavy runtime CSS. Where a site only needs a fixed set of layouts, native blocks or ACF Flexible Content give editors the same control at a fraction of the weight.

A typical rescue project ends with 8 to 12 plugins where it started with 35, and the site does the same things.

Speed and Core Web Vitals

Page speed is a ranking factor and, more importantly, a conversion factor. We work to the Core Web Vitals thresholds — LCP under 2.5s, INP under 200ms, CLS under 0.1 — measured on real mobile connections rather than a desktop test that flatters everyone.

• Page caching. Full-page cache so repeat requests never touch PHP. Server-level caching where the host supports it, otherwise a well-configured caching plugin.
• Object caching. Redis or Memcached for the object cache. On query-heavy sites and WooCommerce especially, this is often the single largest improvement available.
• Query discipline. Uncached WP_Query calls with meta_query on large tables are a common cause of slow admin and slow archives. We profile with Query Monitor, index what needs indexing, and cache expensive results with transients.
• Images. WebP or AVIF with proper fallbacks, correct srcset so phones do not download desktop images, lazy loading below the fold, and explicit dimensions to keep CLS at zero.
• Critical CSS and deferred JavaScript. Inline what is needed for the first screen, defer the rest, and remove render-blocking requests from the head.
• Font loading. Self-hosted, subset, font-display: swap, preloaded. Third-party font CDNs add a DNS lookup and a connection before a single character renders.
• Database hygiene. Post revisions, expired transients, orphaned metadata and abandoned plugin tables accumulate for years. A cleaned wp_options table with autoload under control makes every single request faster.

Security hardening

Most WordPress compromises are opportunistic and automated. They exploit known vulnerabilities in out-of-date plugins, weak credentials, or a server misconfiguration — not a sophisticated attack on your business.

• Least-privilege user roles. Editors do not need administrator accounts, and nobody should share a login.
• Two-factor authentication on all administrator accounts, plus rate limiting and lockout on the login endpoint.
• Disable file editing in the dashboard (DISALLOW_FILE_EDIT) so a stolen session cannot become a shell.
• Correct file permissions, PHP execution blocked in wp-content/uploads, and wp-config.php moved or protected.
• Security headers: HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options.
• REST API and XML-RPC surfaces restricted where the site does not use them; user enumeration blocked.
• A web application firewall, and monitoring that alerts on file changes rather than telling you after the fact.
• Off-site backups tested by actually restoring them. An untested backup is a hope, not a plan.

Upgrades without the fear

Sites become insecure because owners are afraid to update, and they are afraid because an update once broke something at the worst possible moment. The fix is process, not avoidance.

• A staging environment that mirrors production, so updates are applied and checked there first.
• Version control for the theme and any custom plugins, so any change can be traced and reverted.
• Composer-managed dependencies where the project justifies it, so plugin versions are explicit and repeatable rather than whatever happened to be installed.
• Automatic minor core updates and security patches; manual, reviewed major updates.
• PHP version upgrades treated as planned work with a compatibility scan, not as an emergency when the host forces the issue.
• A rollback path defined before the update starts.

Keeping WooCommerce fast

WooCommerce is where an unoptimised WordPress build hurts most, because carts, checkout and account pages are uncacheable by definition and every one of them runs PHP and hits the database.

• High-Performance Order Storage. Moving orders out of the posts table into dedicated tables transforms admin performance on stores with significant order history. We migrate stores onto HPOS and check plugin compatibility as part of it.
• Cache the right things. Full-page cache for the shop and product pages, with cart, checkout and my-account correctly excluded. A cached cart is worse than no cache at all.
• Object cache and session handling. Redis for the object cache, and careful handling of WooCommerce sessions so logged-in traffic does not bypass every optimisation.
• Fix the AJAX cart fragments. The default fragments request fires on every page load and is one of the most common causes of a sluggish-feeling store. It should be limited to pages that actually need it.
• Attribute and variation load. Products with hundreds of variations need a different rendering approach; large catalogues need indexed attribute lookups rather than brute-force meta queries.
• Search and filtering. Beyond a few thousand products, the default search becomes the slowest thing on the site. We move it to a proper index.
• Scheduled tasks. Replace wp-cron with a real system cron so a visitor is not paying the cost of your scheduled jobs.

Headless WordPress

Where a project needs application-grade front-end performance but editors still want the WordPress dashboard, we run WordPress as a headless content API behind a Next.js front end via the REST API or WPGraphQL. It is a genuinely good fit for content-heavy marketing sites with demanding performance targets. It is a poor fit when the team relies on live preview and visual editing, and we will say so rather than sell the more complicated option.

How we work

1. Audit. For an existing site: Core Web Vitals on real devices, plugin inventory, database health, security posture and PHP version. You get the findings in writing, ranked by impact against effort.
2. Content modelling. Post types, taxonomies and fields designed around your actual content, so editors fill in meaningful fields instead of formatting HTML.
3. Build. Custom theme in version control, coding standards enforced, staging environment from day one.
4. Measure. Lighthouse and field data before and after, so the improvement is a number rather than an opinion.
5. Handover. Editor documentation, a maintenance runbook and a walkthrough with the people who will use it.

What you get

• A custom theme built to your design, with no vendor lock-in.
• A justified, minimal plugin set with each choice documented.
• Measured Core Web Vitals improvements, reported before and after.
• A hardened configuration and a tested backup and restore process.
• Staging, version control and a documented upgrade routine.
• Editor training so your team can run the site without us.

WordPress is almost never the reason a site is slow. A purchased theme, thirty plugins and no object cache usually are.