With Long Animation Frames (commonly referred to as LoAF, pronounced 'LO-aff') we finally have a way to understand the impact of our code on our visitors' experiences.Long Animation Frame – a frame that took longer then 50ms from its start to when it started paintingLoAF allows us to understand how scripts and other tasks affect both hard and soft navigations, as well as how scripts affect interactions. Using the data LoAF provides, we can identify problem scripts and target changes that improve our visitors' experience. We can also finally start to quantify the impact of third-party scripts as they execute in our visitors' browsers.Keep reading to learn:Why animation frame rate mattersAnatomy of a Long Animation FrameKey LoAF milestones and what we can do with milestone dataScript attribution (and why script details might sometimes be unavailable)How to match script data to Interaction to Next Paint, including sub-partsHow to capture LoAF entriesGetting started with LoAFLoAF support i

CPU consumption by the browser is one of the main causes – if not the number one cause – of a poor user experience. The primary culprit? JavaScript execution. Now you can use SpeedCurve to monitor Long Animation Frames (LoAFs) and fix the third parties and other scripts that are hurting your page speed.Until recently, we've had little evidence from the field that definitively attributes the root cause of rendering delays. While JavaScript Long Tasks gave us a good indication that there were blocking tasks affecting metrics such as Interaction to Next Paint and Largest Contentful Paint, there was no way to attribute the work or understand how it was ultimately affecting rendering. Fortunately, we've gotten a lot of help from Chrome in improving the attribution – and ultimately the actionability – of the data we collect in the field with RUM. The introduction of the Long Animation Frames API (LoAF) not only gives us better methods for understanding what's happening on the browser's main

Have you ever wondered why your site got faster, but your business and user engagement metrics didn't improve? The answer might lie on the performance plateau.Have you ever asked yourself these questions?"I made my pages faster, but my business and user engagement metrics didn't change. WHY???""How do I know how fast my site should be?""How can I demonstrate the business value of page speed to people in my organization?"The answers might lie with identifying and understanding the performance plateau for your site.What is the "performance plateau"?The performance plateau is the point at which changes to your website’s rendering metrics (such as Start Render and Largest Contentful Paint) cease to matter because you’ve bottomed out in terms of business and user engagement metrics.In other words, if your page speed metrics are on the performance plateau, making them a couple of seconds faster probably won't help your business.A correlation chart is an essential tool for identifying your pe

Our newest performance hero is passionate, provocative, and unapologetically honest. While he's a true champion for web performance, his impact can be measured more broadly across the web. Join us in celebrating Alex Russell!Alex Russell has been a strong voice in the web community for as long as I can remember. He's currently a Partner PM at Microsoft, working on Edge. Before that, he spent several years working at Google on Chrome, web standards, and much more.Not only is Alex an accomplished engineer, he's also an amazing speaker and writer. I last saw Alex on stage at performance.now() in November, where he delivered this inspiring talk that got a lot of attendees talking.After reaching out to Alex for this interview, I was pleased to see how thoughtful he was in his response. Not only did he provide great insights, he was quick to point out a handful of colleagues at Microsoft he felt more deserving of recognition, including Amiya Gupta, Ingrid Caldas, and Paul Roy.Alex's passion

If you could measure the impact of site speed on your business, how valuable would that be for you? Say hello to correlation charts – your new best friend.Here's the truth: The business folks in your organization probably don't care about page speed metrics. But that doesn't mean they don't care about page speed. It just means you need to talk with them using metrics they already care about – such as conversion rate, revenue, and bounce rate.That's why correlation charts are your new best friend.What is a correlation chart?A correlation chart is a powerful data visualization that shows you the relationship between your page speed metrics and your business and user engagement metrics.Correlation charts are generated using real user monitoring (RUM) data. They give you a histogram view of all your user traffic, broken out into cohorts based on performance metrics, such as Start Render, Largest Contentful Paint, Interaction to Next Paint, and more. Each cohort shows you the median time fo

