Dion Almaer

Software, Development, Products

Web Development

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!

Die, Print Layout, Die…. the Chrome Extension

TL;DR I built a Chrome Extension that forces my layout of choice for Google Docs, all thanks to the escape hatches that extensions give you on the Web!

I admit to having a lil bit of OCD when it comes to my digital life. Seemingly small UI and UX choices irk my brain, and I spend a lot of time in Settings and Preferences tweaking my experience.

It’s because of this that I get frustrated when products don’t have the ability to tweak and change, often on purpose, claiming “a great product shouldn’t need complicated settings!”

I disagree. I want escape hatches, and all humans aren’t the same (nor use the product in the same way), especially for tools that you spend significant time in.

Facebook webOS edition 2010

Back in 2010, I got to work on the “official” Facebook app, for webOS. One of the great side effects here, was that we were able to sneak in a slew of power user features, and have keyboard shortcuts for everything.

The place to turn “Print layout” on and off

One of my ticks shows up in Google Docs. I rarely print documents, and thus rarely see the need for the notion of “pages”. For some reason, elves get into my computer and turn on “View => Print Layout”, even though I was constantly turning it off. Even when off, I don’t like the “——-” page break.

I knew I wasn’t the only one, as one way to bug Ben is to have this turned on as you go through something together, and then I saw this:

It was time to fix this…. once and for all!

Die, Print Layout, Die!

I have been enjoying building extensions recently so I fired up VS Code to create another one Die, Print Layout, Die, (open source code here) which simply makes sure to force off Print Layout mode when loading a document, and kills the page break.

Not only do I sleep better at night, not worrying over the elves and if they are messing with my layout, but this made my day:

Escape hatches FTW

I am very thankful that the Web has these escape hatches that enable the ecosystem to evolve products outside of the product development team.

This week, the local school district banned the use of Zoom, and my kids meetings were all moved to Google Meet. As this happened, teachers were emailing parents asking them to install the Google Meet Grid View extension so the kids could all see each other.

And folk from Shopify got in the game too!

There are trade offs on allowing this type of power, which is why we are looking to rebalance them via the next iteration of extensions (manifest v3). Grid view is an awesome feature, but the extension isn’t able to implement it as efficiently as the team itself, and this is often the case. However, it fills a gap and hopefully gets into the core product some time soon.

Once you get used to the power and extensibility, you feel constrained on platforms that don’t enable this kind of flexibility.

And when you get used to the flexibility, you look to extensions as a way to find functionality:

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 right thing to do, is the right thing to do.