Speed Matters

Measuring Blocking Resources

SpeedCurve reports the number of critical blocking resources in the page. These are the resources that block rendering. Since it's important that users see your content as quickly as possible, it's important to know what might be causing your page to render slowly. We recently enhanced the way we measure blocking resources and wanted to share those improvements with our customers as well as the performance community at large. 

The main culprits that block rendering are scripts and stylesheets that are loaded synchronously. A great way to avoid this blocking problem is to load your scripts and stylesheets asynchronously. You can do that for scripts by using the async and defer attributes, plus other programmatic techniques. Loading stylesheets asynchronously is less popular but is still possible using techniques like loadCSS

Continue reading...

SpeedCurve RUM: LUX

We're excited to announce SpeedCurve's RUM product, LUX.

The name LUX is a play on "Live User eXperience" 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. 

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. LUX's RUM metrics help you figure out which design and development improvements will make your users happier and your business more successful.

Continue reading...

Build your own charts

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.

Here's a walkthrough showing you how to slice the available data in different ways:

 

Continue reading...

Track down front-end CPU hogs

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.

CPU usage for all Chrome tests

For any of SpeedCurve's 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 pixels?

We also measure the CPU usage to different key events 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 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.

In the test 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.  

CPU pie charts

Continue reading...

SpeedCurve Waterfall

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 every day, but the waterfall chart I love the most is the one we've built at SpeedCurve:

SpeedCurve waterfall

Continue reading...

PWA Performance

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.

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.

Continue reading...

Measuring the User Experience

SpeedCurve’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 “the DNS lookups are too slow” or “the load event fired late”. Instead, users get frustrated when they have to wait for the content they care about to appear on the screen.

The key to a good user experience is quickly delivering the critical content.

Continue reading...

More emulated devices and improved flexibility

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 and to allow different testing configurations for different sites.

Continue reading...

Critical Blocking Resources

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.

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 ESPN, 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 interactive waterfall chart.

ESPN critical waterfall

Continue reading...

User Timing and Custom Metrics

If you want to improve performance, you must start by measuring performance. But what should you measure?

Across the performance industry, the metric that's used the most is "page load time" (i.e, "window.onload" or "document complete"). 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 comparing Gmail to Amazon.

In the last few years some better alternatives to page load time have gained popularity, such as start render time and Speed Index. 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.

Any performance metric that values all the content the same is not a good metric.

Users don't give equal value to everything in the page. Instead, users typically focus on one or more 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 necessary for website owners to put these performance metrics in place. The way to do this is to create custom metrics with User Timing.

Continue reading...

Performance budgets in action

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 Setting a Performance Budget. The idea is to identify your performance goals and track the metrics that help you achieve your goals.

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.

Image performance budgets

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

Continue reading...

Visual diffs on every deploy

SpeedCurve now provides a visual diff of every deploy. A full resolution PNG is captured for each URL and each pixel is diffed with the previous deploy allowing you to easily spot any visual changes you may or may not have expected.

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

We do a visual diff every time you click "Test Now" on the Deploy dashboard or you use the SpeedCurve API to trigger a round of deploy testing. Integrating with the Deploy API is super easy and provides a robust set of metrics and before/after screenshots, visual diffs, waterfall charts, filmstrips and videos for each deploy. You can then compare any two deploys to see exactly what's changed over time.

Continue reading...

Multiple teams and multiple users

This week we added support for organizations with multiple teams and multiple users.

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’ve done that and if not we’d love your feedback.

Continue reading...

UX Focus for Waterfalls and Third Parties

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.

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 CSS that might be blocking the page from rendering. I recently used this new combined waterfall and filmstrip view to identify a common issue with hero images being delayed.

Continue reading...

The language and metrics of UX evolve at Velocity 2015

Originally published on the O'Reilly Radar Blog

I’ve attended four O’Reilly Velocity conferences 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 of their websites and apps from the user’s perspective.

The balance has shifted from just talking about how fast or reliable a particular system is to the overall experience a user 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 “user” and “user experience” were mentioned again and again by speakers.

Here are recent talks from Velocity and other events that highlight this shift to UX concerns.