Comparing site outages to page slowdowns is like comparing a tire blowout to a slow leak. One is big and dramatic. The other is quiet and insidious. Either way, you end up stranded on the side of the road.Downtime is horrifying for any company that uses the web as a vital part of its business (which is to say, most companies). Some of you may remember the Amazon outage of 2013, when the retail behemoth went down for 40 minutes. The incident made headlines, largely because those 40 minutes were estimated to have cost the company $5 million in lost sales.Downtime makes headlines:2015 – 12-hour Apple outage cost the company $25 million2016 – 5-hour outage caused an estimated loss of $150 million for Delta Airlines2019 – 14-hour outage cost Facebook an estimated $90 millionIt's easy to see why these stories capture our attention. These are big numbers! No company wants to think about losing millions in revenue due to an outage. Page slowdowns can cause as much damage as downtimeWhile Amazo

This month, we've made some updates to our synthetic testing agents. In addition to upgrading the underlying operating system, we've added support for:Lighthouse 12.3.0 (previously 10.4.0)Chrome 133 (previously 126)Firefox 135 (previously 128)What has changed?We understand the sensitivity related to changes in your performance data.Synthetic updates are known to cause baseline changes due to hardware changes, browser optimization or in the case of Lighthouse, changes to the methodology.Here is a rundown of what's changed in this update:ChromeMoving from Chrome 126 to 133 should not have a huge impact on your metrics.As of Chrome 130, transparent text is no longer eligible to be considered for Largest Contentful Paint (LCP) but this change doesn't appear to affect a larger number of sites. There were a number of updates to Chrome, which may affect Interaction to Next Paint (INP) introduced between 126 and 130, but as we don't measure INP with synthetic, there is no impact to your metric

We often hear how special, generous, and supportive the web performance community is. This didn't happen overnight. This month, we're excited to recognize someone who has been a huge part of creating the community culture we enjoy today: Sergey Chernyshev.Whether answering questions on social media, helping someone with a proposal for a conference talk, or simply being welcoming and kind to newcomers, webperf folks are some of the most generous people you could ever hope to find. There are so many folks out there who are organizing, educating, evangelizing, and building great tooling in an effort to improve user experience on the web. Sergey has been doing all of those things earlier and longer than almost everyone!Sergey is a well-known early champion of web performance and user experience. Among other things...Back in 2009, he started the first web performance meetup group in New York City, which is still running strong today.He lit the match for many conversations about how to impro

Have you ever looked at the page speed metrics – such as Start Render and Largest Contentful Paint – for your site in both your synthetic and real user monitoring tools and wondered "Why are these numbers so different?"Photo by FreepikPart of the answer is this: You have a lot of control over the design and code for the pages on your site, plus a decent amount of control over the first and middle mile of the network your pages travel over. But when it comes to the last mile – or more specifically, the last few feet – matters are no longer in your hands. Your synthetic testing tool shows you how your pages perform in a clean lab environment, using variables – such as browser, connection type, even CPU power – that you've selected.Your real user monitoring (RUM) tool shows you how your pages perform out in the real world, where they're affected by a myriad of variables that are completely outside your control. In this post we'll review a handful of those performance-leaching culprits tha

The median web page is 8% bigger than it was just one year ago. How does this affect your page speed, your Core Web Vitals, your search rank, your business, and most important – your users? Keep scrolling for the latest trends and analysis.For almost fifteen years, I've been writing about page bloat, its impact on site speed, and ultimately how it affects your users and your business. You might think this topic would be exhausted by now, but every year I learn new things – beyond the overarching fact that pages keep getting bigger and more complex, as you can see in this chart, using data from the HTTP Archive:In this post, we'll cover:How much pages have grown over the past yearHow page bloat hurts your business and – at the heart of everything – your usersHow page bloat affects Google's Core Web Vitals (and therefore SEO)If it's possible to have large pages that still deliver a good user experiencePage size targetsHow to track page size and complexityHow to fight regressionsanymouse1