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.
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.
Send the URL, affected pages or workflows, examples, timing, recent changes and business impact. You do not need to diagnose the technical cause.
02
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.
03
Trace causes and dependencies
I review the responsible templates, code, plugins, queries, assets, integrations, hosting behaviour or content patterns within the agreed scope.
04
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.
05
Implement safely
Agreed changes happen in staging, version control or another appropriate workflow, with backups and review points suited to the site.
06
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.
Often, yes. I first check whether the problem can be addressed in a specific component, template or workflow. If investigation shows that the wider architecture is the constraint, I explain the options and trade-offs before recommending a rebuild.
There is no single cause that fits every site. Queries, assets, templates, plugins, caching, hosting and third-party scripts can all contribute. I investigate the affected pages and conditions before recommending changes.
No. I can investigate and improve the factors within the agreed scope, but results depend on the actual site, users, hosting and external dependencies. We establish relevant measurements and compare them under meaningful conditions rather than promise a universal score.
Yes. I work to reproduce the problem and trace the responsible dependencies before changing code or configuration. If a third-party limitation cannot be fixed directly, I explain the available options and remaining constraints.
Yes. The work can include readiness checks, deprecated behaviour, theme and plugin compatibility, staged upgrades and functional testing. Dependencies and recovery planning are considered before a live change.
Yes. I can address layout, keyboard, focus, semantic, label and contrast issues within an agreed implementation scope. This does not automatically constitute a complete accessibility audit or compliance certification.
Start with the URL, affected pages or workflows, reproduction steps, timing and recent changes. I then identify the minimum access needed for the investigation, which may include staging, code, logs or relevant administration tools. Do not send credentials in the initial brief.
Sometimes a well-defined fix can be scoped from the available information. For an unclear or recurring issue, a separately agreed diagnostic phase may be needed before a responsible implementation estimate is possible.
Ongoing updates, monitoring and planned development can be agreed separately through maintenance and ongoing support. This service focuses on a defined investigation and improvement project rather than unlimited recurring care.