Project context
The setting
A UK direct-to-consumer WordPress site had a slow mobile loading experience, with the largest delay around Largest Contentful Paint.
Challenge
The problem to solve
The recorded baseline combined an 8.5-second LCP with render-blocking resources, inefficient CSS and JavaScript delivery, and critical-rendering-path bottlenecks.
My role and scope
What I was responsible for
I carried out the mobile performance audit, identified the main rendering bottlenecks, and implemented resource-priority and front-end delivery improvements.
Investigation and reasoning
- Measured representative mobile pages with Lighthouse
- Traced the LCP element and its discovery path
- Reviewed render-blocking CSS and JavaScript and the critical request chain
Approach and implementation
- Prioritised the LCP resource
- Reduced avoidable render-blocking work
- Optimised CSS and JavaScript delivery
- Retested the mobile experience after implementation
Measured Results
Verified Results & Performance Data
Quantitative before-and-after improvements and documented outcomes recorded during the project scope.
The project record reports a mobile Lighthouse Performance score improvement from 61 to 92 and LCP improvement from 8.5 seconds to 3.3 seconds. FCP was recorded at 1.5 seconds in the after-state. Results describe the recorded test conditions and are not a guarantee for other sites.
- Lighthouse Performance
- 6192
- LCP
- 8.5s3.3s
- After-state FCP
- 1.5s
Evidence note
Before-and-after mobile Lighthouse measurements recorded in the existing project data. Test date, Lighthouse version, URL, and report files are not stored in the portfolio.
Constraints and lessons
What this work made clear
- The LCP discovery path can matter as much as image compression
- Performance results should be read in the context of the tested page and environment