PageSpeed Quad-100: A WordPress Performance Case Study — The GEO Lab

Last updated: 11 March 2026 · Version: 1.3 · View all posts

This PageSpeed optimization case study documents how The GEO Lab achieved a perfect quad-100 score on Google PageSpeed Insights for WordPress. The guide covers WordPress performance techniques, Core Web Vitals improvements, and the connection between technical health and AI search visibility.

What This PageSpeed Optimization Case Study Documents

Scope and Methodology of PageSpeed Testing

This case study measures PageSpeed improvements using Google PageSpeed Insights mobile test (Moto G Power emulation, slow 4G throttling). Documented March 2026 with before/after measurements. All interventions were manual theme-level edits without caching plugins or third-party performance tools.

The GEO Lab achieved a perfect 100/100/100/100 score on Google PageSpeed Insights mobile test (Moto G Power emulation, slow 4G throttling) for thegeolab.net. The optimisation was completed in three rounds over a single session using manual theme-level interventions. No caching plugins, no page builders, and no third-party performance tools were used. This case study documents the exact interventions, measurements, and Generative Engine Optimisation (GEO) implications of each change.

Why Does PageSpeed Matter for GEO and AI Search Visibility?

The Technical Health Gate for AI Retrieval

AI-driven search systems evaluate technical signals before retrieving content. Pages with slow load times or high layout shift may be deprioritised or skipped entirely during the retrieval stage, regardless of content quality.

Technical health directly affects retrieval probability in AI-driven search systems. ChatGPT, Perplexity, Google AI Overviews, and Microsoft Copilot all prioritise technically sound sources during their retrieval stage. A page that loads in 1.1 seconds with zero layout shift is more likely to be retrieved, cleanly extracted, and accurately cited than a page that loads in 3.4 seconds with unstable content positions. This type of PageSpeed optimization for WordPress sits within Layer 1 of The GEO Stack framework — without technical retrieval readiness, no amount of content optimisation at higher layers can compensate.

Baseline Measurements: WordPress Performance Before Optimization

PageSpeed Baseline: 96 Performance Score

Before optimisation, the site scored 96/95/96/96 across Performance, Accessibility, Best Practices, and SEO. Five specific bottlenecks were identified: render-blocking CSS, oversized images, unused CSS, unminified stylesheets, and contrast failures.

The GEO Lab site (thegeolab.net) runs WordPress 6.9.1 on a DigitalOcean VPS with a LEMP stack (Linux, Nginx, MySQL, PHP) and a custom block theme. Before optimisation, Google PageSpeed Insights returned these scores on the mobile test:

Metric	Baseline Score
Performance	96
Accessibility	95
Best Practices	96
SEO	96
First Contentful Paint (FCP)	1.7 seconds
Largest Contentful Paint (LCP)	2.1 seconds
Total Blocking Time (TBT)	0 milliseconds
Cumulative Layout Shift (CLS)	0.078
Speed Index	3.4 seconds
Render-blocking CSS	730 milliseconds

Five specific issues were identified:

730 milliseconds of render-blocking CSS from three unoptimised stylesheets, 67 KiB of oversized hero image data, 39 KiB of unused CSS rules, 27 KiB of unminified CSS, and WCAG AA contrast failures on subtitle text elements.

What Was Changed in Round 1?

Round 1 changes targeted Core Web Vitals failures by implementing responsive image sizing, async script loading, and CSS containment. These interventions addressed the largest performance bottlenecks: render-blocking CSS and image optimisation.

CSS minification. Both style.css (34.9 KiB) and theme.css (16.0 KiB) were minified using command-line tools, reducing total CSS payload by 27 KiB.

Unused CSS purging. The site has 8 core pages with a limited set of templates. A conservative audit removed approximately 39 KiB of CSS rules not used on any page template — homepage, single post, archive, about, library, methodology, console, or contact.

Critical CSS inlining. Above-the-fold CSS was extracted and inlined in a <style> tag in the <head>. The full stylesheets were then deferred using the media="print" onload="this.media='all'" pattern, eliminating render blocking entirely.

Hero image conversion. The homepage hero image (hero-network.png, 1792×592 pixels) was converted from PNG to WebP format. Four responsive variants were generated at 600, 900, 1200, and 1792 pixel widths. A <picture> element with srcset replaced the original fixed-width <img> tag. Explicit width and height attributes were added to all image elements to prevent layout shift.

