SpeedCurve Blog https://www.speedcurve.com/blog/ Speed matters. Get the latest on how the areas of design and performance overlap with a focus on creating great user experiences. 2021 in review: It was a big year! https://www.speedcurve.com/blog/2021-recap <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/runners.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>This is the most important question we ask ourselves regularly here at SpeedCurve:</p> <p style="text-align: center;"><strong>Does this bring happiness?</strong></p> <p>"This" can mean anything from design and features to our own internal processes. We apply this litmus test to everything we do, and I believe it's the secret of our success. It's why we have such&nbsp;an incredible team, such wonderful customers, and such a heartfelt commitment to building tools that make your life easier... and ultimately make your users' lives easier, too!&nbsp;</p> <p>2021 has been a full year. We celebrated our eighth birthday &ndash; which I think makes us about eighty-eight in tech years? We've also grown our team, expanded our customer base, completed a full-scale site redesign, launched our in-house consulting practice, and refined our tools and processes. Here are some of the highlights...</p><h2>Elena Kay and Andy Davies joined our team!</h2> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/team.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Technically, <a href="https://www.speedcurve.com/blog/joining-speedcurve-team/">Elena joined us</a> at the very end of 2020, but since this marks the end of her first full year at SpeedCurve, I wanted to include her here. Elena is an invaluable member of our development team &ndash; and as an athlete, adventurer, and traveller, she's equally invaluable as an inspiration for living our best lives outside work hours!&nbsp;</p> <p><a href="https://www.speedcurve.com/blog/hello-from-europe/">Andy joined us in June</a>, and since then he's already helped countless customers in his role as in-house performance consultant. If you've been working in this industry for a while, you'll no doubt be very familiar with Andy's work as an independent consultant. We're so happy to have him on Team SpeedCurve!</p> <h2>Continued focus on Core Web Vitals</h2> <p><a href="https://www.speedcurve.com/blog/new-vitals-dashboard/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/core-web-vitals-budgets.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>Google's Core Web Vitals have been a huge topic this year. We've been tracking these as individual metrics &ndash; Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift &ndash; since before Google branded them as a set. In the past year we've expanded your tracking, budgeting, and alerting capabilities to help you get more insight into how these metrics measure user experience on your site.&nbsp;</p> <ul> <li><strong>Vitals dashboard</strong>&nbsp; &ndash; This dashboard lets you see your Core Web Vitals at a glance, as well as drill down and get helpful visuals that show you what your users see when each metric is fired. (<a href="https://www.youtube.com/watch?v=6dOBbvh4ZLA">Watch a video walkthrough</a> of the Vitals dashboard.)</li> <li><strong>Custom Vitals tracking in your Favorites</strong> &ndash; Track Web Vitals in your Favorites, and set performance budgets for them in both SpeedCurve Synthetic and SpeedCurve RUM. (<a href="https://www.youtube.com/watch?v=jcmLJ8jkL34">Watch a demo video</a> showing how to create custom charts and performance budgets for Web Vitals.)</li> <li><strong>Cumulative Layout Shift visuals</strong> &ndash; Because CLS is a score-based metric that's intended to let you know how janky a page is, it's tricky to understand what it means in terms of actual user experience. We show you screenshots of the visual elements on your pages that contribute to page jank. (<a href="https://youtu.be/L5t8t5oqE-4">This video</a> shows you how to use SpeedCurve to investigate CLS issues.)</li> <li><strong>Largest Contentful Paint element highlighting</strong> &ndash; As you focus on measuring Largest Contentful Paint as part of your Core Web Vitals tracking, you may find yourself wondering what the heck your largest painted elements actually are. <a href="https://www.speedcurve.com/blog/largest-contentful-paint-canary-beta/">We've made LCP events easy to spot by highlighting them</a> in your Vitals dashboard, your test details, and your Sites dashboard, where you'll also see how key metrics are trending over time.</li> </ul> <h2>RUM Live dashboard</h2> <p><a href="https://support.speedcurve.com/changelog/updated-rum-live-and-new-page-views-dashboard"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/rum_live_tv_mode.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>This is so new, you might not have discovered it yet, but we've completely redesigned our RUM Live dashboard to give you a much richer overview of realtime performance. When used in conjunction with <a href="https://support.speedcurve.com/docs/share-dashboards">TV mode</a>, it's perfect for displaying in the office to get the whole team engaged in improving your performance culture. Visibility is the first step!</p> <h2>RUM Sessions dashboard</h2> <p><a href="https://www.speedcurve.com/blog/real-user-monitoring-sessions-dashboard/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/session_dashboard.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>If you want to understand how people actually experience your site, then you need to monitor real users. With your <a href="https://www.speedcurve.com/blog/real-user-monitoring-sessions-dashboard/"><strong>RUM Sessions dashboard</strong></a>, you can investigate things like spikes, baseline changes, or segments from a specific distribution. Your Sessions dashboard lets you drill down and segment your RUM data by:</p> <ul> <li>Metric / duration</li> <li>Browser</li> <li>Location</li> <li>Time period</li> </ul> <p><strong>More:</strong> <a href="https://www.youtube.com/watch?v=YkMB8vMkHMU">Watch this video</a> for a walkthrough of the RUM Sessions dashboard. To see how this dashboard can be used to investigate anomalies, check out <a href="https://www.youtube.com/watch?v=F2yqvLWUfrQ">this deep dive</a>.</p> <h2>Bookmarks dashboard</h2> <p><a href="https://support.speedcurve.com/docs/bookmark-and-compare-tests"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/bookmarks_dashboard.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>Being able to <a href="https://support.speedcurve.com/docs/bookmark-and-compare-tests">bookmark and compare</a>&nbsp;your performance data is crucial for investigating anomalies and diagnosing issues. To that end, we've given you the ability to:</p> <ul> <li><strong>Bookmark RUM sessions</strong> &ndash; Within the popup in any RUM time series chart, you can click on 'View Sessions' if you want to explore that dataset right away. Or if you want to save a dataset to explore and/or compare later, click 'Bookmark Sessions'.</li> <li><strong>Access all your bookmarks within your Bookmarks dashboard</strong> &ndash; Now you can access all your synthetic and RUM bookmarks in the same location, making it even easier for you to bookmark and compare tests and other datasets.</li> </ul> <h2><span style="font-size: 35px; color: #000000;">Relaunched website</span></h2> <p><a href="https://www.speedcurve.com/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/site-redesign.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>In the summer, we launched a brand-new version of <a href="https://www.speedcurve.com/"><strong>our website</strong></a>! This was a monumental overhaul that featured:</p> <ul> <li><a href="https://www.speedcurve.com/">A fresh new look and feel</a>, including energizing graphics from the talented&nbsp;<a href="https://twitter.com/stokedsamantha">Samantha Stokes</a>.&nbsp;</li> <li><a href="https://www.speedcurve.com/features/performance-monitoring/">Updated copy</a> to reflect all the ways that our tools and services can help you get fast and stay fast.</li> <li><a href="https://www.speedcurve.com/pricing/build/">Interactive pricing widget</a> so you can have complete visibility into how to manage your spending.</li> </ul> <h2><span style="color: #000000; font-size: 35px;">New Support Hub</span></h2> <p>On the heels of our site relaunch, we also launched our new <a href="https://support.speedcurve.com/docs/welcome"><strong>Support Hub</strong></a>! Eight years of building new features meant eight years worth of support docs. That's a lot of docs! Inevitably, some dead wood had accumulated, so we decided to give our docs a complete overhaul.</p> <p>We worked hard to structure our support docs to make them easy to scan and quickly find what you need &ndash; from our step-by-step guides to <a href="https://support.speedcurve.com/docs/get-started-synthetic">getting started with Synthetic</a> and <a href="https://support.speedcurve.com/docs/get-started-real-user-monitoring">RUM</a> through to troubleshooting and FAQs. We also added a "Performance 101" section that includes articles like:</p> <ul> <li><a href="https://support.speedcurve.com/docs/synthetic-vs-real-user-monitoring-rum">Synthetic vs. Real User Monitoring</a></li> <li><a href="https://support.speedcurve.com/docs/performance-budgets-101">Performance Budgets 101</a></li> <li><a href="https://support.speedcurve.com/docs/performance-culture-best-practices">Performance Culture Best Practices</a></li> <li><a href="https://support.speedcurve.com/docs/performance-for-product-managers">Web Performance for Product Managers</a></li> <li><a href="https://support.speedcurve.com/docs/performance-for-retailers">Web Performance for Retailers</a></li> <li><a href="https://support.speedcurve.com/docs/seo-and-web-performance">SEO and Web Performance</a></li> </ul> <p>If you have any suggestions for articles and guides you'd like to see, let me know!</p> <h2>SpeedCurve recipes</h2> <p><a href="https://support.speedcurve.com/recipes"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/recipes.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>You'll find <a href="https://support.speedcurve.com/recipes"><strong>Recipes</strong></a> in our Support Hub, but I want to call them out separately here because they're that exciting. Recipes are detailed walkthroughs &ndash; including sample scripts &ndash; of multi-step tasks, such as:</p> <ul> <li>Simulate a user journey</li> <li>Simulate a SPA or AJAX navigation</li> <li>Submit a login form</li> <li>Add a repeat view</li> <li>Track size for a single resource</li> </ul> <p>We'll be adding more recipes in the future, so send us suggestions for what you'd like to see at support@speedcurve.com.</p> <h2>Industry speed benchmarks for Japan</h2> <p>We have a number of SpeedCurve users who want an ongoing understanding of how popular Japanese websites perform, so we added Japan to our <a href="https://app.speedcurve.com/benchmarks/japan/media/fast/start-render/">Industry Page Speed Benchmarks dashboard</a>.&nbsp;</p> <p><a href="https://app.speedcurve.com/benchmarks/japan/retail/fast/start-render/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/432/japan-benchmarks.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>This dashboard gives you a high-level perspective into the performance of industry-leading sites, plus the ability to drill down and see detailed test results, including waterfall charts and Lighthouse scores. (This dashboard is public-facing so you don't need a SpeedCurve account to explore it.)</p> <h2>So many great customer stories!</h2> <p>We love it when our customers share their stories about using SpeedCurve and making their sites faster &ndash; and their users happier! Here are some favourites from the past year.</p> <h3><a href="https://medium.com/gumtree-dev-team/introduction-to-performance-monitoring-with-speedcurve-f51019a1f552">Gumtree: Introduction to performance monitoring</a></h3> <p>This is an excellent primer for anyone who's getting started with performance in general (and SpeedCurve in particular). Conor Malone&nbsp;explains the differences between synthetic and real user monitoring, how to create custom dashboards, and how to set up performance budgets and alerts.&nbsp;</p> <h3><a href="https://medium.com/insider-inc-engineering/the-five-pillars-of-performance-engineering-at-insider-3c562555f01c">The Five Pillars of Performance Engineering at Insider</a>&nbsp;</h3> <p>Jason Merriman shares the five pillars of performance engineering &ndash; from content delivery to performance evangelism &ndash; at Insider.com. This is a great piece about how an organization with a lot of performance maturity got to this point.</p> <h3><a href="https://medium.com/airbnb-engineering/measuring-web-performance-at-airbnb-122da8d3ea3f">Measuring Web Performance at Airbnb</a>&nbsp;</h3> <p>Josh Nelson shares which web performance metrics Airbnb tracks (including Core Web Vitals) and why, how they measure them, and &ndash; importantly &ndash; how they consider tradeoffs between them in practice.</p> <h3><a href="https://insidegovuk.blog.gov.uk/2021/06/16/how-real-user-monitoring-will-improve-gov-uk-for-everyone/">How real user monitoring will improve GOV.UK for everyone</a>&nbsp;</h3> <p>Matt Hobbs shares how the team at GOV.UK rolled out real user monitoring (RUM) and why they believe it will help them improve accessibility and availability for all users.</p> <h3><a href="https://medium.com/adeo-tech/fostering-a-web-performance-culture-on-leroymerlin-fr-41619e1473d6">Fostering a web performance culture at leroymerlin.fr</a>&nbsp;</h3> <p>The strength of your company's performance culture is one of the best indicators of success. Bertrand Laot at French retailer LeroyMerlin shares how they use a combination of RUM and synthetic monitoring &ndash; including performance budgets and alerts &ndash; to keep their entire team up to speed.</p> <h3><a href="https://web.dev/quintoandar/">How QuintoAndar increased conversion rates and pages per session by improving page performance</a>&nbsp;</h3> <p>Daniela Sayuri Yassuda shares how a project that focused on optimizing Core Web Vitals and migrating to Next.js resulted in a 5% increase in conversion rates, an 87% increase in pages per session, and a 46% reduction in bounce rate.</p> <h3><a href="https://web.dev/telegraph/">Improving Cumulative Layout Shift at Telegraph Media Group</a>&nbsp;</h3> <p>Chris Boakes explains how, within a couple of months, the leading UK news website managed to improve their 75th percentile CLS by 250% from 0.25 to 0.1.</p> <h2>That's our year in review</h2> <p>It's been a good one for us. I hope it's been good for you, too. :)</p> Tue, 21 Dec 2021 00:00:00 +1300 SEO and web performance: What to measure and how to optimize https://www.speedcurve.com/blog/seo-and-web-performance <p>Chances are, you're here because of <a href="https://developers.google.com/search/blog/2021/11/bringing-page-experience-to-desktop">Google's update to its search algorithm</a>, which affects both desktop and mobile, and which includes Core Web Vitals as a ranking factor. You may also be here because you've heard about the <a href="https://blog.chromium.org/2021/11/chrome-dev-summit-2021-moving-toward.html">most recent potential candidates for addition to Core Web Vitals</a>, which were just announced at Chrome Dev Summit.&nbsp;</p> <p>A few things are clear:</p> <ul> <li>Core Web Vitals, as a premise, are here to stay for a while.</li> <li>The metrics that comprise Web Vitals are still evolving.</li> <li>These metrics will (I think) always be in a state of evolution. That's a good thing. We need to do our best to stay up to date &ndash; not just with which metrics to track, but also with what they measure and why they're important.</li> </ul> <p>If you're new to <a href="https://web.dev/vitals/">Core Web Vitals</a>, this is a Google initiative that was launched in early 2020. Web Vitals is (currently) a set of three metrics &ndash; Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift &ndash; that are intended to measure the loading, interactivity, and visual stability of a page.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/core-web-vitals-budgets.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>When Google talks, people listen. I talk with a lot of companies and I can attest that, since Web Vitals were announced, they've shot to the top of many people's list of things to care about. <strong>But Google's prioritization of page speed in search ranking isn't new, even for mobile.</strong> As far back as 2013, Google announced that pages that load slowly on mobile devices would be penalized in mobile search.&nbsp;</p> <p>Keep reading to find out:</p> <ul> <li>How much does web performance matter when it comes to SEO?</li> <li>Which performance metrics should you focus on for SEO?</li> <li>What can you do to make your pages faster for SEO purposes?</li> <li>What are some of the common issues that can hurt your Web Vitals?</li> <li>How can you track performance for SEO?</li> </ul><h2>How much does web performance matter when it comes to SEO?</h2> <p>Performance has had an impact on SEO long before Web Vitals came along.</p> <p>Back in 2011, Smartfurniture.com shared:</p> <p style="padding-left: 30px;">"We discovered we could make a quantum leap in search engine rankings simply by increasing site performance. Across the board, we&rsquo;ve seen sales increases because of our improved ranking, with <a href="https://retailtouchpoints.com/features/executive-viewpoints/the-growing-need-for-speed-how-site-performance-increasingly-influences-search-rankings">20% more organic traffic</a> being driven to our site and 14% more page views."&nbsp;</p> <p>More recently, Pinterest shared that rebuilding their site with performance in mind resulted in a <a href="https://medium.com/pinterest-engineering/driving-user-growth-with-performance-improvements-cfc50dafadd7#.wwimdmkpp">15% increase in organic search traffic</a>. (You can find more SEO-related case studies at <a href="https://wpostats.com/tags/seo/">WPOstats.com</a>.)</p> <h2>Great performance isn't a substitute for poor content</h2> <p>As much as I'm an advocate for performance, I'm a greater advocate for overall user experience. And when it comes to user experience, quality content is still king. <a href="https://developers.google.com/search/docs/advanced/experience/page-experience">Google acknowledges this as well</a>, which warms my heart:</p> <p style="padding-left: 30px;">"While page experience is important, Google still seeks to rank pages with the best information overall, even if the page experience is subpar. Great page experience doesn't override having great page content. However, in cases where there are many pages that may be similar in relevance, page experience can be much more important for visibility in Search."</p> <p>Assuming that your content is amazing, let's move on to the next question. :)</p> <h2>Which performance metrics should you focus on for SEO?</h2> <p>In the big picture, SEO is about more than Google and Core Web Vitals.</p> <p>However,&nbsp;<a href="https://www.statista.com/statistics/216573/worldwide-market-share-of-search-engines/">Google has a global market share of almost 87%</a>, and <a href="https://www.contentpowered.com/blog/site-rank-bing-google/">it's the only search engine that factors page speed into its algorithm</a>. So for our purposes as web performance folks, Google controls where the goal posts go.</p> <p>As said, Google has drawn a clear line from search to performance with Core Web Vitals. Currently, these are the metrics that comprise Web Vitals:</p> <ul> <li><strong>Largest Contentful Paint (LCP)</strong> &ndash; The time at which the largest element in the viewport is rendered. It's only tracked on certain elements, e.g., IMG and VIDEO (learn more <a href="https://web.dev/lcp/#what-elements-are-considered">here</a>).</li> <li><strong>First Input Delay (FID)</strong> &ndash; The amount of time it takes for a page to respond to a user input, such as a click, key, or tap (learn more <a href="https://web.dev/fid/">here</a>).&nbsp;</li> <li><strong>Cumulative Layout Shift (CLS)</strong> &ndash; A score that captures how often a user experiences unexpected layout shifts as the page loads. Elements like ads and custom fonts can push important content around while a user is already reading it. A poor CLS score could be a sign that page feels janky to your users (learn more <a href="https://web.dev/cls/">here</a>).</li> </ul> <p>Google has also defined thresholds for "Good", "Needs Improvement", and "Poor". These are the same thresholds that you see in our <a href="https://www.speedcurve.com/blog/new-vitals-dashboard/">Vitals dashboard</a>, pictured here:</p> <p><a href="https://www.speedcurve.com/blog/new-vitals-dashboard/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/core-web-vitals-budgets.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>You should know that Google is exploring other goals and metrics for potential inclusion in Web Vitals down the road:</p> <ul> <li><strong>Responsiveness</strong> &ndash; Think of this as an expansion to First Input Delay. Whereas FID measures initial interaction delay, a more robust interactivity metric would capture the entire event duration, giving you a better idea of how well the page responds throughout a user's engagement with it (learn more <a href="https://web.dev/responsiveness/">here</a>).</li> <li><strong>Smoothness</strong> &ndash; Given the proliferation of animated content on the web, this is a much-needed metric for measuring how smoothly animation is rendered on the page (learn more <a href="https://web.dev/smoothness/">here</a>).</li> </ul> <h2>What can I do to make my pages faster for SEO?</h2> <p>Okay, that was a trick question. I don't believe you should be making your pages faster for SEO purposes.</p> <p>You should be making your pages leaner and faster because it makes your users happier and consumes less of their data, especially on mobile devices. Not surprisingly, happier users spend more time (and more money) on your site, are more likely to return, and are more likely to recommend your site to others.</p> <p>Having said that, there are a number of things you can do to fix your pages, improve user experience, and ultimately boost your Web Vitals results. <strong>If you want to make your pages faster, the first places to look at are images and render-blocking resources.</strong> I'm not a developer and don't pretend to be one, so here are some great resources from devs and engineers who are very well versed in Web Vitals (and performance in general).</p> <h3>1. Optimize images</h3> <p>Google engineer Addy Osmani recently did <a href="https://vimeo.com/622853150">a great talk about image optimization</a> at Smashing Meets for Speed. A quick summary of his main tips:</p> <p><strong>For faster LCP...</strong></p> <ul> <li>Request key hero image early</li> <li>Use &lt;picture&gt;, srcset, and efficient modern image formats</li> <li>Use compression</li> <li>Lazy-load offscreen images</li> </ul> <p><strong>For lower CLS...</strong></p> <ul> <li>Set height and width dimensions</li> <li>Use CSS aspect-ratio or aspect-ratio boxes</li> </ul> <p><strong>For better FID...</strong></p> <ul> <li>Avoid images that cause network congestion with critical CSS and JS</li> </ul> <h3>2. Eliminate/reduce render-blocking resources</h3> <p>Blocking CSS and JavaScript are bottlenecks that hurt your LCP times. In <a href="https://sia.codes/posts/render-blocking-resources/">this post</a>, Google Dev Expert Sia Karamalegos goes deep on how to identify and eliminate render-blocking resources.&nbsp;</p> <h3><span style="color: #000000;">3. Take advantage of proven Web Vitals patterns</span></h3> <p>There are so many common page elements &ndash; such as carousels, banners, videos, and custom fonts &ndash; that can have a serious negative impact on your performance metrics. <a href="https://web.dev/patterns/web-vitals-patterns/">This is a handy collection of common UX patterns</a> &ndash; including code examples that you can use on your own pages &ndash; that have been optimized for Core Web Vitals.&nbsp;</p> <h2>How to use SpeedCurve to track performance for SEO</h2> <p>You can track Web Vitals in both Synthetic and RUM. Your Synthetic tests also include Lighthouse scores and audits for each test run.&nbsp;</p> <h3>1. Baseline your current performance</h3> <p>Before you do anything else, you need to understand how your pages perform relative to Google's thresholds. It's important to note that Google advises that you focus on RUM data at the 75th percentile. If you're using SpeedCurve RUM, that's what we show you by default in your Vitals dashboard.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/vitals-dashboard-1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>If you're not using RUM, then you can see your median Synthetic results for Largest Contentful Paint, Total Blocking Time, and Cumulative Layout Shift. (We can't show you First Input Delay, as that's an interaction metric that can only be gathered from real users.) While we plot these metrics against Google's recommended thresholds, take this with a grain of salt, as <a href="https://support.speedcurve.com/docs/synthetic-vs-lux-data">synthetic test results tend to be slower than RUM</a>. If you're only using synthetic testing, the more important thing to focus on is establishing a baseline for your pages.</p> <p><strong>MORE: <a href="https://www.youtube.com/watch?v=6dOBbvh4ZLA&amp;t=3s">Using the Vitals dashboard</a> [VIDEO]</strong></p> <h3>2. Create an SEO dashboard in your Favorites</h3> <p>You can create as many dashboards as you like in your Favorites. You can create a dashboard that focuses solely on search-related metrics, including separate charts for each of the Web Vitals and Lighthouse SEO scores. It can look as simple as this:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/seo-dashboard-1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Remember that your dashboards and charts don't have to be complex, because you can <a href="https://support.speedcurve.com/docs/filtering-favorites-dashboards">use the filters</a> at the top of the dashboard to refine your charts:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/seo-dashboard-2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><strong>MORE: <a href="https://www.youtube.com/watch?v=jcmLJ8jkL34">Tracking Web Vitals with SpeedCurve</a>&nbsp;[VIDEO]</strong></p> <h3>3. Set performance budgets and alerts</h3> <p><span style="font-size: 16px; font-weight: 400;">A performance budget is a numeric threshold that you apply to your metrics. You can then configure your monitoring tools to send you alerts &ndash; or even break the build, if you're testing in your staging environment &ndash; when your budgets are violated. You can learn much more about performance budgets <a href="https://support.speedcurve.com/docs/performance-budgets-101">here</a>, but for our purposes in this post, the important thing to understand is that p</span>erformance budgets are NOT the same as performance goals:</p> <ul> <li><strong>Your performance goals are aspirational.</strong> They answer the question: How fast do I want to be eventually?</li> <li><strong>Your performance budgets are practical.</strong> They answer the question: How can I keep my site from getting slower while I work toward my performance goals?</li> </ul> <p>A good practice is to look at your last 2-4 weeks of data for a given metric, identify the worst number, and then set your performance budget for that number. For example, looking at the last month of LCP data (captured using RUM, at the 75th percentile), we see that the worst number was 2.02 seconds. So a good performance budget for LCP would be 2.02 seconds.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/seo-dashboard-4.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>4. Find out exactly what to fix&nbsp;</h3> <p>If you have both RUM and synthetic data, it can be helpful to plot both in the same chart. That way, if you get an alert on one of your RUM metrics, you can <a href="https://support.speedcurve.com/docs/test-details">drill down into your synthetic test data</a>, which is where your Lighthouse scores and audits live, along with your waterfall charts and other diagnostic information. For example, by adding synthetic test data to the same chart we looked at above, we can see that there's a spike in the LCP number for synthetic alongside the high LCP number in RUM:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/430/seo-dashboard-5.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Clicking the 'View Test' link takes you to detailed test results, where you can:</p> <ul> <li><a href="https://www.speedcurve.com/blog/largest-contentful-paint-canary-beta/">See what your Largest Contentful Paint (LCP) element is</a> and when it's rendering</li> <li><a href="https://support.speedcurve.com/docs/diagnose-cumulative-layout-shift">Diagnose Cumulative Layout Shift (CLS) issues</a></li> <li><a href="https://support.speedcurve.com/docs/lighthouse">Review Lighthouse SEO audits</a> to get detailed recommendations about what to fix</li> </ul> <h3>5. Stay vigilant</h3> <p>Performance and SEO are always evolving. That means you need to stay up to date on which metrics to track and how those metrics are faring on your own pages. You should routinely audit your metrics and your performance budgets &ndash; ideally on a monthly basis.</p> <h2>How do you monitor performance and SEO?</h2> <p>If you have any insights, feedback, or questions, I'd love to hear it! Reply in the comments or send us a note at support@speedcurve.com.</p> Mon, 08 Nov 2021 00:00:00 +1300 New and improved Support Hub! https://www.speedcurve.com/blog/new-support-hub <p><a href="https://support.speedcurve.com/docs/welcome"><img class="blog-img" src="https://blog-img.speedcurve.com/img/428/support-hub-header.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>One of the things I love about SpeedCurve is our commitment to writing help documents that actually help. Every time we release a new feature, we make sure to give you an accompanying support doc &ndash; often written by the same team member who led the feature development. Luckily, we have great writers on our team, so our docs are exceptionally clear, concise, and easy to follow (if I do say so).&nbsp;</p> <p>We just celebrated our eighth birthday &ndash; hooray! Eight years of building new features means eight years worth of support docs. That's a lot of docs! Earlier this year, we realized that we had well over a hundred articles in our support centre. Inevitably, some duplication had crept in and some dead wood had accumulated. So we decided to give our docs a complete overhaul. That meant editing, organizing, purging &ndash; we gave them the full <a href="https://en.wikipedia.org/wiki/Marie_Kondo" target="_blank" rel="noopener">KonMari</a> treatment.</p> <p><strong>Our brand-new <a href="https://support.speedcurve.com/docs/welcome">Support Hub</a> is live!</strong>&nbsp;Here's a quick overview of what you can expect to find, including new goodies like our "Web Performance 101" guides, as well as recipes for completing common tasks and our improved and expanded API documentation.</p><p>(Aside: Throughout our docs &ndash; and our website &ndash; you may notice that we now refer to our real user monitoring service as SpeedCurve RUM (formerly known as LUX). Our RUM hasn't changed. We simply wanted to make our product naming more straightforward, especially for newcomers.)</p> <h2>Support docs</h2> <p>We worked hard to structure our <a href="https://support.speedcurve.com/docs/welcome">support docs</a> to make them easy to scan and quickly find what you need &ndash; from our step-by-step guides to getting started with <a href="https://support.speedcurve.com/docs/get-started-synthetic">Synthetic</a> and <a href="https://support.speedcurve.com/docs/get-started-real-user-monitoring">RUM</a> through to troubleshooting and FAQs.</p> <p><a href="https://support.speedcurve.com/docs/welcome"><img class="blog-img" src="https://blog-img.speedcurve.com/img/428/support-hub-1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>We've also made it easier for you to find contextual help. When you're logged in to your account, hover over 'Help' in the bottom-left corner of your navbar and you'll see recommended articles based on the dashboard you're on, as well as a shortcut to the Support Hub.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/428/support-help.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h2><span style="font-size: 35px; color: #000000;">Recipes</span></h2> <p>We're really excited about this section. <a href="https://support.speedcurve.com/recipes">Recipes</a> are detailed walkthroughs &ndash; including example scripting &ndash; of multi-step tasks such as:</p> <ul> <li>Simulate a user journey in your synthetic testing&nbsp;</li> <li>Simulate a SPA or AJAX navigation</li> <li>Submit a login form&nbsp;</li> <li>Simulate a checkout process</li> <li>Add a repeat view</li> <li>Track size for a single resource</li> </ul> <p><a href="https://support.speedcurve.com/recipes/simulate-a-checkout-process"><img class="blog-img" src="https://blog-img.speedcurve.com/img/428/support-hub-2.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>We'll be adding more recipes to this section. If you have any suggestions, please let us know!</p> <h2>API Reference</h2> <p>You can use the SpeedCurve API to do&nbsp;things like manage your synthetic test settings, retrieve performance budgets, trigger deploy tests, integrate with your continuous delivery process, configure RUM, and more. <a href="https://support.speedcurve.com/reference/getting-started">Here's how to get started.</a></p> <p><strong>As always, we welcome your feedback and suggestions.</strong> We see our support articles as living documents. If you can't find the help you need here, let us know at support@speedcurve.com. If we don't have a helpful article already on hand, we'll create it!</p> Wed, 06 Oct 2021 00:00:00 +1300 NEW: Exploring RUM sessions https://www.speedcurve.com/blog/real-user-monitoring-sessions-dashboard <p>If you want to understand how people actually experience your site, you need to monitor real users. The data we get from real user monitoring (RUM) is extremely useful when trying to get a grasp on performance. Not only does it serve as the source of truth for your most important budgets and KPIs, it help us understand that performance is a broad distribution that encompasses many different cohorts of users.</p> <p><strong>While real user monitoring gives us the opportunity for unparalleled insight into user experience, the biggest challenge with RUM data is that there's so much of it.</strong> Navigating through all this data has typically been done by peeling back one layer of information at a time, and it often proves difficult to identify the root cause when we see a change:</p> <p style="padding-left: 30px;"><em>"What happened here?"<br /></em><em>"Did the last release cause a drop in performance?"<br /></em><em>"How can I drill down from here to see what's going on?"<br /></em><em>"Is the issue confined to a specific region? Browser? Page?"</em></p> <p>Today we're excited to release a new capability &ndash; your RUM Sessions dashboard &ndash; which allows you to <strong>drill into a dataset and explore those sessions that occurred within a given span of time</strong>.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/117/session_dashboard.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="SpeedCurve Sessions dashboard" /></p><h2>Explore your data</h2> <p>Drill into any RUM data point from any chart in your dashboards to investigate RUM sessions. Whether you're looking into a spike, a baseline change, or a segment from a specific distribution you're interested in, clicking through to 'View Sessions' takes you to your new Sessions dashboard. (You can also navigate to the dashboard from the left-hand navbar.)</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/117/view-sessions.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Click on a data point in your chart to view those sessions" /></p> <p>&nbsp;</p> <p>When you arrive in the dashboard, you'll get a great breakdown of your sessions for that particular point in time. You bring along any of the context from your chart as well, including any filters that have been applied to that dataset. You'll instantly be able to understand the unique breakdown of user sessions across several dimensions, including geography, device, browser, page groups and more.&nbsp;</p> <p>Get a tour of the dashboards in this short video:&nbsp;</p> <div class="video"><iframe src="https://www.youtube.com/embed/YkMB8vMkHMU" width="560" height="315" frameborder="0" allowfullscreen=""></iframe> </div> <h2>Understand what changed?</h2> <p>Answering this question can be difficult and time consuming when you are dealing with a vast amount of RUM data. We make a point to highlight changes from the previous period. The change may be related to volume ("I'm seeing a lot more users from Ireland today" or "We are getting a lot more traffic to our landing pages") or it may be related to a metric ("LCP has really slowed down after this last release, and it looks to be driven by slower backend time"). Whatever the change may be, the comparison to the previous period can be found in several areas of the dashboard.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/117/metrics_change.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Table of metrics illustrating change from previous period" /></p> <h2>Investigate anomalies</h2> <p>Weird stuff happens. Whether you want to understand the long tail of performance or a specific pattern you're seeing in your data, it's useful to be able to quickly slice, dice, and compare.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/117/histogram_slider.gif" alt="Filtering a histogram" /></p> <p>&nbsp;</p> <p>In this video, we explore the mystery of what's behind a site's segment of fast bounces.&nbsp;</p> <div class="video"><iframe src="https://www.youtube.com/embed/F2yqvLWUfrQ" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></div> <h2>Questions?</h2> <p>Want to learn more about this feature? Do you have feedback on how we can make it even better? <a href="mailto:support@speedcurve.com" target="_blank" rel="noopener">Let us know!</a></p> Tue, 21 Sep 2021 00:00:00 +1200 UPDATE: Bookmark and compare synthetic tests https://www.speedcurve.com/blog/compare-web-performance <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/compare.gif" alt="" /></p> <p>One of the huge benefits of tracking web performance over time is the ability to <a href="https://support.speedcurve.com/docs/trend-metrics-compare-time-periods">see trends and compare metrics</a>. Last year we added new functionality that makes it easy for you to bookmark and compare different synthetic tests in your test history. <strong>We recently added some additional enhancements to make comparing tests even easier.</strong></p> <p>With the 'Compare' feature, you can generate side-by-side comparisons that let you not only spot regressions, but easily identify what caused them:</p> <ul> <li>Compare the same page at different points in time</li> <li>Compare two versions of the same page &ndash; for example, one with ads and one without</li> <li>Understand which metrics got better or worse</li> <li>Identify which common requests got bigger/smaller or slower/faster</li> <li>Spot any new or unique requests &ndash; such as JavaScript and images &ndash; and see their impact on performance</li> </ul> <p>Along the way, we've also made it much more intuitive for you to drill down into your detailed synthetic test results. Let's take a look...</p><h2>How to bookmark sites for comparison</h2> <p><em>(If you're more into watching than reading, scroll down to the bottom of this post to check out our short explainer video.)</em></p> <p>To get started, hover over data point in any time series chart and click. Within the popup, you can click "View Test" to see the full median test result for that test run. Or, if you already know that you want to bookmark that test for comparison, you can simply hit "Bookmark Test" within the popup.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/99/new-compare-screenshot.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>If you've drilled down into a Synthetic test result and confirmed that you want to bookmark it for comparison, all you need to do is click the "Add Bookmark" link in the top-left corner of the window.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Then you have the option of giving the bookmarked test a meaningful name and/or description.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-3.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>If you change your mind, just click "Remove Bookmark".</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-4.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Clicking on the bookmark icon in the top-right corner of the window shows you a list of all the tests you've bookmarked for comparison. Note that you can bookmark multiple tests, but you can only compare two at a time.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-5.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h2>NEW: Compare directly from your charts</h2> <p>If you just want to compare two tests and aren't interested in bookmarking them, just click on "Compare Test" within the popup. You'll then see a message instructing you to select another test for comparison.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/99/new-compare-2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>You can click on any synthetic test within the dashboard (or another dashboard with synthetic charts). Once you click on the second test, you'll be directed to the Compare dashboard.</p> <h2>Test case: CNN&nbsp;</h2> <p>Now let's walk through how to run a comparison and analysis using a real-world example from our "Top Sites" demo account. In this demo account, we track a number of leading retail, travel, and media sites. I've randomly selected CNN for the purpose of this post.</p> <p>Looking at the last three month's worth of Synthetic test data, we can see that the CNN home page has a Start Render time that's consistently above the 2-second threshold that we usually recommend &ndash; and that Start Render has sometimes hit almost 5 seconds.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-6.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Let's look at some of the peaks and valleys on their time series chart to see if we can spot the issues.&nbsp;To start, we'll quickly bookmark these two tests:</p> <ul> <li>Monday 11 May - Start Render 3s&nbsp;</li> <li>Saturday 24 May - Start Render 4s&nbsp;</li> </ul> <p>Now that we've selected these two tests, let's look at them side by side.</p> <p>Here you can see the visuals are stacked compactly so you can easily spot any differences. Hovering over any metric in the waterfall chart shows you the metric for both tests. It also shows you how the metrics align with the rendering filmstrips. For example, you can see that not much is happening in either filmstrip when Start Render fires:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-7.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>For this particular page, it looks like Largest Contentful Paint is a more meaningful metric, in terms of tracking when important content has rendered, so let's look at that. Things look a bit better in the May 11 test when Largest Contentful Paint fires at 4.95 seconds. In the May 24 test, LCP lags at almost 7 seconds.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-8.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The gaps get much broader when you look at Visually Complete and Fully Loaded (below). Delays in those metrics can be an indicator that, even though the page's visible content might have rendered, the page might be janky and unpleasant to interact with.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/Untitled-9.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Just below the waterfalls, the CPU timelines are really telling:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-10.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Ideally, you want to see a busy CPU at the start of the page render, but both tests show pockets of dead time early on. CPU utilization doesn't pick up till around 1.7 seconds for the May 11 test and 2.2 seconds for the May 24 test. This begins to explain the slow Start Render.&nbsp;</p> <p>The CPU timeline for the May 24 test also shows that the CPU is thrashing for the entire 80-second duration that the page is rendering.&nbsp;</p> <h2>Two questions for investigation</h2> <p>Based on the comparison so far, there are two questions for investigation:</p> <ol> <li><strong>What is causing the delays in Start Render and Largest Contentful Paint?</strong> High Start Render and LCP times can give users the feeling that the page is <em><strong>unresponsive</strong></em>.</li> <li><strong>What is causing the excessive CPU thrashing?</strong> This thrashing can give users the feeling that the page is <em><strong>janky</strong></em>.&nbsp;</li> </ol> <p>Time to dig deeper. To do that, we show you detailed metrics, along with a calculation of what got better or worse. For obvious reasons, the metrics that see the biggest changes are shown at the top of each list.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-11.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Looking at this list, it's pretty clear where some of the issues lie:</p> <ul> <li>Video size has jumped from 32KB to more than 4MB. This would help explain the extremely delayed Visually Complete and Fully Loaded times.</li> <li>The number of JavaScript Long Tasks has leapt from 1 to 51 &ndash; and 32 of these are third parties. The longest Long Task is 722ms.</li> <li>On the slower page, third-party JavaScript CPU time is more than 7 seconds &ndash; 3 of which are blocking the CPU.</li> </ul> <p>Now that we know that the number and complexity of JS requests is a major issue, we can find out exactly which scripts appear to be the culprits. This is a list of all the common requests that are shared across both pages, along with a calculation of how much performance degradation each request experienced:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-12.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Now let's take a closer look at one of those scripts:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-13.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>I'm not familiar with Exelator, so I had to look it up to identify it as a data collection tracker that is <a href="https://better.fyi/trackers/exelator.com/">reportedly</a> owned by Nielsen. Whatever it is, its duration has increased by 1727% &ndash; from 59ms to 1078ms. Clicking through to the full test result page for May 24 and searching for Exelator yielded four separate requests, with a total duration of more than 1600ms. Here's one of those requests:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/screenshot-14.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Something that's important to note here is that three out of four of those requests had a size of 0 bytes, and the fourth was only 43 bytes. Keep this in mind next time you ponder adding an allegedly small third-party request to your pages.</p> <p>That was just one request issue among the many listed above. To drill down further, next steps could include looking at the detailed waterfall charts for each test run &ndash; May 11 and May 24 &ndash; to see what else is happening before Largest Contentful Paint and Start Render to delay those metrics.&nbsp;</p> <p>A quick glance at the waterfalls for both tests reveals:</p> <ul> <li><strong>40 requests before Start Render </strong>fires on the May 11 test</li> <li><strong>64 requests before Start Render</strong> fires on the May 24 test</li> <li><strong>105 requests before First Contentful Paint</strong> fires on the May 11 test</li> <li><strong>144 requests before First Contentful Paint</strong> fires on the May 24 test</li> </ul> <p>I hope I don't have to tell you that those are a LOT of requests. The volume alone is enough to create performance issues. Add to that any episodic issues with serving those requests, and you can see how easily performance can degrade.</p> <h2>We'd love your feedback!</h2> <p>I adore this feature. We've been talking about building this for quite a while &ndash; not least because it's been requested by a number of our customers. Take it for a spin and let us know what you think!</p> <p>Here's Cliff's tutorial, for all you video lovers out there.</p> <div class="video"><iframe src="https://www.youtube.com/embed/SckTlcICY84" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></div> <h3>Related reading</h3> <ul> <li><a href="https://support.speedcurve.com/docs/competitive-benchmarking">Benchmark yourself against your competitors</a></li> <li><a href="https://support.speedcurve.com/docs/comparison-videos">Generate comparison videos</a></li> <li><a href="https://support.speedcurve.com/docs/trend-metrics-compare-time-periods">Trend metrics and compare time periods</a></li> <li><a href="https://support.speedcurve.com/docs/synthetic-page-labels#compare-your-synthetic-and-real-user-data">Compare your Synthetic and RUM data</a></li> <li><a href="https://support.speedcurve.com/recipes/add-a-repeat-view-for-a-synthetic-test">Compare first and repeat views in Synthetic</a></li> <li>A/B testing in <a href="https://support.speedcurve.com/docs/ab-testing-synthetic">Synthetic</a> and <a href="https://support.speedcurve.com/docs/ab-testing-rum">LUX</a></li> </ul> Mon, 13 Sep 2021 00:00:00 +1200 NEW: Lighthouse v8 support! https://www.speedcurve.com/blog/new-lighthouse-v8 <p><img class="blog-img-sm" src="https://blog-img.speedcurve.com/img/lighthouse-1024x1024.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Google Lighthouse logo" /></p> <p>After Google's&nbsp;<a style="background-color: #f5f5f5;" href="https://github.com/GoogleChrome/lighthouse/blob/master/changelog.md">announcement</a>&nbsp;about Lighthouse 8 this past month, we have updated our test agents. We've gotten a lot of questions about what has changed and the impact on your performance metrics, so here's a summary.</p><h2>What is Lighthouse?</h2> <p>In case you missed it, Lighthouse is a speed tool created by the Chrome Developer team at Google. Lighthouse is a score based system that evaluates lab data (synthetic) through a series of audits in order to identify how your application will perform in the wild.</p> <p>There are five categories evaluated:&nbsp;<strong>Performance, Accessibility, Best Practices, SEO, and Progressive Web App (PWA).</strong> As part our synthetic testing, we run a separate Lighthouse test that produces a full audit and allows you to track these scores over time, alongside your other favorite performance metrics.&nbsp;</p> <h2>What has changed?</h2> <p>No metrics were added or removed from the Lighthouse scoring in version 8. The biggest changes are:</p> <ul> <li>the weighting of metrics used for the performance score, and</li> <li>the adoption of the recently updated&nbsp;<a href="/blog/The%20CLS metric has evolved a lot in the short time that it's been around." target="_blank" rel="noopener">Cumulative Layout Shift (CLS) calculation</a>.</li> </ul> <h3>Weighting adjustments</h3> <ul> <li>First Contentful Paint (FCP): 15 -&gt; <strong style="color: red;">10</strong></li> <li>Speed Index: 15 -&gt; <strong style="color: red;">10</strong></li> <li>Largest Contentful Paint (LCP): 25 -&gt; <strong>25</strong></li> <li>Time To Interactive (TTI): 15 -&gt; <strong style="color: red;">10</strong></li> <li>Total Blocking Time (TBT): 25 -&gt; <strong style="color: green;">30</strong></li> <li>Cumulative Layout Shift (CLS): 5 -&gt; <strong style="color: green;">15</strong></li> </ul> <p>Not surprisingly, we see a shift in importance for metrics related to Core Web Vitals. Largest Contentful Paint (LCP) remains the heaviest weighted, while Cumulative Layout Shift (CLS) shows the biggest increase.</p> <p>We were happy to see the weighting change for Total Blocking Time (TBT), which &ndash; while technically not a Web Vital &ndash; shines the biggest light on the importance of optimizing first and third party JavaScript.</p> <h3>Updated Cumulative Layout Shift (CLS) calculation</h3> <p>CLS now uses session windowing to more accurately measure layout shifts for longer-lived sites, including single page applications. While we don't anticipate a major change for CLS scores measured in a lab environment such as Lighthouse, field data (aka real user monitoring) should generally see improvement for those types of sites as it is adopted more broadly.</p> <h2>How will these changes affect your metrics?</h2> <p>Google anticipates <strong>the majority of sites could see improvements to their scores</strong>, based on their analysis the HTTP Archive.</p> <p>Our own research here at SpeedCurve suggests that there will be a <strong>moderate increase of the performance score (1-5 points) for most sites</strong>. Sites that had a high CLS score and/or TBT were penalized more heavily due to the weighting changes and saw a decrease in the score which was sometimes significant (5-10 points).</p> <h2><span style="font-size: 35px;">What else is new?</span></h2> <p>In addition to the performance weighting changes, Lighthouse has added a few pretty cool features to the report:</p> <h3>Treemaps</h3> <p>Identify opportunities to examine JavaScript size and coverage so you can optimize accordingly.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/116/treemap.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Google Lighthouse Treemap visualization" /></p> <h3>Sort Lighthouse audits by metric</h3> <p>It can be a bit overwhelming to look through the list of audits in your report. Filtering by the metric you're interested in can help slim down your performance to-do list.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/116/filter.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Google Lighthouse filtering by metric" /></p> <h2>Learn more</h2> <p>If you are looking for more details around Lighthouse, or specifics around version 8, here are some good resources:</p> <ul> <li><a style="background-color: #f5f5f5;" href="https://github.com/GoogleChrome/lighthouse/blob/master/docs/v8-perf-faq.md" target="_blank" rel="noopener">Lighthouse v8 Performance FAQ</a></li> <li><a style="background-color: #f5f5f5;" href="https://support.speedcurve.com/en/articles/2569490-lighthouse-scores-and-audits" target="_blank" rel="noopener">Lighthouse Scores and Audits</a>&nbsp;in SpeedCurve</li> <li><a href="https://web.dev/performance-scoring/" target="_blank" rel="noopener">Understanding how Performance scoring works in Lighthouse</a> (Google Webdev)</li> <li><a style="background-color: #f5f5f5;" href="https://youtu.be/_G3X_IsozKk">State of Speed Tooling</a>&nbsp;(video from the 2020 Chrome Developer Summit)</li> </ul> Wed, 07 Jul 2021 00:00:00 +1200 Hello from Europe! https://www.speedcurve.com/blog/hello-from-europe <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/115/andy.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Andy Davies" /></p> <p>I&rsquo;m delighted to be joining some of my favourite web performance people at SpeedCurve!</p> <h2 dir="ltr">Who am I?</h2> <p>I&rsquo;ve been a full-time web performance consultant for around nine years. For about half that time I worked freelance, and the other half for Site Confidence / NCC Group in the UK.</p> <p>My journey into performance started in the late 1990s, while I was working for an elearning provider and discovering the challenges of delivering rich content over the internet. To overcome some of these challenges, we built our own Java-based player, complete with caching, content compression, and even bandwidth detection so it could switch between video, audio, and text versions of a course depending on network speed.</p> <p>Ultimately the business didn&rsquo;t survive the dotcom bust, but it lit a spark...</p><p dir="ltr">Then in 2008, while I was helping an educational publisher launch their elearning platform (and running into the familiar challenges of how do you build and deliver rich content over the internet) I came across Steve Souders&rsquo;s first book, <a href="https://www.oreilly.com/library/view/high-performance-web/9780596529307/">High Performance Web Sites</a>.</p> <p dir="ltr">We were already using both synthetic and network-based real user monitoring (RUM) tools to measure how fast our site was, so we knew we had room to improve. Steve&rsquo;s book gave us some recipes to make those improvements.</p> <p dir="ltr">Within a few releases, we went from customers calling our support team to complain about how slow the platform was to customers calling to say how much faster it was.</p> <p dir="ltr">I think that was the point I became hooked!</p> <p dir="ltr"><img class="blog-img-md" src="https://blog-img.speedcurve.com/img/115/andy-book-2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p dir="ltr">Since then I&rsquo;ve worked with organisations large and small &ndash; across sectors such as retailing, publishing, and marketing &ndash; to help them deliver faster experiences for their customers. I&rsquo;ve written <a href="https://andydavies.me/books/">a couple of books</a>, <a href="https://andydavies.me/talks/">spoken at conferences</a>, and become an organiser of <a href="https://ldnwebperf.org/">London&rsquo;s Web Performance Meetup</a>.</p> <p dir="ltr">As much as I enjoy freelance consulting, I&rsquo;ve always felt there aren&rsquo;t enough consultants. To help more sites, we&rsquo;ve got to take the knowledge that consultants have and build it into tools and products.</p> <h2 dir="ltr">Why SpeedCurve?</h2> <p dir="ltr">I&rsquo;ve known some of the SpeedCurve team for quite a while. I met <a href="https://twitter.com/Souders">Steve</a> at the first O'Reilly Velocity Conference in the EU in 2011, <a href="https://twitter.com/cliffcrocker">Cliff</a> gave the first tutorial at my first Velocity in the US, and I was fascinated by <a href="https://twitter.com/tameverts">Tammy</a>&rsquo;s <a href="https://www.oreilly.com/pub/e/3149">neuroscience-based talk</a> in 2014. (After all, performance is about people.)</p> <p dir="ltr">Velocity 2014 was also when I met <a href="https://twitter.com/MarkZeman">Mark</a>, right at the time that he&rsquo;d built SpeedCurve alongside his day job, launched it in New Zealand, and won a prize to launch it in the US. I think this was the first time I&rsquo;d seen someone bring strong visual design to a web performance product, and it was lovely.</p> <p dir="ltr">The performance company I worked for had a similar product, but it had never gotten much traction, so it was both fascinating (and frustrating) to watch a small bootstrapped business innovate and execute faster than we could, and to grow in space we&rsquo;d been unable to.</p> <p dir="ltr">While I worked for a competitor, my exposure to SpeedCurve was limited. It wasn&rsquo;t until I started freelancing again &ndash; and working with clients who used SpeedCurve &ndash; that I really came to appreciate its capabilities. (SpeedCurve's <a href="https://support.speedcurve.com/docs/custom-metrics">support for User Timing</a> was the &lsquo;cherry on top&rsquo; for me.)</p> <p dir="ltr">Unshackled from competitive pressures &ndash; and with clients in common &ndash; we talked more. I worked on a couple of projects for SpeedCurve, too.&nbsp;One of those projects was a competitive analysis of synthetic and real user monitoring (RUM) products. That analysis reinforced to me how strong SpeedCurve was compared to many other vendors in this space.</p> <p dir="ltr">If the way to help more sites get faster is to combine what I learned as a consultant into products, then one of the strongest web performance vendors seems an excellent place to do that.</p> <h2 dir="ltr">What I&rsquo;m going to be doing</h2> <p dir="ltr">I&rsquo;m going to be working alongside Tammy and Cliff, supporting our customers, helping them to get the most out of our products, and providing advice about how to improve the speed of their sites.</p> <p dir="ltr">We&rsquo;re also going to be exploring what our consulting offering could look like and what services we should provide to complement our products.</p> <p dir="ltr">As an industry, we&rsquo;ve gotten really good at measuring how fast (or slow) a site is, but we&rsquo;re not so good at helping answer the &lsquo;so what&rsquo; type of questions. And these &lsquo;so what&rsquo; type of questions are the questions that intrigue me. Such as...</p> <ul> <li dir="ltr">How can we help customers understand whether their site is fast enough, or what&rsquo;s the benefit of being faster?</li> <li dir="ltr">If they need to be faster, where should they focus their optimisation efforts?</li> <li dir="ltr">And, of course, what can actually be done to make a site faster?</li> </ul> <p dir="ltr">We collect a treasure trove of data about the performance of our customers&rsquo; sites. I&rsquo;m going to be researching how we can use our data to help answer those types of questions.</p> <p dir="ltr"><strong>If you&rsquo;d like to talk about what you&rsquo;d be looking for from our consulting offering, I&rsquo;d love to hear from you.</strong></p> <p dir="ltr">It&rsquo;s been a real pleasure to watch SpeedCurve grow over the past seven years. I&rsquo;m thrilled to have joined the team!</p> Tue, 15 Jun 2021 00:00:00 +1200 NEW! Chrome Beta and Canary support & LCP element highlighting https://www.speedcurve.com/blog/largest-contentful-paint-canary-beta <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/114/rendering-times.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Phew! Between the fast-paced release cycle for Chrome and the rapid evolution of Core Web Vitals, the month of May has been a busy one here at SpeedCurve. With that, we are excited to bring you some new features and enhancements to help you stay focused and ahead of the game as we move into summer.</p> <p>Read on to learn more about:</p> <ul> <li>Chrome Beta and Canary support</li> <li>Largest Contentful Paint (LCP) element highlighting</li> <li>Key rendering times</li> </ul><h2>Introducing Chrome Beta and Canary support</h2> <p>Keeping pace with Chrome release cycles is challenging. On one hand, we like to keep <a href="https://support.speedcurve.com/docs/browsers-and-devices">our synthetic monitoring agents</a> as stable as possible, while on the other we know how important it is to get in front of changes in order to keep your app running smoothly. We're excited to announce custom browser support for Chrome Beta and Canary, in addition to our stable version.</p> <h3>Understanding Chrome releases</h3> <p>The Chromium team provides the community with early&nbsp;<a href="https://www.chromium.org/getting-involved/dev-channel" target="_blank" rel="noopener">access to all releases.</a>&nbsp;For our purposes, we provide three versions for synthetic testing:</p> <ul> <li><strong>Stable</strong>&nbsp;&ndash; This is the latest supported version of Chrome that has been tested for stability on our platform. We update our stable release about once a quarter, so it's quite possible we will be a version or two behind the current stable Chromium build.</li> <li><strong>Beta</strong>&nbsp;&ndash; Think of this as 'What's next'. It's typically very consistent, with builds rolled out about once a week.</li> <li><strong>Canary</strong>&nbsp;&ndash; This is the very latest and greatest. This is expected to be under heavy development, with new builds rolling out daily.</li> </ul> <h3>Getting started</h3> <p>Adding Beta and/or Canary to the list of available browsers in your synthetic test settings is quite simple. <a href="https://support.speedcurve.com/docs/chrome-canary">Check out our guide for a quick walkthrough</a>.</p> <p><a href="https://support.speedcurve.com/docs/chrome-canary" target="_blank" rel="noopener"><img class="blog-img" src="https://blog-img.speedcurve.com/img/114/canary-how-to.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Pro tip: If you want to compare across all three versions, set up a custom stable version as well.</strong> While the default desktop version of Chrome is already available, you can ensure that all other settings you select for the profile are the same.</p> <p>Once created, you can easily add the new profiles to your existing or future site configuration.&nbsp;</p> <h3>Common use cases</h3> <h4>Validate changes seen in RUM</h4> <p>Changes to your real user monitoring (RUM) metrics can happen at any time, for any number of reasons. Our stable agents are only updated after extensive testing and can be out of step with the latest Chrome release. Having early access to beta helps you spot browser-related issues before your users do.</p> <h4>Get ahead of key metric changes</h4> <p>Whether its <a href="https://www.speedcurve.com/blog/new-vitals-dashboard/">Core Web Vitals</a>, <a href="https://support.speedcurve.com/docs/lighthouse">Lighthouse</a>, or your own <a href="https://support.speedcurve.com/docs/custom-metrics">custom metrics</a>, having early access to Chrome builds can help you manage any surprises coming your way and keep you moving in the right direction.</p> <h4>Future-proof your application</h4> <p>While we've historically seen browsers getting faster, that doesn't mean your application will always follow suit. Understanding the behavior of modern-day applications on a rapidly changing platform like Chrome can bring you peace of mind. Your future self will thank you.</p> <h3 style="font-family: Gotham, sans-serif;">What if things look strange?</h3> <p>Don't panic. The Beta and Canary releases are under active development and it's expected that you'll see some instability. If you see an unexpected change related to your metrics or Lighthouse behavior,&nbsp;<a href="mailto:support@speedcurve.com">we'd love to hear about it.</a>&nbsp;Otherwise, cross-check with&nbsp;<a href="https://www.chromestatus.com/features/schedule" target="_blank" rel="noopener">Chrome Platform Status</a>&nbsp;and the&nbsp;<a href="https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/speed/metrics_changelog/README.md">Web Vitals Changelogs</a>.</p> <h2>LCP highlights and key rendering</h2> <p>Chrome recently did everyone a solid by giving us more context for Largest Contentful Paint. As of Chrome 90, the bounding rectangle of the element classified with LCP has been exposed. (Thanks, <a href="https://twitter.com/yoavweiss">Yoav</a>!) This allows us to highlight the element within the frame, removing any doubt of what Chrome identified when reporting LCP.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/114/lcp_netflix.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Image of Netflix website with highlighted LCP" width="351" height="241" /></p> <p>Pairing this with our own Last Painted Hero metric gives you a great way to determine meaningful rendering moments within the page:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/114/renderingmoments.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Image of SpeedCurve rendering moments for Netflix" /></p> <h3>Where can I find these visualizations?</h3> <p>The LCP highlights can be seen in your <a href="https://www.speedcurve.com/blog/new-vitals-dashboard/">Vitals dashboard</a>, your <a href="https://support.speedcurve.com/docs/test-details">test details</a>, and your Sites dashboard, where you'll also see how the metrics are trending over time, like this:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/114/sites-dashboard.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Image of summary rendering times in SpeedCurve Site dashboard." /></p> <p>Things are moving pretty fast in the world of performance these days, but we hope this gives you the head start you need to stay out in front. We think these new capabilities are pretty cool and hope you do as well. As always, if you have any questions or feedback, please shout out in the comments or via email at support@speedcurve.com.</p> Thu, 03 Jun 2021 00:00:00 +1200 Web Performance for Product Managers https://www.speedcurve.com/blog/web-performance-product-managers <p>I love conversations about performance, and I'm fortunate enough to have them <strong>a lot</strong>. The audience varies. A lot of the time it&rsquo;s a front-end developer or head of engineering, but more and more I&rsquo;m finding myself in great conversations with product leaders. As great as these discussions can be, I often walk away feeling like there was a better way to streamline the conversation while still conveying my passion for bringing fellow PMs into the world of webperf. I hope this post can serve that purpose and cover a few of the fundamental areas of web performance that I&rsquo;ve found to be most useful while honing the craft of product management.</p> <p>So, whether you are a PM or not, if you're new to performance I've put together a few concepts and guidelines you can refer to in order to ramp up quickly. This post covers:</p> <ul> <li>What makes a page slow?</li> <li>How is performance measured?</li> <li>What do the different metrics mean?</li> <li>Understanding percentiles and how to use them</li> <li>How to communicate performance to different stakeholders</li> </ul> <p>Let's get started...</p><h2>What makes a page slow?</h2> <p>Short answer: Lotsa stuff. Here are some of the bigger contributors you should know about, but be aware of others as performance is a multi-headed beast.</p> <h3>Requests</h3> <p>Your page is made up of a lot of individual assets. Images, fonts, JavaScript, CSS, tracking pixels... these all play their part in delivering a rich experience. But collectively, these can add up to a "death by a thousand cuts" scenario.</p> <p><a href="https://www.stevesouders.com/blog/2012/02/10/the-performance-golden-rule/">Steve's golden rule</a>&nbsp;remains true today: 80-90% of rendering time is spend in the front end, and the majority of that is requests sent across the wire. If you want to optimize your site, start by making as few requests as possible.</p> <h3>Code</h3> <p>There are a ton of best practices for front-end developers to follow. This is typically the work you'd throw into an optimization sprint (or twenty). Recommendations can come out of audits from consultants or from automated tools like Lighthouse (or SpeedCurve, of course). I like to use&nbsp;<a href="https://developers.google.com/speed/pagespeed/insights/">PageSpeed Insights</a>&nbsp;when checking out a URL for a customer to get some high-level suggestions. We include Lighthouse scores and audits in our product for a good starting point.</p> <p>Problem areas may include (but certainly aren't limited to):</p> <ul> <li>JavaScript,</li> <li>improving the 'critical path' or render blocking, and</li> <li>using directives to preload assets or load scripts asynchronously.</li> </ul> <p>While the focus in most cases tends to be directed toward front-end developers, it's important to remember the back-end as well if you see higher than normal start render times or increases in more basic metrics like time to first byte.</p> <h3 style="font-family: Gotham, sans-serif;">Images</h3> <p>Image optimization continues to be one of the areas where huge performance gains can be made, often with little effort. Image compression has continued to evolve. New formats have been introduced that provide a rich feature set while minimizing bandwidth. In some cases these formats are specific to the browser, which can add some complexity to your workflow.</p> <p>Regardless of whether or not you have the opportunity to make an impact in this area, understanding your image pipeline &ndash; whether it's in house or managed as a service &ndash; is a plus. This is especially true of sites that maintain a large product catalog or include a fair amount of user-generated content.</p> <p>It's also important to note that, while not all performance gains will show up in your metrics, users with poor bandwidth or restrictive data plans will thank you. Consider setting your <a href="https://speedcurve.com/blog/performance-budgets-guide/">performance budgets</a> related to images on size and number of requests as opposed to duration.</p> <h3>Networks</h3> <p>Yeah. The internet. It's consistently inconsistent. How things get from point A to point B still amazes me when you think about the complexity involved in sending bits over the wire.</p> <p>For your purposes, you might be interested in how your technology partners (which you pay good money for) impact your performance. Content Delivery Networks (CDN) like Akamai, Fastly, Cloudflare, Cloudfront can sometimes have a big impact on performance. This traditionally manifests more in back-end time, but can have a huge impact on front-end as well when you factor in asset delivery (images, static content) as well as some advanced optimizations available at the edge. These platforms also give you the power to make things worse, not better, if you aren't careful.</p> <h3>Third parties</h3> <p>[Long audible moan] We love to hate them. However, we also love to use them. Everywhere.</p> <p>Third parties, for our purposes, focus on contributors outside of your domain that enrich your content or deliver a service. The frustration with third parties is that they are often perceived to be outside of your control. Yes, it's true that when they impact your performance, there is little you can do to make them faster, short of removing the tag or throwing the kill switch.</p> <p>That withstanding, you are a product manager. You are a master of influencing that which is outside the scope of your control. You can hold them accountable and maintain a strategy for keeping them in line. For example:</p> <ul> <li>Work with your vendor manager if you have one, or directly with the stakeholders responsible, to set and enforce <a href="https://speedcurve.com/blog/performance-budgets-guide/">performance budgets</a> on your third parties. Maybe you create a tag budget that you can enforce with the responsible party. Maybe the budget relates to size.</li> <li>If your marketing department needs to add a new pixel, force one out in its place.</li> <li>Audit your third parties and prune out any ghost scripts.</li> <li>Before allowing a new third party, implement a vetting process to make sure it passes some basic guidelines around performance. My favorite tool for this is&nbsp;<a style="background-color: #f5f5f5;" href="https://3rdparty.io/">3rdParty.io</a>, contributed by Nic Jansma.</li> </ul> <p>Whatever the cause for performance issues may be, it's important to maintain a team approach when tackling the issue. Rarely is it one person's fault that performance is where it is. It's also rare that a single person or group has ownership of that area and the ability to fix it independently of others.<strong>&nbsp;Performance is a team sport.</strong></p> <h2>How is web performance measured?</h2> <p>There are two primary methods, both of which center around measuring how the browser responds when a user visits your site.</p> <h3>Synthetic monitoring</h3> <p>As in, not real. Synthetic monitoring is essentially a bot that does what you tell it to do ("go visit my home page from X location on X browser") and actively collects performance data.</p> <p>Synthetic is great and has a ton of useful things to offer, as we can get an immense amount of detail around what happened when that action was performed. This includes:</p> <ul> <li>waterfall charts with details about every request,</li> <li>filmstrips and videos that help you visualize the rendering experience, and</li> <li>a reasonably consistent baseline when looking at the makeup of your application.</li> </ul> <p>Synthetic is great for trending over time, especially when looking at the number and size of requests (images, JavaScript, CSS), which collectively have a big impact on speed.</p> <p>But for all the goodness of synthetic monitoring, it's missing a critical component: end users.</p> <h3>Real user monitoring (RUM)</h3> <p>You guessed it: measuring real users. Think of RUM as performance-based analytics measured from the end user's actual browser.</p> <p>As a great product manager, you&rsquo;re already focused on building your product <strong>outside in</strong>. You talk to a gazillion customers, get their feedback, and turn that into requirements for your next product. This gives you&nbsp;the power of empathy that can be shared far and wide across your organization when building an exciting roadmap and creating the vision for your product or product line.</p> <p>This is why you need RUM. Real users. Real experiences. RUM is the basis for understanding web performance and it's become the go-to source of truth when communicating performance to your stakeholders. How can you effectively include performance as a requirement without it? Hard sell here. I know. However, in this day and age, not bringing RUM data into the equation is performance malpractice.</p> <h2>What do the different metrics mean?</h2> <p>Whether you use synthetic or RUM, each tool captures dozens and dozens of performance metrics. Understanding which performance metrics you should care about has been a perilous journey over the years. The pendulum has swung from 'measure all the things' to 'here is my unicorn metric'. Today we're somewhere in between. The frustrating answer to the question "Which metric(s) should I care about?" remains the same:</p> <p>"It depends."&nbsp;</p> <p>Don&rsquo;t get bogged down in the details. There's a plethora of metrics and you don&rsquo;t need to understand all of them.&nbsp;For most of you, especially if you are just getting started with performance, focus on the metrics most closely tied to your user's experience. Here is a&nbsp;<a style="background-color: #f5f5f5;" href="https://speedcurve.com/blog/performance-budgets-guide/" target="_blank" rel="noopener">great guide from Tammy</a>&nbsp;that tackles this head on.</p> <p>In recent months, my conversations with PMs have been heavily centered around Core Web Vitals. If you are in this camp and getting pressure around improving SEO or responding to inbound questions regarding numbers seen in Google Console, you'll want to familiarize yourself with these metrics. Fortunately, there is a lot of good material for you to review on this topic. Start with these resources:</p> <ul> <li><a href="https://www.speedcurve.com/blog/web-vitals-user-experience/">Tracking Core Web Vitals</a></li> <li><a href="https://www.speedcurve.com/blog/google-cumulative-layout-shift/">Understanding Cumulative Layout Shift</a></li> <li><a href="https://www.speedcurve.com/blog/first-input-delay-google-core-web-vitals/">First Input Delay, How vital is it?</a></li> <li><a href="https://simonhearne.com/2021/core-web-vitals-seo/">Everything we know about Core Web Vitals</a>&nbsp;by Simon Hearne</li> </ul> <h2>How to use percentiles</h2> <p>Now that you understand the different metrics, it's important to know how to apply percentiles to each one so that you can understand how different cohorts of real users are experiencing your site.</p> <p>This is a histogram:<br /><img class="blog-img" style="font-size: 15px;" src="https://blog-img.speedcurve.com/img/113/histogram_1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>A histogram represents the distribution of your users who had a range of experiences when visiting your site. Remember that.</p> <p><strong>Performance is a distribution</strong>, not a single number. It's not measured once. A histogram represents a continuum of experiences, which allows you to think of the shape of performance and how you want to influence it. Faster shifts left, slower shifts right.</p> <h3>I still need to communicate a number. What do I do?</h3> <p>No worries, you'll still need to talk in numbers. Percentiles represent segments of your population from 0-100. You don&rsquo;t need to be a statistician to do this. Just think in terms like this:</p> <p><strong>50th percentile (median):&nbsp;</strong>I find using the 50th percentile, aka the median, easier to understand and communicate. You can even refer to it as an average if you want.&nbsp;</p> <p><strong><img class="blog-img" src="https://blog-img.speedcurve.com/img/113/histogram_p50.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram showing users in green up to the median or 50th percentile." /></strong><strong>75th percentile: </strong>For some popular metrics, such as&nbsp;<a style="background-color: #f5f5f5;" href="https://speedcurve.com/blog/web-vitals-user-experience/">Core Web Vitals</a>, the 75th percentile is being used for reporting.&nbsp;</p> <p><strong><img class="blog-img" src="https://blog-img.speedcurve.com/img/113/histogram_p75.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram showing the fastest 75% of users in green and slowest 25% of users in red." /></strong><strong>95th percentile: </strong>If your site is already pretty fast for most users, you can focus on making it fast for your longtail. Five percent of your users may not sound like much, but if you site gets 10M visitors a month, that means 500,000 of those people are having a really poor experience.</p> <p><strong><img class="blog-img" src="https://blog-img.speedcurve.com/img/113/histogram_p95.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram showing the slowest 5% of users in red." /></strong></p> <p>There isn&rsquo;t a wrong answer when it comes to which percentile to focus on, as each has merit, unless you are using an arithmetic mean (AKA traditional average) to describe your population. That doesn't work so well for this type of distribution.</p> <h2>How should I communicate all of this?</h2> <p>I continue to find this to be one of the biggest challenges product managers face when it comes to performance. We've been working on this challenge for years and still haven't nailed it. Here are some thoughts on communication that you may want to keep in mind.</p> <h3>Know your audience</h3> <p>This isn't a new concept. You wear many hats and speak many languages when it comes to working cross-functionally. Think about that before you rolling out new terminology, concepts, or going into the weeds with your CEO.</p> <h3 style="font-family: Gotham, sans-serif;">Keep it simple</h3> <p>Don't over-communicate or confuse folks. If you are centered on a few performance KPIs for your reporting, great. If you manage to get aligned around that unicorn metric, fantastic. Just don't dress it up too much. Leave out terms like percentile and avoid presenting two sets of numbers. This is often a mistake I see PMs making when trying to communicate their RUM metric as well as their synthetic metric. Just don't do it. Again, use RUM whenever humanly possible. You can use synthetic to highlight areas such as page weight or element count or to illustrate the number of third parties on your site. This is where synthetic compliments your RUM data very nicely.</p> <h3>Paint a picture of performance</h3> <p>This is where synthetic monitoring tools steal the show. Using filmstrips or videos to illustrate a point goes a really long way when speaking to stakeholders that are out of the loop on performance. There is nothing better than showing a before-and-after video when promoting the great work of your team.&nbsp;</p> <h3>Benchmark yourself</h3> <p>Another great tool to have in your bag is benchmarking. Teams love to win and hate to lose. Using benchmarking as a way to compare yourselves to your competition is extremely effective. This is especially true when it comes to managing Core Web Vitals. If half of your competitors have a faster LCP time than you, what impact will that have on your search results?</p> <p>As hard as it may be, avoid shaming. Whether you or your competition are at the bottom, that can change at anytime. Use benchmarking to make yourself better or to understand and learn from others. Check out our <a href="https://speedcurve.com/benchmarks/">Industry Page Speed Benchmarks</a> for an idea of how you can use benchmarking part of your toolkit.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/113/benchmarks.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Filmstrip comparison for Industry Benchmarks" /></p> <h2>Summary</h2> <p>These are the fundamentals, and I hope you've found the time reading them to be well-spent. Like any topic you get exposed to as a product manager, you can always go deeper.</p> <p>Still have questions or thoughts? I'm sure others would love to hear them as well, so feel free to comment below.</p> <p>&nbsp;</p> Fri, 26 Feb 2021 00:00:00 +1300 Joining the SpeedCurve team https://www.speedcurve.com/blog/joining-speedcurve-team <p>After all the twists and turns of 2020, the unprecedented year ended up with the pleasure of joining the SpeedCurve team and helping to build the tool trusted by so many brands around the world that are striving to improve their customer experience.</p> <p>As a developer I've always been fascinated by the web and how it enriches people's lives, and now I am jumping into the very essence of it &ndash; how it renders, performs and behaves! Thanks to SpeedCurve for this opportunity, I am so excited to work along with the veterans of the web performance industry (and just plain talented people), as well as to be closer to the performance community.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/elena-bio.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p><h2>My background</h2> <p>I started coding web pages in about 2005 and began my web development career in Moscow, Russia, joining a biotech startup. Ever since, I've enjoyed being part of small to medium teams and participating in building web applications from inception to implementation, with an eye for detail and keeping UX in mind every time I build a new feature.</p> <p>Automating routine tasks and improving user experience are the favourite parts of my job as a software developer. I spent the last few years working at the social network Neighbourly, helping to bring local communities together by building new UIs and automating things under the hood while the project experienced its highest growth. Most recently, I helped develop several applications and startups in the digital healthcare industry.</p> <h2>My mission</h2> <p>As a developer coming from a wider and more generic web development background, I am eager to make the SpeedCurve experience even more smooth, user friendly, and accessible for developers like myself. Extended APIs, developer tools, and CI/CD integration are the things on my list that I am most excited about!</p> <p>As a keen member of the local IT community, I am also interested in expanding performance culture and awareness to the New Zealand tech community.</p> <h2>My other passions</h2> <p>Away from the keyboard, I spend my time exploring the great New Zealand outdoors, usually with a camera in hand. On the weekends, I can normally be found trail running and fastpacking &ndash; plus mountaineering in winter and enjoying water activities in summer.</p> <div> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/_mg_5453.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Surfers" /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/15513049997_25667d4342_o.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Tongariro Alpine Crossing" /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/img_2760.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Kepler Great Walk" /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/img_3729.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Mount Aspiring National Park" /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/112/july.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Tekapo" /></p> </div> Mon, 22 Feb 2021 00:00:00 +1300