Controlled WordPress Core Web Vitals lab: 24–45 to 100
A controlled WordPress lab built to show the failure path behind slow Core Web Vitals work.
The slow baseline and fixed implementation use the same dummy business, page structure, hero area, review widget area, gallery, FAQ, testimonials, and post grid. The difference is the implementation layer: media delivery, script loading, cache behavior, layout stability, and template weight.
This is a technical work sample, not a client case study.
PageSpeed lab results
Slow baseline and fixed implementation
Slow baseline
Fixed implementation
What stayed the same
The lab keeps the page shape controlled.
- same dummy business
- same page structure
- same core content sections
- same hero/review/gallery/FAQ/testimonial/post-grid pattern
- same route set
- same purpose: expose WordPress performance failure paths without private client data
What the fixed implementation cleaned up
The cleanup stayed in the implementation layer.
Why this matters on real WordPress sites
Most WordPress speed problems are not solved by toggling every optimization setting. The useful first step is isolating where the bottleneck actually sits: theme output, plugin scripts, cache/CDN behavior, image delivery, layout shift, fonts, or third-party code.
This lab shows the kind of before/after evidence I want from a real sprint: representative routes, visible scores, specific failure paths, and a written changelog instead of a vague audit.
Scope boundary
This lab does not mean every production WordPress site can or should be forced to 100/100. Real sites have ads, consent tools, ecommerce behavior, tracking requirements, third-party widgets, hosting constraints, and business tradeoffs.
The goal is not a vanity score. The goal is to find the dominant bottleneck, fix what is safe to fix, verify the result, and hand off the remaining constraints clearly.
Have a WordPress Core Web Vitals problem?
Send the affected URL, the PageSpeed or CrUX symptom, what changed recently, and your WordPress/cache/CDN stack.
If the issue is bounded enough, the first step should become a fixed sprint instead of a generic speed audit.