Speed Matters RSS

New LUX JavaScript Dashboards

As organizations work to improve performance for users around the world on slower networks and devices, the focus on JavaScript continues to grow. LUX's new JavaScript dashboards help to identify the problems and solutions for creating a fast, joyous user experience.

LUX is SpeedCurve's real user monitoring product. We launched it two years ago with four dashboards: Live, Users, Performance, and Design. Today we've added two more LUX dashboards: JavaScript and JS Errors. These new dashboards let you see the impact JavaScript has on your site and on your users with new metrics, including First CPU Idle and First Input Delay, and new features, such as correlation charts that show you how CPU time correlates with bounce rate.

Continue reading...

Chart sizes and TV Mode

SpeedCurve now has different chart sizes and a special TV Mode to help you build a performance culture in your organisation. 

TV Mode

From its inception, SpeedCurve has always been designed to look awesome on the big screen. We see SpeedCurve as not just a tool for debugging web performance, but as a communication tool to rally your organisation around the importance of web performance. SpeedCurve helps bring together the development, design, and management teams, and gets everyone focused on turning your product into a fast and joyous experience for your users. 

Continue reading...

JavaScript dominates browser CPU

Loading scripts asynchronously is critical for getting pages to render more quickly. We care about rendering because that's what users see; if rendering is slow users have a negative experience. But it's not just about what users see - how the site feels is also important. That's why we focus so much on CPU time. If the CPU is blocked, then browsers are delayed responding to user interactions like scrolling and clicking on links. In other words, the page feels janky. And what consumes the most CPU in browsers? You guessed it: JavaScript!

Desktop median CPU times

Continue reading...

New LUX metrics

Over the winter holiday we added a bunch of new metrics to LUX:

  • First Contentful Paint
  • First CPU Idle
  • Longest Long Task
  • Number of Long Tasks
  • Connection type
  • HTML transfer size
  • Total # of image requests

Continue reading...

Preload scripts

In my previous post I talked about how loading scripts asynchronously reduces the impact of JavaScript resulting in a (much) faster user experience. But even when scripts are loaded async, the browser may still twiddle its thumbs for a second or more waiting for the first script to arrive. This delay can be decreased by using link rel=preload like this:

<link rel="preload" href="main.js" as="script">

Continue reading...

2018 recap

One of the things that makes SpeedCurve great is the amazing feedback our customers give us – feedback we use to make our tools even better. 

In the past year, awesome customer input has helped us roll out some exciting new features in Synthetic and LUX:

  • Monitor JavaScript performance 
  • Create custom dashboards and charts, including histograms and correlation charts
  • Create performance budgets and set alerts 
  • Monitor all your performance budgets at a glance
  • Generate user-friendly weekly email reports
  • Track Lighthouse scores – including the ability to aggregate and prioritize all your audits across all your pages 
  • Support important new RUM metrics: CPU time and First Input Delay 

Continue reading...

Load scripts async

This blog post has a simple conclusion: Load script asynchronously! Simple, and yet the reality is that most scripts are still loaded synchronously. Understanding the importance of loading scripts asynchronously might help increase adoption of this critical performance improvement, so we're going to walk through the evolution of async script loading starting way back in 2007. Here's what loading 14 scripts looked like in Internet Explorer 7:

IE7 Waterfall

Continue reading...

Trend metrics and compare time periods

The Internet really is a complicated series of tubes. As a result, any time-based metrics we capture can have variations as those tubes wobble a bit as we shove data down them. To help reduce that variation, when we do synthetic tests, we always load a page at least three times and take the median result. But even then you'll find that, over time, your charts will still show plenty of variation.

All that variation can make it difficult to see if your metrics are getting better or worse over time. We recently released a couple of new features in your Synthetic and LUX charts that make it easier for you to visualize trends and compare discrete time periods within your historical data.

Highlight trends in your metrics

To make it easier for you to see which direction your metrics are heading, we've added an option to all your charts to show a trend line which helps you visualize how a particular metric is changing over the timespan of the chart. You can hover over the legend to highlight a trend line or hover over any point on the trend to see the estimated value at that point.

Trends

Continue reading...

JavaScript growth and third parties

JavaScript is the main cause for making websites slow. Ten years ago it was network bottlenecks, but the growth of JavaScript has outpaced network and CPU improvements on today's devices. In the chart below, based on an analysis from the HTTP Archive, we see the number of requests has increased for both first and third party JavaScript since 2011.

JS Requests

Continue reading...

Getting started with performance budgets

Making your site fast is just the first step in your performance journey. You also have to keep it fast. This is why you need performance budgets.

Performance budgets aren't exactly new. People have been talking about them for at least five years. But over the past few months, performance budgets have moved into the spotlight – recently culminating in this excellent post by Google engineer Addy Osmani.

