Web Performance Engineering
Website Speed Optimization
Make your website genuinely fast — not just optimised on a single PageSpeed run. I rebuild the critical rendering path, fix the server, configure the edge, and govern third-party scripts so your real users get a sub-two-second experience that converts.
What's Included
Comprehensive solutions tailored to your specific needs
Server & origin tuning
PHP, opcache, Redis, database indexes, and hosting decisions that take TTFB under 200ms.
Edge caching strategy
Cloudflare or BunnyCDN configured for HTML caching, image transforms, Brotli, HTTP/3, and Early Hints.
Critical rendering path
Inlined critical CSS, deferred non-critical assets, and preloaded LCP image and primary font.
Image & media pipeline
AVIF/WebP, responsive srcset, native lazy loading, and CDN-based transforms — no more 4MB hero images.
Third-party governance
GTM, pixels, chat widgets, and personalisation tools audited, deferred, or moved server-side.
Conversion-side metrics
Reporting against bounce rate, scroll depth, and conversion-adjacent metrics — not just lab scores.
Problems I Solve
Symptoms this engagement is built to fix
A site that scores 95 in PageSpeed Insights but still feels slow to real users.
Mobile load times above 4 seconds on 4G, eroding paid traffic ROI and organic rankings.
Slow TTFB caused by hosting, missing object cache, or uncached database queries.
Bloated themes, page builders, and plugin stacks that ship 2MB of unused JavaScript.
An image library full of 4MB PNGs serving WebP-capable browsers.
A CDN that is enabled but configured to cache almost nothing of value.
Why most speed work is wasted
Most speed optimisation engagements stop at three things: install a caching plugin, enable a CDN, and compress images. That gets the synthetic score up. It rarely makes the site faster for the user who actually matters — the one on a mid-tier Android phone, on a flaky network, with three browser tabs and a third-party script storm already loaded. Real speed engineering is a stack-wide exercise: the server has to respond in under 200ms, the edge has to cache aggressively without breaking dynamic content, the critical rendering path has to fit in the first network round trip, and the marketing tags have to stop blocking the main thread. Skip any of those and the page is still slow, regardless of what the score says.
The speed stack, layer by layer
Server and origin: PHP 8.x with opcache and JIT where supported, Octane for Laravel, MariaDB or PostgreSQL with sane indexes, Redis or Memcached for object caching, and a hosting tier that actually delivers the CPU you are paying for. CDN and edge: Cloudflare or BunnyCDN with HTML caching where the CMS allows, proper cache rules for parameterised URLs, Brotli compression, HTTP/3, Early Hints, and image resizing at the edge. Critical rendering path: inline critical CSS, defer or async the rest, preload the LCP image and primary font with the correct attributes, eliminate render-blocking JavaScript above the fold. Images and media: AVIF and WebP with correct fallback, responsive srcset, native lazy loading below the fold, and a CDN-based image transform pipeline so you stop shipping a 4MB hero. Third parties: deferred, server-side, or removed — the single biggest CWV lever for most sites.
Why server response time is the silent killer
If your TTFB is 800ms, no amount of front-end optimisation will get you to a sub-two-second LCP. The browser cannot start rendering until it receives the first byte, and slow hosting routinely costs sites a full second before any of their own code runs. The fixes are usually unglamorous: move from shared hosting to a properly provisioned VPS, enable object caching against a real Redis instance, add appropriate database indexes, kill the heartbeat that is being called every 15 seconds, and disable the plugins that are running an admin-ajax call on every page load. I do this work as part of the optimisation rather than handing it off as someone else's problem, because the front-end work cannot pay off without it.
Why a faster site sells more
Speed is a conversion lever, not just an SEO one. Google's own studies put the conversion delta between a 1-second and a 3-second LCP at roughly 32 percent on mobile. Amazon famously measured a 1 percent revenue drop per 100ms of added latency. In B2B, slow forms and slow dashboards quietly burn pipeline at the top of the funnel before sales even sees the lead. The point of this engagement is not to win a PageSpeed certificate. It is to make the site faster for the next paying customer, which is why I report on conversion-adjacent metrics — bounce rate, scroll depth, add-to-cart rate, form completion — alongside the technical numbers.
How the work is held in place after I leave
Optimisation is a snapshot; speed is a discipline. Most sites regress within three months because a marketing team ships a new tag, a developer installs a heavy plugin, or someone uploads a 6MB hero image. The optional retainer prevents this with three protections: a Lighthouse CI budget that blocks regressions at the PR level, monthly third-party script reviews before tags go live, and a quarterly re-baseline against CrUX field data. Without these, the work degrades quietly; with them, it compounds.
What You Receive
Deliverables & expected outcomes
- Baseline performance audit (lab + field + RUM)
- Server, CDN, and edge configuration
- Critical rendering path implementation
- Image pipeline and asset compression
- Third-party script governance plan
- Lighthouse CI budget for regression protection
Illustrative Engagement
A representative scenario
The problem
A B2B SaaS site spent £18k on a redesign that shipped at 6.2s LCP on mobile. Organic positions had dropped after the relaunch and paid CPL had risen by 41 percent, with the marketing team blaming Google's ad auction.
The approach
We moved hosting to a tuned VPS with Redis object caching, deployed Cloudflare with HTML caching for marketing pages, inlined critical CSS, preloaded the hero, and deferred a personalisation script that was loading on every route.
The outcome
LCP dropped from 6.2s to 1.8s, TTFB from 920ms to 140ms. Organic clicks recovered within six weeks and paid CPL fell back to pre-redesign levels — a return measured in weeks, not quarters.
Composite scenario based on typical engagements. Replace with a real, attributed case study once published.
My Process
A proven methodology for delivering exceptional results
Baseline
Lab, field, and RUM measurement across the templates that matter, with a clear numeric target for each metric.
Server & edge
Hosting, object cache, database, and CDN configuration — the foundation that everything else depends on.
Front-end engineering
Critical rendering path, image pipeline, JavaScript splitting, and third-party governance.
Lock in the gains
CI budget, RUM dashboard, and a quarterly review so the site does not silently regress.
Why Choose Me?
With 7+ years of experience and a track record of delivering results, I bring expertise, reliability, and a results-driven approach to every project.
- Real-user speed gains, not just synthetic scores
- Stack-aware engineering across server, edge, and browser
- Conversion-adjacent reporting your marketing team understands
- Senior implementation directly — no junior handoff
- Regression protection via CI budgets and monthly governance
- Honest decisions about hosting and platform when warranted
Starting at
€297
End-to-end speed engineering across server, edge, and browser with CI regression protection and conversion-side reporting.
Frequently Asked Questions
Related Services
Further Reading
Related articles from the blog
Ready to Get Started?
Let's discuss your project and create a custom strategy for success.