Marlow & June Performance Optimization

My role: Ran and interpreted Lighthouse audits, traced the root cause in the theme’s PHP, implemented the fix, and re-measured to confirm the result.

Tools: Chrome DevTools (Lighthouse), WordPress, PHP, Google Fonts (self-hosted)

The challenge:

A baseline Lighthouse audit on the Shop page returned a Performance score of 55, with First Contentful Paint and Largest Contentful Paint both around 9.6 seconds — a load time that would lose most real visitors. Total Blocking Time and Cumulative Layout Shift were both already excellent, which ruled out interactivity or layout instability as causes and pointed specifically at a loading bottleneck. Lighthouse’s “Render-blocking requests” audit estimated 8,880ms of possible savings — nearly the entire load time — but didn’t say which request was responsible without further digging. Expanding that audit’s detail table showed a single external Google Fonts request taking 8,940ms on its own, despite the font file itself being only 1.5 KB. Tracing that back through the codebase led to Storefront’s parent theme, where Google Fonts was being requested via a wp_enqueue_style() call using a URL built dynamically from fonts.googleapis.com.

The Solution:

Rather than editing the parent theme directly (which would be overwritten on any Storefront update), the fix was implemented entirely from the child theme: a function hooked to wp_enqueue_scripts at priority 20 — intentionally later than Storefront’s own font-loading hook — that dequeues and deregisters the storefront-fonts style handle, removing the slow external request. To avoid losing the site’s intended typography as a side effect, the actual font (Source Sans Pro/3) was then self-hosted: the two weights the site actually uses were downloaded as .woff2 files, placed in the child theme, and loaded via a small local @font-face stylesheet — eliminating the third-party request entirely rather than just disabling it.