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. 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> 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> 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