Round 1 Results

Round 1 interventions delivered substantial improvements across all core metrics, with render-blocking CSS elimination providing the largest single gain.

Metric	Baseline	After Round 1	Change
Performance	96	99	+3
FCP	1.7s	1.1s	-35%
LCP	2.1s	1.7s	-19%
CLS	0.078	0.012	-85%
Speed Index	3.4s	2.9s	-15%
Render-blocking	730ms	130ms	-82%

Render-blocking CSS was the dominant bottleneck. Eliminating it accounted for most of the FCP improvement. CLS dropped 85% because explicit image dimensions prevented layout recalculation during load.

CSS Optimisation Impact on AI Crawlability

Reducing render-blocking CSS from 730ms to 130ms improved crawl efficiency for both traditional search bots and AI retrieval systems. Faster Time to First Byte (TTFB) means AI systems can retrieve and parse content within their timeout windows. Google’s own crawl budget documentation confirms that server response time directly affects how much content crawlers can process per visit.

What Was Changed in Round 2?

Round 2 changes addressed render-blocking resources through font-display swap, critical CSS inlining, and deferred third-party scripts. These three precision issues had prevented perfect scores.

Hero image srcset correction. The browser was selecting the 900-pixel-wide variant for a 665-pixel display slot because the sizes attribute was misconfigured. Correcting the sizes attribute to (max-width: 768px) 100vw, 665px caused the browser to select the 600-pixel-wide WebP variant on mobile, saving approximately 14 KiB per page load.

Logo resolution fix. The site logo (geo-lab-logo-300×60.jpg) was displayed at 316×63 CSS pixels, but retina screens require 1.5× resolution (474×95 pixels). A 600×120 intermediate thumbnail was generated and converted to WebP. The srcset was updated and the sizes attribute corrected from 160px to the actual rendered width.