[tweet]

In this post, I'm going to explain what a performance budget is, 

Continue reading...

Metrics from 1M sites

The number of performance metrics is large and increases every year. It's important to understand what the different metrics represent and pick metrics that are important for your site. Our Evaluating rendering metrics post was a popular (and fun) way to compare and choose rendering metrics. Recently I created this timeline of performance metric medians from the HTTP Archive for the world's top ~1.3 million sites:

Desktop metric timeline

Continue reading...

Deeper performance analysis with histograms and correlations

This week we've made some pretty exciting new changes to your Favorites dashboards. Aside from a brand-new chart editor interface, you'll also notice that we've introduced two new chart types: histograms and correlations.

In this post, I'm going to talk through some of the features in our new chart editor. I'll also explain in detail explain why I think histograms are such an important tool in your performance toolkit, and how you can get some fascinating insights by correlating other metrics on top of a histogram.

Continue reading...

Performance culture, part 2

One of the things I love about my role here at SpeedCurve is that I get to spend hours every week talking to our users – not just about our tools, but about the problems people are trying to solve with them. 

The current state of performance monitoring is pretty darn good. That's not to say there isn't room for evolution (and we're certainly working hard behind the scenes to make SpeedCurve's tools even better), but we're light years ahead of where we were ten years ago, when we were happy just to be able to measure load time on a single page. 

The more I listen to the people who use our tools, the more I realize the biggest challenge people face isn't technological – it's people. 

  1. You don't have enough people.
  2. You don't have the right people.
  3. Your people don't have enough time.
  4. Your people don't have a strong performance mandate from the people they report to.
  5. Your people are gatekeeping essential tools and data.

I can't help with problems 1 through 3, but I can offer some suggestions for 4 and 5.

An analysis of Chromium's paint timing metrics

Here at SpeedCurve, we are continually gathering detailed performance data from tens of thousands of web pages. This gives us a relatively unique opportunity to analyse and aggregate performance metrics to gain some interesting insights. In this post, I'm going to analyse some browser-based paint timing metrics: First Paint & First Contentful Paint (defined in the Paint Timing spec and implemented in Chromium). I'm also going to analyse First Meaningful Paint (defined in a draft spec and implemented as a Chromium trace metric).

What are paint timing metrics?

The aim of almost any performance optimisation on the web is to improve the user experience. The folk at Google have been pushing this sentiment with a focus on user-centric performance metrics, which aim to answer four questions about users’ experiences:

  1. Is it happening? Is the page that I want to see actually loading?
  2. Is it useful? Has enough content rendered that I can engage with it?
  3. Is it usable? Can I scroll and interact with the page, or is it still loading?
  4. Is it delightful? Are my interactions with the page smooth?

First Paint (FP) measures the point at which pixels are first rendered to the screen after navigating to a new page. First Contentful Paint (FCP) is slightly more specific, in that it measures the point at which text or graphics are first rendered to the screen. Both of these metrics are available in Chromium browsers (Chrome, Opera, Samsung Internet, etc) via the Performance API: performance.getEntriesByType('paint').

The paint timing metrics are important because they aim to answer the first question: is it happening? My analysis will look at performance data from some popular websites in an attempt to figure out whether the paint timing metrics really do answer that question.

Continue reading...

Performance improvement checklist for your whole site

One of the longest-standing items on my performance monitoring tool wishlist is an automatically-generated performance improvement checklist, with the improvements ordered by the impact that they will have on the website. In a previous life, I spent countless hours writing performance reports and conducting A/B performance tests to figure out which change would have the biggest impact on a website's performance.

So I'm understandably very excited that today we're announcing the new Improve dashboard – a prioritised performance improvement checklist that aggregates Lighthouse and Google PageSpeed results across all the URLs in your site to identify the most impactful performance changes you can make.

Continue reading...

Lighthouse scores now available in your test results

In the year since Google rolled out Lighthouse, it's safe to say that "Will you be adding Lighthouse scoring?" is one the most common questions we've fielded here at SpeedCurve HQ. And since Google cranked up the pressure on sites to deliver better mobile performance (or suffer the SEO consequences) earlier this month, we've been getting that question even more often.

We take a rigorous approach to adding new metrics. We think the best solution is always to give you the right data, not just more data. So we're very happy to announce that after much analysis and consideration, we've added Lighthouse scores to SpeedCurve. Here's why – as well as how you can see your scores if you're already a SpeedCurve user.

Continue reading...

Ouch, your JavaScript hurts!

When looking to improve the performance and user experience of our sites we often start by looking at the network:

What's the time to first byte?
How many requests are we making and how long are they taking?
What's blocking the browser from rendering my precious pixels?

