Web Performance Milestone ![rw-book-cover](https://weston.ruter.net/wp-content/uploads/2025/08/core-web-vitals-assessment-passed-v2.png) ## Metadata - Author: [[Weston Ruter]] - Full Title: Web Performance Milestone - Category: #articles - Document Note: --- tags: - #webperformance - #corewebvitals - #wordpress Author: Weston Ruter Source: Personal blog Reference: https://weston.ruter.net/2025/08/21/web-performance-milestone/ date created: 2025-08-22 00:00 --- # Title: Web Performance Milestone ## Table of Contents: - [🚀 Overview](#-overview) - [📈 Field Metrics and CWV](#-field-metrics-and-cwv) - [🧪 Optimization Journey](#-optimization-journey) - [🛠️ WordPress Contributions](#-wordpress-contributions) - [🎤 Talk: The Site Speed Frontier](#-talk-the-site-speed-frontier) - [📊 PSI and Lighthouse Results](#-psi-and-lighthouse-results) - [🔗 References](#-references-1) ### References: Include a list of sources consulted and cited in the article. - Chrome UX Report (CrUX) - PageSpeed Insights - Lighthouse - WordPress Core Performance Team / Performance Lab - WordPress 6.9 roadmap - WordCamp US 2025 ## 📝 Summary: Weston Ruter announces a major performance milestone: his WordPress blog now passes Core Web Vitals (CWV) on both desktop and mobile using real-user field data from CrUX and scores 100 across Performance, Accessibility, Best Practices, and SEO in Lighthouse on both mobile and desktop. He frames this not as the finish line but as a waypoint, emphasizing continuous optimization (e.g., improving LCP beyond “good,” tackling TTFB), and notes that his learnings are being upstreamed into the WordPress Performance Lab, feature plugins, and the WordPress 6.9 roadmap. He also previews his WordCamp US 2025 talk, “The Site Speed Frontier with Performance Lab and Beyond.” ## 📖 Main Content: Weston charts the evolution from seeing origin-level desktop field metrics in CrUX to reaching mobile eligibility and passing CWV on both. He underscores that CWV eligibility requires sufficient traffic for statistically significant field data, which he now has at the origin level. Despite excellent frontend tuning evidenced by very low LCP minus TTFB intervals (400ms mobile, 100ms desktop), he calls out server-side TTFB as an area for continued work. The core message: don’t settle for merely passing CWV or hitting a 100 Lighthouse score—push further, and make performance defaults better in WordPress so site owners benefit without becoming performance experts. He links this personal milestone to broader community outcomes: blog posts documenting techniques, contributions to Performance Lab, and roadmap improvements in WordPress 6.9. He invites the community to his WordCamp US 2025 session and to subscribe for upcoming deep dives. ### 🗒️ Notes - CWV field metrics milestone - Origin-level CWV appeared first on desktop, later on mobile. - CrUX eligibility depends on sufficient traffic for statistically significant samples. - Passing CWV on both desktop and mobile is now achieved. - Continuous improvement mindset - Passing CWV and scoring 100 in Lighthouse isn’t the end. - Aim to reduce LCP further (e.g., driving toward sub-1s and minimizing LCP-TTFB). - TTFB currently near the “needs improvement”/“poor” threshold; target server and network layers next. - Frontend tuning outcomes - LCP–TTFB gap: ~400ms on mobile, ~100ms on desktop, indicating highly optimized render path. - CLS at 0 on both platforms—a sign of stable layouts. - WordPress ecosystem impact - Findings shared via posts; observable community interest. - Learnings flow into Performance Lab feature plugins and WP 6.9 improvements. - Goal: ship best practices by default so site owners don’t have to be performance experts. - Community engagement - WordCamp US 2025 talk: “The Site Speed Frontier with Performance Lab and Beyond” (Aug 27, 11:30am PDT; livestreamed/recorded). - Encourages subscription for upcoming write-ups and elaborations. Direct quotes and key data: - “Core Web Vitals Assessment: Passed” - “LCP is 2.2s, CLS is 0, FCP is 2.1s, and TTFB 1.8s” (mobile) - “LCP is 1.9s, CLS is 0, FCP is 1.9s, and TTFB 1.8s” (desktop) - “on mobile the LCP-TTFB in CrUX is 400ms and on desktop it’s only 100ms” - Lighthouse 100s for Performance, Accessibility, Best Practices, SEO on both mobile and desktop ## 📖 References: - Chrome UX Report (CrUX) - PageSpeed Insights - Lighthouse - WordPress Performance Lab and feature plugins - WordPress 6.9 performance roadmap - WordCamp US 2025 session ## 🗣️ Paraphrase: 1) Original idea: Don’t stop at “passing” CWV or 100 Lighthouse. Why accept a decent 2s LCP if it could be half that or effectively instant? Performance is a journey. Field data shows TTFB hovering near “needs improvement”/“poor,” yet thanks to frontend tuning, LCP minus TTFB is just 400ms on mobile and 100ms on desktop. Paraphrase: Hitting a passing CWV grade or even a perfect Lighthouse score isn’t the ceiling. If LCP is still around two seconds, there’s room to cut it dramatically, potentially to near-zero perceived delays. My field telemetry suggests server response time (TTFB) is the current bottleneck, but the render pipeline is so refined that once bytes arrive, the remaining path to the LCP is only a few hundred milliseconds on mobile and even less on desktop. 2) Original idea: Many people won’t—or shouldn’t have to—obsess over performance. The plan is to integrate these lessons into WordPress core via the Performance Team so best practices are default, sparing site owners from complexity. Paraphrase: Not everyone wants to dive deep into performance tuning, and they shouldn’t need to. By channeling these insights into WordPress core through the Core Performance Team and ecosystem, we can bake in sound defaults so performance improvements just happen for most users. ## 📰 Newsletter: This week in WordPress performance: Weston Ruter hit a big milestone—his blog now passes Core Web Vitals on both desktop and mobile in real-user CrUX data and scores 100 across Performance, Accessibility, Best Practices, and SEO in Lighthouse. The twist? He’s not treating this as “done.” Weston argues we shouldn’t settle for “passing” or “100”—shave LCP further and tame TTFB to make speed feel instant. He’s channeling these learnings into Performance Lab feature plugins and the WordPress 6.9 roadmap so best practices become defaults, not chores. Catch his WordCamp US 2025 talk, “The Site Speed Frontier with Performance Lab and Beyond” (Aug 27, 11:30am PDT), which will be livestreamed. If you’re hungry for actionable insights, subscribe to his updates and bring your favorite TTFB jokes; they’re snappy, unlike slow origins. Useful links: - Weston’s milestone write-up: Web Performance Milestone - Learn about Core Web Vitals: Google CWV overview - Performance Lab plugin: WordPress Performance Team - PageSpeed Insights and Lighthouse docs for hands-on testing ## ✅ Action Items: Prompt for aligning articles with your Developer Advocate/OSPO trajectory: “Analyze how this article advances open-source advocacy, contributor onboarding, and WordPress education. Identify: - Which performance practices can be upstreamed into WordPress core or Performance Lab to reduce user burden and improve defaults. - Opportunities for contributor engagement (good-first-issue areas in performance, docs, and testing across PHP/JS/CSS). - Educational assets to design (tutorials, workshops, code labs, office hours) mapping to PHP, JavaScript, HTML/CSS, Git/GitHub curricula. - How to measure impact (CrUX deltas, Lighthouse trends, adoption of feature plugins, contribution growth). - Governance and OSPO-readiness: policies, contribution pathways, funding models for maintenance of performance improvements, and transparency metrics. - DEIB and accessibility considerations in performance work, ensuring inclusive defaults for global audiences and diverse infrastructures. Conclude with a phased plan (near/mid/long term) that ties the article’s recommendations to my goals of becoming an OSPO director and fostering a sustainable, inclusive WordPress ecosystem.” ## 🧪 Hypotheses: - H1: Reducing server TTFB by 30–50% will yield disproportionately large improvements in LCP distribution tails (p75 and p95) for mobile users. - H2: Shipping more performance defaults via core/Performance Lab reduces the variance in CWV across the plugin/theme ecosystem. - H3: Educating developers on LC - Summary: My blog is now passing the CWV assessment on desktop and mobile in CrUX and has 100 in Lighthouse! But the web performance journey isn't over. - URL: https://weston.ruter.net/2025/08/21/web-performance-milestone/ ![Core Web Vitals Assessment: Passed](https://i0.wp.com/weston.ruter.net/wp-content/uploads/2025/08/core-web-vitals-assessment-passed-v2.png?w=2440&ssl=1) August 22, 2025 [WordPress](https://weston.ruter.net/category/wordpress/) A couple months ago, [this blog](https://weston.ruter.net/) reached a web performance milestone which I shared on [LinkedIn](https://www.linkedin.com/posts/westonruter_for-the-first-time-ever-ive-just-seen-my-activity-7334960747849887744-ubB9), [Bluesky](https://bsky.app/profile/weston.ruter.net/post/3lqkkjkaqc22q), [Mastodon](https://mastodon.social/@westonruter/114608757425002787), [Twitter](https://x.com/westonruter/status/1929195196710875311): > For the first time ever, I’ve just seen my blog appear in field metrics from CrUX (Chrome UX Report), albeit in desktop only and for the origin not an individual URL. Baby steps. In any case, Core Web Vitals Assessment: Passed ✅ > > Yesterday, I checked [PageSpeed Insights](https://pagespeed.web.dev/) again, and I was excited to discover that my blog is now also appearing in field metrics for mobile as well! And like desktop, the CWV assessment is also passing for mobile. The [eligibility criteria](https://developer.chrome.com/docs/crux#:~:text=primarily%20that%20they%20must%20be%20publicly%20discoverable%20and%20there%20must%20be%20a%20large%20enough%20number%20of%20visitors%20in%20order%20to%20create%20a%20statistically%20significant%20dataset) for the CrUX dataset includes that “there must be a large enough number of visitors in order to create a statistically significant dataset.” Granted, my site is still only getting enough traffic for origin-level metrics, and I can’t see field metrics for the homepage URL specifically, but it’s another baby step! (Or maybe a toddler step?) I’ve really been trying to double down this summer on tuning every bit of performance possible out of WordPress (on the frontend), using my site as a case study, and I’ve been sharing my findings in posts here. I hope the site traffic is an indication that the community has found my posts helpful. The learnings are also making their way into [Performance Lab](https://wordpress.org/plugins/performance-lab/) feature plugins as well as in performance improvements on the [roadmap for WordPress 6.9](https://make.wordpress.org/core/2025/07/28/roadmap-to-6-9/#performance-improvements). I have some more posts that I’m working on. You can [subscribe](https://weston.ruter.net/subscribe/) to get them in your inbox. On August 27th (next Wednesday) at [WordCamp US 2025](https://us.wordcamp.org/2025/) here in Portland, Oregon, I’m giving a talk called “[**The Site Speed Frontier with Performance Lab and Beyond**](https://us.wordcamp.org/2025/session/the-site-speed-frontier-with-performance-lab-and-beyond/)” at 11:30am PDT. I hope to see you there, but it will also be livestreamed and recorded. I’ll be blogging an elaborated version of what I have time to share in my talk. (By the way, if you are attending in person, check out [My Portland Picks](https://weston.ruter.net/2024/09/12/my-portland-picks/) post for what I recommend visitors check out!) One takeaway I’ll be emphasizing in my talk is that we needn’t settle with sites merely *passing* the Core Web Vitals assessment or achieving a “perfect” 100 performance score in Lighthouse. Why be content with a good 2-second LCP when it could be half that or even practically zero? Web performance is a journey, and there’s always room for improvement. I can see from my blog’s field metrics, for example, that the TTFB is hovering around the threshold between “needs improvement” and “poor”. In spite of this, the frontend is so tuned that on mobile the LCP-TTFB in CrUX is 400ms and on desktop it’s only 100ms. I personally love optimizing the performance of WordPress sites, but I get it that this isn’t for everyone (nor should it be). By landing our improvements from the [Core Performance Team](https://make.wordpress.org/performance/handbook/about-the-team/), my hope is that WordPress core (and the ecosystem) will have best practices implemented by default so that site owners needn’t worry about performance. I had to take some PSI screenshots to memorialize the milestone: ![Core Web Vitals Assessment for Mobile: Passed. LCP is 2.2s, CLS is 0, FCP is 2.1s, and TTFB 1.8s.](https://i0.wp.com/weston.ruter.net/wp-content/uploads/2025/08/mobile-crux-expanded.png?w=1920&ssl=1)Mobile ![Core Web Vitals Assessment for Desktop: Passed. LCP is 1.9s, CLS is 0, FCP is 1.9s, and TTFB 1.8s.](https://i0.wp.com/weston.ruter.net/wp-content/uploads/2025/08/desktop-crux-expanded.png?w=1920&ssl=1)Desktop ![Lighthouse performance score 100 for mobile, as well as 100 for the Accessibility, Best Practices, and SEO.](https://i0.wp.com/weston.ruter.net/wp-content/uploads/2025/08/mobile-lighthouse.png?w=1920&ssl=1)Mobile ![Lighthouse performance score 100 for desktop, as well as 100 for the Accessibility, Best Practices, and SEO.](https://i0.wp.com/weston.ruter.net/wp-content/uploads/2025/08/desktop-lighthouse.png?w=1920&ssl=1)Desktop, Web Performance Milestone, Weston Ruter, 01k38q6m46xhaksasysnegwffv.