Hi <<First Name>>,
This month's roundup of web performance and observability goodness includes:
- New research that suggests Google's recommended thresholds for Core Web Vitals may be wrong (!)
- Inspiring case study from Nuvemshop
- Performance audit for Kroger.com
- An answer to the question: will AI make performance engineers obsolete?
- Plain-language guide to OpenTelemetry – what it is and why it matters
- Performance.now() talks are now available to watch!
If you have any questions or feedback, I'd love to hear from you. And if you have any great resources you think belong in the next edition of this newsletter, please send them my way!
Until next month,
Tammy
@tammyeverts.com
|
|
|
New research: The Core Web Vitals thresholds you trust may be wrong for your site
I literally just hit the publish button on this exciting new piece of research. I gathered Core Web Vitals data for ten leading online retailers and looked at the relationship between Largest Contentful Paint (LCP) and bounce rate.
My hypothesis, based on data I've observed over the years: "Good" for Google may not be good enough for all websites.
One of the most striking findings: Google's recommended threshold for a "good" LCP time is 2.5 seconds, but for these 10 sites, the optimal LCP time ranged from 100ms to 1s!
If you'd like to learn more, join me for our biweekly Office Hour, coming up on Thursday, July 23. Scroll down for details.
|
|
|
How Nuvemshop's image prioritization strategy led to a 68% improvement in LCP and 8.9% more conversions
Nuvemshop, which powers 180,000+ Latin American ecommerce stores, found their LCP optimizations weren't moving the needle – largely because browsers were often flagging the wrong element as LCP in the first place. The real performance culprits: delayed CSS transitions, misapplied lazy-loading, and missing fetchpriority hints on above-the-fold images.
Fixing all three of those issues improved LCP and increased conversion rate by 8.9% – with the biggest gains coming from mobile. Read the full case study.
|
|
|
Performance audit: Kroger.com
What I love about this performance audit by Ethan Gardner isn't just that Ethan adeptly diagnoses the page-related issues. He also makes keen observations about the organizational priorities that might be at the bottom of the site's real issues:
Since the site has monitoring infrastructure in place, it’s likely that someone within the organization knows the extent of the performance issues. Tools like RUM don’t end up on a site without getting budget approval and making a case for it, so I believe there are teams that care and want to fix things. More than likely, there are competing priorities within the organization that influence the product that gets shipped to users.
|
|
|
Putting users first: What does "reliability" mean today?
Is it possible for your site or app to be completely reliable while at the same time completely failing your users? Yes. Consider this scenario. Your infrastructure is humming along beautifully. Uptime is 99.9%. Your SLOs are green across the board. Your error budget is intact.
You are, by every traditional measure of reliability, crushing it. And yet users are abandoning your app after two seconds on the loading screen. Scrolling feels choppy and weird. Taps on buttons feel laggy. The app crashes, not frequently, but just frequently enough that a certain percentage of your users – the ones who’ve experienced it – have uninstalled and moved on.
This post explores:
- What "reliability" means to an end user
- Four important UX metrics that map to reliability: Screen Load, Smoothness, Responsiveness, and Stability
- Why it's a bad idea to have a narrow reliability lens – for your users, and for you
- How to bridge the gap between engineering and product teams
|
|
|
Will AI make performance engineers obsolete?
A few weeks back, I did my very first AMA. It was super fun. Folks asked great questions, so now I'm wrangling a few of my favourites into LinkedIn articles.
Joan Leon asked: "With the rise of the AI engineer model and a shift toward orchestrating functionality rather than manual coding, will the choice of framework – or even the role of the web performance engineer – become obsolete? Or does the focus just shift to a different part of the stack?"
As a non-engineer, I won't speak to the framework question, but I do have thoughts on the question about the performance engineer's role. Here's what I think about the kind of engineer who might be worried, the kind of engineer who really shouldn't worry, and why, at the end of the day, you're bigger and better than an LLM.
|
|
|
performance.now() talks are online!
If you missed the annual performance.now() conference last October, no worries – you can enjoy many of the talks from the comfort of your chair... or floor, or beach – no judgement! Here are all the talks that have been released so far:
More to come! Subscribe to the playlist for updates.
|
|
|
What is OpenTelemetry? A plain-language guide for beginners
If you already know everything there is to know about OpenTelemetry, this guide is probably not for you. BUT if you find yourself tasked with explaining OTel to other folks and you're looking for a shortcut, you may want to forward this along to them!
This piece covers, in VERY plain language:
- How OpenTelemetry works
- The three main problems that OTel solves
- Use cases where OTel makes a difference
For web performance and observability, the big takeaway is this: connecting your frontend, backend, and mobile data connects your teams and helps you bridge the gap between monitoring your infrastructure and understanding your users.
|
|
|
|