While these are entirely valid questions, over the last few years we've seen a growing number of web performance issues that are caused, not by the network, but by the browser's main thread getting clogged up by excessive CPU usage.

Continue reading...

First Input Delay shows how quickly your site responds to user interaction

We're excited to announce the availability of the First Input Delay metric as part of LUX, SpeedCurve's RUM product.

First Input Delay

Continue reading...

Monitor performance budgets at a glance with your Status dashboard

This may sound counter-intuitive, but we don't want you to spend countless hours using SpeedCurve. In fact, our goal is to make your web performance data so accessible, understandable, and actionable that you can get everything you need from us in just a few minutes.

That's why we're so excited to announce the brand-new Status dashboard – a visualization that lets you see at a glance all your web performance budgets, as well as which budgets have been violated.

Keep reading to find out how to start using your Status dashboard to diagnose and fix your performance pains. But first, let's talk about why we built this feature.

Continue reading...

Weekly email reports from your SpeedCurve dashboards

Part of building a strong performance culture in an organisation is lowering the barrier to getting people excited about performance. One of the most effective ways I've found to do this is to send around a performance report every week that can, at a glance, answer an important question: did performance get better or worse?

That was the motivation behind our new Weekly Report feature. Now you can configure any of your Favorites dashboards to be summarized in a weekly email, like this one:

Weekly report email screenshot

Continue reading...

Using RUM to track CPU time

It's exciting working at SpeedCurve and pushing the envelope on performance monitoring to better measure the user's experience. We believe when it comes to web performance it's important to measure what the user sees and experiences when they interact with your site. A big part of our focus on metrics has been around rendering including comparing TTI to FMP, Hero Rendering, and critical blocking resources.

The main bottleneck when it comes to rendering is the browser main thread getting blocked. This is why we launched CPU charts for synthetic testing over a year ago. Back then it wasn't possible to gather CPU information using real user monitoring (RUM), but the Long Tasks API changes that. Starting today, you can track how CPU impacts your users with SpeedCurve's RUM product, LUX.

Continue reading...

Introducing Last Painted Hero

We're excited to announce that we've launched Last Painted Hero as an official metric. Last Painted Hero is a synthetic metric that shows you when the last piece of critical content is painted. Keep reading to learn how Last Painted Hero works, why (and how) we created it, and how it can help you understand how your users perceive the speed of your pages.

The case for smarter heuristics

When choosing the right performance metric, my soapbox for the last few years has been "not every pixel has the same value". In other words, rather than chase dozens of different performance metrics, focus on the metrics that measure what's critical in your page.

Here at SpeedCurve, we think it's good to focus on rendering metrics, because they're a closer approximation to what the user experiences. There are some good rendering metrics out there, like start render and Speed Index, but the downside to these metrics is that they give every pixel the same value. For example, if the background renders and some ads render, that could improve your start render time and Speed Index score, but it might not have a big impact on the user's experience. Instead, it's better to measure the parts of the page that matter the most to users. We call those parts of the page the "hero elements".

Continue reading...

SpeedCurve Consulting Services with Tim Kadlec

We're excited to announce that SpeedCurve is partnering with Tim Kadlec to provide consulting services to our customers!

Tim is a recognized expert when it comes to web performance. He has spoken at numerous conferences including Velocity, Fluent, QCon, SmashingConf, Beyond Tellerand, and WebStock. He wrote High Performance Images and Implementing Responsive Design, as well as contributing to other books. Mark, Tammy and I have each collaborated with Tim on side projects. We're full of gleeful anticipation as we look forward to this opportunity to work together again.

In the first sentence I mentioned that this is a partnership. Here's what that means: Tim will continue to do consulting outside of SpeedCurve, and if you're not a SpeedCurve customer we encourage you to contact him directly. Tim will also be running SpeedCurve's consulting services. This partnership brings special advantages to SpeedCurve customers:

Continue reading...

More RUM metrics in your Favorites dashboards

SpeedCurve comes with a great set of dashboards for synthetic and RUM. But we know that one size does not fit all when it comes to data charts, which is why we've invested so much work into the Favorites dashboards. For customers who use LUX, it provides a place to create custom charts that combine metrics from synthetic and RUM.

We just added some new RUM metrics from LUX in Favorites to allow for even more customized monitoring:

  • Page Views – The number of page views, including Single-Page-App page transitions
  • Sessions – The number of unique sessions
  • Session Length – The number of page views per session
  • Bounced Sessions – The number of sessions that only have one page view
  • Bounce Rate – The percentage of bounced sessions out of the total number of sessions

Continue reading...

Performance budgets are your friend

Continue reading...

PREVIOUS NEXT RSS