Dion Almaer

Software, Development, Products

Web Performance

Working on our Web Vitals together

tl;dr We need your help to improve the collective Web Vitals. We are putting as much weight as we can behind these vital metrics across our tooling, guidance, and much more.

I am really excited to see the introduction of the Web Vitals program today. The web community has seen the maturation of web performance metrics over the years, and this program brings clarity around the “unified guidance for quality signals that, we believe, are essential to delivering a great user experience on the web.”

How are your vitals?

We want to be able to give you the best possible metrics that you can use to measure your user experience and how it maps to your business. The set of core web vitals is a great step in showing measures that tie well to the initial steps of a web journey: do your users perceive a fast load? can they interact with it? is it stable, or jumping around?

Why Vitals?

We are used to certain metrics as markers for our health, such as resting heart rate, blood pressure, blood sugar, and BMI. Together, they can help tell a story around your health. You can experiment and see how they change. Over time we understand more about these metrics, some go out of fashion as we get new data, but we strive to find those that seem to have the best correlation to health.

All humans are not the same, and we add a layer of context on top of the metrics. A marathon runner will differ from a sprinter, just as a rich desktop web application that sits in the first tab differs from a piece of content that you tap to read and move on, but the metrics are useful to understand across the board, your weighting may vary.

Hitting the bar together

A good experience is the sum of the parts, and the entire ecosystem has a role to play in making sure the web performs great for all users. From hardware though OS, network. web platform, libraries and frameworks, and finally the application code… we all have a role to play.

At the end of the day, it’s the web developer and team who deploy their app, and understands the particular context, that have final control of the outcome.

We want to make sure that everyone along the stack has the best possible information, tools, and guidance, and while we are far from being done, I am glad to see the following launch with the program today:

I hope that the ecosystem makes sure to measure and understand their effect on these vitals, and share how best we can hit them.

I remember a developer at a Chrome DevSummit asking for us to fix the performance problem:

“The web feels too slow and janky at times, and why do browsers take so much memory?”

– Web E. Developer

While we have some levers to help for sure, and will be pushing on as many as we can, we need all of the brains in the community to solve this problem.

I admit that it is tempting to think “let’s fix it in the platform!” but that isn’t the area with most leverage for this one, and if you read Range you will see that it is when generalists with varied expertise and life experience come together that you see the most creative solutions and real impact.

So, we have huge datasets in the wild, richer tooling, and goals to hit for each metric. Let’s work together to make a dent and hit them!

Browsing the Web while watching it’s vitals

TL;DR I built some Chrome Extensions that show you vital metrics for sites as you browse the Web. Here I discuss the current metrics of choice, the extensions, and finish with some magic.

It sure is unprecedented times. My mental state has fluctuated between anger, frustration, grief, guilt (privilege), and beyond. I am thankful for the people in my life who have been amazing, and I am globally thankful to all of the people who are either staying at home to help flatten the curve, or who are courageously doing their duties.

Working (and loving!) from home has been a reset, and I am trying to use that reset by setting up new habits (tiny!) whilst also not being hard on myself for hitting them all.

One of these has been giving myself time to write a little code on something I have wanted to have in my browser for awhile.

web.dev/metrics

What’s the latest with Web Performance Metrics?

We all want to have great metrics that reflect the quality of our web experiences, and use them as guides for how we can improve.

These metrics have changed over time, as we get better at understand the mapping of the browser engine to parts of the experience.

At web.dev/metrics you will see a current set of metrics that each look to understand a different piece of the overall experience:

This video goes into the metrics and much more on speed!

At the last Chrome DevSummit, we spoke about the evolution of metrics, and how they are rolling out across our tooling.

For example, in the field it always starts with Chrome instrumentation, which will then get picked up in CrUX, which will be reused in tools such as PageSpeed Insights.

In the lab, you get access to them as Lighthouse and DevTools implement support.

github.com/dalmaer/lcp-chrome-extension (The LCP extension)

Chrome Extensions that show the metrics

After spending time looking at metrics while developing, and spelunking in the CrUX datasets, I found myself wanting to feel the impact of the metrics, so I decided to build some ambient Chrome Extensions.

There are individual extensions that show scores as the browser’s PerformanceObserver spits them out, and change color depending on the thresholds of each metric.

For example, the LCP extension will be green if it occurs in less than 2.5 seconds (a good score), yellow if between 2.5 and 4 seconds (an adequate score), or red if it takes longer.

There are equivalent extensions for FCP, FID, and CLS.

Now that I have been browsing around the Web, what has surprised me the most is how variable the results can be with N=1. If I load a page while a message comes in to Hangouts Chat and I am on a VC…. it may be slow. When developing, it’s important to isolate your environment… something that we very much notice with Lighthouse development too.

It is also kinda fun to dive into a page when there is an expectation mismatch. I will think to myself “huh, that seems like a decent load, why is the CLS so bad?” and start digging…. and come to find that the web fonts loaded slow and did a swap, causing layout instability (most of the time its ads loading late and resulting in the change to be fair).

