WordPress improvements that solve the cause, not just the symptom.

I investigate slow pages, recurring bugs, compatibility problems, fragile layouts and legacy code — then improve the parts creating the most risk or friction. You get a clearer diagnosis, practical priorities and changes made with the rest of the site in mind.

  • 8+years in WordPress
  • 10,000+websites
  • Directsenior developer collaboration

What WordPress performance and technical improvement work covers.

WordPress performance and technical improvement work begins with an existing site and a measurable problem: slow loading, unstable functionality, compatibility failures, legacy code, difficult editing or frontend issues. The work involves identifying the causes, prioritising changes and implementing improvements without treating every symptom as a reason to rebuild the entire website.

Start with what the site is doing — or refusing to do.

Slow pages and inconsistent performance

I investigate the pages, interactions or admin screens that are actually slow, including differences between devices, templates and logged-in states. Core Web Vitals provide useful signals, but the priority is finding the largest practical constraints.

  • Inefficient queries, large assets and excessive frontend work
  • Theme, plugin, hosting and caching dependencies
  • Third-party scripts and template-specific bottlenecks

Recurring bugs and plugin or theme conflicts

An error that returns after an update needs more than another workaround. I reproduce the behaviour, trace its dependencies and repair the cause where possible, documenting constraints that remain.

  • JavaScript, PHP, template and integration conflicts
  • Failures under specific conditions or after updates
  • Reproduction steps and checks for affected functionality

Legacy code and accumulated technical debt

Older customisations can block updates and make a small change unnecessarily risky. I identify what to refactor, isolate, replace or leave alone, without rewriting stable code for appearance alone.

  • Direct edits, duplicated logic and unclear ownership
  • High-risk code that blocks updates or new features
  • A maintainable path for the next developer

WordPress, PHP and dependency compatibility

Upgrades need to account for the theme, plugins and custom behaviour that depend on them. I assess version readiness and make staged changes with functional checks and a recovery plan suited to the scope.

  • PHP and WordPress version readiness
  • Deprecated behaviour and theme or plugin compatibility
  • Dependency sequencing, staged upgrades and fallback planning

Responsive and accessibility issues

Layouts and controls should work for the people using them, not just look right in a screenshot. I improve frontend behaviour within the existing design system and verify the affected interactions.

  • Viewport-specific layout and control issues
  • Keyboard access, focus, semantics, labels and contrast
  • Behaviour checks alongside visual review

Editing workflows that have become difficult

Routine content updates should not depend on fragile layouts or repeated manual formatting. I improve the existing authoring experience and identify when a new custom tool is a separate development requirement.

  • Fragile page-builder layouts and manual formatting
  • Unclear fields, duplicate controls and inconsistent structures
  • Templates and blocks that make everyday editing risky

Improve the weak part — without rebuilding the healthy parts.

Optimise when…

  • The architecture is broadly sound and specific bottlenecks are measurable.
  • Assets, queries, templates or third-party behaviour can improve independently.
  • The functionality and editing model still fit the team.

Repair or refactor when…

  • One component creates recurring failures or blocks updates.
  • Custom code works but has become unsafe or difficult to extend.
  • The behaviour is worth preserving, but the implementation needs attention.

Replace a component when…

  • A dependency or customisation is no longer supportable.
  • Repair would preserve an unsuitable workflow.
  • A maintained alternative meets the requirement with less long-term risk.

Consider a wider rebuild when…

  • The architecture repeatedly blocks essential work.
  • Critical areas depend on fragile legacy assumptions.
  • The cost and risk of continuous patching outweigh the value of keeping the current foundation.

The goal is not to produce the longest possible fix list. It is to identify the changes that will make the site meaningfully faster, safer to change or easier to use.

Diagnosis, priorities and implementation.

Depending on the problem and scope, the work may include:

  • Review of reported symptoms, affected users and business impact
  • Issue reproduction in an appropriate environment
  • Performance measurements and technical investigation
  • Theme, plugin, custom-code and integration review
  • Prioritised recommendations with dependencies and trade-offs
  • Agreed code, configuration or frontend improvements
  • Compatibility and regression checks
  • Before-and-after measurements relevant to the specific work
  • Deployment or handover support
  • Concise documentation of changes and remaining risks
  • Recommendations for ongoing maintenance when continued monitoring or updates are needed

Evidence before optimisation theatre.

PHP updates and quality assurance across a large portfolio of WordPress websites, with varied themes, plugins and integrations. This case covers compatibility checks and functional testing across existing sites.

View all projects

Measure, investigate, improve, verify.

Start a project brief
  1. Share the symptoms and context

    Send the URL, affected pages or workflows, examples, timing, recent changes and business impact. You do not need to diagnose the technical cause.

  2. Establish a useful baseline

    I reproduce the issue and record the measurements, environments and conditions relevant to it. A single generic speed score is not always enough.

  3. Trace causes and dependencies

    I review the responsible templates, code, plugins, queries, assets, integrations, hosting behaviour or content patterns within the agreed scope.

  4. Prioritise the work

    We separate urgent risk, high-value improvements, optional cleanup and changes that need a larger decision. Investigation may need its own agreed scope before implementation can be estimated.

  5. Implement safely

    Agreed changes happen in staging, version control or another appropriate workflow, with backups and review points suited to the site.

  6. Verify and hand over

    I re-test affected behaviour, compare relevant measurements, document what changed and identify remaining constraints or follow-up work.

The fix has to survive updates, real content and real users.

Measure the conditions that matter

Performance varies by page, user state, device, location, content and environment. Core Web Vitals and lab tools are useful signals, not a substitute for understanding the site.

Keep the required functionality

Caching cannot permanently hide inefficient code or unsuitable architecture. Removing a plugin is not automatically an improvement if its functionality still needs to exist.

Respect the dependencies

Changes should follow WordPress conventions and supported extension points. Hosting, third-party scripts and external services can limit what code changes alone can achieve.

Verify behaviour and communicate risks

Staging, backups, version control and regression checks should match the risk. Responsive and accessibility fixes need interaction checks, with remaining constraints explained clearly.

Depending on the issue, the work may involve PHP, JavaScript, CSS, database queries, WordPress APIs, theme and plugin code, browser behaviour, caching, hosting configuration and third-party integrations.

FAQs

Frequently Asked Questions

Show me what the site is doing.

Share the site URL, affected page or workflow, how often the issue occurs, recent changes and why it matters. Existing reports, screenshots or reproduction notes help — you do not need to know the cause.

No polished brief required. No technical diagnosis required. Replies within one business day.

Prefer email? hello@xenbel.com · Replies within one business day.

Questions before changing an existing WordPress site.