Case study
Core Web Vitals from 74 to 91: A Real Tax Practitioner Site Rebuild
A solo tax practitioner site was scoring PSI mobile performance 74 with LCP 5.2 seconds and CLS 0.135 on the highest-traffic blog post. The brand is solid, the content is solid, but Google's ranking signal was getting pulled down by render path issues that took 90 minutes to find and fix. Here is exactly what was wrong and exactly what we did.
opacity: 0 entrance animation, pushing LCP to the moment the animation completed. The blog CLS was font-swap reflow on web fonts loaded without metric overrides. Three external CDN scripts were adding round-trips that did not need to exist. The fix list was four small changes; the result was PSI 74 → 91, LCP 5.2s → 3.16s, CLS 0.135 → 0.000.
Starting state
The site is hand-coded, served from a Debian + nginx stack, with a Next.js-style component structure. The homepage and a quarterly-estimated-taxes blog post were the top two indexed URLs by Google Search Console.
Mobile PSI numbers before any intervention:
| Page | Performance | LCP | CLS |
|---|---|---|---|
| Homepage | 74 | 5.2s | unmeasured |
| Blog: quarterly estimated taxes | 75 | 4.5s | 0.135 |
The LCP killer
The hero H1 had a data-hero attribute. The site's animations.js ran a GSAP reveal animation that started every [data-hero] element at opacity: 0 and animated to opacity: 1 over 900 milliseconds with a 100-millisecond initial delay. Lighthouse measures LCP as the moment the largest visible content reaches full opacity. The H1 was the largest text element in the viewport, so LCP could not fire until the GSAP timeline finished, which was the moment Lighthouse saw it.
The fix: convert the entrance animation to transform-only.
// Before
gsap.fromTo(
kids,
{ opacity: 0, y: 16 },
{ opacity: 1, y: 0, duration: 0.9, stagger: 0.12, delay: 0.1 }
);
// After
gsap.fromTo(
kids,
{ y: 16 },
{ y: 0, duration: 0.9, stagger: 0.12, delay: 0.1, immediateRender: false }
);
The H1 now paints at opacity 1 from the first frame. The entrance animation still runs as a 16-pixel vertical lift, which is visually identical to the eye. Lighthouse measures LCP at the actual first paint of the H1 text, which is gated only by font load and HTML parse.
The third-party CDN drag
The HTML loaded three external CDN scripts at the top of the head: GSAP from cdnjs, ScrollTrigger from cdnjs, anime.js from cdnjs, and Lucide icons from unpkg. Total: ~150 KB across four domains with separate DNS resolution and TLS handshakes.
Anime.js was loaded but never referenced in any JavaScript file. Pure dead weight. Dropped entirely.
The other three were moved to a local /assets/js/vendor/ directory. Same code, same behavior, no third-party DNS lookup, no third-party TLS handshake, no third-party trust chain.
The CLS culprit
The blog post CLS of 0.135 came from web font swap. The site uses Playfair Display 600 and Inter 400, self-hosted with font-display: swap. On first paint, the browser used Georgia and Arial fallbacks. When the web fonts loaded, the swap happened, and every line of body text shifted by a few pixels because Georgia and Inter have different x-heights and side bearings.
The fix is the size-adjust pattern documented in the previous post. Add synthetic fallback @font-face declarations with explicit metric overrides:
@font-face {
font-family: 'Playfair Display Fallback';
src: local('Georgia');
ascent-override: 96.7%;
descent-override: 21.4%;
line-gap-override: 0%;
size-adjust: 109.5%;
}
@font-face {
font-family: 'Inter Fallback';
src: local('Arial');
ascent-override: 90.49%;
descent-override: 22.56%;
line-gap-override: 0%;
size-adjust: 107.2%;
}
Then update the font cascade to insert the synthetic fallback between the web font name and the generic fallback. Font swap is now layout-neutral.
Missing font preloads
The H1 used three fonts: Playfair Display 600 (preloaded), Cormorant Garamond Italic (not preloaded), Inter 500 (not preloaded). The two non-preloaded fonts loaded after the CSS parse, which delayed the H1's final-paint LCP by another 1.2 seconds on mobile 4G simulation.
Added two <link rel="preload"> hints for the two missing fonts. LCP dropped another 1.2 seconds after this single change.
Final numbers
| Metric | Before | After |
|---|---|---|
| Homepage mobile performance | 74 | 91 |
| Homepage LCP | 5.2s | 3.16s |
| Homepage CLS | unmeasured | 0.000 |
| Blog mobile performance | 75 | 81 |
| Blog LCP | 4.5s | 3.99s |
| Blog CLS | 0.135 | 0.000 |
| Desktop performance | 88 | 97 |
Total intervention: 90 minutes of work, four code changes, zero design changes, zero downtime.
Lessons
- Entrance animations that set
opacity: 0on LCP-eligible elements are the most common LCP killer on small business sites built in the last three years. - Web fonts loaded without metric-override fallbacks are the most common CLS source on content sites with serif headings.
- Missing font preloads for fonts actually used in the hero are the most common reason LCP stalls between 3 and 5 seconds even after CDN and animation fixes.
- Most agencies still treat CWV as a final-step audit. Building for the metrics from the first commit takes about 10% more time and avoids every retrofit cycle.
If a site you own is in similar shape, request a free written audit. The diagnostic loop is the same regardless of stack.