It’s been really nice having the traffic lights give me some feedback as I browse and letting me explore, but this is only the beginning. The product teams are working on much better tooling that can showcase this type of information, and also tie deeper into tooling to give you actionable feedback.

Don’t forget the magic

Hitting these thresholds are good guides for a quality experience, and they are only going to get better over time. It is important that we all take them into account, but also important not to do so blindly.

I like Derren as he explains that his magic is not magic (as it doesn’t exist 😉

I have been enjoying me some Darren Brown action, such as the classic video above. He used a series of techniques in his shows, and good ole misdirection is always involved.

Misdirection is a key trick with UI development too, as the goal centers around the perception of quality. This can sometimes be a touch at odds with pure metrics, as the browser engine may not be fully aware of the tricks that you are playing.

This is why it’s important to consider custom metrics such as the Element Timing API to measure what is really important to see on the page (which may not be the largest element that LCP will fire).

There are some absolutes (human perception research shows those), but it always makes sense to go the extra mile and really understand how users are using your site…. and using the appropriate tricks. It turns out we are simple bears that can only focus on a small area 😉

The Doomed Rewrite

It just happened again. I spoke to a company, with some great engineers, and they just experienced the doomed rewrite.

I remember the days of the Monty Hall Rewrite, which is a situation I would much prefer to DOOM. With Monty Hall, you run into the following situation:

  • A website uses a given tech stack. It feels legacy, and the team gets to a point where it is time to consider a rewrite, to wipe clean the technical debt. This is a very expensive decision, and often the better path is to iterate, but there does often come a time
  • A new website is created, using a newer, shinier, tech stack
  • There is a comparison made between the two, which often isn’t very fair, as it muddies the water based on the fact that the difference isn’t just the tech stack. You have all of the domain knowledge and learnings from the older version(s).

The doomed version, when you choose door three, follows a similar path, but the ending isn’t as happy.

You are not Google, is a great post that basically describes the important value in taking the time to understand that you should validate that you are choosing the right tool for the job. It focuses on backend infrastructure, but the same arguments can be made in the world of frontend.

Just as it is important to understand the problem that Cassandra was solving (database writes for the Add to Cart action), it is important to think through the front-end needs (e.g. what are Facebook’s biggest needs with React, or Google’s with Angular, or Lit, etc).

You want to create the right balance for your needs, and they are varied.

For example, the scenarios below are not the same:

  • You have an existing business at scale, and need to be able to build something that results in higher quality, developer velocity, and will scale with your growth
  • You are creating a new product, and need to build an experience that will find product market fit. Quality attracts, so you don’t want use a stack that will hurt you from finding this fit, but if everything takes off like a rocket ship and you need to rewrite…. that is a win condition

The doom scenario that I am seeing far too often these days relates to the first scenario. A great business is in place, but technical debt has caught up to the team, and they want to take a chance to rewrite in a modern stack that will result in a beautiful PWA experience that will scale to all of their users use cases.

The new stack is assembled, and a small prototype is built against the legacy APIs. It works! Full steam ahead! Fast forward to the launch of the new version, and oops….. it’s kinda slow.

Lighthouse is run for audits, and WebPageTest shows you The Truth in The Trace, and the team has that sinking feeling. The good news is that there are some quick wins: some preconnect, prefetch, and preloads help the cause, images are squooshed, etc.

“There are 44 copies of Object.assign polyfills!”

— Default pit

But this isn’t enough. There’s just way too much JavaScript. Unfortunately, it really is far too easy to npm install yourself to large dependency chains that all bring in polyfills and just a ton of code. It’s time to go back to the drawing board, and see what needs to be re-architected. Just when you were ready to build off of the new base, you have to work on fixing the foundation, and you have that dreaded thought….. do we need to rewrite the rewrite?

This is when I start to tear up. All of that work, and you aren’t at the promised land at all.

How do you avoid this?

You need to start with a performance budget, and stick to it as you grow. Make sure your architecture scales as the app builds (e.g. each new page doesn’t add to a huge bundle that has to be loaded at once. Code split FTW).

Choose the right tools for the job. If you are a content site that averages 1.2 pages per user session (you know who you are 😉…. don’t load the entire world up front. Just show the content. Think about the areas of first load and separate that from subsequent loads. E.g. if you have more of an app, follow the Netflix pattern and have a super lean home / login that then loads up “the app” once there is time (users take time to read…. that’s great Idle time to do work!).

It’s never been a better time to build a web app that can scale to users across feature phones, smart phones, tablets, desktop, and more. If you hit the quality bar you have happy users coming to you from search and social…. and your loyal users will add you to their home screen, from the browser or store.

There is a lot we can do to make great experiences occur as more of a side effect of the toolboxes we have available, but even still: Run. Lighthouse. Early. And. Often. And then you will be set up to brag about your successful Monty Hall rewrite.

Want to learn more about getting started? Check out web.dev!

The right thing to do, is the right thing to do.