SpeedCurve Blog https://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. Rendering Metrics https://speedcurve.com/blog/rendering-metrics <p>At SpeedCurve, we're fond of the phrase "a joyous user experience". Creating this joy requires delivering what users want as quickly as possible. It's important that the critical content is downloaded&nbsp;and rendered before users get frustrated. Network metrics have been around for decades, but rendering metrics are newer. What rendering metrics currently exist? What do they mean? How do they compare? Which are best for you? Let's take a look.</p><h3 style="text-align: left;">A Brief History of Performance Metrics</h3> <p>Metrics quantify behavior. In the case of performance metrics, we're trying to capture the behavior of a website in terms of speed and construction. By "construction"&nbsp;I mean statistics about how the site is built such as number of HTTP requests, size of stylesheets, and DOM depth. Speed is tracked by time-based metrics that capture when things happen during the user's experience with the website: start render, DOM interactive, page load, etc. Often, construction metrics are useful for diagnosing the cause of changes in&nbsp;speed metrics.&nbsp;</p> <div style="padding-left: 30px;"><em>Why did start render get slower?</em></div> <p style="padding-left: 30px;"><em>Ah-ha, the number of blocking scripts increased!</em></p> <p>While construction metrics&nbsp;are fairly well established, time-based performance metrics are newer and still evolving. In the old days, the main time-based performance metric was <code>window.onload</code>. (Actually, before <code>window.onload</code> the main performance metric was the response time of the HTTP request for the HTML document!)&nbsp;</p> <p>The <a href="https://www.w3.org/webperf/">W3C Web Performance Working Group</a> changed everything with the <a href="https://www.w3.org/TR/navigation-timing-2/">Navigation Timing</a>, <a href="https://cdn.rawgit.com/w3c/resource-timing/V2/index.html">Resource Timing</a>, and <a href="https://w3c.github.io/user-timing/">User Timing</a> specifications. Navigation Timing and Resource Timing let us measure things like DNS lookups, TCP connections, and SSL negotiations for the main page as well as all the resources in the page. Most importantly, Navigation Timing gives us a spec'ed milestone for when the page begins to load (<code>performance.timing.navigationStart</code>), as well as other milestones like DOM Interactive and DOM Complete. User Timing doesn't come with any predefined metrics, but instead provides an API for capturing website-specific milestones by simply calling <code>performance.mark</code> and <code>performance.measure</code>.&nbsp;</p> <h3>Gaps in Today's Performance Metrics</h3> <p>While the specifications mentioned previously have greatly improved our ability to measure performance, they actually don't help us capture the most important aspects of web performance. There are two big gaps:&nbsp;</p> <h4>Gap 1: Browser Main Thread</h4> <p>The gating factor in web performance ten years ago was network. Today, the main bottleneck is CPU. The cause of this shift is the increase in CSS and JavaScript, as well as more mobile users. Over the last seven years, the number of scripts jumped from 12 to 36 and the compressed size increased from 110K to 617K for the world's top 1000 websites according to the <a href="http://httparchive.org/trends.php?s=Top1000&amp;minlabel=Jan+20+2011&amp;maxlabel=Nov+15+2017#bytesJS&amp;reqJS">HTTP Archive</a>.</p> <p style="text-align: center;"><a href="http://httparchive.org/trends.php?s=Top1000&amp;minlabel=Jan+20+2011&amp;maxlabel=Nov+15+2017#bytesJS&amp;reqJS"><img style="max-width: 600px;" src="https://speedcurve.com/img/blog/uxmetrics-ha-js.png" alt="JS Growth" width="100%" /></a></p> <p>Construction metrics provide information about the number and size of scripts and stylesheets. But this isn't a direct measure of how JavaScript is impacting the page. Suppose a website has just one script, but that script takes 3 seconds to execute. Another website might have four scripts, but each of them takes less than 100 milliseconds to execute. The number of scripts is a good estimate for whether JavaScript is the bottleneck, but it's based on assumptions about typical execution times.</p> <p>It would be better if there was a way to measure the time each script, especially the blocking scripts, consume on the browser's main thread. Chrome Dev Tools has this information, and a year or so ago Pat Meenan added this to <a title="JS Pink Bars" href="https://wpt1.speedcurve.com/video/compare.php?tests=171130_1J_740afc574b8073ba95af1e00cc1f3817-r:2-c:0">WebPageTest's waterfall charts</a> using pink bars:&nbsp;</p> <p style="text-align: center;"><a href="https://wpt1.speedcurve.com/video/compare.php?tests=171130_1J_740afc574b8073ba95af1e00cc1f3817-r:2-c:0"><img style="max-width: 679px;" src="https://speedcurve.com/img/blog/uxmetrics-pinkbars.png" alt="JS Pink Bars" width="100%" /></a></p> <p>This example illustrates how construction metrics can be misleading. The first script in the waterfall above is the smallest so many people might assume it would execute the fastest, but it actually takes the longest to execute. This insight into browser main thread activity isn't limited to JavaScript execution; WebPageTest also provides information about layout, paint, and loading. In order to help teams focus on CPU, SpeedCurve extracts this information from WebPageTest and shows it in our default <a title="CPU Charts" href="https://dev.speedcurve.com/speedcurve-enterprise/top-100/test/171130_1J_740afc574b8073ba95af1e00cc1f3817/?share=qb3kun47d1buotfo4994o9a4kifbbi#cpu">dashboards</a>.</p> <p style="text-align: center;"><a href="https://dev.speedcurve.com/speedcurve-enterprise/top-100/test/171130_1J_740afc574b8073ba95af1e00cc1f3817/?share=qb3kun47d1buotfo4994o9a4kifbbi"><img style="max-width: 582px;" src="https://speedcurve.com/img/blog/uxmetrics-cpu.png" alt="CPU Charts" width="100%" /></a></p> <p>However, this insight into browser main thread bottlenecks is limited to synthetic testing. It would be great if there was a CPU Timing specification so these metrics were also available in Real User Monitoring (<a title="RUM" href="http://support.speedcurve.com/testing-process/synthetic-vs-real-user-monitoring-rum">RUM</a>). The <a title="Long Tasks API" href="https://w3c.github.io/longtasks/">Long Tasks API</a>&nbsp;is new and could help address this gap.</p> <h4>Gap 2: Rendering</h4> <p>There are a number of rendering metrics available today, but there's a "gap" because of the lack of standardization and accuracy. Let's take a quick survey.</p> <p>WebPageTest is the pioneer in rendering metrics (and many many other parts of performance monitoring). Here's what it offers when it comes to rendering:</p> <ul> <li><strong><a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">Speed Index</a></strong> is "the average time at which visible parts of the page are displayed. It is expressed in milliseconds". Speed Index is not a specific point-in-time but instead is an aggregate stat so is a bit apples-to-oranges when compared to these other time-based metrics.</li> <li><strong><a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics">Start Render</a></strong> is "the time from the start of the initial navigation until the first non-white content is painted".</li> <li><strong><a href="https://github.com/WPO-Foundation/webpagetest/blob/master/docs/Metrics/TimeToInteractive.md">Time to First Interactive</a></strong>&nbsp;(aka, Time to CPU Idle) is "when the page is first expected to be usable and will respond to input quickly." Specifically, it is the first span of 5 seconds where the browser main thread is never blocked for more than 50ms after First Contentful Paint. Note that this is more than just a rendering metric as it also captures interactivity.</li> <li><strong><a href="https://github.com/WPO-Foundation/webpagetest/blob/master/docs/Metrics/TimeToInteractive.md">Time to Consistently Interactive</a></strong>&nbsp;(aka, Time to Interactive) is "when the page is first expected to be usable and will respond to input quickly." Specifically, it is the first span of 5 seconds where the browser main thread is never blocked for more than 50ms after First Contentful Paint with no more than 2 in-flight requests. Note that this is more than just a rendering metric as it also captures interactivity.</li> <li><strong><a href="https://sites.google.com/a/webpagetest.org/docs/advanced-features/raw-test-results">Visually Complete</a></strong> is the "first time when the visual progress reaches 100%".</li> </ul> <p>The new <a href="https://www.w3.org/TR/paint-timing/">Paint Timing</a> specification defines two new metrics. You can extract these values using <code>performance.getEntriesByType("paint")</code>:</p> <ul> <li><a href="https://www.w3.org/TR/paint-timing/#sec-terminology"><strong>First Paint</strong></a> is "the time when the browser first rendered after navigation. This excludes the default background paint, but includes non-default background paint."</li> <li><a href="https://www.w3.org/TR/paint-timing/#sec-terminology"><strong>First Contentful Paint</strong></a> is "when the browser first rendered any text, image (including background images), non-white canvas or SVG."</li> </ul> <p>To compensate for shortcomings in First Contentful Paint, Chrome's <a href="https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint">Lighthouse</a> project attempts to capture when primary content is rendered to the user. This metric can be <a href="https://docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view">found in Chrome traces</a>.&nbsp;</p> <ul> <li><a href="https://developers.google.com/web/tools/lighthouse/audits/first-meaningful-paint"><strong>First Meaningful Paint</strong></a> is "the paint after which the biggest above-the-fold layout change has happened, and web fonts have loaded." (More detail is available <a href="https://docs.google.com/document/d/1BR94tJdZLsin5poeet0XoTW60M0SjvOJQttKT-JK8HI/view">here</a>.)</li> </ul> <p>SpeedCurve also created a new metric that tries to capture when critical content is rendered to the page:</p> <ul> <li><a href="https://speedcurve.com/blog/web-performance-monitoring-hero-times/"><strong>Hero Rendering Times</strong></a> is a combination of when the largest IMG, H1, and background image in the viewport are rendered. The composite metric is computed by taking the maximum of the H1 time and the biggest IMG time (or biggest background image if biggest IMG doesn't exist): <code>max(h1, (biggest_img || bg_img))</code>.</li> </ul> <p>&nbsp;</p> <h3>Evaluating Rendering Metrics</h3> <p>In order to evaluate the different rendering metrics, we recorded WebPageTest <a href="http://lab.speedcurve.com/rendering/picker.php">filmstrips for the world's top ~100 websites</a>. To make the evaluation more interactive (and fun), we created the <a href="http://lab.speedcurve.com/rendering/picker.php">rendering metrics Picker page</a>. It shows the screenshot that corresponds to each metric, but the metric names are hidden until you choose the one that corresponds to what you consider to be a "good UX". It keeps track of which metrics you're most aligned with. (If you want to see all the metrics without clicking on each filmstrip, just scroll to the bottom and click "Show All".)</p> <p style="text-align: center;"><a href="https://speedcurve.com/img/blog/uxmetrics-picker5.png"><img style="max-width: 472px;" src="https://speedcurve.com/img/blog/uxmetrics-picker5.png" alt="" width="100%" /></a></p> <p>I wish I could say "X is the best rendering metric", but it really depends on what you're after. Hopefully you went through the exercise of <a href="http://lab.speedcurve.com/rendering/picker.php">picking which rendering metric best corresponds to what you feel is a "good UX"</a>. For your site, you might be most interested in getting any content to the page as quickly as possible (Start Render). Or maybe you're interested in getting a significant amount of content to the page (First Meaningful Paint, Speed Index). Perhaps you care most about when critical content appears in the page (Hero Rendering Times).&nbsp;</p> <p>Regardless of the question of which rendering matters the most to you, there are a few criteria to keep in mind when evaluating these metrics.&nbsp;</p> <p><em>Does every pixel have the same value?</em></p> <p style="padding-left: 30px;">It's important to focus on rendering when it comes to delivering a good user experience. At SpeedCurve, we feel it's more than just rendering pixels - it's really about <em>rendering the most important pixels</em>. Not every part of the page has the same value. There are certain design elements - the call-to-action, the hero image, etc. - that are more important. A good metric should be able to measure the most important pixels when it comes to rendering.</p> <p><em>Automatic or requires work?</em></p> <p style="padding-left: 30px;">One of the reasons why <code>window.onload</code> is still the most-used performance metric is that it exists in all browsers by default - the website owner doesn't have to do any work to generate this metric. On the other hand, User Timing lets teams track metrics that matter the most to them, but it requires writing, pushing, and maintaining code to generate these metrics - which is probably why only ~5% of the world's top 500K websites use it. All other things being equal, there's a preference for metrics that work automatically.</p> <p><em>Synthetic or RUM?</em></p> <p style="padding-left: 30px;">Performance metrics are gathered either synthetically or via Real User Monitoring. Ideally, the metric of choice supports both. (Note: If a technique can be gathered by RUM it's considered available to synthetic as well, since synthetic monitoring solutions generally have access to JavaScript.)</p> <p>The following table categorizes each metric into the appropriate quadrant:</p> <table id="quad" style="margin: auto; margin-bottom: 1em;"> <tbody> <tr> <th style="background: #888; border: 1px solid #888; font-weight: bold; color: #eee; padding: 1em 1em; text-align: center;">&nbsp;</th> <th style="background: #888; border: 1px solid #888; font-weight: bold; color: #eee; padding: 1em 1em; text-align: center;">Requires Work</th> <th style="background: #888; border: 1px solid #888; font-weight: bold; color: #eee; padding: 1em 1em; text-align: center;">Automatic</th> </tr> <tr> <th style="background: #888; border: 1px solid #888; font-weight: bold; color: #eee; padding: 1em 1em; text-align: center;"> <div>Measures</div> <div>important</div> <div>pixels</div> </th> <td style="padding: 1em 1em; border: 1px solid; text-align: left; vertical-align: top;">User Timing (both)<br />Hero Element Timing (both)</td> <td style="padding: 1em 1em; border: 1px solid; text-align: left; vertical-align: top;">Hero Rendering Times (syn)</td> </tr> <tr> <th style="background: #888; border: 1px solid #888; font-weight: bold; color: #eee; padding: 1em 1em; text-align: center;">All pixels<br />the same</th> <td style="padding: 1em 1em; border: 1px solid; text-align: left; vertical-align: top;">User Timing (both)</td> <td style="padding: 1em 1em; border: 1px solid; text-align: left; vertical-align: top;">Speed Index (syn)<br /> Start Render (syn)<br /> Time to First Interactive (syn)<br />Time to Consistently Interactive (syn)<br /> Visually Complete (syn)<br /> First Paint (both)<br /> First Contentful Paint (both)<br /> First Meaningful Paint (syn)</td> </tr> </tbody> </table> <p>We're pretty excited about Hero Rendering Times. It uses heuristics to estimate which content is critical (H1, hero image, and largest background image). It's available without the website owner having to do any extra work, which means it can also track competitor websites. And it scores well in the subjective results from <a href="http://lab.speedcurve.com/rendering/picker.php">"which metric best approximates a good UX"</a>. However, it's only available in synthetic monitoring.</p> <p>There isn't a good rendering metric available in RUM. There are only three choices right now: First Paint, First Contentful Paint, and User Timing. The results in our examples for First Paint and First Contentful Paint don't map well to actual screen content. This is probably due to the fact that Chrome doesn't know when the pixels actually get painted to the screen. For synthetic results we could round up to the next painted thumbnail, but it's not possible to make this adjustment for RUM. Perhaps website owners could always add an offset, but in our results the delta ranged from 100ms to 3 seconds.&nbsp;</p> <p>User Timing is the third alternative for RUM. The good thing about User Timing is it can be used to measure the rendering time for the critical content in the page, but this requires using <a href="https://speedcurve.com/blog/user-timing-and-custom-metrics/">special techniques</a> that are tricky at best. In addition, it's possible that the results suffer from a similar delta delay as we see with First Paint and First Contentful Paint. (This is an area for further research.)</p> <p><a href="https://docs.google.com/document/d/1sBM5lzDPws2mg1wRKiwM0TGFv9WqI6gEdF7vYhBYqUg/edit">Hero Element Timing</a> is a fourth candidate for RUM rendering metrics, but it's in the early proposal stages and not currently available in any browser. And again, it's likely that this metric would suffer from the same delta delay as the others discussed previously.</p> <h3>What's Next</h3> <p>There's work to do in rendering metrics for RUM. First Paint and First Contentful Paint don't necessarily correspond to a "good UX" (i.e., critical content). Hero Element Timing will be extremely useful for tracking critical content in RUM once browsers support it.&nbsp;</p> <p>The question of measuring "meaningful" content is an area for more research. In our experience with the <a href="http://lab.speedcurve.com/rendering/picker.php">Picker</a>, First Meaningful Paint often doesn't match the point where critical content is rendered. Hero Rendering Times does better at identifying when critical content hits the screen, but isn't without flaws. Its calculations are based on analyzing the filmstrip screenshot images. Rotating content and pop-ups are a challenge, as is transparent H1 elements that overlay hero images and background images. Identifying critical content without requiring website owners to modify their code is an exciting goal for future work.</p> <p>Further down the road it'd be great to get more CPU information for RUM possibly from the <a href="https://w3c.github.io/longtasks/">Long Tasks API</a>. This&nbsp;could help developers diagnose why their rendering metrics have changed, especially if timing information can be associated with individual scripts and stylesheets.&nbsp;</p> <p>In this blog post I focused on rendering metrics and haven't spent much time on the interactive metrics (Time to First Interactive and Time to&nbsp;Consistently&nbsp;Interactive). It's important that these interactivity metrics&nbsp;incorporate a rendering metric as a baseline. Currently, they rely on First Contentful Paint but other rendering metrics should also be considered, especially Hero Rendering Times since it's performed well in our studies.&nbsp;</p> Mon, 11 Dec 2017 00:00:00 +1300 By popular demand: Multiple Favorites dashboards! https://speedcurve.com/blog/multiple-favorites-dashboards <p>Rolling out new features is always a blast, and it's extra rewarding when the new feature is a response to a customer request. We've had&nbsp;many&nbsp;conversations with SpeedCurve users who've told us that&nbsp;multiple Favorite dashboards would be a huge benefit for their teams.&nbsp;</p> <p style="text-align: center;"><img style="max-width: 600px; width: 100%;" src="https://img.speedcurve.com/blog/favorites-chat.png?w=799&amp;auto=format,compress" sizes="(max-width: 600px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/favorites-chat.png?w=300&amp;auto=format,compress 300w, https://img.speedcurve.com/blog/favorites-chat.png?w=400&amp;auto=format,compress 400w, https://img.speedcurve.com/blog/favorites-chat.png?w=600&amp;auto=format,compress 600w, https://img.speedcurve.com/blog/favorites-chat.png?w=799&amp;auto=format,compress 799w" alt="Favorites Chat" /></p> <p>Today, we're very excited to announce that multiple Favorites dashboards are now available. Here's why you need them and how to create them.</p><h2>Who needs multiple Favorites dashboards?</h2> <p>The ability to create multiple Favorites dashboards is a huge boon <strong>for organizations that have many different teams and projects</strong> on the go at any given time. They're also helpful if you need to <strong>curate charts for different audiences</strong>.&nbsp;</p> <p>For example, if you need to do regular performance presentations at monthly management meetings, you can curate high-level charts in an "Executive Summary" dashboard. Each dashboard also allows you to generate a "share" URL &ndash; which can be sent to non-users as well &ndash; so you can also share individual dashboards via email or on a display monitor.</p> <p>Within your performance team, you can create specific dashboards for separate projects. For example, if you're using custom timers to track ads on your pages, you can create a dashboard called "Third Party Ads". And so on.&nbsp;</p> <p style="text-align: center;"><img style="max-width: 1200px; width: 100%;" src="https://img.speedcurve.com/blog/favorites-dashboards.png?w=1200&amp;auto=format,compress" sizes="(max-width: 1200px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/favorites-dashboards.png?w=300&amp;auto=format,compress 300w, https://img.speedcurve.com/blog/favorites-dashboards.png?w=400&amp;auto=format,compress 400w, https://img.speedcurve.com/blog/favorites-dashboards.png?w=600&amp;auto=format,compress 600w, https://img.speedcurve.com/blog/favorites-dashboards.png?w=1000&amp;auto=format,compress 1000w, https://img.speedcurve.com/blog/favorites-dashboards.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/favorites-dashboards.png?w=1800&amp;auto=format,compress 1800w" alt="Favorites Dashboards" /></p> <h2>Why you need custom charts</h2> <p>We think our curated charts, which are available by default with your SpeedCurve plan, are pretty great. We've put a lot of thought into creating visualizations that are as meaningful as possible.</p> <p>But you know your own business better than we do. By building custom charts, you can&nbsp;<strong>cherry pick the metrics and data that are most&nbsp;important to your business and track them over time</strong>.</p> <p>Custom charts let you do things like:</p> <ul> <li>Combine&nbsp;multiple metrics</li> <li>Combine synthetic&nbsp;and LUX (real user monitoring) data in one&nbsp;place</li> <li>Choose average, median, or 95th percentile</li> <li>Select multiple values for a filter (e.g., browser = Chrome or Firefox, country = UK or US)</li> <li>Compare A/B tests in a single chart</li> </ul> <h2>Getting started</h2> <p><strong>If you&rsquo;re already a SpeedCurve user:</strong>&nbsp;Creating multiple Favorites dashboards is easy! You can get started in minutes. Check out our short tutorial that walks you through the process for <a href="http://support.speedcurve.com/get-the-most-out-of-speedcurve/create-custom-dashboards-and-charts">creating custom dashboards and charts</a>.&nbsp;</p> <p><strong>If you&rsquo;re not a SpeedCurve user:&nbsp;</strong> <a href="https://speedcurve.com/plan/trial/">Sign up for your free trial</a>&nbsp;and start creating your own custom charts and dashboards.</p> <h2>How have custom performance charts helped you?&nbsp;</h2> <p>We'd love to&nbsp;know what kind of custom charts you've created, and how they've helped your performance team and your company. Let us know in the comments, or email us at support@speedcurve.com.</p> Thu, 02 Nov 2017 00:00:00 +1300 Engagement charts: See correlations between performance and user engagement https://speedcurve.com/blog/web-performance-monitoring-user-engagement <p>One of the best &ndash; and worst &ndash; things about real user monitoring is that it gives you unparalleled access to massive amounts of user data. The problem is when&nbsp;all this data leads to&nbsp;data indigestion. How do you know where to begin? And how do you know what to leave out in order to present a clear case for performance?</p> <p>At SpeedCurve, we care about more than just showing you all your data. We want to show you the <em>most important</em> data. And we want to make it easy for you to share that data with people throughout your organization. <strong>That&rsquo;s why we&rsquo;re excited about the newest addition to our family of visualizations: engagement&nbsp;charts.</strong>&nbsp;</p> <p style="text-align: center;"><img style="max-width: 1200px;" src="https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=1200&amp;auto=format,compress" sizes="(max-width: 1200px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=1250&amp;auto=format,compress 1250w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-01.png?w=1689&amp;auto=format,compress 1689w" alt="Load Time vs Bounce Rate" width="100%" /></p><h2>What are engagement charts?</h2> <p>Engagement charts&nbsp;&ndash; which are generated by the RUM data gathered by&nbsp;<a href="https://speedcurve.com/features/lux/">SpeedCurve LUX</a>&nbsp;&ndash; are the first&nbsp;member in our new family of <strong>correlation charts</strong>. (We'll be introducing new members of the family down the road, but for today, let's focus on engagement.)</p> <p>Engagement charts&nbsp;give you a histogram view of all your&nbsp;user&nbsp;traffic, broken out into cohorts based on start render and load time. You also get an overlay that shows you the bounce rate that correlates to each of these cohorts. This lets you see at a glance the relationship between page speed and user engagement. (Spoiler alert: The dominant trend is that as pages get slower, bounce rate gets worse.)</p> <p style="text-align: center;"><img style="max-width: 1200px;" src="https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=1200&amp;auto=format,compress" sizes="(max-width: 1200px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=1250&amp;auto=format,compress 1250w, https://img.speedcurve.com/blog/lux-load-time-vs-bounce-rate-02.png?w=1689&amp;auto=format,compress 1689w" alt="Load Time vs Bounce Rate" width="100%" /></p> <p><strong>&gt;&gt; Demo:</strong> <a href="https://speedcurve.com/webpagetest/lux-perf/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median">Interact with engagement charts in our live LUX demo account</a></p> <h2>Why you need them</h2> <p>Engagement charts&nbsp;are a great way to communicate about performance to a business audience. These visualizations let even the most non-technical stakeholder easily see the correlation between performance and user engagement. In my experience with talking about performance to a&nbsp;wide variety of audiences, graphs like this (which I&rsquo;ve manually created the old-fashioned way in the past) can be extremely effective in winning performance buy-in.&nbsp;</p> <p>But wait&hellip; there&rsquo;s more!&nbsp;</p> <h2>Spot&nbsp;performance-blocking trends&nbsp;</h2> <p>We&rsquo;ve created overlays that let you see the correlation between blocking JavaScript and CSS with your other metrics.</p> <p style="text-align: center;"><img style="max-width: 1200px;" src="https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=1200&amp;auto=format,compress" sizes="(max-width: 1200px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=1250&amp;auto=format,compress 1250w, https://img.speedcurve.com/blog/lux-start-render-vs-bounce-rate-02.png?w=1689&amp;auto=format,compress 1689w" alt="Load Time vs Bounce Rate" width="100%" /></p> <p>This lets you spot trends on your pages &ndash; for example, in the sample graph above, you can see that while there are fewer blocking resources on the faster pages, this number takes a sharp upturn starting with the cohort of pages that&nbsp;have a start render time&nbsp;of&nbsp;1.1&nbsp;seconds. If your goal is to deliver faster start render times to more users (and 1.1 seconds is a pretty good goal to shoot for), then this might trigger you to do an audit of your pages to analyze how your scripts and stylesheets are being executed.&nbsp;</p> <h2>Get started</h2> <p><strong>If you&rsquo;re already a SpeedCurve LUX user:</strong>&nbsp;Engagement charts are available by default at the top of your LUX Performance Dashboard. Use the arrow icon in the top right corner of the dashboard to easily share them with your team members and other folks in your organization.&nbsp;</p> <p><strong>If you're&nbsp;a SpeedCurve Synthetic user, but haven't tried LUX yet:</strong> Activating your LUX trial is easy: all you have to do is grab the LUX ID for your team (available in the Admin&gt;Teams panel), <a href="https://speedcurve.com/features/lux/#snippet">install the&nbsp;lux.js snippet on your site</a>, and let us know when it&rsquo;s live so that we can turn on your trial.</p> <p><strong>If you&rsquo;re not a&nbsp;SpeedCurve user: </strong>Explore engagement charts in our <a href="https://speedcurve.com/webpagetest/lux-perf/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median">live LUX demo account</a>, then&nbsp;<a href="https://speedcurve.com/plan/trial/">sign up for your free trial</a>&nbsp;and get these graphs for your own site.</p> <h2>How would you use engagement and correlation charts?</h2> <p>As always, we&rsquo;d love to hear your feedback and suggestions for iterating on these charts. Which metrics would you love to see by default, and why? Let us know in the comments, reply to our <a href="https://twitter.com/SpeedCurve/status/923657181513125888" target="_blank">Twitter announcement</a>, or send us a note at <a href="mailto:support@speedcurve.com">support@speedcurve.com</a>.</p> Thu, 26 Oct 2017 00:00:00 +1300 Keeping track of performance changes https://speedcurve.com/blog/web-performance-keeping-track-of-changes <p>Being able to track which changes have an impact &ndash; either positive or negative &ndash; on your site&rsquo;s performance is an important part of performance monitoring that can provide valuable feedback to your team. We wanted to make it easier to see at a glance all the changes to your site, without the cognitive overhead of interpreting charts. That&rsquo;s why we created the new Changes dashboard, which gives you a newsfeed-style overview of recent activity in your SpeedCurve account.</p> <p>Your Changes dashboard shows your&nbsp;<a href="https://speedcurve.com/blog/performance-budgets-in-action/">performance budget</a> alerts, deploys, site notes, and SpeedCurve product updates:</p> <p><img src="https://img.speedcurve.com/blog/changes-overview.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/changes-overview.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/changes-overview.png?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/changes-overview.png?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/changes-overview.png?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/changes-overview.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/changes-overview.png?w=1250&amp;auto=format,compress 1250w" alt="Changes dashboard (overview)" width="100%" /></p><p>The Changes dashboard is designed to be quickly scanned for changes that are relevant to you. Everything is ordered chronologically to make it easy to correlate changes, and each change can be expanded to reveal more detail.</p> <p><img src="https://img.speedcurve.com/blog/changes-expanded.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/changes-expanded.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/changes-expanded.png?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/changes-expanded.png?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/changes-expanded.png?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/changes-expanded.png?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/changes-expanded.png?w=1250&amp;auto=format,compress 1250w" alt="Changes dashboard (expanded view)" width="100%" /></p> <p>To save you the trouble of checking back for updates, we show a small notification in the navigation bar whenever there are any new changes for your sites:</p> <p style="text-align: center;"><img src="https://img.speedcurve.com/blog/changes-menu-notification.png?w=170&amp;auto=format,compress" alt="" width="170" height="210" /></p> <h2>Get started</h2> <p>The Changes dashboard is a great place to keep track of performance changes across your sites. If you're already a SpeedCurve user, you can start exploring this feature right away. If you're not yet a SpeedCurve user, sign up for your <a href="https://speedcurve.com/plan/trial/">free trial</a> and check it out.</p> Wed, 11 Oct 2017 00:00:00 +1300 A retailer's guide to web performance https://speedcurve.com/blog/retail-guide-web-performance <p>I&rsquo;m at Shop.org this week, having really interesting conversations with online retailers. What I love about talking with this crowd is that &ndash; like me &ndash; they're super&nbsp;focused on user-perceived performance. Not surprisingly, we have a lot to talk about.</p> <p>Making customers happy is the not-so-secret secret to retail success. Delivering a fast, consistent online experience has been proven&nbsp;to measurably increase every metric retailers care about &ndash; from conversions and revenue to retention and brand perception. (In fact, there's so much research in this area, I dedicated an entire chapter in <a href="https://tammyeverts.wordpress.com/2016/06/06/woohoo-my-book-is-out/" target="_blank">my book</a> to it. You can also find a number of great studies on <a href="https://wpostats.com/" target="_blank">WPO Stats</a>.)</p> <p>Delivering great, fast&nbsp;online experiences starts with asking two questions:</p> <ul> <li>What&rsquo;s making my pages seem slower <strong>for my users</strong>?</li> <li>What can I do about it?</li> </ul> <p>The good news is that most of the issues that are making pages slow for your shoppers are right on your pages, which means you have control over them. Here's an overview of the most common performance issues on retail sites, and how you can track them down and fix them.&nbsp;</p><h2><strong>What's making my pages seem slower?</strong></h2> <p>I&rsquo;ve analyzed hundreds (and possibly thousands) of retail web pages over the past several years. In my experience, the vast majority of performance issues are caused by four things:</p> <ul> <li>Third parties, such as trackers and analytics</li> <li>Stylesheets</li> <li>Custom fonts</li> <li>Page size, particularly image size</li> </ul> <h3><strong>Third parties&nbsp;</strong></h3> <p>A typical retail web page these days&nbsp;can contain upwards of 75 third-party scripts, such as trackers and analytics beacons. Third parties add tons of value by increasing conversions (via targeting beacons) and helping you understand your users in unprecedented ways (via analytics tags), so they&rsquo;re not going away any time soon. But as pretty much everyone knows by now, they can really affect how your page renders.&nbsp;</p> <h4><strong>What you can do: Monitor the speed of your third parties</strong></h4> <p>Start by&nbsp;taking a proactive approach to understanding&nbsp;any potential performance damage your third parties can&nbsp;cause. You can't fix what you're not measuring, which is why we built a <a href="https://speedcurve.com/features/synthetic/#thirdparty">third-party waterfall chart</a> into SpeedCurve, so you can see at a glance how your third parties are performing.&nbsp;</p> <p style="text-align: center;"><img style="width: 100%; max-width: 1000px;" src="https://img.speedcurve.com/blog/retail_1.png?w=1226&amp;auto=format" sizes="(max-width: 1000px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/retail_1.png?w=613auto=format 613w, https://img.speedcurve.com/blog/retail_1.png?w=1226&amp;auto=format 1226w" alt="" /></p> <p><strong>Read &gt;</strong> <a href="https://speedcurve.com/blog/ux-focus-for-waterfalls-and-third-parties/">UX focus for third parties</a></p> <p><strong>Case study &gt;</strong> <a href="https://www.youtube.com/watch?v=LHlmJIjhzoM#t=23m29s" target="_blank">Marks &amp; Spencer revolutionized performance by focusing on third party content</a>&nbsp;</p> <p><strong>Live demo account &gt;</strong> <a href="https://speedcurve.com/demo/thirdparty/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">SpeedCurve Third Party Dashboard</a></p> <h3><strong>Stylesheets</strong></h3> <p>Stylesheets are an incredible boon for modern webpages. They solve a myriad of design problems, from browser compatibility to design maintenance and updating. Without stylesheets, we wouldn&rsquo;t have great things like responsive design. However, poorly executed stylesheets can create a host of performance problems. These range from CSS&nbsp;that takes too long to download and parse, to improperly placed stylesheets&nbsp;that blocks the rest of the page from rendering.&nbsp;</p> <h4><strong>What you can do: Know which of your stylesheets can block your pages from rendering&nbsp;</strong></h4> <p>Again, you can't fix what you don't measure. We've made it easy for you to find out if your pages have critical blocking resources, such as CSS and JavaScript. This chart is available on your <a href="https://speedcurve.com/demo/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">Site dashboard</a> and lets you quickly spot any issues.</p> <p style="text-align: center;"><img style="width: 100%; max-width: 1000px;" src="https://img.speedcurve.com/blog/retail_2.png?w=1030&amp;auto=format" sizes="(max-width: 1000px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/retail_2.png?w=515auto=format 515w, https://img.speedcurve.com/blog/retail_2.png?w=1030&amp;auto=format 1030w" alt="" /></p> <p style="text-align: left;"><strong>Read &gt;</strong> <a href="https://speedcurve.com/blog/measuring-blocking-resources/">Measuring blocking resources</a>&nbsp;</p> <p style="text-align: left;"><strong>Live demo account &gt;</strong> <a href="https://speedcurve.com/demo/site/?b=apple-ipad&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">SpeedCurve Site Dashboard</a></p> <h3><strong>Custom fonts</strong></h3> <p>Custom fonts allow designers unprecedented control over the typefaces used in their designs. This desire for control accounts for the surge in popularity for custom fonts. In 2010, only 1% of the top 1,000 websites used custom fonts. Today, that number has grown to 65%.</p> <p>This popularity comes with a performance price tag. Some fonts require huge amounts of CSS code, while others have heavy JavaScript or are hosted externally  &ndash;  all of which can dramatically slow down page rendering.</p> <h4><strong>What you can do: Track how quickly your fonts&nbsp;render</strong></h4> <p>SpeedCurve&rsquo;s new Hero Rendering Times are a set of metrics that measure when a page's most important content finishes rendering in the browser. H1 Render is one of these metrics. (I'll be talking about the other metrics later in this post.) It measures when your first H1 element finishes rendering. If a site uses custom fonts, it's quite likely that those fonts will be applied to H1 copy, which makes this metric a great way to measure how quickly your custom fonts are rendering.&nbsp;</p> <p style="text-align: center;"><img style="width: 100%; max-width: 350px;" src="https://img.speedcurve.com/blog/retail_3.png?w=479&amp;auto=format" sizes="(max-width: 350px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/retail_3.png?w=239auto=format 239w, https://img.speedcurve.com/blog/retail_3.png?w=479&amp;auto=format 479w" alt="" /></p> <p><strong>Read &gt;</strong> <a href="https://speedcurve.com/blog/web-performance-monitoring-hero-times/">Hero Rendering Times: New metrics for measuring UX</a></p> <p><strong>Case study &gt;</strong> <a href="https://medium.com/@francis.john/web-font-optimization-at-nerdwallet-6a447be9b570" target="_blank">NerdWallet used the H1 Render metric to help improve font loading by up to 30%</a></p> <p><strong>Live demo account &gt;</strong>&nbsp;<a href="https://speedcurve.com/demo/site/?b=apple-ipad&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">SpeedCurve Site Dashboard</a></p> <h3><strong>Images and page size</strong></h3> <p>I&rsquo;ve written about page bloat a lot over the years (most recently in this post). While page size doesn&rsquo;t always correlate to a slower user experience, it often does. Huge unoptimized images are a frequent culprit. I&rsquo;ve seen retail pages that contained hero images that were up to 5MB in size. That&rsquo;s a lot of bytes, folks.</p> <h4><strong>What you can do: Create&nbsp;performance budgets&nbsp;</strong></h4> <p><a href="https://speedcurve.com/features/synthetic/#budgets">Performance budgets</a> are a great way to manage page bloat. A performance budget starts with your team (everybody: marketing, designers and developers) agreeing on the principles around the user experience and how fast your website should feel.</p> <p>You define a budget for each metric, such as the total size of your JavaScript, how many images should be on the page, and how quickly the page should start rendering. Once you define your budget, SpeedCurve starts monitoring and alerts you if the target budget is exceeded.</p> <p style="text-align: center;"><img style="width: 100%; max-width: 1000px;" src="https://img.speedcurve.com/blog/retail_4.png?w=1000&amp;auto=format" sizes="(max-width: 1000px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/retail_4.png?w=500&amp;auto=format 500w, https://img.speedcurve.com/blog/retail_4.png?w=1000&amp;auto=format 1000w, https://img.speedcurve.com/blog/retail_4.png?w=2000&amp;auto=format 2000w" alt="" /></p> <p><strong>Read &gt;</strong> <a href="https://speedcurve.com/blog/performance-budgets-in-action/">Performance budgets in action</a></p> <p><strong>Case study &gt;</strong> <a href="https://www.zillow.com/engineering/bigger-faster-more-engaging-budget/">How Zillow became bigger, faster, and more engaging while on a budget</a></p> <p><strong>Live demo account &gt;</strong>&nbsp;<a href="https://speedcurve.com/demo/site/?b=apple-ipad&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">SpeedCurve Site Dashboard</a></p> <h4><strong>What you can do (part deux): Track the speed of your hero images</strong></h4> <p>We&rsquo;ve also made it easy for you to see at a glance how quickly your hero images render. For example, the Largest Image Render metric identifies when the largest image in the viewport finishes rendering. This metric is especially relevant to retail sites, where hero images on home, product, and campaign landing pages are critical elements.&nbsp;</p> <p style="text-align: center;"><img style="width: 100%; max-width: 500px;" src="https://img.speedcurve.com/blog/retail_5.png?w=500&amp;auto=format" sizes="(max-width: 500px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/retail_5.png?w=500&amp;auto=format 500w, https://img.speedcurve.com/blog/retail_5.png?w=917&amp;auto=format 917w" alt="" /></p> <p><strong>Read &gt;</strong> <a href="https://speedcurve.com/blog/web-performance-monitoring-hero-times/">Hero Rendering Times: New metrics for measuring UX</a></p> <p><strong>Live demo account &gt;</strong>&nbsp;<a href="https://speedcurve.com/demo/site/?b=apple-ipad&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">SpeedCurve Site Dashboard</a></p> <h2><strong>Get started</strong></h2> <p>Delivering fast, joyous experiences to online shoppers has never been as important as it is now. If you're already a SpeedCurve user, you can take advantage of the many ways to make your site feel faster for your users. If you're not already a SpeedCurve user, <strong><a href="https://speedcurve.com/demo/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">explore our live demo account</a></strong>,&nbsp;<a href="https://speedcurve.com/plan/trial/"><strong>sign up for your free trial</strong></a> so you can explore these features and get to know your site better &ndash; the way your users see it.</p> Thu, 28 Sep 2017 00:00:00 +1300 Woohoo! I'm helping build SpeedCurve https://speedcurve.com/blog/woohoo-helping-build-speedcurve <p>I&rsquo;m super excited to be able to say that I&rsquo;ve joined Mark, Steve, and Tammy at SpeedCurve!</p> <p>I&rsquo;ve watched how Mark has shown over the last couple of years that performance monitoring doesn&rsquo;t have to be dry and data-heavy; it can be insightful, interactive, and actionable. I&rsquo;ve also been a follower of Steve&rsquo;s work for many years. In fact, I should probably thank Steve for providing me with the knowledge that got me interested in web performance in the first place! Tammy&rsquo;s work has been really interesting to follow, too - her focus on real people and how web performance impacts the way they use our websites is something that resonates strongly with me.</p> <p style="margin-bottom: 0px;"><img src="https://img.speedcurve.com/blog/joseph-bbc.jpg?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/joseph-bbc.jpg?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/joseph-bbc.jpg?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/joseph-bbc.jpg?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/joseph-bbc.jpg?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/joseph-bbc.jpg?w=1200&amp;auto=format,compress 1200w, https://img.speedcurve.com/blog/joseph-bbc.jpg?w=1900&amp;auto=format,compress 1900w" alt="Joseph Wynn" width="100%" /></p> <p style="font-size: 12px; text-align: center;">Joseph making BBC News way faster for all users.</p><p>For the last 3 years I worked at BBC News as a Principal Software Engineer. The BBC News website is accessed by 10 million people every day - people from all around the world using every conceivable device on all sorts of network connections. I always felt that it was important to understand whether or not all of those people were having a good experience when they visited our website.</p> <p>I got a glimpse of what sort of experiences people were having every time I went travelling. In rural Scotland, BBC News pages would take up to a minute to load. When I visited Morocco the connection would time out before I saw any content. In New Zealand the pages would initially load quickly but then the content would jump around while adverts were being loaded. But this was all anecdotal and I had no way to back it up empirically.</p> <p>We trialled several performance monitoring tools at the BBC, but I was always frustrated that they were unable to give a simple answer to questions like: How fast are our pages? Are they getting faster or slower? What should we work on next to improve performance? When I was introduced to SpeedCurve, this all changed. The important data is presented in a way that&rsquo;s easy to understand and -more importantly- easy to communicate to non-technical stakeholders.</p> <p>I&rsquo;ve always believed that <a href="https://www.youtube.com/watch?v=nE4LTRfcr94">performance is not a technical problem</a> - that the hardest part of making a website fast is educating other people about the impact that performance has on users and on the business. That&rsquo;s why I&rsquo;m really excited to help build what I think is the best tool available for doing that.</p> Tue, 12 Sep 2017 00:00:00 +1200 Waterfall with browser events https://speedcurve.com/blog/waterfall-with-browser-events <p>We've improved our already fantastic interactive waterfall chart with a new collapsed mode that highlights all the key browser events. This lets you quickly scan all the events that happen as the page loads and if you scrub your mouse across the waterfall you can easily correlate each event to what the user could see at that moment.</p> <p>Along with all the browser metrics you also get to see our new <a href="https://speedcurve.com/blog/web-performance-monitoring-hero-times/">hero rendering times</a> in context. Click on any event to see a large version of that moment in the filmstrip.</p> <p><video autoplay="autoplay" loop="loop" width="100%"><source src="https://cdn.speedcurve.com/img/blog/waterfall-mini.mp4" type="video/mp4" /></video></p><p>If you want to dig into the detail of the network requests and how they relate to the browser events, just click "Expand" or on the background of the waterfall chart.</p> <p>We've now made it even easier to correlate network requests, browser events and browser main thread with what the user is actually seeing as the page loads. All your web performance debugging goodness in one powerful interactive tool!</p> <p>If you're already a SpeedCurve user, you can start exploring this feature right away. If you're not yet a SpeedCurve user, sign up for your <a href="https://speedcurve.com/plan/trial/">free trial</a> and check it out.</p> Fri, 08 Sep 2017 00:00:00 +1200 Hero Rendering Times: New metrics for measuring UX https://speedcurve.com/blog/web-performance-monitoring-hero-times <p>The key to a good user experience is quickly delivering the content your visitors care about the most. This is easy to say, but tricky to do. Every site has&nbsp;unique content and user engagement goals, which is why measuring how fast critical content renders has historically been a challenging task.</p> <p><strong>That's why we're very excited to introduce Hero Rendering Times, a set of new metrics for measuring the user experience. </strong>Hero Times measure when a page's most important content finishes rendering in the browser. These metrics are available right now to SpeedCurve users.&nbsp;</p> <p><a href="https://speedcurve.com/speedcurve-enterprise/top-sites/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=20637&amp;u=41165&amp;share=0cv2ymz1ymyhv8b0hwbuvsz1a480u3" target="_blank"><img style="width: 100%; max-width: 1200px;" src="https://img.speedcurve.com/blog/hero-main.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/hero-main.png?w=250&amp;auto=format,compress 200w, https://img.speedcurve.com/blog/hero-main.png?w=533&amp;auto=format,compress 533w, https://img.speedcurve.com/blog/hero-main.png?w=772&amp;auto=format,compress 772w, https://img.speedcurve.com/blog/hero-main.png?w=959&amp;auto=format,compress 959w, https://img.speedcurve.com/blog/hero-main.png?w=1169&amp;auto=format,compress 1169w, https://img.speedcurve.com/blog/hero-main.png?w=1328&amp;auto=format,compress 1328w, https://img.speedcurve.com/blog/hero-main.png?w=1464&amp;auto=format,compress 1464w, https://img.speedcurve.com/blog/hero-main.png?w=1639&amp;auto=format,compress 1639w, https://img.speedcurve.com/blog/hero-main.png?w=1788&amp;auto=format,compress 1788w, https://img.speedcurve.com/blog/hero-main.png?w=1926&amp;auto=format,compress 1926w, https://img.speedcurve.com/blog/hero-main.png?w=2069&amp;auto=format,compress 2069w, https://img.speedcurve.com/blog/hero-main.png?w=2199&amp;auto=format,compress 2199w, https://img.speedcurve.com/blog/hero-main.png?w=2400&amp;auto=format,compress 2400w" alt="Hero Rendering Times" /></a></p> <p>More on how Hero Rendering Times work further down in this post. But first, I want to give a bit of back story that explains how we got to here.</p><h2>A brief history of UX metrics</h2> <p><strong>In the beginning, there was load time.</strong> But then we realized that there was too much stuff on pages (e.g., third parties, outside-the-viewport content) that resulted in long load times, and these <a href="https://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/">long load times didn't actually reflect how fast pages felt to users</a>.</p> <p><strong>Start render is better than load time</strong>, because it measures when content starts to render &ndash; and when users can ostensibly begin to interact with the page. The other advantage is that it can be used in synthetic, so it's a good-enough way to compare the UX of your site to your competitors. But start render isn't ideal, because it only measures the <em>beginning</em> of content rendering, not when users can actually engage meaningfully with the page.</p> <p><strong>Then Speed Index came along.</strong> This metric, which is measured in <a href="https://www.webpagetest.org/">WebPageTest</a>, identifies when the visible parts of a page are displayed. This was a huge evolutionary leap in that it represented the first time any tool attempted to tackle the issue of measuring what users actually see. <a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index#TOC-Measuring-Visual-Progress">Speed Index is based on measuring when visual content (e.g., images and video) render within the viewport.</a></p> <p>We like Speed Index (which is why <a href="https://speedcurve.com/blog/measuring-the-user-experience/">we've included it in SpeedCurve</a>), but because it's dependent on how the page is built, it's not a one-size-fits-all metric. For example, I recently spoke with a customer who was getting confusing Speed Index results for mobile. It turned out that&nbsp;the reason why their Speed Index was fast &ndash; despite the fact that their viewport was almost empty &ndash; was because most of their "above the fold" content was not image-based.</p> <p><strong>Recently, metrics like Time to Interact (TTI) and Time to First Meaningful&nbsp;Paint (TTFMP) have gotten a lot of attention.</strong> But TTI doesn't consistently and accurately measure user experience. And while TTFMP&nbsp;&ndash; which is available through the new <a href="https://blog.chromium.org/2017/06/chrome-60-beta-paint-timing-api-css.html">Paint Timing API</a> &ndash; does illustrate when content becomes visible in the browser, its weakness is that, like Start Render and Speed Index, it gives equal value to every pixel. In other words, it doesn't discriminate between useful and non-useful content. (This is a hugely fascinating topic for discussion, which is why I'll be talking more about these metrics in an upcoming post.)</p> <p><strong><a href="https://speedcurve.com/blog/user-timing-and-custom-metrics/">Custom metrics are a great solution</a></strong>&nbsp;(and they remain the best solution for real user monitoring), but they require additional dev time and expertise, which might be why only 14% of sites use them.</p> <h2>We need better metrics for measuring user&nbsp;experience</h2> <p>Given the constraints and limitations of existing metrics, we realized we need a solution that:</p> <ul> <li>Correlates to what users actually see in the browser.</li> <li>Recognizes that not all pixels and page elements are equal, from a user's&nbsp;perspective.</li> <li>Allows us to customize what we measure on specific pages.</li> <li>Is easy to use and accessible right out of the box.</li> </ul> <h2>Introducing&nbsp;Hero Rendering Times</h2> <p>Here's the great news: You don't have to do anything at all to get started! <strong>If you're a SpeedCurve user, these&nbsp;core Hero Rendering Times are already sitting in your Sites&nbsp;dashboard.</strong> If you're not a SpeedCurve user, click on each of the images below to check out these metrics in our live demo dashboards.&nbsp;</p> <h3><strong>Largest Image&nbsp;Render&nbsp;</strong></h3> <p>Just as its name suggests, Largest Image&nbsp;Render identifies when the largest image in the viewport finishes rendering. This metric&nbsp;is especially relevant to retail sites, where images on home, product, and campaign landing pages are critical elements.</p> <p><a href="https://speedcurve.com/speedcurve-enterprise/top-sites/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=38668&amp;u=73840&amp;share=0cv2ymz1ymyhv8b0hwbuvsz1a480u3" target="_blank"><img style="width: 100%; max-width: 1200px;" src="https://img.speedcurve.com/blog/hero-image.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/hero-image.png?w=250&amp;auto=format,compress 200w, https://img.speedcurve.com/blog/hero-image.png?w=533&amp;auto=format,compress 533w, https://img.speedcurve.com/blog/hero-image.png?w=772&amp;auto=format,compress 772w, https://img.speedcurve.com/blog/hero-image.png?w=959&amp;auto=format,compress 959w, https://img.speedcurve.com/blog/hero-image.png?w=1169&amp;auto=format,compress 1169w, https://img.speedcurve.com/blog/hero-image.png?w=1328&amp;auto=format,compress 1328w, https://img.speedcurve.com/blog/hero-image.png?w=1464&amp;auto=format,compress 1464w, https://img.speedcurve.com/blog/hero-image.png?w=1639&amp;auto=format,compress 1639w, https://img.speedcurve.com/blog/hero-image.png?w=1788&amp;auto=format,compress 1788w, https://img.speedcurve.com/blog/hero-image.png?w=1926&amp;auto=format,compress 1926w, https://img.speedcurve.com/blog/hero-image.png?w=2069&amp;auto=format,compress 2069w, https://img.speedcurve.com/blog/hero-image.png?w=2199&amp;auto=format,compress 2199w, https://img.speedcurve.com/blog/hero-image.png?w=2400&amp;auto=format,compress 2400w" alt="Largest Image Rendering Time" /></a></p> <h3><strong>H1 Render</strong>&nbsp;</h3> <p>H1 Render measures when your first H1 element finishes rendering. This metric is especially useful&nbsp;to media and informational sites. Because the&nbsp;H1 tag is usually wrapped around header copy, there's a reasonable assumption that this is copy you want your users to see quickly.</p> <p><strong>&gt;&gt; Case study:</strong> <a href="https://medium.com/@francis.john/web-font-optimization-at-nerdwallet-6a447be9b570">How NerdWallet used H1 Render Time to help improve font loading by up to 30%</a></p> <p><a href="https://speedcurve.com/demo/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906&amp;share=39tfnozeq94p1o0hndk1kpbg4vb7cg" target="_blank"><img style="width: 100%; max-width: 1200px;" src="https://img.speedcurve.com/blog/hero-h1.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/hero-h1.png?w=250&amp;auto=format,compress 200w, https://img.speedcurve.com/blog/hero-h1.png?w=533&amp;auto=format,compress 533w, https://img.speedcurve.com/blog/hero-h1.png?w=772&amp;auto=format,compress 772w, https://img.speedcurve.com/blog/hero-h1.png?w=959&amp;auto=format,compress 959w, https://img.speedcurve.com/blog/hero-h1.png?w=1169&amp;auto=format,compress 1169w, https://img.speedcurve.com/blog/hero-h1.png?w=1328&amp;auto=format,compress 1328w, https://img.speedcurve.com/blog/hero-h1.png?w=1464&amp;auto=format,compress 1464w, https://img.speedcurve.com/blog/hero-h1.png?w=1639&amp;auto=format,compress 1639w, https://img.speedcurve.com/blog/hero-h1.png?w=1788&amp;auto=format,compress 1788w, https://img.speedcurve.com/blog/hero-h1.png?w=1926&amp;auto=format,compress 1926w, https://img.speedcurve.com/blog/hero-h1.png?w=2069&amp;auto=format,compress 2069w, https://img.speedcurve.com/blog/hero-h1.png?w=2199&amp;auto=format,compress 2199w, https://img.speedcurve.com/blog/hero-h1.png?w=2400&amp;auto=format,compress 2400w" alt="H1 Rendering Time" /></a></p> <h3><strong>Largest Background Image Render</strong></h3> <p>For some pages, the background image is just as &ndash; or more &ndash; important than the largest image. We created this metric&nbsp;to ensure that you're not missing out.&nbsp;</p> <p><a href="https://speedcurve.com/speedcurve-enterprise/top-sites/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=20751&amp;u=41458&amp;share=0cv2ymz1ymyhv8b0hwbuvsz1a480u3" target="_blank"><img style="width: 100%; max-width: 1200px;" src="https://img.speedcurve.com/blog/hero-background.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/hero-background.png?w=250&amp;auto=format,compress 200w, https://img.speedcurve.com/blog/hero-background.png?w=533&amp;auto=format,compress 533w, https://img.speedcurve.com/blog/hero-background.png?w=772&amp;auto=format,compress 772w, https://img.speedcurve.com/blog/hero-background.png?w=959&amp;auto=format,compress 959w, https://img.speedcurve.com/blog/hero-background.png?w=1169&amp;auto=format,compress 1169w, https://img.speedcurve.com/blog/hero-background.png?w=1328&amp;auto=format,compress 1328w, https://img.speedcurve.com/blog/hero-background.png?w=1464&amp;auto=format,compress 1464w, https://img.speedcurve.com/blog/hero-background.png?w=1639&amp;auto=format,compress 1639w, https://img.speedcurve.com/blog/hero-background.png?w=1788&amp;auto=format,compress 1788w, https://img.speedcurve.com/blog/hero-background.png?w=1926&amp;auto=format,compress 1926w, https://img.speedcurve.com/blog/hero-background.png?w=2069&amp;auto=format,compress 2069w, https://img.speedcurve.com/blog/hero-background.png?w=2199&amp;auto=format,compress 2199w, https://img.speedcurve.com/blog/hero-background.png?w=2400&amp;auto=format,compress 2400w" alt="Largest Background Image Rendering Time" /></a></p> <p>These core hero metrics&nbsp;are a great start, and they're now available by default in SpeedCurve.&nbsp;We've also created one more Hero Rendering Time that requires a bit more work on your end, but which will allow you to fine-tune your monitoring...</p> <h3><strong>Hero Element Timing</strong></h3> <p>Default metrics are important to have &ndash; not least because they're based on universal page elements, which means&nbsp;you can use them to <a href="http://support.speedcurve.com/videos/benchmark-yourself-against-your-competitors">compare your site to your competitors</a>. But chances are you want to get a more nuanced look at hero elements that are unique to your site, your pages, and your users. This is where Hero Element Timing comes in.&nbsp;</p> <p>Hero Element Timing &ndash; which is based on the&nbsp;<a href="https://docs.google.com/document/d/1yRYfYR1DnHtgwC4HRR04ipVVhT1h5gkI6yPmKCgJkyQ/edit?usp=sharing">Hero Element Timing API&nbsp;</a>&ndash; lets you select and annotate specific hero elements on your pages, such as search boxes, image carousels, and blocks of text.</p> <p>Right now, if you're a SpeedCurve user, you can&nbsp;<a href="https://docs.google.com/document/d/1yRYfYR1DnHtgwC4HRR04ipVVhT1h5gkI6yPmKCgJkyQ/edit?usp=sharing">follow the instructions in the API spec to annotate your pages</a>, and see the results in your SpeedCurve results. (As a bonus, when browsers inevitably catch up and adopt the spec, you'll be ahead of the game.)</p> <p><a href="https://speedcurve.com/speedcurve-enterprise/top-sites/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=40207&amp;u=75705&amp;share=0cv2ymz1ymyhv8b0hwbuvsz1a480u3" target="_blank"><img style="width: 100%; max-width: 1200px;" src="https://img.speedcurve.com/blog/hero-element.png?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/hero-element.png?w=250&amp;auto=format,compress 200w, https://img.speedcurve.com/blog/hero-element.png?w=533&amp;auto=format,compress 533w, https://img.speedcurve.com/blog/hero-element.png?w=772&amp;auto=format,compress 772w, https://img.speedcurve.com/blog/hero-element.png?w=959&amp;auto=format,compress 959w, https://img.speedcurve.com/blog/hero-element.png?w=1169&amp;auto=format,compress 1169w, https://img.speedcurve.com/blog/hero-element.png?w=1328&amp;auto=format,compress 1328w, https://img.speedcurve.com/blog/hero-element.png?w=1464&amp;auto=format,compress 1464w, https://img.speedcurve.com/blog/hero-element.png?w=1639&amp;auto=format,compress 1639w, https://img.speedcurve.com/blog/hero-element.png?w=1788&amp;auto=format,compress 1788w, https://img.speedcurve.com/blog/hero-element.png?w=1926&amp;auto=format,compress 1926w, https://img.speedcurve.com/blog/hero-element.png?w=2069&amp;auto=format,compress 2069w, https://img.speedcurve.com/blog/hero-element.png?w=2199&amp;auto=format,compress 2199w, https://img.speedcurve.com/blog/hero-element.png?w=2400&amp;auto=format,compress 2400w" alt="Hero Element Rendering Time" /></a></p> <h2>Get started</h2> <p>That's it! Login to your SpeedCurve account to check out your core Hero Rendering Times and start exploring Hero Element Timing. If you're not already using SpeedCurve, <a href="https://speedcurve.com/plan/trial/"><strong>sign up for a free trial</strong></a>.</p> <p>If you have any questions or feedback about Hero Rendering Times, we'd love to hear them.</p> Tue, 22 Aug 2017 00:00:00 +1200 The average web page is 3MB. How much should we care? https://speedcurve.com/blog/web-performance-page-bloat <p>A couple of month ago, someone asked if I'd written a page bloat update recently. The answer was no. I've written a lot of&nbsp;posts about page bloat, starting&nbsp;way back in 2012, when the average page hit 1MB. To my mind, the topic had been well covered. We know that the general trend is that pages are getting bigger at a fairly consistent rate of growth. It didn't feel like there was much new territory to cover.</p> <p>Also: it felt like Ilya Grigorik dropped the mic on the page bloat conversation with&nbsp;<a href="https://www.igvita.com/2016/01/12/the-average-page-is-a-myth/">this awesome post</a>, where he illustrated why&nbsp;the "average page" is a myth. Among the many things Ilya observed after&nbsp;analyzing <a href="http://httparchive.org/" target="_blank" rel="noopener">HTTP Archive</a> data for desktop sites, when you have outliers that weigh in at 30MB+ and&nbsp;more than 90% of your pages are under 5MB, an "average page size" of 2227KB (back in 2016) doesn't mean much.</p> <p>The mic dropped. We all stared at it on the floor for a while, then wandered away. And now I want to propose we wander back. Why? Because the average page is now 3MB in size, and this seems like a good time to pause, check our assumptions, and ask ourselves:</p> <p><strong>Is there any reason to care about page size as a performance metric? And if we don't consider page size a meaningful metric, then what should we care about?</strong></p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-1-2011-vs-2017.png" alt="Web performance: page bloat" width="100%" /></strong></p><h2>Before we wade into this topic (again), some big important caveats</h2> <ul> <li><strong>The averages we're about to look at, which are taken from the HTTP Archive, are just that &ndash; averages of large datasets.</strong> They don't represent the "typical" website, because there's no such thing as a typical website.</li> <li><strong>These numbers are mainly relevant when viewed in a historical context.</strong> They represent trends &ndash; that's all.</li> <li><strong>These numbers should not <em>in any way</em> even remotely 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.</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> <h2>Graphs or it didn't happen, right?</h2> <p>Here you can see page growth from 2011 to now, broken out by content type:</p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-2-2011-to-2017.png" alt="Web performance: page bloat" width="100%" /></strong></p> <p>The first thing that jumps out is the <strong>large amount of page real estate being taken up by video</strong>. Not a huge surprise, given the popularity of hero videos and such, but still interesting to note that this seems to account for much of the recent growth.</p> <p><strong>Custom font use continues to increase</strong>: 69% of the top 500,000 websites use them. Interesting to note the dip that took place, in terms of total KB, in 2016.</p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-4-fonts.png" alt="Web performance: page bloat" width="100%" /></strong></p> <p>It's interesting to graph some of the current HTTP Archive data (below) and see which metrics remain flat relative to page size and which ones don't.</p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-si-sr-ol.png" alt="Web performance: page bloat" width="100%" /></strong></p> <p>You can see above that <strong>start render is fairly consistent regardless of page size</strong>. This is quite interesting, because it suggests that bigger pages don't necessarily correlate to when users start being able to see content.</p> <p>Also, you can also see how easy it is to be <a href="https://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/" target="_blank">misled by onload</a> as a performance metric, because it correlates so strongly with page size. In this graph, the steep rise of onload slightly hides the fact that Speed Index trends upward quite significantly &ndash; from 2393 (~2.4 seconds) for pages in the 500KB cohort to 10266 (~10.3 seconds) for pages in the 20MB cohort. This serves as a good reminder that <strong>Speed Index is generally a solid synthetic metric for user experience</strong>.</p> <h2>Prediction: 4MB pages by 2019?</h2> <p>I'm putting this out there as an interesting talking point, not as a cause for panic. Assuming a roughly 16% year-over-year increase in page size, the average page could exceed 4MB in just over two years.</p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-5-prediction-2019.png" alt="Web performance: page bloat" width="100%" /></strong></p> <p>But again, going back to Ilya's point, this is just an average. 4MB pages are already here. According to the HTTP Archive, <strong>almost 16% of pages today &ndash; in other words, about 1 out of 6 pages &ndash; are 4 MB or greater in size</strong>. I routinely see pages (and I'm sure you do, too) that are 10MB or larger. When I was talking about this issue with <a href="https://twitter.com/MarkZeman">Mark</a> and <a href="https://twitter.com/Souders">Steve</a>, Mark referred to the fact that <a href="http://support.speedcurve.com/videos/conference-presentations/delivering-fast-and-rich-web-user-experiences">he's built pages that were 30MB that were still highly performant</a>.</p> <h2>If you care about user experience, page size isn't the right metric to track</h2> <p><a href="https://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/">Metrics like page size and load time typically are not good indicators of user-perceived performance.</a></p> <p>Take Amazon, for example. It's widely considered to be a performance leader, yet it has relatively heavy pages (I'm defining "heavy" as 3MB or more) and slow load times (I'm defining "slow" as 5 seconds or more). But for Amazon, page size and load time are the wrong metrics to look at.</p> <p>For example, looking at this recent test result page for the Amazon home page (which weighs in at just over 5MB), you can see a start render time of 1.4 seconds and a well-populated viewport at 2.5 seconds &ndash; despite the fact that the page doesn't fully load till 18.8 seconds.</p> <p><strong><img style="max-width: 900px;" src="https://cdn.speedcurve.com/img/blog/page-bloat-amazon2.png" alt="Web performance: page bloat" width="100%" /></strong></p> <p>(If you're not already a SpeedCurve user and you want to noodle around with the SpeedCurve synthetic monitoring dashboard, <a href="https://speedcurve.com/demo/site/?b=chrome&amp;d=30&amp;de=1&amp;ds=1&amp;r=us-west-1&amp;s=299&amp;u=906">check out our demo account</a>, which lets you explore data for a handful of media sites, including The Guardian, Huffington Post, and The New York Times. <strong>Even better, <a href="https://speedcurve.com/plan/trial/" target="_blank">sign up for a free trial</a> and take SpeedCurve out for a spin.</strong>)</p> <h2>Takeaways</h2> <h3>1. Page size matters, but perhaps not in the way you think</h3> <p>You can have large, robust pages that still feel fast. But you should care about page bloat in terms of how it affects mobile users, especially mobile-only users who are dealing with bandwidth constraints or data limits. At <a href="https://conferences.oreilly.com/fluent/fl-ca">Fluent</a> this past June, Tim Kadlec delivered a passionate <a href="https://www.youtube.com/watch?v=61MuwOtZBOE" target="_blank" rel="noopener">keynote</a> that addressed this issue. You should also check out Tim's nifty <a href="https://whatdoesmysitecost.com/" target="_blank" rel="noopener">online calculator</a>, which calculates the cost, in dollars, of your pages in countries around the world. It's an eye-opener.</p> <p><strong>What you can do:</strong> If you're not actively using performance budgets to set thresholds for metrics like page size, start render, and Speed Index, you should start.&nbsp;<a href="http://support.speedcurve.com/videos/performance-budgets-custom-metrics" target="_blank" rel="noopener">I love this short explainer video that explains how performance budgets work</a>.</p> <h3>2. Worry about images, but not too much</h3> <p>Yes, images make up the bulk of the average page, and you should definitely make sure you're not serving huge unoptimized images to your users. But this is one of those low-hanging fruit that's relatively easily addressable.</p> <p><strong>What you can do:</strong> <a href="https://speedcurve.com/blog/find-and-fix-what-matters-most/">Find and fix problem images on your pages</a>.</p> <h3>3. Worry more about CSS and JavaScript</h3> <p>If you're serving asynchronous versions of your stylesheets and scripts, you need to know that these have the potential to block your pages altogether, because they're major CPU hogs.</p> <p><strong>What you can do: </strong>Asynchronous scripts are better than synchronous, <a href="https://calendar.perfplanet.com/2016/prefer-defer-over-async/" target="_blank" rel="noopener">but there's an argument for deferring scripts (if you can wrangle it)</a>. And if you're not already measuring CPU usage,&nbsp;<a href="https://speedcurve.com/blog/track-down-front-end-cpu-hogs/">you should consider starting now.</a></p> <h3>4. If you care about measuring user experience, then use custom metrics</h3> <p>Correlating page size with user experience is like presenting someone with an entire buffet dinner and assuming that it represents what they actually ate. To properly measure user experience, we need to focus on the content &ndash; such as the navbar or hero product image &ndash; that users actually want to consume. The best performance metric for measuring user experience is one that measures how long the user waits before seeing this critical content.</p> <p><strong>What you can do:</strong> This is where custom timers, via the <a href="https://www.w3.org/TR/user-timing/">W3C User Timing spec</a>, come in. To implement custom timers, you need to identify the critical content on your pages, then add marks and measures to track when they render. Steve wrote <a href="https://speedcurve.com/blog/user-timing-and-custom-metrics/">a great blog post</a> that goes into custom timers in more detail, as well as providing a handful of sample metrics to get you started. If you care about measuring UX, I strongly recommend checking it out.</p> <h2>To sum up...</h2> <p>At SpeedCurve, we don't think you need more performance data. <strong>We think you need the right performance data.</strong> That's why we're always working to develop metrics that give you meaningful insight into how your users experience your site. And it's why we believe setting performance budgets and alerts for those metrics is crucial. (If you're not already using SpeedCurve to monitor your site's performance, <a href="https://speedcurve.com/plan/trial/"><strong>set up your free trial here</strong></a>.)</p> <p>The key to a good user experience is quickly delivering the critical content. This is easy to say, but historically has been tricky to do. Custom metrics are a huge evolutionary step forward. If you're using custom metrics, I'd love to hear how they're working for you and what you're learning from them. And if you're not using custom metrics, I'm curious to learn what the barriers are for you.</p> Wed, 09 Aug 2017 00:00:00 +1200 Find and fix what matters most https://speedcurve.com/blog/find-and-fix-what-matters-most <p>Being able to monitor and measure the performance of your pages is crucial. You know that already. You also know that the next step is to quickly find out what&rsquo;s hurting your pages so you can stop the pain.</p> <p>You want to know:</p> <ul> <li>Which performance rules is my page breaking?</li> <li>How do I prioritize my optimization efforts?</li> <li>How can I communicate this quickly and clearly to my team?</li> </ul> <p>We&rsquo;re super excited to announce that you can now use <a href="https://speedcurve.com/features/synthetic/">SpeedCurve</a> to answer these questions.</p> <p><img src="https://img.speedcurve.com/blog/perf-recommendations.png?w=919&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/perf-recommendations.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/perf-recommendations.png?w=526&amp;auto=format,compress 526w, https://img.speedcurve.com/blog/perf-recommendations.png?w=742&amp;auto=format,compress 742w, https://img.speedcurve.com/blog/perf-recommendations.png?w=919&amp;auto=format,compress 919w, https://img.speedcurve.com/blog/perf-recommendations.png?w=1854&amp;auto=format,compress 1854w" alt="Performance Recommendations" width="100%" /></p><p>Inspired by the great work done by Google&rsquo;s PageSpeed Insights team, we developed our own curated list of performance rules. We took the rules that are most relevant to developers in the real world, then augmented them with data that&rsquo;s unique to SpeedCurve &ndash; such as <a href="https://speedcurve.com/blog/measuring-blocking-resources/">critical blocking JavaScript and CSS.</a>&nbsp;And we packaged it with an intuitive UI that makes it easier for you to share your test results with your team, as well as other non-technical teams throughout your organization.</p> <h2>Get started</h2> <p>To get to your page-level diagnostics, go to your test timeline and open up any test results page. Scroll down, and voila. At a glance, you can see our curated list of performance rules, stacked and color-coded in their order of importance for this particular page. (We define &ldquo;importance&rdquo; as &ldquo;the total amount of positive impact that optimizing for this rule would have on performance&rdquo;.)</p> <p><img src="https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=919&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=526&amp;auto=format,compress 526w, https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=742&amp;auto=format,compress 742w, https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=919&amp;auto=format,compress 919w, https://img.speedcurve.com/blog/perf-recommendations-blocking.png?w=1852&amp;auto=format,compress 1852w" alt="Performance Recommendations Blocking" width="100%" /></p> <p>You can then expand any of these rules and see a list of specific assets that are causing trouble &ndash; again, listed in order of importance.</p> <p>And here&rsquo;s a feature I really love: When you look at your list of images that need optimization, you actually see thumbnails of each one, as well as a calculation of how much further each image can be optimized. This is a fantastic, fast, effective way to communicate to other teams in your organization, such as marketing and sales.</p> <p><img src="https://img.speedcurve.com/blog/perf-recommendations-images.png?w=919&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/perf-recommendations-images.png?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/perf-recommendations-images.png?w=526&amp;auto=format,compress 526w, https://img.speedcurve.com/blog/perf-recommendations-images.png?w=742&amp;auto=format,compress 742w, https://img.speedcurve.com/blog/perf-recommendations-images.png?w=919&amp;auto=format,compress 919w, https://img.speedcurve.com/blog/perf-recommendations-images.png?w=1852&amp;auto=format,compress 1743w" alt="Performance Recommendations Images" width="100%" /></p> <p>At SpeedCurve, we know you don&rsquo;t have infinite amounts of developer hours to optimize your pages. We want to help you focus on what matters. This new feature is just the beginning.</p> Thu, 22 Jun 2017 00:00:00 +1200 I've joined SpeedCurve! Here's why https://speedcurve.com/blog/tammy-everts-has-joined-speedcurve <h2 style="padding-top: 0px;">TL;DR</h2> <p>If Mark and Steve invited you to work with them, what would you say? Exactly.</p> <h2>Long version</h2> <p>Okay, I have to elaborate a bit more about why I&rsquo;m ridiculously excited about working with Mark and Steve. My first foray into the performance space was at the Velocity Conference in 2009. If you had told me then that someday I&rsquo;d be working with that tall guy rocking the main stage, I would&rsquo;ve thanked you for the kind words&hellip; while secretly thinking you were nuts. But here I am!</p> <p style="margin-bottom: 0px;"><img src="https://img.speedcurve.com/blog/tammy-conf.jpg?w=1200&amp;auto=format,compress" sizes="(max-width: 768px) 100vw, 60vw" srcset=" https://img.speedcurve.com/blog/tammy-conf.jpg?w=250&amp;auto=format,compress 250w, https://img.speedcurve.com/blog/tammy-conf.jpg?w=682&amp;auto=format,compress 682w, https://img.speedcurve.com/blog/tammy-conf.jpg?w=972&amp;auto=format,compress 972w, https://img.speedcurve.com/blog/tammy-conf.jpg?w=1188&amp;auto=format,compress 1188w, https://img.speedcurve.com/blog/tammy-conf.jpg?w=1200&amp;auto=format,compress 1200w" alt="Tammy at International Women's Day Tech Talks in Toronto" width="100%" /></p> <p style="font-size: 12px; text-align: center;">Tammy at <a href="http://iwd.devto.ca/">International Women's Day Tech Talks</a> in Toronto</p><p>And the first time I saw Mark's <a href="https://chrome.google.com/webstore/detail/perfmap/hgpnhiajcdppfbogcpfdgcceepgkhdmk" target="_blank" rel="noopener noreferrer">awesome Perfmap plugin</a>, I knew that it was created by someone who thinks about performance and usability the same way I do... and someone I needed to get to know.</p> <p>Saying yes to working with Mark and Steve was a no-brainer, of course. Here's why I'm excited not just about working with these guys, but also about working at SpeedCurve.</p> <p>I spent the past two decades studying how people use the web. As already mentioned, for the past eight years I focused on how web performance intersects with user experience and business metrics. I&rsquo;ve done everything from studying massive data sets of billions of user experiences to far-out neuroscientific lab studies involving EEG headsets. I even wrote <a href="http://shop.oreilly.com/product/0636920041450.do" target="_blank" rel="noopener noreferrer">a book</a> about it.</p> <p>I tend to think of my work as answering three different questions:</p> <ul> <li>How do people use the web?</li> <li>How do site owners want to understand how people use the web?</li> <li>How can we build better and better tools that let site owners understand their visitors in ways that are most meaningful to them and their business?</li> </ul> <p>As Chief Experience Officer at SpeedCurve, I get to answer all three of those questions in new and exciting ways. I&rsquo;ll be marrying two aspects of experience that go together like PB&amp;J:</p> <p><strong>User experience, as measured and monitored by our synthetic and <a href="https://speedcurve.com/features/lux/">RUM</a> tools.</strong> I&rsquo;ve said this countless times: <em>Every company is different. Every site is different. Every visitor is different. Every visit is different.</em> I never stop being curious about these differences, and there are always new metrics to create and new things to learn. I love SpeedCurve&rsquo;s tools and I&rsquo;m thrilled to have the opportunity to use them every day.</p> <p><strong>Customer experience, in terms of how our customers use our tools.</strong> I&rsquo;ll be working closely with our customers to understand the specific ways they use SpeedCurve to understand their visitors. I&rsquo;ll use that understanding to help make our tools &ndash; and our own customers&rsquo; experience &ndash; even better. Full disclosure: While I&rsquo;ve been involved in a lot of conversations with customers in the past, it&rsquo;s never been part of my official job description. I&rsquo;m super excited about this aspect of my new role!</p> <p>The best tools are driven by listening to what people want. I&rsquo;m a good listener. <a href="mailto:support@speedcurve.com">Hit me up.</a></p> Mon, 15 May 2017 00:00:00 +1200 A/B Testing JSONP and the Preloader with RUM https://speedcurve.com/blog/ab-testing-jsonp-and-the-preloader-with-rum <p>SpeedCurve is a SPA (Single Page App) so we construct the charts dynamically using <a href="https://en.wikipedia.org/wiki/JSONP">JSONP</a>. It works great, but we're always looking for ways to make the dashboards faster. One downside to&nbsp;making requests dynamically is that the browser <a href="https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/">preloader</a> isn't used. This isn't a factor for later&nbsp;SPA requests, but on the first page view the preloader might still bring some benefits. Or maybe not. We weren't sure, so we ran an A/B test. Long story short, doing the first JSONP request via markup caused charts to render 300 milliseconds faster.&nbsp;</p> <p><img style="width: 100%;" src="https://speedcurve.com/img/blog/jsonpmarkup.png" alt="A/B Test Results" /></p><p>It's easy to run&nbsp;this A/B test using our RUM product,&nbsp;<a href="https://speedcurve.com/features/lux/">LUX</a>. The first step is&nbsp;to add a&nbsp;<a href="https://www.w3.org/TR/user-timing/">User Timing</a>&nbsp;metric that marks when the JSONP response is received. We call this metric OnDataReceived.&nbsp;<a href="http://caniuse.com/#feat=user-timing">Some popular browsers don't support User Timing</a>, so we use LUX's shim for mark() and measure() since it works in all browsers:</p> <pre> function OnDataReceived(jsondata) { LUX.measure("OnDataReceived"); ...</pre> <p>The code above measures the time from <a href="https://www.w3.org/TR/navigation-timing/#dom-performancetiming-navigationstart">NavigationStart</a> to when the JSONP response is processed. All User Timing marks and measures are automatically captured by LUX and displayed in customers' dashboards.</p> <p>The next step is to split users across two buckets. In the control bucket we continue to fetch the JSONP dynamically. In the test bucket we use&nbsp;markup to make the JSONP request. We use LUX's <a href="https://speedcurve.com/features/lux/#addData">addData API</a>&nbsp;to segment&nbsp;the RUM data across these buckets. The control bucket has JsonpMarkup=no, while the test bucket has JsonpMarkup=yes. Here's the backend PHP snippet:</p> <pre> if ( rand(0,1) ) { echo "&lt;script&gt;onGo();&lt;/script&gt;\n"; // request JSONP dynamically echo "&lt;script&gt;LUX.addData('JsonpMarkup', 'no');&lt;/script&gt;\n"; } else { echo "&lt;script src='/site-data?jsonp=OnDataReceived'&gt;&lt;/script&gt;\n"; echo "&lt;script&gt;LUX.addData('JsonpMarkup', 'yes');&lt;/script&gt;\n"; } </pre> <p>Within a few minutes the data shows that OnDataReceived is ~300 milliseconds faster for the JsonpMarkup=yes bucket. We let the A/B test run a few days to confirm that using markup for the initial JSONP request is faster thanks to the browser preloader.</p> <p>If you make requests dynamically using JavaScript, you might be missing a performance opportunity by letting the preloader do its work. This isn't just true for JSONP requests, it also applies to images. If you're curious about this optimization, run an A/B test to&nbsp;see if making initial requests using markup makes your site faster and your users happier. We'd be happy to set you up with a <a href="https://speedcurve.com/features/lux/#snippet">LUX free trial</a>&nbsp;to make it easy&nbsp;peasy (lemon squeezy).</p> Tue, 02 May 2017 00:00:00 +1200 Improved Favorites https://speedcurve.com/blog/improved-favorites <p>We've improved the&nbsp;"Favorites" dashboard which now lets you build your own charts which:</p> <ul style="margin-bottom: 25px;"> <li style="margin-bottom: 5px;">Combine synthetic tests and <a href="https://speedcurve.com/features/lux/">LUX (real user monitoring)</a> in one chart.</li> <li style="margin-bottom: 5px;">Choose average, median, or 95th percentile.</li> <li style="margin-bottom: 5px;">Create charts that have multiple metrics.</li> <li style="margin-bottom: 5px;">Select multiple values for a filter, eg, browser = Chrome or Firefox, country = UK or US.</li> <li style="margin-bottom: 5px;">Compare A/B tests in a single chart.</li> </ul> <p>Here's a walkthrough showing you some of the new features:</p> <script charset="ISO-8859-1" src="https://fast.wistia.com/assets/external/E-v1.js"></script> <div class="wistia_embed wistia_async_zemnmyfu9k videoFoam=true" style="width: 540px; height: 304px; margin-bottom: 25px;">&nbsp;</div><p>We've also improved the performance and user experience of the Favorites charts. There are a lot more filter options and each chart loads individually getting charts to you faster.</p> <p>We'd love your feedback. Let us know what else you'd like to see added to the Favorites dashboard. Here's a few of the things we're considering&nbsp;adding like filmstrips and histograms.</p> Tue, 18 Apr 2017 00:00:00 +1200 Measuring Blocking Resources https://speedcurve.com/blog/measuring-blocking-resources <p>SpeedCurve reports the number of critical blocking resources in the page. These are the resources that block rendering. Since it's important that users see your content as quickly as possible, it's important to know what might be causing your page to render slowly. We recently enhanced the way we measure blocking resources and wanted to share those improvements with our customers as well as the performance community at large.&nbsp;</p> <p>The main culprits that block rendering are scripts and stylesheets that are loaded synchronously. A great way to avoid this blocking problem is to load your scripts and stylesheets asynchronously. You can do that for scripts by using the <a href="https://www.w3.org/TR/html5/scripting-1.html#attr-script-async">async</a> and <a href="https://www.w3.org/TR/html5/scripting-1.html#attr-script-defer">defer</a> attributes, plus other <a href="https://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/">programmatic techniques</a>. Loading stylesheets asynchronously is less popular but is still possible using techniques like <a href="https://github.com/filamentgroup/loadCSS">loadCSS</a>.&nbsp;</p><p>We recently improved how blocking stylesheets are measured. The first change is&nbsp;to ignore stylesheets loaded via loadCSS; these are asynchronous and thus don't block rendering. Similarly, we ignore stylesheets that are initially loaded with <a href="https://www.smashingmagazine.com/2016/02/preload-what-is-it-good-for/#markup-based-async-loader">link-rel-preload</a>&nbsp;and later added to the DOM dynamically.&nbsp;Finally, we ignore stylesheets with a "print" media type. If your site uses any of these techniques, then your "Blocking CSS" SpeedCurve metric&nbsp;will decrease.</p> <p>We also improved how blocking scripts are measured. But before diving into that, I need to explain a subtle difference in how scripts and stylesheets block rendering. Synchronous stylesheets block the entire DOM from rendering. Synchronous scripts, however, only block the elements that follow the SCRIPT tag in the DOM tree. This is illustrated in the figure below where scripts that block rendering are shown in red. Async and defer scripts are always green (non-blocking) no matter where they occur in the DOM. Synchronous scripts, however, block rendering if they occur in the HEAD or in the BODY above any DOM elements that are in the viewport. If synchronous scripts&nbsp;occur below the visible DOM, then they don't block rendering.&nbsp;</p> <p style="text-align: center;"><img style="width: 100%; min-width: 250px; max-width: 549px;" src="https://cdn.speedcurve.com/img/blog/blocking.png" alt="Blocking Scripts" /></p> <p>This leads to an important optimization in how to measure blocking JS. If a page has a synchronous script at the bottom of the page (below all the visible DOM elements), then it does <em>not</em> block rendering (because all the visible DOM elements precede the SCRIPT tag).</p> <p>In order to accurately measure blocking scripts, SpeedCurve does more than just track whether scripts are sync or async. We also determine if the script blocks rendering. We do this by determining if the synchronous script occurs before any of the DOM elements in the viewport. If a script is loaded synchronously and occurs before any DOM elements in the viewport, then we count it as "blocking JS". If it occurs after all the viewport's DOM elements, then it is not counted as blocking (even if it's loaded synchronously).</p> <p>This change may&nbsp;decrease your "Blocking JS" SpeedCurve metric if you have synchronous scripts in the body of the page. It did for us! In the SpeedCurve.com dashboards, all the charts are loaded via synchronous scripts, but all those synchronous scripts are below the visible DOM. So our Blocking JS metric dropped from 4 to 0! This helps us focus on the resources that are most important for improving rendering.</p> <p><img style="display: block; margin-left: auto; margin-right: auto;" src="https://cdn.speedcurve.com/img/blog/blocking-js.png" alt="Blocking JS Chart" width="572" height="375" /></p> <p>Measuring blocking resources&nbsp;is difficult to do, but it's one of the most important metrics to track if you want to optimize your Start Render time. We're glad we have both of these metrics. We're also glad this code is behind us. Phew!</p> Thu, 02 Feb 2017 00:00:00 +1300 SpeedCurve RUM: LUX https://speedcurve.com/blog/speedcurve-rum-lux <p>We're excited to announce SpeedCurve's RUM product, <a href="https://speedcurve.com/features/lux/">LUX</a>.</p> <p>The name LUX is a play on "<span style="text-decoration: underline;"><strong>L</strong></span>ive <span style="text-decoration: underline;"><strong>U</strong></span>ser e<span style="text-decoration: underline;"><strong>X</strong></span>perience" and reflects how we've taken a different approach compared to other Real User Monitoring products. SpeedCurve's mission is to help designers and developers create joyous, fast user experiences. To do that, we focus on metrics that do a better job of revealing what the user's experience is really like.&nbsp;</p> <p>In addition to standard RUM metrics like page load time and total size, LUX includes innovative new metrics that have more to do with the user experience like start render time, number of critical blocking resources, images above the fold, and viewport size.&nbsp;LUX's RUM metrics help you figure out which design and development improvements&nbsp;will make your users happier and&nbsp;your business more successful.</p><p>Now that SpeedCurve has both synthetic monitoring and RUM, we can mash those up to give better insights. For example, we compare your synthetic metrics to&nbsp;RUM so&nbsp;you understand how your synthetic performance will translate when&nbsp;staged code is pushed to production. Also, we give you feedback on which URLs, browsers, and geo locations are popular from RUM to help you improve your synthetic test settings to better approximate the real user experience.</p> <p>You can see SpeedCurve RUM&nbsp;in action by viewing the&nbsp;<a href="https://speedcurve.com/webpagetest/lux-users/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX demo account</a>. The data comes from <a href="https://www.webpagetest.org/">webpagetest.org</a> where Pat Meenan agreed to inject the LUX snippet. There are four LUX dashboards: <a href="https://speedcurve.com/webpagetest/lux-live/?ld=1&amp;share=uga4v95goqtuwzip0h1yus236zp92f">Live</a>, <a href="https://speedcurve.com/webpagetest/lux-users/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">Users</a>, <a href="https://speedcurve.com/webpagetest/lux-perf/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">Performance</a>, and <a href="https://speedcurve.com/webpagetest/lux-design/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">Design</a>.</p> <p>The&nbsp;<a href="https://speedcurve.com/webpagetest/lux-live/?ld=1&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX Live</a>&nbsp;dashboard constantly updates to show the users currently&nbsp;visiting your site.</p> <p><img style="width: 100%;" src="https://speedcurve.com/img/lux-live.png" alt="LUX Live" /></p> <p>You can hover over a row to highlight all visits for that user's session. Clicking on a row shows the details for that user's visit including Navigation Timing, User Timing, user interaction, and page design metrics.</p> <p><img style="width: 100%; border: 2px solid #000;" src="https://speedcurve.com/img/lux-page-details.png" alt="LUX Page Details" /></p> <p>The&nbsp;<a href="https://speedcurve.com/webpagetest/lux-users/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX Users</a>&nbsp;dashboard shows information about your users including page views broken out by type of user interaction. It also shows the top pages,&nbsp;browsers, viewports, cities, and countries across all your users.</p> <p><img style="width: 100%;" src="https://speedcurve.com/img/lux-users-pvs.png" alt="Page Views" /></p> <p><a href="https://speedcurve.com/webpagetest/lux-perf/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX Performance</a>&nbsp;shows the core performance metrics like backend vs frontend time (where everyone should start), User Timing custom metrics (if you have any), and time to first user interaction (often the best reflection of the user's experience). It also contains a great example of mashing up RUM and synthetic for start render and page load time.</p> <p><img style="width: 100%;" src="https://speedcurve.com/img/lux-perf-syn.png" alt="LUX and Synthetic" /></p> <p>The&nbsp;<a href="https://speedcurve.com/webpagetest/lux-design/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX Design</a>&nbsp;dashboard has most of our innovative views of how performance and design impact the user experience. If your start render time is slow, it's good to see how many critical blocking stylesheets and scripts are being served to real users, especially if you have third party tags. Comparing the number of images above-the-fold with the total number of images indicates whether you should be lazy loading images outside of the initial viewport. Similarly, comparing viewport size to document size indicates if you have other content that you should lazy load. LUX also shows the most popular DOM elements that&nbsp;users interact with.</p> <p><img style="width: 100%;" src="https://speedcurve.com/img/lux-design-critical.png" alt="Critical Blocking Resources" /></p> <p>We also make it easy to slice-and-dice the data. Expanding the Dropdown reveals various dimensions that can be used to segment the data. You can choose from the top values that are shown, or enter a value. Wildcards are supported. You can also click on any of the lists of values in the dashboards to filter on that value.</p> <p style="text-align: center;"><img style="width: 100%; border: 2px solid #000; max-width: 689px;" src="https://speedcurve.com/img/lux-dropdown.png" alt="LUX Dropdown" /></p> <p>Take LUX for a test drive&nbsp;by going to&nbsp;the&nbsp;<a href="https://speedcurve.com/webpagetest/lux-users/?ld=1&amp;lde=1&amp;lds=1&amp;stat=median&amp;share=uga4v95goqtuwzip0h1yus236zp92f">LUX demo account</a>. More information, including an FAQ and API, can be found on the <a href="https://speedcurve.com/features/lux/">LUX features</a> page.&nbsp;</p> <p>If you'd like to signup for LUX, head over to our <a href="https://speedcurve.com/pricing/">pricing page</a> and fill out the signup form. We look forward to helping you create fast, joyous experiences for your users.&nbsp;</p> Tue, 01 Nov 2016 00:00:00 +1300 Build your own charts https://speedcurve.com/blog/build-your-own-charts <p>We put a lot of thought into curating a thematic set of dashboards that help you understand the performance of your front-end, but sometimes you just want to play with the data yourself and slice 'n' dice the data in all sorts of different ways. We've added a new "Favorites" dashboard that lets you do just that. You can explore the data and build your own charts, then rearrange them and share them with the team to help demonstrate the performance issues you're focused on right now.</p> <p>Here's a walkthrough showing you how to slice the available data in different ways:</p> <script charset="ISO-8859-1" src="https://fast.wistia.com/assets/external/E-v1.js"></script> <div class="wistia_embed wistia_async_breilivn0j videoFoam=true" style="width: 540px; height: 304px; margin-bottom: 25px;">&nbsp;</div><p>We'd love your feedback. Let us know what else you'd like to see added to the Favorites dashboard. Here's a few of things we're considering&nbsp;adding:</p> <ul> <li>Select multiple metrics on the same chart</li> <li>Choose median rather than average along with support for percentiles</li> <li>Custom metrics</li> <li>Click through to an individual test for each data point</li> <li>Filmstrips</li> <li>Histograms</li> </ul> Mon, 10 Oct 2016 00:00:00 +1300 Track down front-end CPU hogs https://speedcurve.com/blog/track-down-front-end-cpu-hogs <p>Often when monitoring and debugging site performance we focus on network activity and individual resources, but what about the CPU? As more and more sites switch to using large Javascript frameworks and manipulating the page using Javascript, the execution time this code takes and the available CPU can instead become the performance bottleneck.</p> <h2>CPU usage for all Chrome tests</h2> <p>For any of SpeedCurve's&nbsp;Chrome-based tests, including emulated devices, we capture the Chrome Dev Tools timeline. From the browser main thread usage in the timeline we extract how busy the CPU is and what it's spending time on. Is it busy executing Javascript functions or busy laying out elements and painting&nbsp;pixels?</p> <p>We also measure the CPU usage to different key events&nbsp;in the rendering of the page. SpeedCurve's focus is on the user experience and getting content in front of people as fast as possible, so we show you what the CPU is doing up till the&nbsp;page starts to render. This reflects CPU usage during the browser critical rendering path and can highlight various issues. If there's lots of CPU idle time then you're not delivering your resources efficiently. You want to get the CPU busy nice and early rendering the page, rather than sitting idle waiting for slow resources.</p> <p>In the test&nbsp;below we see in the first pie chart that the CPU is spending a lot of time on layout up to the start render event, which is quite a different picture from the Fully Loaded CPU usage. &nbsp;</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/cpu_pie.png" alt="CPU pie charts" /></p><h2>CPU trends and budgets</h2> <p>We've also added trending charts for the CPU time to both the Start Render and Fully Loaded browser events. This allows you to spot any significant changes over time and can highlight both CSS and Javascript changes&nbsp;which are causing CPU issues. In the example below we see a dramatic change in the Layout CPU time for this URL. The browser was being tied up by dodgy Javascript which was causing a huge amount of layout thrashing and reflows. Once fixed the Layout time drops dramatically.</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/cpu_start_render.png" alt="CPU to Start Render" /></p> <p>We also support performance budgets for all the CPU metrics allowing you to get email and Slack alerts whenever a threshold is crossed. It's going to be interesting to see what sort of budgets teams put on script execution and layout. Not only can you monitor the size and number of Javascript or CSS scripts but&nbsp;you can ensure it's well written code that's not thrashing the CPU.</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/cpu_layout_budget.png" alt="CPU layout budgets" /></p> <h2>Chrome Dev Tools timeline goodness</h2> <p>It's amazing how much performance data is packed into the Chrome Dev Tools timeline and for every single Chrome based test on SpeedCurve we capture the timeline. You can click through to an online timeline viewer at the bottom of the SpeedCurve waterfall chart.</p> <p>Here's the timeline for the URL above which had a layout thrashing issue, highlighted by the dark red bar between 2-4s. It's amazing to have this level of debugging for every test!</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/cpu_chrome_timeline.png" alt="Chrome Dev Tools Timeline" /></p> <h2>Test agent CPU</h2> <p>It's worth noting that the test agents we currently run at SpeedCurve are fairly low spec and so don't have oodles of available CPU. We do this to help emulate lower spec mobile devices. Over the last year we've seen CPU usage grow and some URLs with a lot of heavy Javascript and CSS are now maxing out the CPUs on our test agents. Although it's fascinating to see well constructed sites (I'm looking at you <a href="https://speedcurve.com/demo/site/?b=chrome&amp;d=30&amp;r=us-west-1&amp;s=302&amp;u=917&amp;share=39tfnozeq94p1o0hndk1kpbg4vb7cg" target="_blank">Smashing</a>) not have this issue at all, with plenty of CPU idle time available as the page renders.</p> <blockquote> <p>We all need to add CPU usage to our front-end performance toolkits!</p> </blockquote> <p>We're thinking about introducing new agents with higher CPU specs so that you can test on both a lower spec CPU that represents an emulated device and a high CPU agent that better represents a desktop browser. Sing out in the comments if this is something you're interested in or you've discovered something interesting in your CPU usage charts.</p> <p>If you're not already using SpeedCurve to monitor your site's performance and track your own CPU hogs,&nbsp;<a href="https://speedcurve.com/plan/trial/"><strong>set up your free trial here</strong></a>.</p> Thu, 22 Sep 2016 00:00:00 +1200 SpeedCurve Waterfall https://speedcurve.com/blog/speedcurve-waterfall <p>If you're a performance engineer, then you're familiar with waterfall charts. They are found in browser dev tools as well as other performance services. I use multiple waterfall tools&nbsp;every day, but the waterfall chart&nbsp;I love the most is the one we've built at SpeedCurve:</p> <p style="text-align: center;"><img style="width: 100%; min-width: 300px; max-width: 712px; border: 1px solid;" src="https://cdn.speedcurve.com/img/blog/sc-waterfall-startrender.png" alt="SpeedCurve waterfall" /></p><p>We've added a number of great features to our waterfall chart. In&nbsp;the screenshot above we see the&nbsp;vertical lines we've added to show Backend, Start Render, and Onload. My favorite feature is the thumbnail "scrubber" at the bottom of the waterfall. As you move your mouse horizontally through the timeline, the scrubber shows the thumbnail that corresponds to that point in time. This makes it easier to correlate the rendering experience with what's happening in the network.</p> <p>For example, in the waterfall above we see that Start Render occurs at 5208 milliseconds. It's a good thing that we can see the thumbnail at that point in time because the only thing being&nbsp;rendered is a spinner! To find out when the actual page content is displayed, we move the mouse forward in time while watching the scrubber. Eventually we see that the actual content on the page appears at 9139 milliseconds, as shown below. By correlating this thumbnail with the network requests we can track down the cause for this four second delay, most likely the late arrival of a JSON payload containing the search results.</p> <p style="text-align: center;"><img style="width: 100%; min-width: 300px; max-width: 712px; border: 1px solid;" src="https://cdn.speedcurve.com/img/blog/sc-waterfall-content2.png" alt="SpeedCurve content waterfall" /></p> <p>By default we color the network requests to reflect the Content-Type: scripts are orange, images are purple, etc. We also provide options that allow you to use colors that reflect&nbsp;the connection state: DNS lookup (aqua), TCP connection (orange), SSL negotiation (purple), Time-to-First-Byte (green), and content download (blue). You can also choose to have the height of each request reflect the content size. Both of these options are shown here:</p> <p style="text-align: center;"><img style="width: 100%; min-width: 300px; max-width: 712px; border: 1px solid;" src="https://cdn.speedcurve.com/img/blog/sc-waterfall-connection.png" alt="SpeedCurve connection waterfall" /></p> <p>I've added a screencast below to give a taste of what these features are&nbsp;like. But the&nbsp;best way to experience these awesome features is to do&nbsp;a <a href="https://speedcurve.com/plan/trial/">free trial</a>. Signup today to scrub your thumbnails and&nbsp;give your users a&nbsp;fast, joyous experience.</p> <p><iframe src="https://www.youtube.com/embed/um0BavAbYNE" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> Tue, 20 Sep 2016 00:00:00 +1200 PWA Performance https://speedcurve.com/blog/pwa-performance <p>Progressive Web Apps (PWAs) combine the best and newest features of the Web to deliver an experience that rivals native applications on mobile. Even better, they work on desktop, too. In fact, they work everywhere that the Web works! "Ah", you say, "that's not true! They require features that don't exist in all browsers." Because PWAs are "progressive", they can adapt to older browsers to deliver the best experience possible given the features that are available.</p> <p>Given these winning attributes, it's no surprize that PWAs are the most popular movement in web development today. And while there are already numerous conferences, videos, and evangelists for PWAs, there's less focus on testing and tracking the performance of PWAs. Mark and I discussed this gap in PWA performance. In response, we added some new features to SpeedCurve that, coupled with some existing features, provide a great toolkit for evaluating the performance of PWAs.</p><h2>PWA Offline Script</h2> <p style="margin-bottom: 0; padding-bottom: 0;">To answer the question "What's the key to measuring PWA performance?" let's look at some of the <a href="https://developers.google.com/web/fundamentals/getting-started/your-first-progressive-web-app/">key features of PWAs</a> that have the biggest impact on performance:</p> <ul style="color: black;"> <li style="margin-bottom: 11px;"><b>responsive</b> - PWAs work across different devices and viewport sizes</li> <li style="margin-bottom: 11px;"><b>progressive</b> - they adapt to different browsers, regardless of missing features</li> <li style="margin-bottom: 11px;"><b>offline</b> - they work offline (after an initial <em>lightweight</em> installation)</li> </ul> <p style="margin-bottom: 0; padding-bottom: 0;">The trickiest part is testing the offline experience. SpeedCurve is built on top of <a href="https://www.webpagetest.org/">WebPageTest</a>, so we use its scripting language to load the PWA while online, and then load it again without any network access. Here's the script using&nbsp;<a href="https://www.pokedex.org/">Pokedex</a> as our example PWA:</p> <pre style="margin-left: 4em;">logData 0 navigate https://www.pokedex.org/ execAndWait document.body.innerHTML="" logData 1 blockDomainsExcept unused.zz navigate https://www.pokedex.org/ </pre> <p>For the initial load while we're online, we turn off data logging and navigate to the URL. For cleaner filmstrips we clear the body's content between loads. Then we turn logging on and navigate to the URL again, but this time we're offline. The offline experience is created by blocking all domains. This forces the browser to fallback to its offline capabilities.</p> <h2>Responsive, Progressive, &amp; Offline</h2> <p>Let's look at how SpeedCurve measures these key PWA features. Using the PWA offline script shown above, we can verify that Pokedex loads without a network. Looking at the <a href="https://speedcurve.com/speedcurve-enterprise/pwas/test/160910_2J_d966378ffdbf084c298f54d9fc2b0a0f/">Pokedex test results for Samsung Galaxy S III</a>, we notice something really peculiar. There's a filmstrip, but there's no waterfall chart! What also stands out is that the Start Render time is 0.1 seconds! Pokedex loads instantly because it falls back to its offline experience. This is a web developer's (and user's) dream come true: a fast experience even while offline.</p> <p>SpeedCurve's <a href="https://speedcurve.com/speedcurve-enterprise/pwas/responsive/?d=30&amp;m=speedindex&amp;r=us-west-1&amp;s=20351&amp;u=40456&amp;share=m8crfo97k8yns71io7syaon6mfuo22">Responsive dashboard for Pokedex</a> sheds light on both the PWA's responsive and progressive behavior. Even while offline, the app loads on all browsers except IE 11. The site also behaves in a responsive manner as well. Notice how the left nav only appears on larger viewports. (Note: Since SpeedCurve uses emulation for mobile devices, it's not worth testing iOS since it doesn't support offline.)&nbsp;</p> <div style="text-align: center; margin-bottom: 1em;"><img style="width: 60%; min-width: 320px; margin-bottom: 50px;" src="https://cdn.speedcurve.com/img/blog/pwa-performance-responsive2.jpg" alt="PWA Performance" /></div> <h2>Script Templates</h2> <p>Mark added a cool new "script templates" feature in SpeedCurve to make it easier to create this PWA offline script, as well as other important scripts.</p> <div style="text-align: center; margin-bottom: 1em;"><img style="width: 75%; min-width: 320px;" src="https://cdn.speedcurve.com/img/blog/pwa-script-templates.png" alt="PWA Script Template" /></div> <p style="margin-bottom: 0; padding-bottom: 0;">In addition to the PWA offline script, we have these other script templates:</p> <ul style="color: black;"> <li style="margin-bottom: 11px;"><b>Repeat View</b> - See what performance is like when the cache is full.</li> <li style="margin-bottom: 11px;"><b>Block Third Party</b> - This script blocks all third party requests. This is helpful for teams who want to focus on the parts of the page that they control and eliminate variability from external resources.</li> <li style="margin-bottom: 11px;"><b>Don't add "PTST" to user agent</b> - By default, WebPageTest includes the string "PTST" in the User-Agent request header, but that may cause some web services (especially ad networks) to send back a different response. Using this script ensures third parties are behaving the way they do in the real world, but it also removes the ability to filter out the testing in your own analytics.</li> </ul> <p>NOTE: You need a <a href="https://speedcurve.com/pricing/">SpeedCurve Enterprise Plan</a> to see the scripting UI. If you don't have an Enterprise Plan you can try the PWA offline script in <a href="https://www.webpagetest.org">WebPageTest</a>.</p> <h2>Happy PWA</h2> <p>Thanks to the PWA offline script, you can verify that your PWA loads without any network. SpeedCurve also helps you&nbsp;see that it's progressive across all browsers, and responsive across all viewport sizes. And don't forget about the initial load experience! That's easy to test with SpeedCurve (just enter the URL without any script). It's important to make sure that your PWA fully loads as quickly as possible so that it's ready to work if the user goes offline.</p> <p>Making sure your PWA is responsive, progressive, and works offline is key. SpeedCurve is&nbsp;a great way to keep track of how your PWA performs and&nbsp;to deliver a fast, enjoyable experience for your users across all devices.</p> Mon, 12 Sep 2016 00:00:00 +1200 Measuring the User Experience https://speedcurve.com/blog/measuring-the-user-experience <p>SpeedCurve&rsquo;s sweet spot is the intersection of design and performance - where the user experience lives. Other monitoring services focus on network behavior and the mechanics of the browser. Yet users rarely complain that &ldquo;the DNS lookups are too slow&rdquo; or &ldquo;the load event fired late&rdquo;. Instead, users get frustrated when they have to wait for the content they care about to appear on the screen.</p> <p><em>The key to a good user experience is quickly delivering the critical content.</em></p><p>SpeedCurve helps you do this by focusing on metrics that reflect what the user actually experiences. For web pages, this comes down to when the content gets rendered. In last month&rsquo;s redesign, we added a new rendering chart. Here&rsquo;s an example of <a href="https://speedcurve.com/demo/site/?s=302&amp;u=917&amp;b=chrome&amp;r=us-west-1&amp;d=30&amp;share=39tfnozeq94p1o0hndk1kpbg4vb7cg">Smashing&rsquo;s rendering chart</a>:</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/chart-rendering-chart.png" alt="Rendering Chart" /></p> <p>To emphasize the importance of rendering, we made this&nbsp;the first chart in the dashboard. The rendering chart includes metrics for Start Render, Speed Index, and Visually Complete. Start Render is the lower bound indicating render time for the first pixel. Visually complete bookends that with a metric for rendering the last pixel. Speed Index sits in-between showing the average render time across all pixels. (Many people were surprised to find out that Speed Index is &ldquo;<a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">expressed in milliseconds</a>&rdquo;.)</p> <p>Rendering is important, but not all pixels have equal importance. Instead, most pages have critical design elements (e.g, the call-to-action or hero image). Knowing when this critical content is available is even more important than overall rendering metrics. Measuring critical content is done with <a href="https://speedcurve.com/blog/user-timing-and-custom-metrics/">Custom Metrics and the User Timing spec</a>. We jazzed up the Custom Metrics chart as part of the recent redesign:</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/chart-custom-metrics.png" alt="" /></p> <p>If rendering and critical content get slower, the first place to investigate&nbsp;is the number of <a href="https://speedcurve.com/blog/critical-blocking-resources/">critical blocking resources</a>. Since it&rsquo;s hard for developers to track changes in the number of blocking scripts and stylesheets across releases, we added that as a new metric in SpeedCurve. Here&rsquo;s the chart of <a href="https://speedcurve.com/demo/site/?s=300&amp;u=909&amp;b=chrome&amp;r=us-west-1&amp;d=30&amp;share=39tfnozeq94p1o0hndk1kpbg4vb7cg">critical blocking resources for NY Times</a>:</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/chart-critical-resources.png" alt="" /></p> <p>We&rsquo;re excited to find such fertile ground for accelerating how our customers deliver their critical content to users. If you&rsquo;d like to see these metrics for the user experience on your website, start a <a href="https://speedcurve.com/plan/trial/">free trial</a> today and give SpeedCurve a try.</p> Tue, 03 May 2016 00:00:00 +1200 More emulated devices and improved flexibility https://speedcurve.com/blog/more-emulated-devices-and-improved-flexibility <p>SpeedCurve users may have noticed some changes recently. At the beginning of March we released a major redesign of our Settings UI that gives users more flexibility to get the exact test results they want. The two biggest changes were to the way we emulate devices&nbsp;and to allow different testing&nbsp;configurations for different sites.</p><h2>Emulated Phones &amp; Tablets</h2> <p>Previously, emulated devices&nbsp;were hidden in the Responsive testing option. Now you can choose the specific phones and tablets you want to emulate. We use the device&nbsp;emulation built into <a href="https://developers.google.com/web/tools/chrome-devtools/iterate/device-mode/">Chrome DevTools</a> so your tests run in the same environment&nbsp;as your&nbsp;local development. SpeedCurve provides nine emulated phones &amp; tablets or you can build your own custom browsers and control settings like viewport size, device pixel ratio, connection speed and even packet rate loss.</p> <p><img style="display: block; margin-left: auto; margin-right: auto; max-width: 600px;" src="https://cdn.speedcurve.com/img/blog/emulated_browsers.png" alt="Emulated Phones &amp; Tablets" width="100%" /></p> <h2>Flexible Testing</h2> <p>Previously, geographic regions used average network speeds, but the new version of SpeedCurve allows you to test specific network configurations for different browsers.&nbsp;For example, you can now emulate the experience of a phone on a 2G network in Brazil or a desktop PC on fibre in Germany.</p> <p>The new SpeedCurve architecture allows you to access all the granularity of <a href="http://www.webpagetest.org/">WebPageTest</a> via our user interface.</p> <p>You can also distribute checks more flexibly across your sites and the competitors you are benchmarking. For example,&nbsp;you might currently check your website several times a day&nbsp;but with the new version you can test production and pre-prod hourly&nbsp;to see the impact of each&nbsp;change, and drop your competitor checks to once a&nbsp;day.</p> <p>We are constantly working on the SpeedCurve codebase and this is the third&nbsp;complete re-write.&nbsp;Our changes are&nbsp;driven by customer feedback. So if you've provided feedback via <a href="https://github.com/SpeedCurve-Metrics/SpeedCurve/issues">Github</a> - thank you - we are listening and please keep posting suggestions. We love hearing how we can&nbsp;make SpeedCurve better.</p> Thu, 24 Mar 2016 00:00:00 +1300 Critical Blocking Resources https://speedcurve.com/blog/critical-blocking-resources <p>At SpeedCurve, we focus on metrics that capture the user experience. A big part of the user experience is when content actually appears in front of the user. Since stylesheets and synchronous scripts are the culprits when it comes to blocking rendering, we've rolled out some new metrics that focus on these critical blocking resources.</p> <p>The most helpful innovation we made is to highlight the critical blocking stylesheets and synchronous scripts in our waterfall charts. In the following example waterfall chart for <a href="http://espn.go.com/">ESPN</a>, notice how the critical stylesheets (green) and synchronous scripts (orange) have a red hash pattern. Not surprisingly, the Start Render metric is delayed until after the last of these critical blocking resources is done loading. The "scrubber" at the bottom of the waterfall (showing the screenshot at that point in time) confirms that rendering has been blocked up to this point. Explore an example of a&nbsp;<a href="https://speedcurve.com/demo/test/151124_GG_b27586e08f44f38825dfd058f12a5c7c/39tfnozeq94p1o0hndk1kpbg4vb7cg/">interactive waterfall chart.</a></p> <p><img style="max-width: 563px; display: block; margin-left: auto; margin-right: auto;" src="https://cdn.speedcurve.com/img/blog/espn-critical-waterfall-2.png" alt="ESPN critical waterfall" width="100%" /></p><p>Not all scripts and stylesheets necessarily have a big impact on performance, so it's important to be able to tell the blocking requests when trying to improve the user experience. In the waterfall above we see that there's an early script (request #6, "lazysizes.js") that is <em>not</em> marked as a critical resource. That's because this script is loaded asynchronously and thus doesn't block rendering of the page. Since we only want to highlight resources that block rendering, asynchronous scripts are not highlighted.</p> <p>Similarly, in some cases it's possible to have stylesheets that don't block rendering of the main page. This typically happens with third party widgets that are loaded in an iframe, like the Twitter widget. Since stylesheets in iframes do not block the main page from rendering, they're not marked&nbsp;as critical resources.</p> <p>In addition to highlighting critical resources in the waterfall, the number of blocking&nbsp;stylesheets and synchronous scripts is shown under Other Metrics.&nbsp;</p> <p><img src="https://cdn.speedcurve.com/img/blog/critical-metrics-2.png" alt="Other Metrics" width="100%" /></p> <p>Once we have a month of historical&nbsp;data for critical requests, we'll add charts to track this metric over time. This new visibility into the number of blocking requests, and which ones they are, will help teams&nbsp;create fast, enjoyable experiences for their users.</p> <h2>The critical rendering path</h2> <p>For more on what the critical rendering path is, why it matters so much and how to optimize asset delivery to ensure you don't block it <a href="https://www.igvita.com/">IIya Grigorik</a> gave a great overview of the topic at Velocity Conf 2014.</p> <p><iframe src="https://www.youtube.com/embed/YV1nKLWoARQ" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> Mon, 23 Nov 2015 00:00:00 +1300 User Timing and Custom Metrics https://speedcurve.com/blog/user-timing-and-custom-metrics <p>If you want to improve performance, you must start by measuring performance. But what should you measure?</p> <p>Across the performance industry, the metric that's used the most is "page load time" (i.e, "window.onload" or&nbsp;"document complete").&nbsp;Page load time was pretty good at approximating the user experience in the days of Web 1.0 when pages were simpler and each user action loaded a new web page (multi-page websites). In the days of Web 2.0 and single-page apps, page load time no longer correlates well with what the user sees. A great illustration is found by&nbsp;<a href="http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/">comparing Gmail to Amazon</a>.</p> <p>In the last few years some better alternatives to page load time have gained popularity, such as start render time and <a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">Speed Index</a>. But these metrics suffer from the same major drawback as page load time: they are ignorant of what content the user is most interested in on the page.</p> <blockquote>Any performance metric that values all the content the same is not a good metric.</blockquote> <p>Users don't give equal value to everything in the page. Instead, users typically focus on one or more&nbsp;critical design elements in the page, such as a product image or navbar. In searching for a good performance metric, ideally we would find one that measures how long the user waits before seeing this critical content. Since browsers don't know which content is the most important, it's&nbsp;necessary for website owners to put these performance metrics in place. The way to do this is to create custom metrics&nbsp;with User Timing.</p><h2>User Timing Spec</h2> <p>The <a href="http://www.w3.org/TR/user-timing/">W3C User Timing spec</a>&nbsp;provides an API for developers to add custom metrics to their web apps. This is done via two main functions: performance.mark and performance.measure.&nbsp;</p> <ul> <li><a href="http://www.w3.org/TR/user-timing/#dom-performance-mark">performance.mark</a>&nbsp;records the time (in milliseconds) since navigationStart</li> <li><a href="http://www.w3.org/TR/user-timing/#dom-performance-measure">performance.measure</a>&nbsp;records the delta between two marks</li> </ul> <p>There are other User Timing APIs, but mark and measure are the main functions. Once your page is chock full of marks and measures, the question arises as to how to actually collect these metrics so you can track them. Thankfully, because User Timing is an official W3C specification, many metrics services automatically extract and report these custom metrics in their dashboards. This is true for <a href="http://www.soasta.com/performance-monitoring/">SOASTA's mPulse</a>, <a href="http://www.webpagetest.org/">WebPageTest</a>, and SpeedCurve.&nbsp;</p> <h2>Sample Custom Metrics</h2> <p>While the User Timing API is simple, it can sometimes be difficult to know where and when to capture these marks and measures. This&nbsp;is due to the complexity of the browser's inner workings, primarily the way&nbsp;that stylesheets and synchronous scripts block parsing and rendering. Let's look at a few examples of likely custom metrics to gain a better understanding.</p> <p>A quick note about browser compatibility: User Timing is available in most browsers except Safari. In the examples below we use the native API, but in your live code you'll need to check for compatibility and either use a shim or wrapper. A <a href="https://gist.github.com/pmeenan/5902672">good polyfill</a> is available from Pat Meenan.</p> <h3>example 1: stylesheets done blocking</h3> <p>Loading a stylesheet blocks the entire page from rendering. This is true in all&nbsp;browsers as well as for stylesheets that are loaded dynamically. Therefore, knowing when stylesheets are done blocking is a good metric for understanding why rendering might start later than desired. Here's sample code for capturing this custom metric:</p> <pre class="brush: js; html-script:true; toolbar:false;">&lt;link rel="stylesheet" href="/sheet1.css"&gt; &lt;link rel="stylesheet" href="/sheet4.css"&gt; &lt;script&gt; performance.mark("stylesheets done blocking"); &lt;/script&gt;</pre> <p>The key to this snippet is making sure that it's placed below all the stylesheet LINK tags in the page. That's a reasonable requirement since most stylesheets are listed at the top of the page. While simple in appearance, some complex performance know-how is behind this snippet:</p> <ul> <li>Inline scripts are not executed until all previous stylesheets are downloaded, parsed, and applied to the page. Therefore, placing the inline script after the LINK tags ensures that the mark is set after all the blocking CSS has been processed.</li> <li>It's possible that a stylesheet might include <code>@import</code> which would pull in other stylesheets, for example, sheet1.css might cause sheet2.css and sheet3.css to be downloaded, parsed, and applied. Therefore, simply tracking a stylesheet's load time (with Resource Timing for example) isn't enough. Doing so would produce a measurement that was too short and underestimated the impact of stylesheet blocking.</li> </ul> <p>In order to produce a good (fast) user experience, it's important to understand what might be blocking your web app's rendering. The likely culprits are stylesheets and synchronous scripts, but often it's hard to disambiguate which is responsible for delayed rendering. This "stylesheets done blocking" custom metric is handy because if rendering starts well after the "stylesheets done blocking" metric, then the investigation should focus on synchronous scripts, which leads to our next example.</p> <h3>example 2: scripts done blocking</h3> <p>Synchronous scripts block rendering for all following DOM elements, so knowing when script blocking is finished is also important. Here's a snippet for capturing this measurement:</p> <pre class="brush: js; html-script:true; toolbar:false;">&lt;script src="a.js"&gt;&lt;/script&gt; &lt;script src="b.js" async&gt;&lt;/script&gt; &lt;script&gt; performance.mark("scripts done blocking"); &lt;/script&gt;</pre> <p>The inline script (which calls performance.mark) is guaranteed to execute after script a.js has been downloaded, parsed, and executed. On the other hand, the mark will be recorded before b.js is done loading because b.js has the async attribute. This behavior matches our goal of measuring script blocking because a.js blocks rendering, but b.js doesn't.</p> <p>Capturing an accurate "scripts done blocking" metric is a bit more challenging than its stylesheet counterpart. The reason is that, similar to stylesheets, the User Timing mark must be placed below all synchronous scripts. This can be difficult since websites frequently sprinkle scripts throughout the page. If that's the case, the mark measurement may occur after earlier DOM elements have rendered, and thus it doesn't accurately measure when rendering starts.</p> <p>Therefore, this example is only useful for pages that have their synchronous scripts in the HEAD. Even with this limitation, this custom metric can be very useful for pages that have large scripts where the blocking time is much longer than the download time due to parsing and execution. When looking at waterfalls for these types of pages, all the scripts finish downloading but there's still a long gap before rendering starts. With a "scripts done blocking" mark, it would be possible to identify long parse and execute times as the culprit for render blocking.</p> <h3>example 3: fonts loaded</h3> <p>If your site uses custom fonts, it's important to know&nbsp;that some browsers won't render the text that use those fonts until after the font file is downloaded. In other browsers the text may be rendered in a system default font and then re-rendered ("flash"ed) when the custom font is loaded. Therefore, a "fonts loaded" custom metric would be valuable to indicate when text elements were rendered.</p> <p>Currently, there is not an "onload" event for fonts. Nevertheless, there are techniques for observing fonts and determining when they load, for example, <a href="https://www.filamentgroup.com/lab/font-events.html">Font Loading Revisited with Font Events</a>&nbsp;by Scott Jehl from the Filament Group as well as <a href="https://github.com/typekit/webfontloader#events">Web Font Loader</a>&nbsp;used by Typekit and Google Fonts. You could use these&nbsp;to track when your fonts are done loading, and include a call to performance.mark to set the "fonts loaded" custom metric at that time.&nbsp;</p> <h3>example 4: hero images</h3> <p>A "hero image" is often the most important element in the page when it comes to user experience. The <a href="http://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/">Hero Image Custom Metrics</a>&nbsp;article describes an innovative technique for measuring when images are rendered. The snippet looks like this:</p> <pre class="brush: js; html-script:true; toolbar:false;">&lt;img src="hero.jpg" onload="performance.clearMarks('img displayed'); performance.mark('img displayed');"&gt; &lt;script&gt; performance.clearMarks("img displayed"); performance.mark("img displayed"); &lt;/script&gt;</pre> <p>The innovation is to take the greater of the image onload mark and the inline script mark. This accurately captures when the image is actually rendered. The image onload mark reflects the render time when the image download takes longer than any blocking resources. The inline script mark reflects the render time when the image downloads quickly but blocking resources prevent it from being rendered. In many cases, the most critical content in a page involves images, so this snippet is useful for a wide variety of custom metrics.</p> <h3>example 5: paragraph of text</h3> <p>Surprisingly, one of the most challenging custom metrics is determining when text is displayed. In addition to being blocked by stylesheets and synchronous scripts, text elements (P, SPAN, LI, DIV, etc.) can also be blocked from rendering if they use a custom font that takes a long time to download.</p> <p>If the text element does not use a custom font, then the time at which it renders is captured by simply putting an inline script after the text element:</p> <pre class="brush: js; html-script:true; toolbar:false;">&lt;p&gt;This is the call to action text element.&lt;/p&gt; &lt;script&gt; performance.mark("text displayed"); &lt;/script&gt;</pre> <p>If the text element DOES use a custom font, then the render time is the maximum of the inline script's mark and the font loading mark (see previous example). The key here is to use a pattern similar to the hero image where we record the "text displayed" mark twice: once in the font-loading snippet and again in the inline script after the text element. Additionally, we clear any previous marks of the same name before setting the new mark, thus ensuring that we get the maximum of the two values which properly reflects when the text is displayed.</p> <h3>example 6: Single Page Apps</h3> <p>One of the drawbacks of relying on page load time as a metric is that it doesn't measure user actions inside a single page app (SPA) where window.onload only fires once but the user might perform multiple actions, each of which should be measured. Custom metrics solve this problem, but it requires taking on the added responsibility of creating an appropriate <em>start</em> time.</p> <p>In order to show some sample code, lets assume we have a SPA that has an "Update" button. When clicked, an XHR or JSON request is launched to fetch new data. That returned data is passed to the updateData() function which changes the DOM. Here's sample code that measures this SPA user action:</p> <pre class="brush: js; html-script:true; toolbar:false;">&lt;input type=button value="Update" onclick="fetchData()"&gt; &lt;script&gt; function fetchData() { performance.clearMarks("start update"); performance.mark("start update"); // Do an XHR or JSON request that calls updateData() with the new data. } function updateData(data) { // Update the DOM with the new data. performance.clearMarks("finish update"); performance.mark("finish update"); perforance.measure("update data", "start update", "finish update"); } &lt;/script&gt;</pre> <p>Notice that the "start update" mark is the first JavaScript in the&nbsp;SPA action, and "finish update" is the last JavaScript executed in&nbsp;the SPA action. This ensures that the entire SPA&nbsp;action is measured, including downloading the XHR or JSON and updating the DOM. Also notice that we used performance.measure for this first time. That's because we want to get the delta relative to a start time <em>other than</em> navigationStart.</p> <h2>Custom Metrics in SpeedCurve</h2> <p>A big benefit of building custom metrics with User Timing is that many performance metric services automatically extract the User Timing marks and measures to show in your performance dashboards. WebPageTest does this, and since SpeedCurve is built on top of WebPageTest we do it as well.&nbsp;</p> <p>You can see your custom metrics in SpeedCurve by giving them a name in your Settings. In&nbsp;the speedcurve.com&nbsp;website, we use a custom metric called "heromark" to measure when the hero image (typically the chart at the top of the page)&nbsp;is displayed. We can give it a prettier name, "Hero Mark", using the form found under Settings:</p> <p><img style="max-width: 441px;" src="https://speedcurve.com/img/custom-metric-settings.png" alt="" width="100%" /></p> <p>You can add multiple&nbsp;custom metrics to SpeedCurve Settings. Since some pages contain dozens of marks and measures, including ones set by third party scripts, this step ensures that only the most important custom metrics are shown.&nbsp;</p> <p>Custom metrics are visible on various SpeedCurve dashboards. For example, the Site dashboard shows a trendline&nbsp;of our "Hero Mark" custom metric over time.&nbsp;</p> <p><img src="https://speedcurve.com/img/custom-metric-site.png" alt="" width="100%" /></p> <p>It's extremely valuable to see custom metrics on a waterfall chart. This allows you to "debug" if your custom metric is measuring the right thing. For example, in the waterfall below for speedcurve.com, we can see that the "Hero Mark" custom metric is blocked until all the preceding scripts&nbsp;(orange) and stylesheets (green) are done downloading. Using the thumbnails at the bottom confirms that this is when the hero image (the chart) actually gets displayed.&nbsp;</p> <p><img style="max-width: 734px;" src="https://speedcurve.com/img/custom-metric-waterfall.png" alt="" width="100%" /></p> <p>No one knows your website as well as you do. Therefore, it's important that you add custom&nbsp;metrics that measure&nbsp;the content&nbsp;that you and your users care about most. This allows you to track the speed of&nbsp;what your user's are experiencing in both synthetic and RUM.</p> <p>If you're not already using SpeedCurve to create custom metrics and monitor your site's performance,&nbsp;<a href="https://speedcurve.com/plan/trial/"><strong>set up your free trial here</strong></a>.</p> Thu, 12 Nov 2015 00:00:00 +1300 Performance budgets in&nbsp;action https://speedcurve.com/blog/performance-budgets-in-action <p>Performance budgets are an important tool for ensuring your site is delivering a great user experience. Steve first experienced performance budgets while Head Performance Engineer at Google. The practice of using budgets to track performance took off with Tim Kadlec's blog post <a>Setting a Performance Budget.</a> The idea is to identify your performance goals and track the metrics that help you achieve your goals.</p> <p>At SpeedCurve, we give performance budgets first-class status by tracking them in the Site dashboard. Here's an example of tracking a budget for image size.</p> <p><img src="https://cdn.speedcurve.com/img/blog/budget.png" alt="Image performance budgets" width="100%" /></p> <p>Before setting your performance budgets, you first have to be monitoring your user experience. Only then can you set budgets and thresholds for improving your baseline user experience. This also allows you to quantify the improvements you're making and share success stories across the organization like "We just improved start render by 32% by reducing image requests to half the budgeted amount".</p><h2>What should my budget be?</h2> <p>There are various ways to approach setting a performance budget depending on the nature of your team, and what's going to make the most sense to them and motivate change:</p> <ul> <li>Be faster than your competition. Benchmark a variety of metrics and choose a target of 20% faster or less resources.</li> <li>Be faster than what&rsquo;s in production right now. This is great when doing a responsive redesign. Fork your code, rip out the old cruft, set new aggressive budgets and watch for alerts as you add new components and content back in.</li> <li>Adopt Human Computer Interface (HCI) guidelines such as those described in <a href="http://www.nngroup.com/articles/response-times-3-important-limits/">Response Times: The 3 Important Limits.</a> Aim for rendering the first meaningful content in under 1000ms.</li> <li>Base your budget on user research and design principles, such as <a href="https://speedcurve.com/blog/velocity-better-performance-through-better-design/">Better performance through better design.</a> What are your users actually trying to achieve and how long will they wait?</li> </ul> <p>SpeedCurve's <a href="https://speedcurve.com/demo/benchmark/a/1/a/a/30/speedindex/39tfnozeq94p1o0hndk1kpbg4vb7cg/">Benchmark dashboard</a> is a great way to see how you compare to your competitors for setting budgets. In the chart below, we can see why Smashing Magazine is so much faster - they're simply delivering a lot less JavaScript. If this was your site you could pick a metric like JS requests, set a lower budget and see if you can beat the competition!</p> <p><img src="https://cdn.speedcurve.com/img/blog/home-requests.png" alt="Comparing Homepages" width="100%" /></p> <h2>Not all metrics are equal</h2> <p>It&rsquo;s vitally important you evaluate which metrics you&rsquo;ll budget against. For a long time now we&rsquo;ve known that metrics like the <a href="http://www.stevesouders.com/blog/2013/05/13/moving-beyond-window-onload/">page onload event are terrible indicators</a>&nbsp;of user experience and yet many performance tools and organisations still use it as a key indicator of performance.</p> <p>At SpeedCurve we often audit sites and it&rsquo;s surprising how even very large sites can be misled into delivering a very poor user experience by focusing on optimising for the wrong metric or taking a performance guideline too literally.</p> <p>The only metrics you should care about and champion across your organization are the ones that represent what a user is actually seeing as the page renders. Other metrics can be useful secondary measures to track the changing nature of your site but don't necessarily correlate to what makes a good user experience. Your users don't care how your website is constructed. What they really care about is how long it takes before they can engage with your awesome content. You need to focus on letting them see that content as quickly as possible!</p> <p>Herein lies the problem, the majority of metrics are not visual metrics based on what a user is actually seeing but rather events that reflect the processes running in the browser. These two sets of metrics can paint very different pictures and it&rsquo;s the reason SpeedCurve is built on <a href="http://www.webpagetest.org/">WebPageTest</a>&nbsp;the leading open source performance tool.</p> <p>WebPageTest records video and creates filmstrips of how a page loads in a real web browser leading to unique metrics based on visual analysis from a users perspective rather than what a browser thinks it&rsquo;s doing. It&rsquo;s an independent measure and provides two unique metrics we can budget against, <a href="http://support.speedcurve.com/knowledgebase/articles/640174-what-do-the-different-speedcurve-metrics-represent">start render</a>&nbsp;and&nbsp;<a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">speed index.</a>&nbsp;These two metrics are a far better representation of the user experience than any of the built-in browser events.</p> <p><img src="https://cdn.speedcurve.com/img/blog/filmstrip.png" alt="Performance filmstrips" width="100%" /></p> <h2>Better yet define your own custom metrics</h2> <p>While start render and speed index are great, ultimately the best metric is the one you define yourself. Like Twitter&rsquo;s <a href="https://blog.twitter.com/2012/improving-performance-on-twittercom">time to first tweet</a>&nbsp;you should be adding a custom metric that represents when the user can actually view and interact with your content. Custom metrics are easy to add with <a href="http://www.html5rocks.com/en/tutorials/webperformance/usertiming/">user timing marks</a>&nbsp;and SpeedCurve automatically picks up any marks added to your site without additional configuration. There can be challenges around instrumenting assets like images though and Steve recently discussed these in&nbsp;<a href="http://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/">hero image custom metrics.</a></p> <h2>Recommended metrics for performance budgets</h2> <p>In order of preference, here are the metrics we recommend you benchmark your user experience against:</p> <ol> <ol> <li>A single UX based custom metric for each template. E.g., the hero image on a product page.</li> <li>Speed Index. <a href="https://docs.google.com/presentation/d/1MtDBNTH1g7CZzhwlJ1raEJagA8qM3uoV7ta6i66bO2M/present?slide=id.p19">Paul Irish</a> recommends aiming for under 1000.</li> <li>Start render under 1000ms.</li> </ol> </ol> <p>Then for each of these metrics pick a budget, set alerts and monitor it as your codebase evolves and (hopefully) improves. You can also add secondary budgets like the size and number of requests to help correlate the construction of your code base with the user experience but the three above are the ones you should really focus on.</p> <h2>Performance budgets in action</h2> <p><img style="display: block; margin-left: auto; margin-right: auto;" src="https://cdn.speedcurve.com/img/blog/zillow-gray.jpg" alt="" width="50%" /></p> <p>See how a SpeedCurve budget alert led Zillow to discover a bug that increased its image size on mobile by 4x in <a href="http://engineering.zillow.com/bigger-faster-and-more-engaging-while-on-a-budget/">Bigger, Faster, and More Engaging while on a Budget.</a>&nbsp;Interestingly the increase in images didn&rsquo;t have a noticeable effect on Speed Index and the user experience. Does this mean Zillow could be delivering even more content than it does now as long as the initial content in the viewport renders just as quick? Breaking your performance budgets can lead to really interesting insights on how users interact with your content.</p> <p><img style="display: block; margin-left: auto; margin-right: auto;" src="https://cdn.speedcurve.com/img/blog/verge.jpg" alt="" width="50%" /></p> <p>Vox Media, makers of The Verge and SB Nation, benchmarked themselves against the competition and then <a href="http://product.voxmedia.com/2015/5/6/8561867/declaring-performance-bankruptcy">declared performance bankruptcy.</a>&nbsp;This is a great way to engage with your community and be transparent about the challenges of delivering a rich and fast user experience.</p> <blockquote> <p>It's oftentimes hard to give a direct answer when someone asks you, "how fast is your site?" so we're educating our team on how we quantify performance at Vox by explaining what each metric means and how they interplay with one another.<br /><span class="quote-byline">Dan Chilton - Front-End Engineering Director, Vox Media</span></p> </blockquote> <p>Etsy have also done a great job of publicly <a href="https://codeascraft.com/2015/07/13/q2-2015-site-performance-report/">reporting on performance</a> and meeting the budgets they set for themselves.</p> <p>Performance budgets are a great way to ensure you deliver an enjoyable, fast user experience. But they only work if you pick the right metrics and set the right thresholds. It's best to focus on metrics that more accurately measure the user experience, such as custom metrics, Speed Index, and start render. All of these metrics are available in SpeedCurve. We focus on measuring what users actually see, and tracking that so you can deliver it even faster.</p> Tue, 20 Oct 2015 00:00:00 +1300 Visual diffs on every deploy https://speedcurve.com/blog/visual-diffs-on-every-deploy <p>SpeedCurve now provides a visual diff of every deploy. A full resolution PNG&nbsp;is captured for each URL&nbsp;and each pixel is diffed with the previous deploy allowing you to easily spot any visual changes you may or may not have expected.</p> <p>The key to practising safe continuous deployment is to have a robust set of tools that give you immediate feedback on how your code has changed between deploys and its effect on the user experience. It's often very hard to spot all the visual changes in each&nbsp;deploy, especially in fast moving teams where a lot of the focus is on unit tests and other automated pass/fail systems. Visual diffs bring an increased level of tracking and confidence when you're able to compare any two deploys and see exactly what has visually changed.</p> <p><img src="https://cdn.speedcurve.com/img/blog/diff-nav2.jpg" alt="" width="100%" /></p> <p>We do a visual diff every time you click "Test Now" on the Deploy dashboard or you use the <a href="https://api.speedcurve.com/">SpeedCurve API</a> to trigger a round of deploy testing. Integrating with the <a href="https://api.speedcurve.com/#deployments">Deploy API</a>&nbsp;is super easy and provides a robust set of metrics and before/after screenshots, visual diffs, <a href="https://speedcurve.com/blog/ux-focus-for-waterfalls-and-third-parties/">waterfall charts</a>, filmstrips and videos for each deploy. You can then compare any two deploys to see exactly what's changed over time.</p><h2>Spot the difference</h2> <p><img src="https://cdn.speedcurve.com/img/blog/diff-nav.jpg" alt="Visual diff navigation" width="100%" /></p> <p>Sometimes when just scanning before/after screenshots themselves without a visual diff it can be very hard to spot subtle changes. In the Tommy John example above just one extra item has been added to the main navigation. Do you think you would have spotted it without the visual diff giving you a clue as to what has changed? The visual diff really highlights the pixel level changes and also shows the effect on other nav items when a new item is added.</p> <p><img src="https://cdn.speedcurve.com/img/blog/diff-alignment.jpg" alt="Visual diff alignment" width="100%" /></p> <p>Quickly spot changes in grid and CSS alignment. Did you mean to move it or change a column width? With pixel by pixel matching it's easy to see exactly what's changed in your layout.</p> <p><img src="https://cdn.speedcurve.com/img/blog/diff-background.jpg" alt="Visual diff background" width="100%" /></p> <p>Sometimes you want to see what hasn't changed as well as what has. Here all the foreground elements in white remain in exactly the same place while the background which has been swapped out becomes bright red, really drawing your attention immediately to what's changed.</p> <p><img src="https://cdn.speedcurve.com/img/blog/diff-small-detail.jpg" alt="Visual diff small details" width="100%" /></p> <p>Surprisingly you can also spot the really small stuff when highlighted in red. Visual diffs are sensitive enough to pick up even single character changes helping you focus in on every single pixel that has changed from one deploy to another.</p> <p><img src="https://cdn.speedcurve.com/img/blog/diff-filmstrip.jpg" alt="Filmstrips" width="100%" /></p> <p> <script src="//fast.wistia.com/assets/external/E-v1.js" async="" charset="ISO-8859-1"></script> </p> <div class="wistia_responsive_padding" style="padding: 40.71% 0 0 0; position: relative; margin-bottom: 25px;"> <div class="wistia_responsive_wrapper" style="height: 100%; left: 0; position: absolute; top: 0; width: 100%;"> <div class="wistia_embed wistia_async_1aqietp6wj videoFoam=true" style="height: 100%; width: 100%;">&nbsp;</div> </div> </div> <p>We also provide side by side filmstrips and video comparisons which are fantastic not only for reviewing the visual differences&nbsp;but also putting in presentations so everyone across the organization can see exactly how long it takes to render the page from a user's perspective.</p> <h2>Make continuous deployment safe</h2> <p>Google uses visual diffs to spot release issues and make continuous deployment a safer practice. Brett Slatkin gave a great presentation at Velocity on the sorts of unexpected bugs you can discover with visual diffs. Check out the <a href="https://www.youtube.com/watch?v=1wHr-O6gEfc">video of Brett's talk</a>&nbsp;and learn more about how visual diffs help you track changes to what you're delivering to users.</p> <p><iframe src="https://www.youtube.com/embed/1wHr-O6gEfc" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> Mon, 12 Oct 2015 00:00:00 +1300 Multiple teams and multiple users https://speedcurve.com/blog/multiple-teams-and-multiple-users <p>This week we added support for organizations with multiple teams and multiple users.</p> <p><img src="https://cdn.speedcurve.com/img/blog/model.png" alt="" width="100%" /></p> <p>One of the toughest challenges was simply working out what to call the different layers within the SpeedCurve app. Developers can spend years buried inside a data model but at the end of the day the UI has to be intuitive and easy to use! I hope we&rsquo;ve done that and if not we&rsquo;d love your feedback.</p><p>SpeedCurve now has a new <strong>&ldquo;organization&rdquo;</strong> and <strong>&ldquo;team&rdquo;</strong> structure that provides a great deal of flexibility when setting up a new account.</p> <p>Larger organisations or agencies can now add multiple teams to their <a href="https://speedcurve.com/pricing/">Enterprise plan.</a>&nbsp;Billing and budgets are held at the organization level making it easy to manage costs while giving new teams access to SpeedCurve monitoring for their projects.</p> <p>If you're an agency you can swap the idea of internal teams for clients. This lets you have an isolated set of dashboards for each client while easily swapping between them using the new menu if you belong to the organization. Each client only has access to their dashboards, while you have the ability to browse across dashboards.&nbsp;</p> <p>Multiple users can be invited to join a team and you control their view or edit permissions for any of the SpeedCurve dashboards. Users can belong to multiple teams and even multiple organizations.</p> <p>We also recently added new dashboard sharing links so you can either send someone a read-only private url (without them having to login) or invite a user to join your team.</p> <p>Here&rsquo;s a walk-through of the new account structure and features. If you're on an <a href="https://speedcurve.com/pricing/">Enterprise plan</a>&nbsp;you have access to these features now, otherwise get in touch to upgrade your existing account.</p> <script src="//fast.wistia.com/assets/external/E-v1.js" async="" charset="ISO-8859-1"></script> <div class="wistia_responsive_padding" style="padding: 56.25% 0 0 0; position: relative;"> <div class="wistia_responsive_wrapper" style="height: 100%; left: 0; position: absolute; top: 0; width: 100%;"> <div class="wistia_embed wistia_async_9njjg0qa2h videoFoam=true" style="height: 100%; width: 100%;">&nbsp;</div> </div> </div> <p><br />Up next we&rsquo;re doing a complete redesign of the Settings UI which will provide a great deal more granularity for each Site being monitored.</p> Wed, 30 Sep 2015 00:00:00 +1300 UX Focus for Waterfalls and Third Parties https://speedcurve.com/blog/ux-focus-for-waterfalls-and-third-parties <p>At SpeedCurve, we want to help designers and developers have better insight into the user experience they're delivering. For websites, this means understanding when the critical parts of the page render and what might be blocking rendering.</p> <p><video autoplay="autoplay" loop="loop" width="100%"><source src="https://cdn.speedcurve.com/img/blog/waterfall.mp4" type="video/mp4" /></video></p> <p>We've redesigned our waterfall chart to really highlight the relationship between the assets on the page and their affect on the user experience. Now as you move you mouse over the waterfall chart we show you exactly what a user is seeing at that millsecond while the page loads. This makes it much easier to identify any Javascript or&nbsp;CSS that might be blocking the page from rendering. I&nbsp;recently used this new combined waterfall and filmstrip view to identify a common issue with <a href="http://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/">hero images being delayed.</a></p><p>If rendering is blocked, it's important to figure out&nbsp;the cause. This isn't always easy, especially with the amount of third party content on websites today. Often the scripts and stylesheets that come with ads, analytics, and social widgets aren't delivered in a high performant way and can block the main content on the page from ever being seen by users. To help identify this possibility, you can use the Start Render line in the <a href="https://speedcurve.com/thirdparty/3/1/chrome/1/30/39tfnozeq94p1o0hndk1kpbg4vb7cg/">Third Party waterfall chart</a>.</p> <p><img src="https://cdn.speedcurve.com/img/blog/thirdparty.png" alt="Third Party Start Render" width="100%" /></p> <p>The Third Party waterfall chart bundles HTTP requests into groups representing first and third parties. The grouping logic is based on technology developed at&nbsp;SpeedCurve. We draw a vertical line representing the Start Render point on top of the waterfall. Any third parties to the left on the line have the potential of blocking rendering. You can click on each third party to see more detail and go to the <a href="https://speedcurve.com/test/150622_0Z_Z6J/39tfnozeq94p1o0hndk1kpbg4vb7cg/">full waterfall chart</a>&nbsp;to investigate the filmstrip thumbnails.</p> <p>Waterfall charts are great. Adding the ability to see when&nbsp;rendering occurs and how it's affected by third parties makes them even an even better tool for designers and developers to create great experiences for their users.</p> Tue, 23 Jun 2015 00:00:00 +1200 The language and metrics of UX evolve at Velocity 2015 https://speedcurve.com/blog/the-language-and-metrics-of-ux-evolve-at-velocity-2015 <p><em>Originally published on the&nbsp;<a href="http://radar.oreilly.com/2015/06/devops-developers-designers-ux-metrics-velocity.html">O'Reilly Radar Blog</a></em></p> <p>I&rsquo;ve attended four&nbsp;<a href="http://velocityconf.com/">O&rsquo;Reilly Velocity conferences</a>&nbsp;over the last year, and I was struck by a notable shift in the conversations at Velocity in Santa Clara, Calif. Many speakers and attendees have started to change their language and describe the experience&nbsp;of their websites and apps from the user&rsquo;s perspective.</p> <p>The balance has shifted from just talking about how fast or reliable a particular&nbsp;system&nbsp;is to the overall experience&nbsp;a&nbsp;user&nbsp;has when they interact with and experience a product. Many people are now looking at themselves from the outside in and developing more empathy for their users. The words &ldquo;user&rdquo; and &ldquo;user experience&rdquo; were mentioned again and again by speakers.</p> <p>Here are recent talks from Velocity and other events that highlight this shift to UX concerns.</p><h2>The next billion users</h2> <p>At Velocity 2015 in Santa Clara,&nbsp;<a href="http://www.brucelawson.co.uk/">Bruce Lawson</a>&nbsp;described the dramatic growth of connected users in Asia and Africa, while highlighting the challenge faced when trying to deliver great experiences to a broad range of devices. Companies looking to these regions for their next billion users need to keep in mind that these users are on underpowered phones over slow networks with high data costs.</p> <p><iframe src="https://www.youtube.com/embed/BHO70H9tvqo" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <h2>Reaching everyone</h2> <p>The techniques required to reach such a broad audience were covered by&nbsp;<a href="http://timkadlec.com/">Tim Kadlec</a>&nbsp;at Velocity 2015 in Santa Clara, who took us through the process of creating a high-performant responsive site that can effectively reach a diverse global audience. Here&rsquo;s Kadlec&rsquo;s related talk from Velocity 2014 in New York:</p> <p><iframe src="https://www.youtube.com/embed/fHcl5lpgQ1g" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <h2>The path to performance</h2> <p>Successful performance begins far earlier than development. So, how do you get your entire team excited by it? At Velocity 2015 in Santa Clara,&nbsp;<a href="http://kovalc.in/">Katie Kovalcin</a>&nbsp;discussed everyone&rsquo;s role in performance and how to get all teammates caring.</p> <p> <script class="speakerdeck-embed" src="//speakerdeck.com/assets/embed.js" async="" data-id="0754d7ddff3a45819e900966c2592d6d" data-ratio="1.77777777777778"></script> </p> <h2>Design + performance</h2> <p><a href="http://stevesouders.com/">Steve Souders</a>&nbsp;really captured the growing crossover of design and performance cultures within organizations and the desperate need to move from purely technical instrumentation to a focus on custom metrics that capture what the user actually sees as the page loads. Below you&rsquo;ll find Souders&rsquo; related talk from&nbsp;<a href="http://fluentconf.com/javascript-html-2015">Fluent 2015</a>:</p> <p><iframe src="https://www.youtube.com/embed/A9rKO2rhYYM" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <h2>Visualizing performance data in engaging ways</h2> <p>In the talk I gave, I focused on how performance data can be visualized in ways that engage the wider team, ensuring that everyone across the organization understands the impact of their work on the user experience:</p> <p><iframe src="https://www.youtube.com/embed/lEhmmTlbCss" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <p>Coming from a design background, I&rsquo;m happy discussions at Velocity are focusing on the importance of viewing performance from the user&rsquo;s perspective. The key is ensuring that the design and development process keeps the user and their experience of a product as a constant focus.</p> <h2>Operations has users, too</h2> <p>Running and maintaining high-performance, highly-available sites and apps necessitates&nbsp;a near obsession with monitoring and metrics. With operational metrics come a host of tools, and the current state of these tools is unfortunately well behind the end-user customer experience.&nbsp;Two talks focused on the need for a UX-focused approach for operations tools, one&nbsp;<a href="http://cdn.oreillystatic.com/en/assets/1/event/122/When%20UX%20meets%20operations%20Presentation.pdf">from the perspective of UX designer</a>&nbsp;Tim Sheiner, the other from Rob Treat,&nbsp;who&nbsp;<a href="http://www.slideshare.net/xzilla/whatopscanlearnfromdesign">uses ops tools on a daily basis</a>. Both stressed the importance of understanding the goals, tasks, and mindset of operations teams when building tools, notably for&nbsp;handling stressful situations like site outages.</p> <p>Velocity was one of the early places where DevOps originated, bringing developers and ops folks closer together. Last week, we witnessed an additional convergence of developers, ops, and designers. It&rsquo;s exciting that Velocity is helping these siloed groups find ways to share with and learn from each other. Much of this thinking comes from Lara Callender Hogan&rsquo;s book&nbsp;<a href="http://shop.oreilly.com/product/0636920033578.do?intcmp=il-webops-books-videos-product-na_20150601_radar_mark_zeman_velocity_highlight_post">Designing for Performance</a>. If you want to produce amazing, fast, enjoyable user experiences, I recommend you read Hogan&rsquo;s book and review the sessions highlighted above. And keep your focus on the user.</p> Thu, 11 Jun 2015 00:00:00 +1200 Responsive Design Dashboard https://speedcurve.com/blog/responsive-design-performance-testing <p>The dramatic growth of mobile traffic has created an urgency for websites to adapt to different screen sizes. <a href="http://alistapart.com/article/responsive-web-design">Responsive design</a> is the preferred technique for making web content adapt to the device on which it's viewed. This approach ensures that the appropriate content is rendered in an appropriate way on phones, tables, laptops, and any other screen being used.</p> <p>A corollary to responsive design is the need for performance. Delivering content that's customized for a particular device isn't enough if its delivery is slow and frustrating. Indeed, last week <a href="http://www.huffingtonpost.com/2015/04/17/google-search-update_n_7085642.html">Google announced</a> that websites need to deliver their design appropriately and quickly on mobile devices or they will be demoted in Google's search results.</p> <p>How can you know if your website matches these standards for adaptive content and speed? SpeedCurve's <a href="https://speedcurve.com/features/responsive/">Responsive Design Dashboard</a> answers both questions in one view.</p> <p style="text-align: center;"><img src="//speedcurve.com/img/blog/responsive-filmstrip.png" alt="Responsive Filmstrips" width="100%" /></p><p>The Responsive Design Dashbard shows the URL's filmstrip across different viewport sizes: 320x568, 568x320, 768x1024, 1024x768, 1280x768, and 1366x768. Viewing these thumbnails over time reveals how quickly the content is rendered. Similarly, you can see how the site's design adapts to different screen sizes.</p> <p>The Responsive Design Dashboard is created using Chrome's mobile browser emulation feature. In addition to specifying the viewport size, the User-Agent string is also adapted to correspond to the emulated device's default characteristics. (Soon we'll adapt the network settings, as well.)</p> <h2>Asset Breakpoints</h2> <p>The filmstrips show how the website adapts to different visual breakpoints. It's also important to think about <em>asset breakpoints</em> - how the size and number of requests adapts based on the screen size. For example, we know we don't want to send huge desktop images to smaller screens.</p> <p>The Responsive Design Dashboard shows asset breakpoints by revealing information about HTTP requests at each viewport size. The screenshot below, for example, paints a picture that we like to see where smaller screens receive fewer bytes, while larger screens get a heavier experience.</p> <p style="text-align: center;"><img src="//speedcurve.com/img/blog/responsive-sizes.png" alt="Responsive Sizes" width="100%" /></p> <p>The Responsive Design Dashboard perfectly captures what SpeedCurve is about: the intersection of design and performance. Understanding how a design adapts across viewports to tracking kilobytes by Content-Type. We're having fun bringing you the information you need to create great user experiences.</p> Wed, 29 Apr 2015 00:00:00 +1200 Mark+Steve, Performance+Design https://speedcurve.com/blog/mark-plus-steve-performance-plus-design <p>I'm excited to announce that I've joined <a href="https://speedcurve.com/">SpeedCurve!</a></p> <p>When SpeedCurve was just a twinkle in Mark's eye, he contacted me about the concept and I encouraged him that a commercial version of <a href="http://www.webpagetest.org/">WebPageTest</a> was needed. When I saw the early versions of SpeedCurve, I was blown away. Mark presents traditional performance data in a way that is more compelling, revealing his strong design background.</p> <p>Mark has pioneered this new territory where performance and design overlap. It's exciting to say "overlap". Many times there's little interaction between designers and performance engineers. When there is interaction, it can feel adversarial with no one wanting to give any ground. And yet, designers and performance engineers are after the same thing: creating a great user experience!</p> <p>Design and performance are connected, like the yin and yang. They aren't opposing forces, but instead complement each other. Users want an experience that is rich <em>and</em> fast. The trick is figuring out how to do that. That's where SpeedCurve comes in.</p><p>SpeedCurve focuses on measuring the interplay between design and performance. Rather than providing typical performance metrics that focus on resource downloads, SpeedCurve focuses on metrics and visualizations that correspond more closely to the user experience, such as:</p> <ul> <li>the <a href="//speedcurve.com/features/responsive/">responsive design dashboard</a> that shows pages rendering in different viewports, orientations, and connection speeds</li> <li><a href="//speedcurve.com/features/custom/">custom metrics</a> that measure what you decide is critical to your users</li> <li>the impact of <a href="//speedcurve.com/features/thirdparty/">third party content</a> on your site</li> <li>whether you're sticking to your <a href="//speedcurve.com/features/budgets/">performance budget</a></li> </ul> <p>I've been working on performance for more than a decade and have witnessed (and instigated) a lot of changes. I'm excited about this movement to bring design &amp; performance closer together. In the end it'll produce what matters the most: a great web experience for users.</p> <p>Mark and I are a good team to work on this - with his background heavy in design and mine in performance. Today we just re-launched the site with a major design overhaul and many new features. (Plus a new pay-as-you-go pricing plan that actually lowers costs for most of our existing customers!) We hope you'll give SpeedCurve a try, and that you'll find it useful for understanding what your users are experiencing and how to make that experience richer and faster.</p> <p style="text-align: center;"><img style="width: 100%; max-width: 630px;" src="//dev.speedcurve.com/img/mark_and_steve_small.jpg" alt="" /><br /><br /> <em>Steve and Mark at the SpeedCurve re-launch in New Zealand.</em></p> Tue, 24 Mar 2015 00:00:00 +1300 Velocity: Better performance through better&nbsp;design https://speedcurve.com/blog/velocity-better-performance-through-better-design <p>Improve web performance by improving your design process&hellip; it needs to be iterative, mindful, principled and visual.</p> <p>At my third Velocity conference for the year (this time in beautiful Barcelona) my keynote presentation explored the ways in which a thoughtfully developed design process can lead to higher functioning teams and better web performance.</p> <p><iframe src="//www.youtube.com/embed/DFImM0r4EpE" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p><p>I start out by suggesting that before a project is launched the team must sit down and design the process that they are going to use to reach a solution. This process needs to be guided by a project specific set of principles, higher level than requirements, identifying the core &lsquo;values&rsquo; and priorities of the project. A performance budget should be represented in one of the principles and will guide the team as they navigate through each iteration.</p> <p>Small multi disciplinary teams are key to executing this better designed approach. An agile style of working results, one which no longer excludes designers but has the entire team -&nbsp; designer, developer, researcher and the client, revolving around a prototype. Iteration after iteration is refined through the team effort.</p> <p>Once again I talk about the importance of effective visualization for engaging the entire team and beyond, to the wider organization.</p> <p>What tactics do you use in your organization to improve your design process?</p> <p>How is performance incorporated into discussions within your project teams?</p> <p>Are you working in Agile and are designers part of that process?</p> <p>What metric are you choosing to share with the wider organization around your project - and how?</p> Mon, 17 Nov 2014 00:00:00 +1300 Velocity: A better waterfall chart https://speedcurve.com/blog/velocity-a-better-waterfall-chart <p>The way we visualize performance data can have an impact on how we interpret and communicate performance issues within our teams.</p> <p>In this talk from <a href="http://velocityconf.com/velocityny2014">Velocity New York</a>&nbsp;I explored the importance of data visualization and presented some of my own explorations into re-imagining the classic waterfall chart which is the mainstay of front-end performance analysis.</p> <p>Skip to 15:30 if you just want to see the data visualization experiments, and you can play with them directly on&nbsp;<a title="SpeedCurve LAB" href="http://lab.speedcurve.com">lab.speedcurve.com</a></p> <p>One of these experiments was also turned into a <a href="https://github.com/zeman/perfmap">performance heatmap bookmarklet.</a></p> <p><iframe src="//www.youtube.com/embed/Olwm3l4rfns?rel=0" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p><p>To date waterfall charts have been a mainstay in visualizing web performance, giving us details on each asset and how it cumulatively effects the load time of a web page. But there are many ways of visualizing performance: histograms, flame charts, heatmaps, frequency tails, and colony graphs to name just a few.</p> <p>I&nbsp;explored the strengths and weaknesses of various types of charts and how well suited they are at answering a range of performance questions from both the perspective of a manager looking for quick high level answers and a developer needed to dig into the details. It&rsquo;s important to start with the questions about performance first and then find the tools, metrics, and visualizations to best answer a question rather than inferring problems and answers from an existing metric.</p> <p>Often charts are rendered along just two dimensions, which can limit the amount of information displayed and hide important detail. I&nbsp;presented several new visualizations that introduce depth, animation, and interaction to reveal performance bottlenecks and insights at both a holistic and detailed level.</p> <p>These new visualizations make the most of modern browser techniques allowing greater interaction and demonstrating just how powerful the modern browser has become at visualizing it&rsquo;s own performance.</p> <p>Let me know which&nbsp;visualizations&nbsp;you enjoyed the most and I'll add them to SpeedCurve!</p> Tue, 16 Sep 2014 00:00:00 +1200 Velocity: Responsive in the wild https://speedcurve.com/blog/velocity-responsive-in-the-wild <p>I was lucky enough to give a Lighting Demo at <a href="http://velocityconf.com/velocity2014">Velocity Conference</a> in Santa Clara. The focus was on research I conducted into 250 responsive websites and how well optimized for performance they were.</p><p><iframe src="//www.youtube.com/embed/3Lhwso2GaN0?rel=0" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <p> <script class="speakerdeck-embed" src="//speakerdeck.com/assets/embed.js" async="" data-id="61b543b0dec80131ffee2ad9291baba4" data-ratio="1.77777777777778"></script> </p> <h2>Methodology</h2> <p>250 responsive websites were loaded at 17 different viewport widths between 320px and 1920px using WebPagetest. The number of requests and size of assets were captured for each width and used to build a visulization that revealed the cross-section of a site's performance breakpoints rather than it's visual breakpoints.</p> <h2>Results</h2> <p>Averages can hide the patterns in data so after visually sorting and grouping the cross sections of the sites we see that there are distinct patterns and approaches used by sites to tune their assets for performance at different widths.</p> <p><img src="https://cdn.speedcurve.com/img/blog/responsive-stack.png" alt="" width="100%" /></p> Wed, 25 Jun 2014 00:00:00 +1200 Faster EC2 testing agents https://speedcurve.com/blog/faster-ec2-testing-agents-for-speedcurve <p>As of the 1st of June SpeedCurve has switched to using faster testing agents at Amazon EC2 data centers. As web pages become more Javascript and resource heavy I've noticed more and more pages max out the CPU while performance testing.</p><p>SpeedCurve now uses EC2 m1.medium instances which have 3.75GB of RAM with faster CPU and network performance. For CPU heavy pages you should see a drop in overall load time. The connection speed for testing agents is still throttled to an average US connection speed so simple pages may not improve as much.</p> <p>Overall this should provide more consistent results that are more on par with what an average user of your website might experience.</p> <p>Do note that SpeedCurve's strength is competitive benchmarking and detailed build analysis. If you're after actual on the ground performance numbers then we suggest combining <a href="https://speedcurve.uservoice.com/knowledgebase/articles/355134-synthetic-vs-real-user-monitoring-rum">SpeedCurve with Real User Monitoring.</a>&nbsp; &nbsp;</p> Sun, 01 Jun 2014 00:00:00 +1200 Speed Index now available https://speedcurve.com/blog/speedindex-now-available-on-speedcurve <p><a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">Speed Index</a>&nbsp;is now available on SpeedCurve. Choose "SpeedIndex" from the top right of the main graphs.</p> <p><img src="https://cdn.speedcurve.com/img/blog/speedcurve-speedindex.png" alt="Speed Index" width="100%" /></p><p><a href="https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index">Speed Index</a>&nbsp;is an important measure of a user's experience as the page loads. It's based on video analysis of how the page loads over time. Here's a great video from Paul Irish introducing Speed Index at the recent <a href="http://www.feopsconf.com/">Front End Ops Conference.</a></p> <p><iframe src="//www.youtube.com/embed/E5lZ12Z889k?rel=0" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> Wed, 28 May 2014 00:00:00 +1200 IE11 and average speed update https://speedcurve.com/blog/ie11-and-average-speed-update <p>To keep inline with browser trends and average connection speeds SpeedCurve will begin updating the test setting every quarter.</p> <p>For Q2 2014 we're switching to IE11 which is now the most popular version of IE according&nbsp;to <a href="http://www.akamai.com/html/io/io_dataset_v2.html#stat=browser_ver&amp;top=10&amp;type=line&amp;start=20140101&amp;end=20140317&amp;mobile_browser=Internet%20Explorer:11~8~10~9~7~6">Akamai</a>&nbsp;and <a href="http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201312-201402">StatsCounter</a>&nbsp;and the average connection speed has been updated to 9.8Mbps download, 2.5Mbps upload with a 10ms latency. The 9.8Mbps download speed is based on the latest <a href="http://www.akamai.com/stateoftheinternet/">State of the Internet</a> report from Akamai.&nbsp;</p> Tue, 01 Apr 2014 00:00:00 +1300 SpeedCurve wins Webstock BNZ Start-Up Alley https://speedcurve.com/blog/speedcurve-wins-webstock-bnz-start-up-alley <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/webstock-logo.svg" alt="" /></p> <p>I'm stoked that SpeedCurve has been chosen&nbsp;as one of two winners in the&nbsp;<a href="http://www.webstock.org.nz/14/supalley/">2014 Webstock Start-Up Alley.</a>&nbsp;I'll be using the 10k prize money and two flights to the US to attend&nbsp;<a href="http://velocityconf.com/velocity2014">Velocity Conf</a>&nbsp;in San Fran in June and New York in September.</p> Thu, 23 Jan 2014 00:00:00 +1300 Performance tips for building responsive&nbsp;sites https://speedcurve.com/blog/performance-tips-for-building-responsive-sites <p>The following article was originally published in the <a href="http://calendar.perfplanet.com/2013/">2013 Performance Calendar.</a> There's 31 great articles to explore in the calendar including Steve Souders's <a href="http://calendar.perfplanet.com/2013/browser-wishlist-2013/">browser wishlist</a> and Tim Kadlec's take on what it takes to <a href="http://calendar.perfplanet.com/2013/holistic-performance/">create a performance culture.</a></p> <p>----</p> <p>Responsive Web Design (RWD) is now a well established technique yet it&rsquo;s adoption is still surprisingly low. Guy Podjarny&rsquo;s <a href="http://www.guypo.com/mobile/roughly-1-in-8-websites-is-responsive/" target="_blank">recent research</a> shows that only one in eight websites is responsive. Often when responsive sites are designed the approach is primarily from a visual design perspective and teams struggle with the complexity of changing design and navigation patterns let alone any performance concerns, which become secondary. This can lead to serving the same sized assets to all browser widths resulting in a responsive site that is visually scaled but not performance optimised. On average responsive sites at 320 pixels wide are only 8% small than at 1600 pixels wide. Unsurprisingly these <a href="http://blog.cloudfour.com/responsive-web-design-is-solid-gold/" target="_blank">performance concerns</a> and a lack of established techniques have made some hesitate when considering RWD adoption.</p> <p><a href="http://www.guypo.com/mobile/what-are-responsive-websites-made-of/"><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/guypo-rwd-page-size.png" alt="Page size by file type" /></a></p> <p>Responsive page sizes across different screen resolutions. Source: <a href="http://www.guypo.com/mobile/what-are-responsive-websites-made-of/" target="_blank">Guy Podjarny</a></p><p>However, we do now have a full set of techniques to effectively deliver highly performative sites that not only visually scale across devices but also deliver code and assets tuned to the width of a device. Sites need to be built utilising these techniques from a mobile first (and performance first) perspective.</p> <p>Here are three key techniques that you can use to optimise performance using mobile as your starting point. Let&rsquo;s tackle these in order of the page load&hellip;</p> <h2>Inline the initial experience (within 14k if&nbsp;possible)</h2> <p>First impressions do count. While it&rsquo;s easy to throw jQuery, a framework like Bootstrap/Foundation and web fonts on a page you trade ease of use for performance. It&rsquo;s increasingly a <a href="http://gs.statcounter.com/#desktop+mobile-comparison-ww-weekly-201342-201351" target="_blank">mobile world</a> and your main aim should be to engage users as quickly as possible.</p> <p>Ilya Grigorik&rsquo;s recent Velocity conference <a href="http://www.youtube.com/watch?v=YV1nKLWoARQ" target="_blank">presentation</a> explored the browser's critical rendering path and highlighted exactly what it takes to deliver a mobile page within one second. Surprisingly you&rsquo;ve got just one HTTP request and only 14k of HTML to play with to get content in front of users. One of the only ways to achieve this is by inlining any &ldquo;above the fold&rdquo; CSS and JS required to render the first screen of content. Recently Grigorik has been championing this approach and the <a href="https://developers.google.com/speed/pagespeed/insights/" target="_blank">Google Pagespeed Insight</a> rules have been updated to reflect this best practice with recommendations on how to <a href="https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent" target="_blank">reduce the size of "above the fold" content.</a></p> <h2>Control and branch the loading of CSS and&nbsp;JS</h2> <p>There are plenty of automated front-end optimisation tools available like modpagespeed and CloudFlare but being a bit old-school and craft-orientated I prefer the ability to control the load order and optimise not only the individual assets but their sequencing as well.</p> <p>Often responsive sites combine the desktop and mobile CSS and JS into one set of files but this results in delivering unnecessary code to the width you&rsquo;re viewing. You can optimise what&rsquo;s delivered by using javascript to detect the width of the page and then request specific styles and javascript appropriate to that width. There might even be whole features or different navigation patterns introduced or removed at different widths to optimize the size of the user experience.</p> <p><a href="https://github.com/blog/1559-github-s-on-your-phone"><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/github-desktop-mobile.png" alt="Github desktop vs mobile" /></a></p> <p>Github write mobile specific CSS and JS resulting in much smaller and faster pages. Source: <a href="https://github.com/blog/1559-github-s-on-your-phone" target="_blank">Github Blog</a></p> <p>Here&rsquo;s a few libraries you can use to enable the decision making and branching of assets as the page loads: <a href="https://github.com/scottjehl/eCSSential" target="_blank">eCSSential,</a> <a href="http://foundation.zurb.com/docs/components/interchange.html" target="_blank">Interchange,</a> and good old <a href="http://modernizr.com/" target="_blank">Modernizer.</a></p> <h2>Shrink and art direct your&nbsp;images</h2> <p>Images often make up the largest set of assets on a page. There are two key considerations here - serving the right image to the right width and being able to art direct the image for smaller screen sizes, i.e. crop into the focal point of an image for smaller widths.</p> <p>If possible eliminate an image altogether by using an <a href="http://fontello.com/" target="_blank">icon font</a> for icons and small graphics. Alternatively use <a href="http://css-tricks.com/using-svg/" target="_blank">SVG images</a> for logos and other simple graphics. Both these techniques use vector data rather than pixels so they are small in file size and scale efficiently across all sizes including high resolution retina screens.</p> <p>However when it comes to photos you need to stick with pixel based formats and this requires switching between different sized images to save bandwidth. <a href="https://github.com/scottjehl/picturefill" target="_blank">Picturefill</a> is an interim polyfill for responsive images allowing you to curate which image gets served to which width.</p> <p>Often image generation can be a real chore and rather than manually outputting images in different formats and sizes your backend or CMS should be doing the hard work for you. <a href="http://www.cdnconnect.com/" target="_blank">CDN Connect</a> is a promising new service that allows you to transform a single high quality image into many different formats and has an impressive range of <a href="http://www.cdnconnect.com/docs/image-api" target="_blank">methods</a> to crop, filter and manipulate images. All CMS's should be offering this level of image manipulation and caching.</p> <p>While you&rsquo;re outputting your images to different formats consider adding <a href="http://www.igvita.com/2013/03/07/faster-smaller-and-more-beautiful-web-with-webp/" target="_blank">WebP</a> into the mix. It&rsquo;s a new image format developed by Google that&rsquo;s 30-40% smaller than a jpeg. Currently WebP is only supported in Chrome and Firefox are considering adding support. <a href="http://davidnewton.ca/responsive-images-picturefill-type-attribute" target="_blank">David Newton</a> has created a <a href="https://github.com/nwtn/picturefill" target="_blank">fork of Picturefill</a> that adds WebP and SVG detection so you can not only deliver the right size but the smallest format to different browsers.</p> <h2>Case study: the new responsive Guardian&nbsp;site</h2> <p><a href="http://speedcurve.com/demo/"><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/speedcurve-guardian-size.png" alt="SpeedCurve Demo" /></a></p> <p>Comparison of page size and assets types across different responsive widths. Source: <a href="http://speedcurve.com/demo/" target="_blank">SpeedCurve</a></p> <p>A great example using the above techniques is the new Guardian newspaper website, currently in <a href="http://www.theguardian.com/uk?view=mobile" target="_blank">alpha.</a> On average it&rsquo;s start render time is 3 seconds faster than the current Guardian site and the mobile width inlines CSS and is 42% smaller overall, leading to a 1 second saving over the desktop width.</p> <p><a href="http://speedcurve.com/demo/"><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/speedcurve-guardian-loaded.png" alt="SpeedCurve Guardian" /></a></p> <p>Comparison of full loaded time for new Guardian responsive site (Guardian NGW) vs current Guardian site and the New York Times. Source: <a href="http://speedcurve.com/demo/" target="_blank">SpeedCurve</a></p> <p>The Guardian have released their <a href="https://github.com/guardian/frontend" target="_blank">responsive code base</a> on Github so you can easily dig through their development setup and see these techniques in action.</p> <h2>Establish a performance baseline and then go performance&nbsp;first</h2> <p>Performance optimisations like these are often invisible and it can be hard to demonstrate a return on investment without clear metrics in place. Some of these techniques can require a significant amount of work and it&rsquo;s critical you establish a performance baseline first and then experiment with the techniques above to clearly show the improvements in user experience. There are great tools available to monitor the actual in <a href="https://www.pingdom.com/rum/" target="_blank">browser speed</a> and <a href="http://speedcurve.com/" target="_blank">benchmark your site</a> against others.</p> <p>Putting all these techniques together you can dramatically improve the performance of your responsive site. There&rsquo;s really no excuse for serving the same large sized assets across all browser widths. Make your responsive website respond not only to changing design patterns but to the browser environment it&rsquo;s being served into. <a href="http://bradfrostweb.com/blog/web/mobile-first-responsive-web-design/" target="_blank">Go mobile first</a> and performance first when designing and coding your next responsive website!</p> <p>Thanks to <a href="http://www.guypo.com/" target="_blank">Guypo</a> for his ongoing responsive research and <a href="http://www.patrickhamann.com/" target="_blank">Patrick Hamann</a> from The Guardian for letting me share their SpeedCurve dashboard.</p> Thu, 26 Dec 2013 00:00:00 +1300 New weekly emails https://speedcurve.com/blog/weekly-frontend-performance-emails <p>I've redesigned the weekly email reports to provide more trending information so you can compare week on week performance improvements. They're nice simple visualizations for forwarding around your whole team.</p> <p><img style="max-width: 660px;" src="https://cdn.speedcurve.com/img/blog/email-weekly.png" alt="Weekly frontend performance email" width="100%" /></p><p>Let me know what you'd like to see added to these emails.</p> Wed, 06 Nov 2013 00:00:00 +1300 Share dashboards, basic auth and export HAR's https://speedcurve.com/blog/share-dashboards-basic-auth-and-export-hars <p>New features:</p> <ol> <li>Share your dashboard via a private url. Find the link on the "account" page.</li> <li>During site setup you can now add a user/pass for developments sites using basic authentication.</li> <li>On the individual test pages below the waterfall are links to the underlying WebPagetest waterfall and ability to export a HAR file.</li> </ol> Tue, 15 Oct 2013 00:00:00 +1300 SpeedCurve dashboard walkthrough https://speedcurve.com/blog/speedcurve-dashboard-walkthrough-video <p> <script charset="ISO-8859-1" src="https://fast.wistia.com/assets/external/E-v1.js"></script> </p> <div class="wistia_embed wistia_async_er7vm722y6 videoFoam=true" style="width: 540px; height: 304px; margin-bottom: 25px;">&nbsp;</div> <p>See how powerful the SpeedCurve dashboard is for digging into your website's front-end performance.</p><p>Let me know which parts of the dashboard you'd like to learn more about.</p> Tue, 08 Oct 2013 00:00:00 +1300 Live! https://speedcurve.com/blog/live <p><img src="https://cdn.speedcurve.com/img/blog/launch.jpg" alt="Helena, Mark &amp; Bruno" width="100%" /></p> <p>SpeedCurve is now live! To mark the occasion I took the day off work and Helena &amp; Bruno helped send out the launch emails.</p><p>All done while stuffing our faces with cake at Vevo cafe in Titirangi, Auckland. We watched the stats explode and 3 people signed up for subscriptions before we finished our hot chocolates. Start how you intend to continue I say!</p> Tue, 08 Oct 2013 00:00:00 +1300 SpeedCurve elevator pitch https://speedcurve.com/blog/speedcurve-elevator-pitch-video <p> <script charset="ISO-8859-1" src="https://fast.wistia.com/assets/external/E-v1.js"></script> </p> <div class="wistia_embed wistia_async_o1xrcypjsz videoFoam=true" style="width: 540px; height: 304px; margin-bottom: 25px;">&nbsp;</div> <p>I've been having a blast over the last couple of weeks putting an intro video together for SpeedCurve.</p><p>Big thanks to Matt from <a href="http://www.assemblyltd.com/">Assembly</a>&nbsp;for casting an eye over my dodgy 3D AfterEffects camera work.</p> <p>This is just the elevator pitch and I'll be working on some product walk through videos shortly. Let me know what web performance techniques, strategies or theory you'd like to see explained in video format. I've been inspired by the charming team at <a href="http://wistia.com/learning">Wistia</a> to create a video learning center for SpeedCurve.</p> Thu, 26 Sep 2013 00:00:00 +1200 Speed Matters talk at Auckland Web Dev Nights https://speedcurve.com/blog/speed-matters-talk-at-auckland-web-dev-nights <p>Here's the slides from my presentation at the <a href="http://www.meetup.com/Auckland-Web-Dev-Nights/">Auckland Web Dev Nights</a> meetup. It's an overview of why front-end performance matter, how to monitor it and the challenges faced when building for an increasingly mobile world.&nbsp;</p> <p> <script class="speakerdeck-embed" src="//speakerdeck.com/assets/embed.js" async="" data-id="9355f4b0f8c90130ea303645efc5dc25" data-ratio="1.77777777777778"></script> </p><h2>Content</h2> <p>Why speed matters, examples of the impact saving a few seconds of load time has had on revenue and engagement. The network constraints and what makes the web slow? Bandwidth, latency and it's fundamental impact on the speed of the web. An overview of tools for measuring performance, uptime monitoring, real user monitoring and performance benchmarking. How to make your website faster. Optimization tools and techniques. Muti-device challenges. Responsive vs Adaptive and delivering to mobile within a second. Drop that donut superman!</p> <h2>Performance Tools</h2> <p>Diagnotic Tools<br /> <a href="http://www.webpagetest.org">WebPagetest</a> and <a href="http://www.youtube.com/watch?v=Z6_7r0faQpI">how to read a browser waterfall</a><br /> <a href="http://developers.google.com/speed/pagespeed/insights/">Google Pagespeed Insights</a><br /> <a href="http://developer.yahoo.com/yslow/">YSlow</a></p> <p>Uptime Monitoring<br /> <a href="http://www.pingdom.com/">Pingdom</a></p> <p>Competitive Benchmarking<br /> <a href="http://speedcurve.com">SpeedCurve</a></p> <p>Real User Monitoring (RUM)<br /> <a href="http://www.pingdom.com/">Pingdom</a><br /> <a href="http://www.newrelic.com">New Relic</a>&nbsp;(also backend, database and server health monitoring)<br /> <a href="https://support.google.com/analytics/answer/1205784?hl=en">Google Analytics</a><br /> <a href="http://www.soasta.com/products/mpulse/">mPulse</a></p> <h2>Performance Checklists</h2> <p><a href="http://stevesouders.com/hpws/rules.php">14 Rules for Faster-Loading Web Sites</a><br /> <a href="http://browserdiet.com/">25 tips on how to lose weight in the browser</a></p> <h2>References</h2> <p><a href="https://github.com/zenorocha/browser-diet/wiki/Impact-of-performance">Impact of performance improvements</a><br /> <a href="http://www.youtube.com/watch?v=YV1nKLWoARQ">Optimizing the Critical Rendering Path for Instant Mobile Websites (Video)</a><br /> <a href="http://www.guypo.com/mobile/what-are-responsive-websites-made-of/">What are responsive websites made of?</a><br /> <a href="http://blog.cloudfour.com/responsive-web-design-is-solid-gold/">Responsive web design is solid gold</a><br /> <a href="http://www.youtube.com/watch?v=bM0yL0eQ9EM">Etsy - Building Resilient User Experiences</a><br /> <a href="http://www.youtube.com/playlist?list=PL055Epbe6d5bdB4KPqssegVpYUDJXSzOp">Velocity Conference Videos</a><br /> <a href="https://github.com/zenorocha/browser-diet/wiki/References">Browser Diet References</a></p> <h2>Credits</h2> <p>These slides are heavily derived and mangled from awesome presentations by <a href="http://andydavies.me/">Andy Davies</a> and <a href="http://www.igvita.com/">Ilya Grigorik</a>. Illustrations by <a href="http://frogpants.bigcartel.com/product/56-geeks-12x18-and-20x30-inch-prints">Scott Johnson</a> via Browser Diet. Feel free to steal it, adapt it and spread the word on front-end web performance.</p> Thu, 05 Sep 2013 00:00:00 +1200 Sort browser waterfalls https://speedcurve.com/blog/sort-browser-waterfalls <p>Sort the items in a browser waterfall by Time, Savings and Slowest. Time is the default showing how assets loaded in the browser. Savings places assets at the top that have the greatest optimization potential and Slowest shows you which are the slowest overall requests. &nbsp;&nbsp;</p> Wed, 14 Aug 2013 00:00:00 +1200 Annotate your graphs https://speedcurve.com/blog/annotate-your-graphs <p>You can now annotate the main graph on SpeedCurve with notes about deployments or specific performance optimizations you may have put live. Just click on the "Annotate" link at the bottom right of the main graph to start adding them and comparing the before and after performance of your website. A vertical line will be placed on the graph where ever a note has been added.</p> <p><img style="width: 100%;" src="https://cdn.speedcurve.com/img/blog/annotate.jpg" alt="Annotate web performance graph" /></p> Sun, 21 Jul 2013 00:00:00 +1200 Easily add WebP, SVG and Retina responsive images to your site https://speedcurve.com/blog/easily-add-webp-svg-and-retina-responsive-images-to-your-site <p>A lot of sites are now using responsive design techniques to create great user experiences across mobile, tablet and desktop. Unfortunately images are often just set to 100% width with the same large image being delivered to all browsers and platforms. Picturefill was an important step in delivering responsive images and David Newton's fork now extends that approach to include WebP and SVG images in the mix you send down the pipe.</p><h2>Picturefill</h2> <p><a href="https://github.com/scottjehl/picturefill" target="_blank">Picturefill</a> is a fantastic browser polyfill by Scott&nbsp;Jehl that mimics the proposed picture element allowing you to deliver responsive images to users. It gives you control over what image is loaded and displayed at each browser width using conditional loading based on media queries. You can then curate each user's&nbsp;experience optimizing for screen proportions and assumed&nbsp;bandwidth. You could send smaller images with different aspect ratios to mobile users while desktop users with HiDPI Retina screens might get images twice as large as normal.</p> <h2>Now with file types</h2> <p><a href="http://davidnewton.ca/responsive-images-picturefill-type-attribute" target="_blank">David Newton</a> has forked <a href="https://github.com/nwtn/picturefill" target="_blank">Picturefill</a> adding detection for WebP and SVG, allowing you to combine the switching of sizes and formats into one easy to implement HTML structure.</p> <h2>30% smaller images with WebP</h2> <p>With WebP detection now in place it's easy to send this new image format to browsers that support it and save <a href="https://developers.google.com/speed/webp/docs/webp_study" target="_blank">24%-34%</a> in file size.&nbsp;WebP is a new image format from Google that provides lossless and lossy compression for images.&nbsp;The Chrome Web Store recently switched to WebP images and is&nbsp;<a href="http://blog.chromium.org/2013/02/using-webp-to-improve-speed.html" target="_blank">saving terabytes of bandwidth a day.</a></p> <p>If you're looking to experiment with WebP, <a href="http://www.xnview.com/en/xnconvert/" target="_blank">XnConvert</a> is an easy to use cross platform batch processing tool that supports WebP or grab the <a href="https://developers.google.com/speed/webp/download" target="_blank">latest package</a> from Google.</p> <p>I've added WebP to the SpeedCurve homepage and now people using Chrome and Opera actually get images <strong>56%</strong> smaller.</p> <p>For more on detail on the WebP format, development status and various implementation options check out the video below and Ilya Grigorik's great <a href="http://www.igvita.com/2013/03/07/faster-smaller-and-more-beautiful-web-with-webp/" target="_blank">overview of WebP.</a></p> <p><iframe src="https://www.youtube.com/embed/4tu2SJfSalA?rel=0" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> Sun, 07 Jul 2013 00:00:00 +1200 How SpeedCurve fits into your web performance toolkit https://speedcurve.com/blog/how-speedcurve-fits-into-your-web-performance-toolkit <p>Over the last few years the web performance monitoring toolset has expanded dramatically with the introduction of many new services and products. There are two main types of web performance monitoring, uptime monitoring and real user monitoring. SpeedCurve focuses on a third which I like to call web performance benchmarking.</p><h2>Uptime Monitoring</h2> <p>Uptime services like <a href="http://www.pingdom.com/" target="_blank">Pingdom</a> and <a href="http://www.uptimerobot.com/" target="_blank">Uptime Robot</a> ping your website with an HTTP request every couple of minutes to check that it's online and available. These services often check from various geographic locations to keep an eye on network routes to your server and will send you alerts via email and txt if your website is down. Reporting is often simplistic with just the load time of the initial HTML page reported but it's perfect for knowing if your server is up and running. It's often called synthetic testing as tests are run from servers in a data centre and don't accurately represent what speeds an actual user might get.</p> <h2>Real User Monitoring</h2> <p>Real user monitoring (RUM) sends performance data directly from a user's browser to a cloud service like <a href="http://newrelic.com/" target="_blank">New Relic</a> or <a href="http://www.google.com/analytics/" target="_blank">Google Analytics</a> that aggregates and reports on millions of combined measurements. RUM provides the most realistic picture of what users are actually experiencing in their browsers across different platforms and countries. Google Analytics recently updated their Site Speed report, allowing you to measure up to 10,000 page loads a day with a simple change to the <a href="https://developers.google.com/analytics/devguides/collection/gajs/gaTrackingTiming#sampleRate" target="_blank">sample rate</a> in your tracking code. RUM code must be added to the pages you want to track so you can only get detailed performance insights for your own website.</p> <p><img src="https://cdn.speedcurve.com/img/blog/newrelic.jpg" alt="New Relic" width="100%" /></p> <p>Real user monitoring dashboard on New Relic.</p> <h2>Web Performance Benchmarking</h2> <p>SpeedCurve is neither an uptime or real user monitoring service. We focus on bringing two important benchmarking techniques together in a way that no other product does.</p> <p>Firstly we provide detailed analysis of the build of your website over time. We dive right down into the detail of each request a page makes and demonstrate how your front-end code is effecting the performance of your site. Our analysis is based on the industry leading open source project <a href="http://www.webpagetest.org/" target="_blank">Webpagetest.</a> Importantly we do this analysis every 24 hours which allows you to monitor changes to your front-end code base over time, catching any regression issues and monitoring the ongoing effects of any performance optimization changes.</p> <p>Secondly we benchmark your website against two of your competitors or category leaders. We do this by monitoring 3 pages on each site so you get a robust across-site comparison rather than just individual pages. It's not just your homepage that needs to be fast. This benchmarking provides you with the relative performance of each website and allows you to see what a competitor might be doing differently to make their site faster than yours. Are they making less requests than you? Are their images more optimised and grouped into sprite sheets making them a full 2 seconds faster to load? SpeedCurve will tell you.</p> <p>Web performance benchmarking helps you focus on performance problems with your website build and compares you directly with your competitors to ensure you're keeping your users happy with a smokingly fast website.</p> <h2>Recommended Web Performance Toolset</h2> <p>It's vital you combine a real user monitoring tool with the build detail and competitive benchmarking that SpeedCurve provides. This way you get the best of both worlds with robust high level performance metrics from actual users and detailed build analysis and benchmarking from SpeedCurve.</p> <p>Our favourite RUM tool is <a href="http://newrelic.com/" target="_blank">New Relic</a> which gives you great insight across your stack from server health, uptime and backend right through to real user monitoring. It does require an agent to be installed on each server, so won't work for shared hosting. In that case use Google Analytics or Pingdom.</p> <p>Combine New Relic with SpeedCurve and you've got a very detailed picture of performance across your entire backend stack, the front-end of your site and your competitors.</p> Wed, 03 Jul 2013 00:00:00 +1200 Filter graphs by browser events https://speedcurve.com/blog/ <p>It's important to not obsess over the full load time of your website. The point at which a user can see content and interact with your site is arguably more important. To help keep a focus on this you can now filter the main graph by the different browser events like "start render" and "DOM complete".</p> Sat, 22 Jun 2013 00:00:00 +1200 SpeedCurve launches at Velocity Conf https://speedcurve.com/blog/speedcurve-launches-at-velocity-conf <p>SpeedCurve is now in beta. Sign up, check it out and then <a href="http://speedcurve.uservoice.com/forums/193594-general/filters/top">vote for the features</a> you'd like to see.</p><p><iframe src="http://www.youtube.com/embed/JTk26phHGZo?rel=0" width="560" height="315" frameborder="0" allowfullscreen=""></iframe></p> <p>A huge thanks <a href="http://stevesouders.com/">Steve Souders</a> for encouraging me to build SpeedCurve and introducing it at Velocity Conference 2013.&nbsp;</p> Wed, 19 Jun 2013 00:00:00 +1200