Performance / WordPress
FIX THE CAUSE. NOT THE SCORE.
A slow WordPress site can be caused by hosting, rendering, images, fonts, plugins, third-party scripts, database work or simply too much front-end. The useful job is to isolate the constraint before adding another optimization plugin.
SCOPE / DELIVERY
WHAT THE WORK COVERS.
Performance work starts with a comparable baseline and ends with verification. Changes are prioritised by user impact, implementation risk and the business functionality that must remain intact.
Representative baseline
Record representative pages, mobile and desktop conditions, Core Web Vitals and technical constraints before changing the stack.
Rendering and asset diagnosis
Trace render-blocking assets, oversized media, fonts, scripts, queries, plugin dependencies and third-party cost to the parts that actually affect delivery.
Code/dependency reduction
Reduce or restructure the highest-impact causes in controlled batches without removing required functionality just to improve a laboratory score.
Comparable post-change verification
Repeat comparable measurements and verify layout, forms, interaction and conversion paths so the site is not faster only on paper.
FAQ / DECISION
Questions, answered.
Is performance optimization worth doing before a redesign?
Sometimes. If the structure is still viable, targeted optimization can be the highest-value move. If the theme or architecture is the main constraint, a rebuild may be more rational.
Do you work only from Lighthouse or PageSpeed?
No. Those tools are evidence, not the whole diagnosis. I also inspect network cost, rendering, dependencies, HTML/CSS/JS, real page behaviour and the functionality the business cannot lose.
Diagnosis first
The useful question is not only “why is the score low?”
The first step is to identify which constraints affect users and the business: server response, rendering, images, fonts, third-party scripts, dependency sprawl or structural problems. A technical audit is appropriate when the causes or scope are still unclear; focused optimisation is appropriate when there is enough evidence to implement and verify improvements.
Optimization has limits. If the dominant cost comes from a theme, builder or dependency architecture that cannot be changed safely, I will say so rather than sell incremental tuning as a permanent solution.
- 01
Comparable before-and-after measurementsUse the same representative pages and conditions before and after changes so the comparison is meaningful.
- 02
Priority based on impact and implementation riskFix the causes with the highest user impact before low-value tool warnings that do not change the experience.
- 03
No removal of required business functionality without agreementKeep forms, tracking, commerce and other required business functions unless a trade-off is explicitly agreed.
- 04
Clear limits when optimisation cannot replace a rebuildState when the existing architecture has reached the point where redesign or rebuild has better economics than further tuning.
Project workflow
A controlled performance optimisation process
Performance work is staged so the baseline, cause and improvement stay comparable. Optimization without a controlled before/after turns into guesswork.
-
Baseline
Record representative pages, devices, environments and the current technical constraints.
-
Isolate
Separate the largest causes from secondary warnings and tool-specific noise.
-
Optimise
Improve assets, rendering, delivery, queries and dependencies in controlled batches.
-
Verify
Repeat comparable tests and check functionality, layout, forms and conversion paths.
Questions answered
Questions clients usually ask
Can you guarantee a specific PageSpeed score?
No responsible optimisation project should guarantee a score before the site, hosting, required functionality and measurement conditions are reviewed. Targets and constraints are defined from the baseline.
Do I need a complete redesign?
Not necessarily. Focused optimisation is appropriate when the existing structure is viable. A redesign is recommended only when the foundation, content structure or conversion path creates broader limitations.
Will you remove plugins?
Only when a dependency is unnecessary, duplicated or can be replaced safely. Required business functionality is not removed merely to produce a cleaner test result.
Does performance optimisation include SEO?
It supports technical SEO by improving delivery, rendering and page quality, but it does not replace keyword research, content strategy or a complete SEO engagement.
NEXT / COMMERCIAL
BRING THE REAL PROBLEM
START THERE.
If the site feels slow, Core Web Vitals are unstable or optimization plugins keep stacking up without fixing the cause, send the URL and the pages that matter most. I will start from evidence, not a preset recipe.
DISCUSS A PROJECT