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. June 2022 product update: Performance recommendations on Vitals dashboard, RUM path filters & more https://www.speedcurve.com/blog/product-update-june-2022 <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/438/blog-product-june-2022-newer.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>We've been busy here at SpeedCurve HQ! Here's a roundup of our recent product updates.</p><h2>Performance recommendations on your Vitals dashboard</h2> <p><a href="https://support.speedcurve.com/docs/get-started-with-core-web-vitals"><img class="blog-img" src="https://blog-img.speedcurve.com/img/438/blog-vitals-audits.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>On <a href="https://www.youtube.com/watch?v=6dOBbvh4ZLA">your Vitals dashboard</a>, you now get performance recommendations that are specific to each of the Vitals you're tracking &ndash; Largest Contentful Paint, First Input Delay, Total Blocking Time, and Cumulative Layout Shift. This makes your Vitals dashboard a powerful tool for not only seeing how your metrics perform relative to Google's thresholds, but also diagnose your biggest pain points and get prioritized solutions.</p> <h2>Vitals badges on Lighthouse performance audits</h2> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/438/blog-vitals-badges2.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Elsewhere in SpeedCurve, all the performance recommendations you see in your&nbsp;<a href="https://youtu.be/6dOBbvh4ZLA">Vitals</a>&nbsp;and&nbsp;<a href="https://support.speedcurve.com/docs/aggregated-lighthouse-results">Improve</a>&nbsp;dashboards &ndash; as well as in your synthetic test details &ndash; are now badged so you can see which&nbsp;<a href="https://support.speedcurve.com/docs/get-started-with-core-web-vitals">Web Vitals</a>&nbsp;they affect. Fix those issues and you should see improvements in your Vitals and&nbsp;<a href="https://support.speedcurve.com/docs/lighthouse">Lighthouse</a>&nbsp;scores.</p> <h2>RUM update: Path filters</h2> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/438/blog-rum-paths.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><code></code></p> <p><code></code></p> <h2>RUM update: lux.js v301</h2> <p>New features:</p> <ul> <li>The synthetic onload time for <a href="https://support.speedcurve.com/docs/single-page-applications">SPAs</a> can be marked with <code>LUX.markLoadTime()</code>, allowing <code>LUX.send()</code> to be called later in the page lifecycle.?</li> <li>Added the <a href="https://speedcurve-metrics.github.io/lux.js/debug-parser.html">SpeedCurve RUM Debug Parser</a> to help interpret the debug messages.?</li> <li><code>LUX.getDebug()</code> now includes events that help to debug some metrics including LCP, CLS, element timing, and long tasks.?</li> <li>Source maps are now available for lux.js.?</li> </ul> <p>Bug fixes:</p> <ul> <li>Fixed a bug where JavaScript errors were only tracked on the first SPA page view.?</li> </ul> <h2>Synthetic update: Compare third parties</h2> <p><a href="https://youtu.be/UrF6HpFC08Q"><img class="blog-img" src="https://blog-img.speedcurve.com/img/438/blog-third-parties2.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p style="color: #1f1f1f; font-family: Gotham, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">&nbsp;</p> <p style="color: #1f1f1f; font-family: Gotham, sans-serif; font-size: 16px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">When&nbsp;<a style="text-decoration: underline; color: #35a2d3;" href="https://support.speedcurve.com/docs/bookmark-and-compare-tests">comparing two tests</a>, we now give you a comparison of common&nbsp;<a style="text-decoration: underline; color: #35a2d3;" href="https://support.speedcurve.com/docs/first-third-parties">third parties</a>. We also identify which third parties are unique to each test. Using this feature, you can quickly identify new and problematic third parties.&nbsp;<a style="text-decoration: underline; color: #35a2d3;" href="https://youtu.be/UrF6HpFC08Q">This short video</a>&nbsp;explains how to diagnose third-party regressions in SpeedCurve.</p> <h2>New in the Support Hub</h2> <ul> <li><a href="https://support.speedcurve.com/docs/get-started-with-core-web-vitals">Get started with Core Web Vitals</a>?</li> <li><a href="https://support.speedcurve.com/docs/seo-and-web-performance">SEO and web performance</a>?</li> <li><a href="https://support.speedcurve.com/docs/custom-metrics-for-anti-flicker-snippets">Custom metrics for anti-flicker snippets</a>?</li> <li><a href="https://support.speedcurve.com/docs/cls-scores-in-rum-vs-synthetic">Understand Cumulative Layout Shifts (CLS) scores in RUM vs synthetic?</a></li> <li><a href="https://support.speedcurve.com/docs/investigate-rum-sessions">Investigate RUM Sessions</a>?</li> </ul> <h2>Questions? Feedback? Suggestions?</h2> <p>We'd love to hear from you! Send us a note at support@speedcurve.com</p> Mon, 13 Jun 2022 00:00:00 +1200 Sampling RUM: A closer look https://www.speedcurve.com/blog/sampling-rum <p>Being able to set a sample rate in your real user monitoring (RUM) tool allows you to monitor your pages while managing your spending. It's a great option if staying within a budget is important to you. With the ability to sample real user data, comes this question...</p> <h2>"What should my RUM sample rate be?"</h2> <p>This frequently asked question doesn't have a simple answer. Refining your sample rate can be hit or miss if you aren&rsquo;t careful. In a <a href="https://www.speedcurve.com/blog/sampling-real-user-monitoring/">previous post</a>, I discussed a few considerations when determining how much RUM data you really need to make informed decisions. If you sample too much, you may be collecting a lot of data you may never use. On the other hand, if you sample too little, you risk creating variability in your data that is hard to trust.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/rum-sample-rate2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>In this post, we are going to do a bit of research and let the data speak for itself. I took a look at the impact of sampling at various levels for three t-shirt sized companies (Small, Medium, Large) with the hope of providing some guidance for those of you considering sampling your RUM data.</p> <p>In this post, I'll cover:</p> <ul> <li>Methodology</li> <li>Key findings</li> <li>Considerations</li> <li>Recommendations</li> </ul><h2 id="methodology">Methodology</h2> <h3>Traffic size</h3> <p>I tried to keep this research as simple as possible. We see a large variety of sites at SpeedCurve, representing an assortment of countries, industry segments, traffic levels and more. For the purposes of this study, I'll use example sites from three cohorts:</p> <ol> <li>Large: &gt;1M daily page views</li> <li>Medium: 250K-500K daily page views</li> <li>Small: 10K-100K daily page views</li> </ol> <p>It's important to note that the sites I looked at collect 100% of their RUM data.&nbsp;</p> <h3>Time frame</h3> <p>24 hours. Traffic fluctuates based on the hour of the day, day of the week, and due to seasonality. I looked at the same date, mid-week, for each of the sites, which represented a consistent pattern of daily traffic.</p> <h3>Metric</h3> <p>This was a little tough. Not all metrics are created equal and I try to avoid picking favorites. At the time of this writing, Largest Contentful Paint (LCP) is <a href="https://caniuse.com/mdn-api_largestcontentfulpaint" target="_blank" rel="noopener">not supported by all browsers</a>, so it brings with it a bit of bias. This is true of many of the metrics we collect at SpeedCurve. We'll discuss this and other considerations a bit later. In the end, I settled on <a href="https://caniuse.com/mdn-api_performancetiming_loadeventend" target="_blank" rel="noopener">loadEventEnd</a>&nbsp;due to the fact that it has widespread support across browser platforms.&nbsp;</p> <h3>Sampling method</h3> <p>At SpeedCurve, we have the ability to sample based on sessions versus randomly sampling page views. We feel it's more important to maintain the integrity of the session than to specify precisely how many page views you want to look at. Because we track and identify user sessions, it made things a lot easier for me to sample the data&nbsp;<em>after</em> the fact.</p> <h3>Interpreting the data</h3> <p>There are a lot of ways to compare the data. I'm not a data scientist and I wanted to demonstrate the impact of sampling using views of the data that are familiar to those who have at least seen performance data before.</p> <p style="padding-left: 30px;"><strong>Aggregates:</strong> We will look at the percentage change between the 50th, 75th, and 95th percentiles. I considered anything under 5% acceptable.</p> <p style="padding-left: 30px;"><strong>Histograms:</strong> You can learn a lot if you just look at your data. Histograms are great for showing the performance characteristics of an entire population. (<a href="https://support.speedcurve.com/docs/how-to-read-a-histogram">Learn more about understanding and interpreting histograms</a><span style="color: #1f1f1f;">.)&nbsp;</span><span style="color: #1f1f1f;">For this experiment, we are comparing the overall shape and distribution of our sampled versus unsampled&nbsp;populations. In some cases, the aggregates may have been under 5%, but the the histogram was very sparse and didn't resemble the original distribution. </span><span style="color: #1f1f1f;">For example, the differences between these two histograms is obvious despite their medians being within reason. When looking at the 95th percentile, you observe that the long tail is essentially 'missing' from the sampled data. While somewhat unscientific, I used the eyeball test along with the aggregates to decide if the rate was appropriate.</span></p> <p><span style="color: #1f1f1f;"><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/bad_histo.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Side by side comparison of 100% and 1% histogram samples." /><br /></span></p> <p style="padding-left: 30px;"><span style="color: #1f1f1f;"><strong>Time series:</strong>&nbsp;</span>Intraday variability is important if you're using the RUM data operationally. A simple time series will be used to illustrate how sampling impacts the 'noise' factor.</p> <h2 id="findings">Key findings</h2> <h3>TL;DR</h3> <p>For the most part, I found that if the sampled population of users was greater than 3,000, the aggregate stats were pretty close to your upsampled population (1-2% difference in the median). However, you should read on to understand some of the trade-offs dependent on your use case for RUM. Or, if you'd rather, go ahead and <a href="#recommendations">jump to the results.</a></p> <h3>RUM for reporting</h3> <p>If you're simply looking to RUM as a reporting tool that can represent your daily performance, you're in luck. You can get away with a relatively small sample of your overall population depending on your size.</p> <p>To determine the smallest sample rate for each group, we looked at a combination of the aggregate numbers and a comparison of the histograms. Note the consistency in the 95th percentile illustrated in these comparison charts.&nbsp;</p> <h4>Small (10K-100K daily page views sampled at 50%)</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/histo_compare_small.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram comparison of full data set and 50% of population for a small site." /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/table1.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h4>Medium (250K-500K daily page views sampled at 10%)</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/histo_compare_medium.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram comparison of full data set and 10% of population for a medium site." /></p> <div class="table-responsive"><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/table2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></div> <h4><br />Large (&gt;1M daily page views sampled at 1%)</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/histo_compare_large.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Histogram comparison of full data set and 1% of population for a large site." /></p> <div class="table-responsive"><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/table3.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></div> <h3>&nbsp;</h3> <h3>Intraday performance monitoring</h3> <p>You might be one of those sites deploying code multiple times a day. Maybe you're susceptible to variability from things such as third parties, varying traffic patterns, or other unknowns. (Aren't we all?) If this is the case, you may have more operational need for RUM. Your sampling rate can have a bit of impact on whether or not your data appears noisy or unpredictable.</p> <p>Looking at the recommended rates from the previous use case, the examples below show you how much you'll need to dial that up to get a reliable picture of hourly performance, and even more if you are looking at real-time monitoring (by minute).</p> <h4 style="text-align: left;"><strong><span style="color: #1f1f1f;">Hourly monitoring:</span></strong></h4> <h4 style="text-align: left; padding-left: 90px;">Small &ndash; increased from 50% -&gt; 75%</h4> <h4><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/small_timeseries_compare_by-hour.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Side by side comparison of time series hourly data for a small site." /></h4> <p style="text-align: center;"><em>While increasing the rate helped remove some of the large deviations seen, the data is naturally much more variable for small-traffic sites.</em></p> <h4 style="text-align: left; padding-left: 90px;">Medium &ndash; increased from 10% -&gt; 25%</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/medium_timeseries_compare_by-hour.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Side by side comparison of time series hourly data for a medium site." /></p> <p style="text-align: center;"><em style="text-align: center;">While the peak hours were somewhat consistent at 10%, increasing the rate to 25% removed the larger off-peak deviations.</em></p> <h4 style="text-align: left; padding-left: 90px;">Large &ndash; increased from 1% -&gt; 10%</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/large_timeseries_compare.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Side by side comparison of time series hourly data for a large site." /></p> <p style="text-align: center;"><em style="text-align: center;">Increasing the rate by 10% greatly improved consistency for the large-traffic site.</em></p> <p><strong>Real-time monitoring:</strong>&nbsp;</p> <h4 style="text-align: left; padding-left: 90px;">Small &ndash; increased from 75% -&gt; 95%</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/small_timeseries_compare_by-minute.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Time series comparison of realtime data for a small site." /></p> <p style="text-align: center;"><em style="text-align: center;">For some of the larger spikes in the data, increasing the sample to 95% was effective. However, given how variable the data is, it's hard to say if real-time monitoring of smaller sites like this is really very effective.</em></p> <h4 style="text-align: left; padding-left: 90px;">Medium &ndash; increased from 25% -&gt; 75%</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/medium_timeseries_compare_by-minute.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Time series comparison of realtime data for a medium site." /></p> <p style="text-align: center;"><em style="text-align: center;">For the medium-traffic site, there was benefit&nbsp;when increasing the rate to 75%.&nbsp;</em></p> <h4 style="text-align: left; padding-left: 90px;">Large &ndash; increased from 10% -&gt;&nbsp; 40%</h4> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/large_timeseries_compare_by-minute.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Time series comparison of realtime data for a large site." /></p> <p style="text-align: center;"><em style="text-align: center;">For this particular large-traffic site, getting real-time data consistent with the whole population required a much larger increase in the sample rate than anticipated.</em></p> <p>&nbsp;</p> <div style="overflow-x: auto;"> <div class="table-responsive"><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/table4.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></div> <h2 id="considerations">Considerations</h2> <h3>Data segmentation</h3> <p>Here comes the kicker. One of the great things about RUM is the ability to slice and dice your data. The distribution of your user population is made up of all types of user experiences. This has a pretty big impact on your sample rate, as when you filter/segment/slice/dice your data, you're effectively reducing the size of your population.</p> <p><strong>When determining how sampling will be affected by the segments you care about, get an idea of the percentage of traffic that is represented by the segment and factor that percentage into your overall rate.</strong> Some of the common segments include country, page types, device types and browsers. After applying a lot of segmentation to the experiments above, a good rule of thumb is to increase your sample rate by 50% (or collect 100% of the data for small sites).</p> <h3>Metrics</h3> <p>As mentioned earlier, there are some metrics (okay, many metrics) that aren't supported across browsers. Just as you would increase your sample rate for the segments, <strong>you should consider increasing the sample rate for metrics such as FCP, LCP and Total Blocking Time, which don't have broad browser support</strong>. This is also true of some network-related metrics that don't occur on every page load (DNS, Connect, SSL, Redirect).</p> <h3>Increasing time windows</h3> <p>It's sometimes recommended that you need to capture 100% of your data if you are comparing RUM data for different experiments, or capturing conversion data in order to understand the business impact of performance. This is not always the case. As an alternative, <strong>you can look at a much larger time window with a LOT more sampled data</strong>. This is also true of sites with low traffic numbers. Simply expand your time window until you have a healthy distribution.<br /><br /><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/largerwindows-histo.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Comparing 3 histograms to show the impact of widening your time window." /></p> <h2 id="recommendations">Recommendations</h2> <p>The intent of this post was to help provide some direction around sampling RUM data. The recommended levels are not intended to be precise, as there are too many factors that could influence things one way or the other. Use this table as a guide in addition to the knowledge you have about your users:</p> <p>&nbsp;</p> <div class="table-responsive"><img class="blog-img" src="https://blog-img.speedcurve.com/img/437/table5.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></div> <h2>Learn more about RUM sampling</h2> <p>As you may have guessed, SpeedCurve supports data sampling in RUM. <a href="https://support.speedcurve.com/docs/sample-rate" target="_blank" rel="noopener">This article goes into detail about how our RUM sampling works</a> and explains the different ways you can implement it. If you have any questions or feedback, we'd love to hear from you. Leave a comment below or send us a note at support@speedcurve.com.</p> </div> Wed, 01 Jun 2022 00:00:00 +1200 Understanding the performance impact of anti-flicker snippets https://www.speedcurve.com/blog/web-performance-anti-flicker-snippets <p>Experimentation tools that use asynchronous scripts &ndash; such as Google Optimize, Adobe Target, and Visual Web Optimizer &ndash;&nbsp; recommend using an anti-flicker snippet to hide the page until they've finished executing. But this practice comes with some performance measurement pitfalls:</p> <ul> <li>Hiding the contents of the page can have a dramatic effect on the Web Vitals that measure visual experience, such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)</li> <li>Anti-flicker snippets can also affect Cumulative Layout Shift (CLS) and the synthetic equivalent of First Input Delay (FID), Total Blocking Time (TBT).</li> </ul> <p>In this post we'll look at how anti-flicker snippets work, their impact on Web Vitals, and how to measure the delay they add to visitors' experience.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/436/anti-flicker-vc-bounce-rate.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p><h2>Hiding the page contents</h2> <p>Normally web pages are rendered progressively. As browsers start to receive content, they can layout and render page elements and display the content bit by bit.</p> <p>Anti-flicker snippets hide the contents of a page until the the experimentation tool (e.g. Google Optimize) has finished applying its experiments. The hypothesis is that if a visitor sees the page changing, it may influence how they behave &ndash; either because they had an unpleasant experience or simply because they became aware that they're in an experiment.&nbsp;<br /><br />But as you can see in these filmstrips of Wiggle, a UK cycling retailer, hiding the page can have a dramatic impact on a visitor's experience:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/436/wiggle.001.jpg?auto=format,compress&amp;fit=max&amp;w=2000" alt="Filmstrip showing how Google Optimize's Anti-Flicker snippet delays content from being visible" /></p> <p style="text-align: center;"><em>Comparison of a site loading with (top) and without (bottom) the anti-flicker snippet enabled</em></p> <p style="text-align: center;">&nbsp;</p> <p><strong>The test in top row has the anti-flicker snippet in place.</strong> The content is displayed 'all at once' when the anti-flicker snippet reveals the page.&nbsp;</p> <p><strong>The test in the bottom row has the anti-flicker snippet removed.</strong> The page loads progressively, with the menu and logo appearing about 1.5s before the hero image. The anti-flicker snippet delayed showing the content for two seconds.</p> <p>These tests were over a fast network connection, so First Contentful Paint and Last Contentful Paint happened simultaneously. On slower connections, however, there is a gap between FCP and LCP &ndash; and some progressive rendering &ndash; but FCP still won't start until the anti-flicker snippet finishes.<br /><br />(I chose Wiggle semi-randomly after searching the HTTP Archive for sites that use Google Optimize.)</p> <h2>Effects on other Web Vitals</h2> <p>Anti-flicker snippets can affect other Web Vitals, too:</p> <ul> <li><strong>Decrease in Total Blocking Time</strong> &ndash; TBT is a synthetic monitoring metric that measures how long JavaScript and others tasks prevent the page from handling user interaction. It starts measuring at First Contentful Paint (FCP) and stops at Time to Interactive (TTI). As anti-flicker snippets delay FCP, then the window for measuring the Long Tasks gets smaller, which means you may see a decrease in TBT.</li> <li><strong>Lower Cumulative Layout Shift score</strong> &ndash; CLS measures how much content moves around on the page. If some of this movement happens while the page is hidden, then the CLS score will be lower.</li> </ul> <p>To summarize: On one hand, anti-flicker snippets make metrics such as FCP (and possibly LCP) worse. On the other hand, they can appear to improve TBT and CLS.</p> <p>My instinct is that showing content to the visitor sooner may be a higher priority than the incidental TBT or CLS boost. But rather than trust my instincts, we should measure the impact of hiding the page. To do that, we need to understand a little about how the snippets work.</p> <h2>How anti-flicker snippets work</h2> <p>Anti-flicker snippets typically add a style with <code>opacity: 0</code> to the elements to be hidden. In Google Optimize's default case is the whole document.</p> <p>The (un-minified) Optimize snippet below declares the <code>.async-hide</code> class in a style block, and then applies it to the document using a script. It also defines a function to remove the class and sets a timer to call this function after four seconds.</p> <p>The <code>.async-hide</code> class will either be removed when Google Optimize finishes applying its variants or when the timeout value is reached. In the example below, FCP can be delayed by up to four seconds (the default in the snippet example).</p> <pre class="language-markup"><code>&lt;!-- anti-flicker snippet for Google Optimize (recommended) --&gt; &lt;style&gt; .async-hide { opacity: 0 !important } &lt;/style&gt; &lt;script&gt; (function(a, s, y, n, c, h, I, d, e) { s.className += ' ' + y; h.start = 1 * new Date; h.end = I = function() { s.className = s.className.replace(RegExp(' ?' + y), '') }; (a[n] = a[n] || []).hide = h; setTimeout(function() { I(); h.end = null }, c); h.timeout = c; } )(window, document.documentElement, 'async-hide', 'dataLayer', 4000, { 'GTM-XXXXXX': true }); &lt;/script&gt;?</code></pre> <p>&nbsp;</p> <p>If you'd like to understand the snippet in more detail, there's an annotated version in this Optimize support article: <a href="https://developers.google.com/optimize">Using the Optimize anti-flicker snippet | Google Developers</a></p> <p>As a fallback, four seconds is a long time. Based on the Chrome UX Report thresholds, a page needs to display the Largest Contentful Paint element within 2.5s for it to be considered good.</p> <p>Not every visitor may reach that timeout. For some visitors the experiments may complete soon enough to avoid it.</p> <p>How often the snippet reaches the timeout will depend on factors like:</p> <ul> <li>the number of experiments,</li> <li>how long the experiments take to execute,</li> <li>what device the visitor is using, and</li> <li>the speed of the network the device is connected to.</li> </ul> <p>If we measure how long the page is hidden, we can start to understand how Optimize affects our visitors experiences, the range of delays it adds, and how it influences visitor behaviour.&nbsp;</p> <h2>Measuring how long the page is hidden</h2> <p>Unfortunately, Google Optimize &ndash; like most third-party tags &ndash; doesn't expose any timing information for its key milestones (page hidden, page shown), but there are still ways we can measure them.</p> <h3>1. Update the Optimize anti-flicker snippet to include performance marks and measures&nbsp;</h3> <p>A start mark is recorded just before the hide class is added, and then when the class is remove an end mark, and duration measure are recorded.</p> <pre class="language-markup"><code>&lt;!-- anti-flicker snippet for Google Optimize (recommended) --&gt; &lt;style&gt; .async-hide { opacity: 0 !important } &lt;/style&gt; &lt;script&gt; (function(a, s, y, n, c, h, I, d, e) { performance.mark('anti-flicker-start'); s.className += ' ' + y; h.start = 1 * new Date; h.end = I = function() { s.className = s.className.replace(RegExp(' ?' + y), '') performance.mark('anti-flicker-end'); performance.measure('anti-flicker-duration', 'anti-flicker-start', 'anti-flicker-end'); }; (a[n] = a[n] || []).hide = h; setTimeout(function() { I(); h.end = null }, c); h.timeout = c; } )(window, document.documentElement, 'async-hide', 'dataLayer', 4000, { 'GTM-XXXXXX': true }); &lt;/script&gt;</code></pre> <pre></pre> <p>&nbsp;</p> <p>Editing the predefined snippet might be a bit fragile, as in the future someone might not notice it's been customised and overwrite it with the default version.</p> <h3>2. Create a second snippet that uses a MutationObserver to detect when the <code>async-hide</code> class is removed from the document</h3> <p>This is probably more sustainable as it's less prone to being overwritten.</p> <pre class="language-javascript"><code>(function (node, selector, name) { performance.mark(name + '-start'); const callback = function (mutationsList, observer) { // Use traditional 'for loops' for IE 11 support for (const mutation of mutationsList) { if (mutation.attributeName === 'class' &amp;&amp; !mutation.target.classList.contains(selector) &amp;&amp; mutation.oldValue.includes(selector)) { performance.mark(name + '-end'); performance.measure(name + '-duration', name + '-start', name + '-end'); observer.disconnect(); break; } } } const observer = new MutationObserver(callback); observer.observe(node, { attributes: true, attributeOldValue: true }); })(document.documentElement, 'async-hide', 'anti-flicker'); </code></pre> <p><span style="color: #1f1f1f; font-family: Gotham, sans-serif;"><br />This measurement snippet should be placed immediately after Google Optimize's anti-flicker snippet. It creates a mark when it runs, and then another when the class is removed from the document. It also creates a measure to record how long the page was hidden for.</span></p> <p>The snippet takes three parameters:</p> <ol> <li>the element that's being hidden,</li> <li>the name of the class used to hide it, and</li> <li>a prefix for the name of the marks and measures.</li> </ol> <p>The first two must match their equivalents in the anti-flicker snippet.<br /><br />A similar measuring approach can be used for Adobe Target and VisualWebOptimizer. There are example snippets for these in our support docs:&nbsp;<a href="https://support.speedcurve.com/docs/custom-metrics-for-anti-flicker-snippets">Custom metrics for anti-flicker snippets</a></p> <h2>Using the data</h2> <p>Once the snippet is installed on the page and the&nbsp;<a href="https://support.speedcurve.com/docs/custom-metrics">User Timing metrics configured in SpeedCurve</a>, they can be included in dashboard charts. For example, you can <a href="https://support.speedcurve.com/docs/create-correlation-charts">create a correlation chart</a> in RUM to plot how bounce rate is affected by the length of time page is hidden for.<br /><br /><br /><a href="https://support.speedcurve.com/docs/create-correlation-charts"><img class="blog-img" src="https://blog-img.speedcurve.com/img/436/anti-flicker-duration-vs-bounce-rate.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Chart showing bounce rate increasing as the page is hidden for longer" /></a></p> <p style="text-align: center;"><em>Correlation chart showing relationship between bounce rate and how long the page is hidden</em></p> <p><br />In this example, the chart shows the bounce rate increasing when the page is hidden for longer durations. It also shows that some visitors are waiting four seconds before the see any content!</p> <p>Measuring how long the page is hidden opens up opportunities to get a better understanding of how this wait time affects our visitors' experience. We can use the <a href="https://support.speedcurve.com/docs/investigate-rum-sessions">RUM Sessions dashboard</a> to identify and explore which visitors are being affected by slow Optimize experiments. We can experiment with reducing the timeout so that visitors won't see a blank screen for as long. Or if we recorded which variant the visitor was seeing via&nbsp;<a href="https://support.speedcurve.com/docs/customer-data">RUM's custom data API</a>, we could see which experiments took the longest to execute.&nbsp;<br /><br />(While testing the snippet, I discovered a common third-party reviews service was corrupting the duration measure, so in some cases you may need to switch to using the anti-flicker end mark instead)</p> <h2>Summary</h2> <p>Managing the performance of third-party tags is a key aspect of delivering great web experiences. Unfortunately, the performance of third-party tags can be pretty opaque. In an ideal world, tag vendors would use marks and measures to help us understand how their tags behave in the field, but until they do, browser APIs such as MutationObserver and User Timing can help us to measure some aspects of them.</p> <p>If you've got other third-party tags that you'd like help with measuring, or if you try out one of the snippets for measuring anti-flicker snippets, we'd love to <a href="mailto:support@speedcurve.com">hear from you</a>.</p> Thu, 28 Apr 2022 00:00:00 +1200 Industry page speed benchmarks (March 2022) https://www.speedcurve.com/blog/page-speed-benchmarks-march-2022 <p><a href="https://app.speedcurve.com/benchmarks/">Page Speed Benchmarks</a> is an interactive dashboard that lets you explore and compare web performance data for leading websites across several industries &ndash; from retail to media &ndash; over the past year. This dashboard is publicly available (meaning you don't need a SpeedCurve account to explore it) and is a treasure trove of meaningful data that you can use for your own research.</p> <p>The dashboard allows you to easily filter by region, industry, mobile/desktop, fast/slow, and key web performance metrics, including Google's Core Web Vitals. (Scroll down to the bottom of this post for more testing details.)</p> <p>At the time of writing this post, these were the home pages with the fastest Start Render times in key industries:</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/industry-benchmarks-top-sites-march2022.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>As you can see, I've included Largest Contentful Paint alongside Start Render in this chart, for reasons I explain below.</p><h2>Key metrics</h2> <p>Numbers are good, but visuals are even better. Below you can see the fastest sites &ndash; ranked by Start Render time &ndash; in each category, along with screenshots taken from their rendering timelines, which show you what the viewer sees at key render moments:</p> <ul> <li><a href="https://support.speedcurve.com/docs/metrics-glossary#start-render-synthetic-and-rum"><strong>Start Render</strong></a> &ndash;&nbsp;The time from the start of the initial navigation until the first non-white content is painted to the browser display.&nbsp;</li> <li><strong><a href="https://support.speedcurve.com/docs/metrics-glossary#largest-contentful-paint-synthetic-and-rum">Largest Contentful Paint</a></strong> &ndash; When the largest element &ndash; usually image or video &ndash; in the viewport is rendered. LCP is one of Google's <a href="https://www.speedcurve.com/blog/web-vitals-user-experience/">Core Web Vitals</a>, so it should be on your radar, especially if you care about SEO.</li> <li><a href="https://support.speedcurve.com/docs/metrics-glossary#hero-rendering-times-synthetic"><strong>Last Painted Hero</strong></a> &ndash;&nbsp;When the last piece of critical content (largest image, largest background image and/or first H1 tag) is painted in the browser.&nbsp;</li> <li><a href="https://support.speedcurve.com/docs/metrics-glossary#visually-complete-synthetic"><strong>Visually Complete</strong></a> &ndash; The time at which all the content in the viewport has finished rendered and nothing changed in the viewport after that point as the page continued loading.</li> </ul> <p>These visuals are a great tool for validating the best metrics to focus on for your pages. Looking at the screenshots below, you can really see the disparities between metrics, especially for pages served to mobile.</p> <h2><span style="font-size: 35px; color: #000000;">Fastest Media Sites</span></h2> <h3>UK &amp; EU</h3> <p><strong>The Guardian</strong> (<a href="https://app.speedcurve.com/benchmark/media-eu/test/220331_K1_5e8901097f34e8917d0a816eb8200720/?share=freljsuj6913s9s5an29pktz92alec">view desktop test results</a>)&nbsp;</p> <p><a href="https://app.speedcurve.com/benchmark/media-eu/test/220331_K1_5e8901097f34e8917d0a816eb8200720/?share=freljsuj6913s9s5an29pktz92alec"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-eu-desktop-guardian.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>El Pais</strong> (<a href="https://app.speedcurve.com/benchmark/media-eu/test/220331_SD_d05b2d6a5a95a36b020af0d025e49151/?share=freljsuj6913s9s5an29pktz92alec">view mobile test results</a>)&nbsp;</p> <p><a href="https://app.speedcurve.com/benchmark/media-eu/test/220331_SD_d05b2d6a5a95a36b020af0d025e49151/?share=freljsuj6913s9s5an29pktz92alec"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-eu-mobile-el-pais.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>United States</h3> <p><strong>LA Times</strong> (<a href="https://app.speedcurve.com/benchmark/media-us/test/220330_7J_14ea715c67cf8fa06caee4349e8dc934/?share=5o1gzxgw7797gujjwwgn9i1kffs4g1">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/media-us/test/220330_7J_14ea715c67cf8fa06caee4349e8dc934/?share=5o1gzxgw7797gujjwwgn9i1kffs4g1"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-us-desktop-latimes.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>LA Times</strong> (<a href="https://app.speedcurve.com/benchmark/media-us/test/220331_XH_6910e72661c1f6aa7faec6e84fd05cc0/?share=5o1gzxgw7797gujjwwgn9i1kffs4g1">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/media-us/test/220331_XH_6910e72661c1f6aa7faec6e84fd05cc0/?share=5o1gzxgw7797gujjwwgn9i1kffs4g1"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-us-mobile-latimes.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>Japan&nbsp;</h3> <p><strong>Jiji</strong> (<a href="https://app.speedcurve.com/benchmark/media-jp/test/220331_73_07c3c7fd88cf65dd31fa7d3dee01b33e/?share=oo2me887vtotlylh8bjtx9pz259zt7">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/media-jp/test/220331_73_07c3c7fd88cf65dd31fa7d3dee01b33e/?share=oo2me887vtotlylh8bjtx9pz259zt7"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-jp-desktop-jiji.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Nikkei</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/media-jp/test/220331_60_89dab7755b00ada5e33ff1238e809c33/?share=oo2me887vtotlylh8bjtx9pz259zt7">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/media-jp/test/220331_60_89dab7755b00ada5e33ff1238e809c33/?share=oo2me887vtotlylh8bjtx9pz259zt7"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/media-jp-mobile-nikkei.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h2>Fastest Retail Sites</h2> <h3>UK &amp; EU</h3> <p><strong>Carrefour</strong> (<a href="https://app.speedcurve.com/benchmark/retail-eu/test/220331_M7_e2c7a3106e36482fa6dc0b0b9aaae374/?share=tib9jvxn423ft62vmp5x4ntc16krkb">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-eu/test/220331_M7_e2c7a3106e36482fa6dc0b0b9aaae374/?share=tib9jvxn423ft62vmp5x4ntc16krkb"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-eu-desktop-carrefour.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Edeka</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/retail-eu/test/220331_63_c44fa6aefc7a5bfb3dfec3196e2a1fe5/?share=tib9jvxn423ft62vmp5x4ntc16krkb">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-eu/test/220331_63_c44fa6aefc7a5bfb3dfec3196e2a1fe5/?share=tib9jvxn423ft62vmp5x4ntc16krkb"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-eu-mobile-edeka.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>United States</h3> <p><strong>Amazon</strong> (<a href="https://app.speedcurve.com/benchmark/retail-us/test/220331_X5_d8c87f369d2a841f704fb8b6cf5b3ca7/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-us/test/220331_X5_d8c87f369d2a841f704fb8b6cf5b3ca7/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-us-desktop-amazon.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Wish</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/retail-us/test/220331_4N_b384f1781bc7986c7715fc0e277377fb/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-us/test/220331_4N_b384f1781bc7986c7715fc0e277377fb/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-us-mobile-wish.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>Japan</h3> <p><strong>Rakuten</strong> (<a href="https://app.speedcurve.com/benchmark/retail-jp/test/220331_2T_a3655522fb0df5c109622b465b1fbb9c/?share=u1lwaz44pc9tv5m44vpbqp41w1ldfy">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-jp/test/220331_2T_a3655522fb0df5c109622b465b1fbb9c/?share=u1lwaz44pc9tv5m44vpbqp41w1ldfy"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-jp-desktop-rakuten.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Yodobashi</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/retail-jp/test/220331_TW_6331ab3eee98f4888ce770970a2eaf66/?share=u1lwaz44pc9tv5m44vpbqp41w1ldfy">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/retail-jp/test/220331_TW_6331ab3eee98f4888ce770970a2eaf66/?share=u1lwaz44pc9tv5m44vpbqp41w1ldfy"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/retail-jp-mobile-yodobashi.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h2>Fastest Travel Sites</h2> <h3>UK &amp; EU</h3> <p><strong>Airbnb</strong> (<a href="https://app.speedcurve.com/benchmark/travel-eu/test/220331_KN_760b1e4a0ba44c7a796d8bae4fbb9fcf/?share=i256t8bjv28n4i2ui7ffbvwkulnrr2">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-eu/test/220331_KN_760b1e4a0ba44c7a796d8bae4fbb9fcf/?share=i256t8bjv28n4i2ui7ffbvwkulnrr2"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-eu-desktop-airbnb.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Skyscanner</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/travel-eu/test/220331_2P_90e975b1abea387ff9d6e4ab438e67fc/?share=i256t8bjv28n4i2ui7ffbvwkulnrr2">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-eu/test/220331_2P_90e975b1abea387ff9d6e4ab438e67fc/?share=i256t8bjv28n4i2ui7ffbvwkulnrr2"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-eu-mobile-skyscanner.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>United States</h3> <p><strong>HomeAway</strong> (<a href="https://app.speedcurve.com/benchmark/travel-us/test/220331_XY_70b091a425ecb3683215ad1727f1ddf6/?share=lzc3770o3nzhn5zwl6j5xvqeak8np1">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-us/test/220331_XY_70b091a425ecb3683215ad1727f1ddf6/?share=lzc3770o3nzhn5zwl6j5xvqeak8np1"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-us-desktop-homeaway.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Lonely Planet</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/travel-us/test/220331_TH_e01e26d48bedc21a8f2cd2d41cb55ea1/?share=lzc3770o3nzhn5zwl6j5xvqeak8np1">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-us/test/220331_TH_e01e26d48bedc21a8f2cd2d41cb55ea1/?share=lzc3770o3nzhn5zwl6j5xvqeak8np1"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-us-mobile-lonelyplanet.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h3>Japan</h3> <p><strong>Rakuten Travel</strong> (<a href="https://app.speedcurve.com/benchmark/travel-jp/test/220331_P4_7ea2cc9bee57c81882c00df5a51ba5c1/?share=9ub9f5s75dvgwcquk3me8qxj769ldm">view desktop test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-jp/test/220331_P4_7ea2cc9bee57c81882c00df5a51ba5c1/?share=9ub9f5s75dvgwcquk3me8qxj769ldm"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-jp-desktop-rakuten.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p><strong>Expedia</strong>&nbsp;(<a href="https://app.speedcurve.com/benchmark/travel-jp/test/220331_MB_0acb3a49090c47b3e43ba9a607d08000/?share=9ub9f5s75dvgwcquk3me8qxj769ldm">view mobile test results</a>)</p> <p><a href="https://app.speedcurve.com/benchmark/travel-jp/test/220331_MB_0acb3a49090c47b3e43ba9a607d08000/?share=9ub9f5s75dvgwcquk3me8qxj769ldm"><img class="blog-img" src="https://blog-img.speedcurve.com/img/435/travel-jp-mobile-expedia.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <h2>Takeaways</h2> <h3>1. Start Render is an important metric for measuring user-perceived responsiveness.</h3> <p>Visual feedback that something is happening on the page is important to users. This is why it's frequently proven to be a good metric to use when creating correlation charts that map performance to user engagement and business metrics, like bounce rate and conversion rate.&nbsp;</p> <h3>2. If you're not tracking Largest Contentful Paint, you should be... especially for mobile.</h3> <p>To me, the biggest takeaway here is noting the disparity between Start Render and Largest Contentful Paint. Some disparity is to be expected, as Start Render measures when the first pixels start to appear on the page, and LCP measures when the largest visual element (image or video) finishes rendering.</p> <p>In most cases, the difference between Start Render and Largest Contentful Paint isn't huge for pages served to desktop. Mobile tells a different story, even among the fastest pages we tested. For example:</p> <ul> <li>LA Times home page had a Start Render time of 2.5 seconds, but its LCP was 37.42 seconds.&nbsp;</li> <li>Lonely Planet Start Render was 3.1 seconds, while LCP was 37.22 seconds.</li> <li>Expedia had a Start Render time of 5.8 seconds, while LCP was 35.4 seconds.</li> </ul> <p>While those were the most glaring examples, most of the other sites also had significant differences. There's also this gotcha...</p> <h3>3. LCP doesn't always correlate to meaningful content in the viewport... specifically for mobile.</h3> <p>If you're serving a lot of mobile users, you may want to validate that LCP is a valid metric to track &ndash; and troubleshoot any issues that are preventing it from being measured correctly.</p> <h3><span style="color: #000000;">4. Visually Complete is not a meaningful metric for most sites.</span></h3> <p>Visually Complete was a helpful metric for its time, but it came with its fair share of gotchas &ndash; such as the fact that it sometimes didn't fire until long after the page had fully rendered. You can see examples of this above. While we still track Visually Complete in SpeedCurve for folks who are still using it, <a href="https://www.speedcurve.com/blog/performance-budgets-guide/">we consider it unofficially deprecated</a> in favour of more precise metrics.</p> <h2>Testing details</h2> <p>Here's how we set up testing for the Page Speed Benchmarks:</p> <ul> <li>Home pages of 10 leading sites in the US, EU, and Japan, in each of the following industries: Auto, Finance, Media, Retail, Tech, and Travel.</li> <li>Tested on our private agents in Frankfurt (EU), US East Coast (US), and Japan.</li> <li>Tested once per day on a Chrome desktop browser with a fast connection (25Mbps/10Mbps 10ms RTT).&nbsp;</li> <li>Tested once per day on an emulated Nexus 5X mobile at 3G Slow (400Kbps/400Kbps 400ms RTT).&nbsp;&nbsp;</li> <li>Three tests per test time, with the medians used in the charts.</li> </ul> <h2>Create your own custom benchmark dashboard</h2> <p>If you're not already using SpeedCurve, I encourage you to <a href="https://app.speedcurve.com/setup/trial/"><strong>sign up for a free trial</strong></a> and <a href="https://support.speedcurve.com/docs/competitive-benchmarking"><strong>create your own benchmarks dashboard</strong></a> where you can see how your site compares to your competitors.</p> <p>I also encourage you to check out the entire <a href="https://app.speedcurve.com/benchmarks/"><strong>Industry Page Speed Benchmarks dashboard</strong></a> (no login required). You can drill down into the historical test data for every site. If you spot something interesting, let me know!</p> Mon, 04 Apr 2022 00:00:00 +1200 Ten years of page bloat: What have we learned? https://www.speedcurve.com/blog/ten-years-page-bloat <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-2012-2022.gif?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>I've been writing about page size and complexity for years. If you've been working in the performance space for a while and you hear me start to talk about page growth, I'd forgive you if you started running away. ;)</p> <p>But pages keep getting bigger and more complex year over year &ndash; and this increasing size and complexity is not fully mitigated by faster devices and networks, or by our hard-working browsers. Clearly we need to keep talking about it. We need to understand how ever-growing pages work against us. And we need to have strategies in place to understand and manage our pages.&nbsp;</p> <p>In this post, we'll cover:</p> <ul> <li>How big are pages today versus ten years ago?</li> <li>How does page bloat hurt your business?</li> <li>How does page bloat affect other metrics, such as Google's Core Web Vitals?</li> <li>Is it possible to have large pages that deliver a good user experience?</li> <li>What can we do to manage our pages and fight regression?</li> </ul><h2>What do we mean when we talk about page size?</h2> <p style="font-size: 16px;">When we talk about page size, we're referring to overall page weight and complexity. This includes:</p> <ul style="font-size: 16px;"> <li><strong>Size</strong>&nbsp;&ndash; Total page weight in bytes. Size matters especially to mobile users who have limited and/or metered data.</li> <li><strong>Resources</strong>&nbsp;&ndash; Total number of resources on the page (listed below). The more resources, the greater the complexity and the increased likelihood of rendering delays and blockages.</li> <li><strong>HTML</strong>&nbsp;&ndash; Typically the smallest resource on the page, HTML's performance risk is usually negligible. Having said that, I recently did some digging into a page where the total HTML size jumped dramatically because of a bunch of inline JavaScript, which led to rendering delays, so keeping an eye on HTML size is still a good idea.</li> <li><strong>Images</strong>&nbsp;&ndash; Often the greatest contributor to page bloat. Looking at the 90th percentile of the distribution of page weight, images account for a whopping 5.7 MB of a roughly 8.2 MB page. In other words, images comprised almost 75% of the total page weight. And if that already wasn&rsquo;t enough, the number of images on a page has been linked to lower conversion rates on retail sites. (More on that later.)</li> <li><strong>JavaScript</strong>&nbsp;&ndash; A page can have a relatively low JS weight but still suffer from JS-inflicted performance problems. Even a single 100 KB third-party script can wreak havoc with your page. The more scripts on your page, the greater the risk. It&rsquo;s not enough to focus solely on blocking JavaScript. It&rsquo;s possible for your pages to contain zero blocking resources and still have less-than-optimal performance because of how your JavaScript is rendered. That&rsquo;s why it&rsquo;s so important to understand CPU usage on your pages, because JavaScript consumes more CPU than all other browser activities combined. While JavaScript blocks the CPU, the browser can&rsquo;t respond to user input. This creates what&rsquo;s commonly called &ldquo;jank&rdquo; &ndash; that annoying feeling of jittery, unstable page rendering.</li> <li><strong>CSS</strong>&nbsp;&ndash; Like JavaScript, CSS doesn&rsquo;t have to be bulky to cause problems. Poorly executed stylesheets can create a host of performance problems, ranging from stylesheets taking too long to download and parse, to improperly placed stylesheets that block the rest of the page from rendering. And, similar to JavaScript, more CSS files equals more potential trouble.</li> </ul> <h2><span style="font-size: 35px; color: #000000;">How does page bloat hurt your business?</span></h2> <p>A&nbsp;<a href="https://www.thinkwithgoogle.com/marketing-strategies/app-and-mobile/mobile-page-speed-load-time/">Google machine-learning study</a>&nbsp;I participated in a few years ago found that the total number of page elements was the single greatest predictor of conversions. The number of images on the page was the second greatest predictor.</p> <p><a href="https://www.slideshare.net/tammyeverts/using-machine-learning-to-determine-drivers-of-bounce-and-conversion-66319405"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/machine-learning-images.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>We also found that the more scripts there were in a series of pages in a session, the less likely that session was to convert.&nbsp;</p> <p><a href="https://www.slideshare.net/tammyeverts/using-machine-learning-to-determine-drivers-of-bounce-and-conversion-66319405"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/machine-learning-scripts.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>Image size is another issue, as excessive image weight hurts your SEO ranking in Google Image Search. Given that Image Search comprises upwards of 26% of Google searches, this is something you should care about. (You can dive deeper into image optimization and SEO tips in&nbsp;<a href="https://developers.google.com/search/docs/advanced/guidelines/google-images">this article</a>&nbsp;in Google Search Central.)&nbsp;</p> <h2>How big are pages today versus ten years ago?</h2> <p>Before we get into these numbers, some background and caveats:</p> <ul> <li><strong>These numbers all come from the <a href="https://httparchive.org/reports/page-weight">HTTP Archive</a>.</strong> It's important to mention that there have been changes to how the Archive collects data over the years. Having said that, looking at data over the past ten years, it's safe to make the observation that pages are definitely trending bigger.</li> <li><strong>I intentionally left out the numbers for video, because they seemed inconsistent.</strong> For the purposes of this post, they're not high priority, so I'm fine with setting them aside for now.</li> <li><strong>These numbers should not be taken as a benchmark for your own site.</strong> You haven't necessarily achieved anything great if your pages are smaller than this, nor have you failed if your pages are bigger.&nbsp;</li> <li><strong>Not all pages are getting bigger.</strong> Many have gotten smaller over the years. Maybe yours is one of them!</li> </ul> <h3>1. The median desktop page is 3X bigger now than ten years ago</h3> <p>As someone who's been watching these numbers for more than ten years, this growth doesn't come as a surprise. The median size of 2159 KB is about what I expected to see, given how many pages I inspect in any given week that are much larger than this.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>2. Images and JavaScript comprise two-thirds of total page weight</h3> <p>Predictably, much of this page growth is driven by images and JavaScript. Images account for roughly 945 KB (44%) of median desktop page weight, and JS accounts for about 500 KB (23%).&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/new-desktop-page-weight-breakdown-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>3. The median mobile page is almost 7X bigger than ten years ago</h3> <p>The pages being served to mobile users have experienced massive growth. At 1984 KB, the median mobile page is only somewhat smaller than the median desktop page (2159 KB). While it is possible to have large, robust pages that feel fast, you should care about page bloat in terms of how it affects mobile users, especially mobile-only users who are on older low-CPU devices, or who are dealing with bandwidth constraints or data limits.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/mobile-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>4. Images and JavaScript comprise the bulk of mobile page weight</h3> <p>We're serving about 876 KB of images and 453 KB of scripts to mobile &ndash; in other words 67% of total page weight. JavaScript is a massive CPU hog, so this is concerning, especially if your users are on older devices with less processing power. (If you're counting on your users having newer devices, you might want to rethink that. In recent years, <a href="https://www.cnet.com/tech/mobile/getting-a-new-iphone-every-2-years-is-making-less-sense-than-ever/">the smartphone replacement cycle has gotten longer</a> and it looks like this trend is here to stay.)</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/new-mobile-page-weight-breakdown-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>5. Pages are huge at the 90th percentile, and the bulk is image weight</h3> <p>Focusing on medians is not enough. You should also care about your cohort of users at the 90th percentile. Ten percent of your users may not sound like much, but if your site gets 10 million visitors a month, that means a million of those people are having a really poor experience.</p> <p>The 90th percentile page served to desktop is 8271 KB and contains 177 resources. Almost 75% of page weight is consumed by images, which add up to more than 5 MB.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-90th-percentile-kb.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>The 90th percentile page served to mobile is only slightly smaller, at 7574 KB and 168 resources.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/mobile-90th-percentile-kb.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>6. The number of resources served to desktop has stayed flat over the years</h3> <p>You can see this relative flatness at both the median and 90th percentile. This actually came as a bit of a surprise. I had assumed that there'd be more significant growth, especially given the growth in total page size. More on that in a bit.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/new-desktop-resources.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>7. But more resources are being served to mobile</h3> <p>No surprises here. We've moved considerably beyond the pared-down pages we used to serve to mobile users a decade ago.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/new-mobile-resources.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>8. Image requests are way down, while image size is way up</h3> <p>We're serving fewer images, but the images we are serving are high-resolution and/or unoptimized. The median page today serves 25 images, compared to 42 images back in 2012. While the number of image requests has reduced dramatically, the combined size has increased almost threefold, from 331 KB to 945 KB.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-images-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>This trend carries over to mobile. The number of image requests has remained the same, but in this case the total image size has increased almost 6X &ndash; from 151 KB to 876 KB.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/mobile-images-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>9. JavaScript requests have doubled, while JS size has almost quadrupled</h3> <p>Not only are we serving more scripts than ever &ndash; with all the performance risks that those entail &ndash; we're also bulking out pages with 500 KB of JS weight.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-scripts-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p>Mobile pages fare only slightly better with 453 KB of JS weight.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/mobile-scripts-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h3>10. CSS requests have more than doubled for desktop and mobile</h3> <p>More stylesheets equal more risk of performance degradation. The amount of CSS on your pages is something to keep an eye on, because problematic CSS can block the rest of your page from rendering.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/desktop-css-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/mobile-css-2012-2022.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h2>How does page bloat affect Core Web Vitals?</h2> <p>Google's <a href="https://web.dev/learn-web-vitals/">Core Web Vitals</a> are a set of metrics that are intended to focus on measuring performance from a user-experience perspective. While total page size and weight don't directly affect Web Vitals, there are some nuanced ways that you should think about the number and size of resources you're serving.</p> <h3>Largest Contentful Paint&nbsp;</h3> <p>Largest Contentful Paint (LCP) measures when the largest visual element on the page renders. Page bloat issues that can hurt your LCP time include:</p> <ul> <li><strong>Slow or blocking scripts and stylesheets</strong> that load at the beginning of the page's rendering path can delay when images start to render.</li> <li><strong>Unoptimized images with excessive load times.</strong> Largest Contentful Paint includes the entire time it takes for the image to finish rendering. If your image starts to render at the 1-second mark but takes 4 seconds to fully render, then your LCP time is 5 seconds. This falls short of <a href="https://web.dev/vitals/">Google's threshold of 2.5 seconds for Largest Contentful Paint</a>.</li> </ul> <h3>First Input Delay</h3> <p>First Input Delay (FID) measures how quickly a page responds to a user interaction. Input delay happens when the browser's main thread is too busy to respond to the user. Commonly, this is due to the browser being busy parsing and executing large JavaScript files.</p> <p>There's a lot of unnecessary JS on many pages, and as noted above, JS files have gotten bigger over the years. The more JS on your page, the more potential for slow FID times. As Tim Kadlec said a couple years back in his performance.now() talk <a href="https://www.youtube.com/watch?v=JvJ0v5OohNg">When JavaScript Bytes</a>:</p> <blockquote> <p>JavaScript is, byte-for-byte, the most expensive resource on the web and we&rsquo;re using more of it than ever in our sites. You can optimize the delivery, the parsing and the execution until you&rsquo;re blue in the face but you&rsquo;ll never make it as performant as simply not using it in the first place.</p> </blockquote> <h3>Cumulative Layout Shift</h3> <p>Cumulative Layout Shift (CLS) measures how visually stable a page is. It's a formula-based metric that, put simply, takes into account how much a page's visual content shifts within the viewport, combined with the distance that those visual elements shifted. You can <a href="https://web.dev/cls/">dig deeper</a> into the mechanics of how CLS is calculated, but the human-friendly definition is that CLS helps you understand how likely a page is to deliver a janky, unpleasant experience to viewers.&nbsp;</p> <p>CLS is strongly affected by the number of resources on the page, and by how and when those resources are served. You can see this by looking at the <a href="https://app.speedcurve.com/benchmark/retail-us/test/220307_0Q_629df0001e6f8cd98dabbb42196ff7a5/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae">synthetic test result for Sears.com</a>&nbsp;(again, available via our <a href="https://app.speedcurve.com/benchmarks/usa/retail/slow/cumulative-layout-shift/">Industry Benchmarks</a>). The CLS score for this page is 1.0468. For context, Google recommends a score of 0.1 or less. Translation: This is a really, really janky page!</p> <p>These screenshots highlight the most significant visual element shifts:</p> <p><a href="https://app.speedcurve.com/benchmark/retail-us/test/220307_0Q_629df0001e6f8cd98dabbb42196ff7a5/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/cls-sears.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>Not surprisingly, this page, while not overly huge in terms of total size (almost 3 MB), contains a massive number of requests. Of those 559 requests, the bulk is images (175 requests), JavaScript (140 requests), and 'other' (133 requests).&nbsp;</p> <p><a href="https://app.speedcurve.com/benchmark/retail-us/test/220307_0Q_629df0001e6f8cd98dabbb42196ff7a5/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae&amp;share=3ssmi8mdfi7g5j2m3oinu6d74c9tae"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/sears-page-size.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p>Looking at the <a href="https://app.speedcurve.com/benchmark/retail-us/test/220307_0Q_629df0001e6f8cd98dabbb42196ff7a5/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae&amp;share=3ssmi8mdfi7g5j2m3oinu6d74c9tae">waterfall chart for this same page</a>, we see that there are:</p> <ul> <li>16 requests before Start Render</li> <li>52 requests before Largest Contentful Paint, and</li> <li>62 requests before the Largest Layout Shift (a CLS-related metric that SpeedCurve captures)</li> </ul> <p>That's a lot of requests!</p> <h2>Is it possible to have big pages that deliver a good user experience?</h2> <p style="font-size: 16px;">Yes. While page size can be a red flag for real performance issues, if you care about user experience, you need to take a closer look at how your pages are built to see if the size and complexity of your pages actually affect how fast your site feels to your users.</p> <p style="font-size: 16px;">It's not enough to look at crude metrics like total requests and size. You need to know:</p> <ul style="font-size: 16px;"> <li>How many of your requests are blocking requests?</li> <li>If your page contains blocking requests, how many of them occur in the critical rendering path? That is, how many blocking requests are there before key page metrics like Start Render and Largest Contentful Paint?</li> <li>How many of your potentially problematic requests come from third parties, and how do you maintain visibility into how they're performing?</li> <li>Are the most important images on your page the first images to render? How quickly do they show up?</li> </ul> <p style="font-size: 16px;">Amazon is a good example of a site that serves large, fast pages. In&nbsp;<a href="https://app.speedcurve.com/benchmark/retail-us/test/220302_0C_0b8d7eaa99a061a20d14cd485217b33a/?share=3ssmi8mdfi7g5j2m3oinu6d74c9tae">this recent test run</a>&nbsp;from our&nbsp;<a href="https://app.speedcurve.com/benchmarks/usa/retail/fast/start-render/">Industry Page Speed Benchmarks</a>, you can see that the Amazon home page ranks fastest in terms of Start Render. This is despite the fact that the page contains 410 requests and weighs in at 4,311 KB &ndash; far beyond the median sizes shared above. Yet the page has a Start Render time of 0.3 seconds, a Largest Contentful Paint time of 0.48 seconds, and a CLS score of 0.1526.</p> <p style="font-size: 16px;"><a href="https://app.speedcurve.com/benchmarks/usa/retail/fast/start-render/"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/amazon-benchmarks-2.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></a></p> <p style="font-size: 16px;">Looking at a close-up of Amazon's waterfall chart (below) reveals why. While there are 38 resources that load before Largest Contentful Paint, only one of them is render blocking, and all of them are extremely lean.</p> <p style="font-size: 16px;"><img class="blog-img" src="https://blog-img.speedcurve.com/img/434/amazon-waterfall.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="" /></p> <h2>Takeaways</h2> <p>I meet with so many people whose job it is to build and optimize websites. When we look at how their pages are built, I routinely witness their surprise at spotting things like ghost scripts, huge unoptimized images, and blocking resources they weren't aware of. These are smart people. The problem isn't them &ndash; it's the scale of their sites, the speed of their release cycles, and the number of people who touch each page.</p> <p>We're never going to get our lean, pre-1999, under-1MB web pages back. But we can regain control over the pages we have today.</p> <h3>1. Understand the critical rendering path for each page</h3> <p>Your pages probably have a lot of unnecessary junk on them, and some of that junk is unoptimized. Too much stuff means you can't see the forest for the trees. You can have large, complex pages that still feel fast. The key to a good user experience is quickly delivering the most important content first. Here are some <a href="https://developers.google.com/web/fundamentals/performance/critical-rendering-path/measure-crp">great resources for analyzing and optimizing the critical rendering path</a>.</p> <h3>2. Make sure everyone who touches a page understands the performance impact of what they do</h3> <p>All the fancy performance monitoring tools in the world can't help you if you don't have a strong performance culture at your organization. Here are some <a href="https://support.speedcurve.com/docs/performance-culture-best-practices">tips and best practices</a> to help on that journey.</p> <h3>3. Fight regression</h3> <p>Page bloat happens when people stop paying attention. We need to monitor our pages consistently over time.<a href="https://support.speedcurve.com/docs/continuous-integration">Integrating performance testing into your CI/CD process</a> is a great way to fight regression, especially if you combine this with creating&nbsp;<a href="https://support.speedcurve.com/docs/performance-budgets-101">performance budgets</a>. By creating performance budgets for key metrics &ndash; such as Start Render, Largest Contentful Paint, and various page size and weight metrics &ndash; you can get alerted when they go out of bounds.&nbsp;</p> <h3>4. Don't assume hardware and networks will mitigate page bloat</h3> <p>While some of your users may have newer devices and speedy networks, not all are this lucky.&nbsp;If you're using a <a href="https://support.speedcurve.com/docs/synthetic-vs-real-user-monitoring-rum">real user monitoring</a> tool, <a href="https://support.speedcurve.com/docs/performance-for-product-managers">keep an eye on your performance metrics at the 75th and 95th percentiles</a> so you have an understanding of your site's less-optimal performance.&nbsp;</p> <hr /> <p style="text-align: center;"><strong><em>If you're not already using SpeedCurve to monitor your site's performance,&nbsp;</em></strong><strong><em><a href="https://app.speedcurve.com/setup/trial/">start your free trial</a>!</em></strong></p> Tue, 08 Mar 2022 00:00:00 +1300 NEW: RUM Live and Page Views dashboards https://www.speedcurve.com/blog/new-rum-live-and-page-views-dashboards <p>Shortly before the end of the year, we snuck in a couple of last-minute gifts for 2021. It was a great year for SpeedCurve with a lot of renewed focus on RUM. We couldn't think of a better way to finish out the year than to launch the new <strong>Live</strong> and <strong>Page Views</strong> dashboards. Let's take a look!</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/large_animated_rum.gif" alt="Animated RUM Live dashboard from SpeedCurve" /></p><h2>RUM Live</h2> <p>How are users experiencing my site right now? The Live dashboard gives you a near real-time view of how users are interacting with your website. This is a great way to spot current issues or just answer the question '<strong>Are my users happy?</strong>'</p> <p>There are several components on this dashboard, which all automatically refresh to give you the most current look at user performance.</p> <h3>Summary</h3> <p>Here you'll find a high-level overview for your site over the most recent time period, so you can see basic usage metrics at a glance. The default time period is 30 minutes, but you can select anything from 15 minutes to 12 hours.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/summary.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Summary table for Live dashboard" /></p> <h3>Geographic performance</h3> <p>Understanding performance across different markets is critical for site owners. Are investments you've made into your CDN paying off? Did you realize you were getting traffic from Turkey? Now you can quickly see performance by country for any of your favorite metrics. The gradient scale will help you to understand varying levels of performance, while the size of the bubble indicates the volume of users in that region.</p> <h3><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/geo.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="World map showing performance by country" /></h3> <h3>User Happiness and Core Web Vitals</h3> <p>Our <a href="https://support.speedcurve.com/docs/user-happiness" target="_blank" rel="noopener">user happiness</a> scoring quickly identifies the impact performance has on the user experience of your site. We've also included a new performance time-series view with page view columns to indicate the performance of key metrics compared with the size of the sample over the period. <a href="https://www.speedcurve.com/blog/new-vitals-dashboard/">Core Web Vitals</a> are presented by default, but you can select any of the metrics you care about for these charts.</p> <h3><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/happiness_cwv.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Charts illustrating SpeedCurve's User Happiness index and Core Web Vitals." /></h3> <h3>Sessions</h3> <p>Finally, the last component on this dashboard is the 'Latest Sessions' table. This is a list of the most current user sessions on your site.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/sessions.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Table of unique user sessions." /></p> <p>From any one of the listed sessions in the table, you can click through to look at the details, including the user's journey and the page level performance across all collected metrics. (Note that SpeedCurve RUM does not collect personal identifiable information (PII). <a href="https://support.speedcurve.com/docs/rum-data">Learn more</a> about the data that our RUM does and does not collect.)</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/session_details.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="image of the session details for an anonymous user" /></p> <h2><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/page_details.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Performance details for a specific page in the user's session" /></h2> <h2>Page Views</h2> <p>Are things working as expected? Did my most recent change to RUM take effect? Am I collecting any data? Are my new custom metrics working as expected? Sometimes, you just need to <a href="https://www.youtube.com/watch?v=coNDCIMH8bk" target="_blank" rel="noopener">look at your data</a>. The Page Views dashboard allow you to do just that.&nbsp;</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/pageviews.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="SpeedCurve's RUM Page Views dashboard" /></p> <p>By drilling into any of the summarized entries in the table, you'll find everything we know about that page view. This includes both default and <a href="https://support.speedcurve.com/docs/custom-metrics" target="_blank" rel="noopener">custom metrics</a> as well as any <a href="https://support.speedcurve.com/docs/customer-data">custom data</a> you've defined.</p> <p><img class="blog-img" src="https://blog-img.speedcurve.com/img/433/pageview_detail.png?auto=format,compress&amp;fit=max&amp;w=2000" alt="Expanded view of custom and default metrics for a specific page view" /></p> <h2>There was at least one good thing about 2021</h2> <p>We hope you enjoy all the new features we've added to RUM over the last year. It's exciting for us to continue to push the boundaries of what we can do with real user data and see firsthand how it helps our customers. In case you are wondering, 2022 has even more RUM goodness in store! As always, <a href="mailto:support@speedcurve.com" target="_blank" rel="noopener">feedback is welcomed</a> and encouraged.</p> <p>Not a RUM user? <a href="https://www.speedcurve.com/" target="_blank" rel="noopener">Start a free trial today</a>!</p> Tue, 18 Jan 2022 00:00:00 +1300 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