WordPress Development Without the Plugin Sprawl

Why is my WordPress site slow?

Almost never WordPress itself. In practice it is some combination of a page builder, plugin overload, unoptimized images, cheap shared hosting and a theme loading assets for features the site does not use.

Page builders are the most common single cause. They generate deeply nested markup and load their own CSS and JavaScript on every page, whether a page uses their components or not. The convenience is real; so is the weight, and it does not go away once the site is built.

Plugin count matters less than plugin behavior. Twenty well-written plugins can be lighter than three that each load a framework on every request. The audit worth doing is not "how many" but "what does each one load, and on which pages".

Hosting sets the floor. A site on oversubscribed shared hosting has a slow server response time before any of your code runs, and no amount of front-end optimization fixes that.

Custom theme or a marketplace theme?

A marketplace theme is the right call when budget is the binding constraint and the site is straightforward. Custom is right when performance, editing experience or a specific design matter more than the initial saving.

The hidden cost of marketplace themes is that they are built to sell to thousands of different businesses, so they include everything any of those businesses might want. You disable most of it. Much of it still loads. And customizing beyond what the theme anticipated tends to cost more than building the thing properly would have.

The other cost is lock-in. Themes built around a specific page builder mean your content is stored in that builder's format. Moving away later is a rebuild, not a redesign.

For a brochure site with a modest budget and no unusual requirements, a good marketplace theme is genuinely fine and we will say so.

Is WordPress good for SEO?

It is capable, not automatic. WordPress produces clean URLs, handles metadata well through plugins, and outputs semantic HTML if the theme does. None of that is a ranking advantage on its own.

What actually decides organic performance on a WordPress site is the same as anywhere else: site speed, information architecture, internal linking, content quality and indexation control. WordPress makes those achievable; it does not make them happen.

The place WordPress genuinely helps is publishing velocity. A well-modeled site lets a content team publish consistently without developer involvement, and that compounds. The place it commonly hurts is performance, when the build was assembled rather than engineered — which is a technical SEO problem inherited from a development decision.

How do we keep the site fast after launch?

By deciding, before launch, who is allowed to add what. Most WordPress sites regress within months because there is no policy — a plugin gets installed to solve one problem and permanently costs performance on every page.

The practical version is a short set of rules: new plugins get reviewed before installation, images go through a defined pipeline rather than being uploaded at camera resolution, and Core Web Vitals get checked after any significant change rather than only at launch.

We build this into handover documentation because it is the difference between a site that is fast for a month and one that is fast in two years. A build cannot enforce it on its own.

What does content modeling actually mean?

It means deciding what kinds of things your site holds, what information each kind carries, and how they relate — before anyone designs a page. A service, a case study, a team member and a location are four different things, and treating them as four variations of "page" is what produces sites nobody can maintain.

Done properly, an editor adding a new service fills in a title, a summary, a set of features and a related-service reference. Everything else — the layout, the breadcrumb, the internal links, the schema markup — follows automatically, because the structure knows what a service is.

Done badly, the same editor opens a blank page, copies the last service page and edits it by hand. Every copy drifts a little further from the design, and internal linking depends on somebody remembering to add it. Six months later no two service pages are the same shape.

The test we use is simple: can a new person add a new item of each type without opening an existing one for reference? If not, the model is doing too little and the editor is doing too much.

This is also the step that decides whether your content can be reused. Well-modeled content can feed a redesign, a mobile app or a search index without being rewritten. Content stored as page-builder layout markup can only ever be that page.

Should we use Gutenberg or a page builder?

For new builds we use the block editor with custom blocks written for your content. It ships with WordPress, stores content in a portable format, and carries no license.

The argument for a commercial builder is speed of initial delivery, and it is a real argument — assembling a site is genuinely faster than building one. The cost is paid later, in page weight on every request and in content stored in a proprietary shape.

The distinction that matters is not Gutenberg versus builder; it is constrained versus unconstrained. An unconstrained block editor has the same problem a page builder does — an editor can produce any layout, including ones that break the design. Custom blocks with defined options remove that risk without removing useful flexibility.

Where you already run a builder-based site and want to keep it, we will work inside it. We will also tell you plainly which of your performance problems cannot be fixed without leaving it, rather than selling optimization that cannot deliver what you are hoping for.

How should hosting and caching be set up?

Hosting is the single biggest performance lever on most WordPress sites, and the one most often chosen on price alone. Shared hosting puts your site on a machine with hundreds of others; when one of them gets busy your server response time suffers, and nothing in your code compensates for that.

Managed WordPress hosting costs more and removes most of the tuning work — object caching, page caching and a CDN are configured for you. For most businesses that is the right trade. For unusual requirements, a virtual private server with a properly configured stack gives more control at the cost of needing someone to maintain it.

Caching has layers and they solve different problems. Page caching serves a stored copy of the whole page. Object caching stores the results of database queries. A CDN moves static assets closer to the visitor. Most slow sites are missing one specific layer rather than all three.

What goes wrong most often is invalidation — content is updated and the old version keeps being served, or the cache is cleared so aggressively it never helps. We set those rules explicitly at build time and document them, because it is the thing most likely to confuse an editor later.

What does handover need to include?

A repository you own, a staging environment that matches production, documentation written for editors rather than developers, and a stated update policy. Anything less and the build depends on us being available, which is not a position you should be in.

The documentation that gets used is short and specific to your site. Generic WordPress guides are freely available; what your team needs is the page that says how your content types work, which blocks exist and what they are for, and what to do when a plugin update appears.

The update policy matters more than it sounds. WordPress security incidents are overwhelmingly caused by outdated plugins rather than by WordPress itself. A policy naming who checks updates, how often, and where they are tested first removes most of that risk at almost no cost.

We also hand over the performance budget the site was built to, so any future change can be measured against the same standard rather than against whatever the site happens to be doing that month.

How do you keep editors from breaking the design?

By removing the ability rather than writing a policy against it. Any system that depends on people remembering a rule will be broken by the person who joins next month and never saw it.

In practice that means blocks with defined options instead of free-form layout. A testimonial block takes a quote, an attribution and an optional image, and renders them the one correct way. It cannot be centered, recolored or given a different font, because those are not offered.

The balance to strike is real. Constrain too little and the design erodes within months. Constrain too hard and your team starts working around the system — pasting formatted text from a document, or asking a developer for every campaign page, which is exactly the dependency the build was meant to remove.

We settle it by asking which decisions genuinely vary by content and which only ever vary by accident. The first group becomes options. The second group becomes fixed, and nobody misses it.