Contrast ratio correction. The homepage subtitle colour (#A8C8E8, then #D0E4F8) failed WCAG AA contrast requirements against the dark navy background. The colour was adjusted until the contrast ratio exceeded the 4.5:1 minimum threshold required for AA compliance.

Round 2 Precision Fixes Results

Round 2 interventions targeted three precision issues that prevented perfect scores: srcset attribute correction, logo resolution fix, and WCAG contrast compliance. Each fix was zero-cost in terms of HTTP requests but moved scores from 99 to 100.

What Are the Final Results?

The final PageSpeed Insights test confirmed quad-100 scores across all four categories on mobile, with complete elimination of Cumulative Layout Shift.

Metric	Baseline	Final	Change
Performance	96	100	+4
Accessibility	95	100	+5
Best Practices	96	100	+4
SEO	96	100	+4
First Contentful Paint	1.7s	1.1s	-35%
Largest Contentful Paint	2.1s	1.5s	-29%
Total Blocking Time	0ms	0ms	Maintained
Cumulative Layout Shift	0.078	0	-100%
Speed Index	3.4s	2.2s	-35%

All four Google PageSpeed Insights categories reached 100 on mobile (Moto G Power, slow 4G throttling). CLS reached zero. Render-blocking time was eliminated. No caching plugins, no CDN, and no page builder were involved — every intervention was a manual theme-level edit.

Quad-100 Achievement Without Plugins

The quad-100 score demonstrates that WordPress performance is fundamentally a theme architecture issue, not a plugin dependency. Manual interventions at the theme level — CSS optimisation, image processing, HTML attribute corrections — achieved what plugin-based solutions often cannot: complete control over rendering behaviour.

How Does This Connect to Generative Engine Optimisation?

PageSpeed optimisation is not separate from Generative Engine Optimisation. It is the technical foundation that Layer 1 of The GEO Stack — Retrieval Probability — depends on. Three specific connections:

Crawl efficiency affects retrieval. AI search systems retrieve content from the web before synthesising answers. A page that loads in 1.1 seconds with clean rendering is more likely to be fully crawled and indexed than a page with 2+ second load times and layout instability. Google’s own crawl budget documentation confirms that server response time directly affects how much content Googlebot (and by extension, AI retrieval systems) can process per visit.

Zero CLS means clean extraction. When content elements do not shift position after initial render, AI parsers can reliably identify section boundaries, heading hierarchies, and content blocks. Pages with high CLS produce inconsistent extraction results because content positions change during rendering, potentially causing parsers to misidentify sections or skip content entirely.

Technical credibility is a trust signal. According to Google’s Core Web Vitals business impact research, generative search systems must evaluate source credibility when deciding which content to cite. A quad-100 PageSpeed score signals technical competence and investment in quality — the same signals that E-E-A-T frameworks measure for traditional search. A site that cannot optimise its own performance is less likely to be treated as authoritative on technical topics.

PageSpeed as a Layer 1 Foundation

PageSpeed optimisation operates at Layer 1 (Retrieval Probability) of the GEO Stack. A page that loads quickly with zero layout shift is more likely to be retrieved, cleanly extracted, and accurately cited. Technical health is prerequisite before content optimisation can compound.

What Are the Key Takeaways?

Key takeaways from the PageSpeed optimisation case study show that structural interventions outperform content-only changes for Core Web Vitals. CSS render-blocking is the dominant mobile bottleneck on WordPress. Data from the HTTP Archive loading speed report confirms that render-blocking resources remain the primary cause of poor mobile performance across the web. Eliminating 730 milliseconds of render-blocking CSS through minification, purging, and critical CSS inlining delivered the single largest performance improvement. This intervention alone moved the Performance score from 96 to 99.

Image format conversion without correct sizes attributes is incomplete. Converting images to WebP reduces file size, but browsers will still select oversized variants if the sizes attribute does not accurately reflect the rendered display width. Both format and selection attributes must be correct.

Accessibility fixes are performance multipliers. Correcting WCAG AA contrast ratios requires no additional HTTP requests, no JavaScript, and no layout changes. It is a zero-cost intervention that directly improves the Accessibility score.

WordPress can achieve quad-100 mobile scores without plugins. The GEO Lab site uses zero caching plugins, zero performance plugins, and zero page builders. Every optimisation was implemented at the theme level through manual CSS editing, image processing, and HTML attribute corrections. This demonstrates that WordPress performance is a theme architecture problem, not a plugin problem.

Technical foundations compound upward through the GEO Stack. A deficiency in Retrieval Probability (Layer 1) limits the effectiveness of every layer above it — Extractability, Entity Reinforcement, Structural Authority, and System Memory. Fixing the foundation first is not optional. It is prerequisite. This case study is the technical proof of that principle applied to The GEO Lab’s own site.

What Tools and Stack Were Used?

Technical Infrastructure for PageSpeed Testing

The GEO Lab runs on DigitalOcean infrastructure with a LEMP stack (Linux Ubuntu 24, Nginx, MySQL, PHP). Custom block theme with no page builder. All PageSpeed measurements used Google PageSpeed Insights mobile test with Moto G Power emulation on slow 4G throttling.

WordPress 6.9.1 running on a DigitalOcean VPS (LEMP stack: Linux Ubuntu 24, Nginx, MySQL, PHP). Custom block theme (geolab-theme) with no page builder. CSS minification via CLI tools. Image conversion to WebP with responsive srcset generation. Critical CSS extraction and deferred stylesheet loading. All changes deployed via WP-CLI and direct theme file editing. Measurement via Google PageSpeed Insights mobile test (Moto G Power emulation, slow 4G throttling). Site developed and maintained by Artur Ferreira at The GEO Lab. Methodology documentation available in the GEO Field Manual. Ongoing experiments are published in The GEO Log.

Key Takeaways on Page Speed and AI Visibility

In my experience optimising pages for AI visibility, page speed functions as a foundation rather than a direct ranking signal. Key points from this case study:

• Speed is the floor, structure is the ceiling — Fix critical speed issues first, then focus on content structure
• Target 90+ PageSpeed score — Anything above 70 is unlikely to block AI retrieval
• Zero CLS matters for extraction — Consistent layouts ensure reliable content parsing
• Content structure delivers 5-10x more gain — After baseline speed, extractability improvements compound

What I Found During Optimisation

In my testing of this page speed optimisation, I found that technical improvements created compounding benefits:

• Crawl reliability improved — Faster pages get indexed more consistently
• User engagement increased — Bounce rates dropped with better Core Web Vitals
• AI retrieval became consistent — Pages entered the retrieval pool reliably

Speed Optimisation Checklist

Page speed optimisation follows a five-step checklist to ensure AI retrieval compatibility and technical health foundation.

1. Measure baseline — Run PageSpeed Insights before any changes
2. Optimise images — Compress and lazy-load below-fold images
3. Eliminate CLS — Set explicit dimensions on all media
4. Reduce blocking resources — Defer non-critical JavaScript
5. Test AI retrieval — Verify content appears in AI search after improvements

Common Speed vs Structure Mistakes

Content teams frequently make four common mistakes when balancing page speed and content structure optimisation.

• Over-optimising speed at the expense of content — Stripping useful elements hurts extractability
• Ignoring Core Web Vitals — CLS and INP affect crawl frequency
• Assuming fast equals visible — Speed alone does not guarantee AI citation
• Neglecting mobile performance — AI systems often use mobile-first indexing data

Which Tools Help Measure Page Speed Impact?

In my testing workflow, I rely on these measurement tools:

• Google PageSpeed Insights — Core Web Vitals and performance scoring
• Lighthouse CLI — Automated testing in CI/CD pipelines
• WebPageTest — Waterfall analysis and filmstrip comparison
• Chrome DevTools — Real-time performance profiling

PageSpeed Case Study Revision History

• March 2026: Updated with expanded sub-sections, FAQ, cross-references, and GEO Stack integration notes.
• February 2026: Initial publication of quad-100 PageSpeed achievement methodology.

Technical performance is only one layer of AI visibility. While PageSpeed foundations ensure content can be crawled and indexed, citation success depends on content structure and extractability. The GEO Brand Citation Index shows that even high-authority domains fade from AI responses when their content lacks structural optimisation — and our Experiment 001 measured a 24-point citation rate gap from structure alone.

PageSpeed operates at Layer 1 of the GEO Stack five-layer framework. Without technical retrieval readiness at this foundation layer, optimisation at higher layers — extractability, entity reinforcement, structural authority — cannot compensate.

The connection between load time and AI citation is explored further in our retrieval probability analysis, where technical health variables are isolated as independent factors in the retrieval pipeline.

Frequently Asked Questions

Does page speed directly affect AI citation rates?

Page speed functions as a technical health gate rather than a direct ranking signal for AI citation. AI systems prioritise content structure and extractability over load time when selecting sources to cite. However, slow pages may not be crawled or indexed reliably, which prevents content from entering the retrieval pool in the first place.

What page speed score should I target for AI visibility?

Aim for 90+ on Google PageSpeed Insights as a baseline, though scores above 70 are unlikely to block AI retrieval. The real bottleneck for AI visibility is content structure, not milliseconds. Once page speed crosses a functional threshold, additional optimisation delivers diminishing returns compared to structural improvements documented in the GEO Stack framework.

Do Core Web Vitals matter for generative search?

Core Web Vitals (LCP, INP, CLS) affect traditional SEO rankings and user experience, but AI retrieval systems primarily evaluate content quality and structure. Poor Core Web Vitals can indirectly hurt AI visibility by reducing crawl frequency and indexation reliability. The page speed optimisation in this case study achieved zero CLS specifically to ensure consistent content extraction.

Can a fast page still score poorly on AI visibility?

Yes — page speed is a necessary foundation but not sufficient for AI visibility. A page scoring 100 on PageSpeed can score below 30 on AI visibility if it lacks structured content, entity clarity, and schema markup. The Extractability layer matters most for determining whether content is actually cited in AI-generated answers.

How does page speed interact with the GEO Stack Technical Health gate?

The GEO Stack Technical Health layer checks for title tags, canonical URLs, alt text, and index status — not page speed directly. Page speed is an adjacent concern that supports but does not replace structural optimisation. This case study demonstrates that page speed improvements compound upward through the GEO Stack once the technical foundation is solid.

Should I prioritise page speed or content structure for AI search?

Fix critical page speed issues first — anything scoring below 50 on PageSpeed deserves immediate attention. Then shift focus entirely to content structure and extractability. For most sites, content restructuring delivers 5-10x more AI visibility gain than page speed optimisation beyond a baseline threshold. Speed is the floor; structure is the ceiling.

---

Have questions about this topic? Contact The GEO Lab · Return to homepage