Continue reading...

Responsive Design Dashboard

The dramatic growth of mobile traffic has created an urgency for websites to adapt to different screen sizes. Responsive design 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.

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 Google announced that websites need to deliver their design appropriately and quickly on mobile devices or they will be demoted in Google's search results.

How can you know if your website matches these standards for adaptive content and speed? SpeedCurve's Responsive Design Dashboard answers both questions in one view.

Responsive Filmstrips

Continue reading...

Mark+Steve, Performance+Design

I'm excited to announce that I've joined SpeedCurve!

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

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!

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 and fast. The trick is figuring out how to do that. That's where SpeedCurve comes in.

Continue reading...

Velocity: Better performance through better design

Improve web performance by improving your design process… it needs to be iterative, mindful, principled and visual.

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.

Continue reading...

Velocity: A better waterfall chart

The way we visualize performance data can have an impact on how we interpret and communicate performance issues within our teams.

In this talk from Velocity New York 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.

Skip to 15:30 if you just want to see the data visualization experiments, and you can play with them directly on lab.speedcurve.com

One of these experiments was also turned into a performance heatmap bookmarklet.

Continue reading...

Velocity: Responsive in the wild

I was lucky enough to give a Lighting Demo at Velocity Conference in Santa Clara. The focus was on research I conducted into 250 responsive websites and how well optimized for performance they were.

Continue reading...

Faster EC2 testing agents

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.

Continue reading...

Speed Index now available

Speed Index is now available on SpeedCurve. Choose "SpeedIndex" from the top right of the main graphs.

Speed Index

Continue reading...

IE11 and average speed update

To keep inline with browser trends and average connection speeds SpeedCurve will begin updating the test setting every quarter.

For Q2 2014 we're switching to IE11 which is now the most popular version of IE according to Akamai and StatsCounter 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 State of the Internet report from Akamai. 

SpeedCurve wins Webstock BNZ Start-Up Alley

I'm stoked that SpeedCurve has been chosen as one of two winners in the 2014 Webstock Start-Up Alley. I'll be using the 10k prize money and two flights to the US to attend Velocity Conf in San Fran in June and New York in September.

Performance tips for building responsive sites

The following article was originally published in the 2013 Performance Calendar. There's 31 great articles to explore in the calendar including Steve Souders's browser wishlist and Tim Kadlec's take on what it takes to create a performance culture.

----

Responsive Web Design (RWD) is now a well established technique yet it’s adoption is still surprisingly low. Guy Podjarny’s recent research 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 performance concerns and a lack of established techniques have made some hesitate when considering RWD adoption.

Page size by file type

Responsive page sizes across different screen resolutions. Source: Guy Podjarny

Continue reading...

New weekly emails

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.

Weekly frontend performance email

Continue reading...

Share dashboards, basic auth and export HAR's

New features:

  1. Share your dashboard via a private url. Find the link on the "account" page.
  2. During site setup you can now add a user/pass for developments sites using basic authentication.
  3. On the individual test pages below the waterfall are links to the underlying WebPagetest waterfall and ability to export a HAR file.

SpeedCurve dashboard walkthrough

 

See how powerful the SpeedCurve dashboard is for digging into your website's front-end performance.

Continue reading...

Live!

Helena, Mark & Bruno

SpeedCurve is now live! To mark the occasion I took the day off work and Helena & Bruno helped send out the launch emails.

Continue reading...

SpeedCurve elevator pitch

 

I've been having a blast over the last couple of weeks putting an intro video together for SpeedCurve.

Continue reading...

Speed Matters talk at Auckland Web Dev Nights

Here's the slides from my presentation at the Auckland Web Dev Nights 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. 

Continue reading...

Sort browser waterfalls

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.   

Annotate your graphs

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.

Annotate web performance graph

Easily add WebP, SVG and Retina responsive images to your site

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.

Continue reading...

How SpeedCurve fits into your web performance toolkit

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.

Continue reading...

Filter graphs by browser events

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

SpeedCurve launches at Velocity Conf

SpeedCurve is now in beta. Sign up, check it out and then vote for the features you'd like to see.

Continue reading...

RSS