• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Dion Almaer

Software, Development, Products

  • @dalmaer
  • LinkedIn
  • Medium
  • RSS
  • Show Search
Hide Search

Web Performance

Working on our Web Vitals together

May 5, 2020

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:

  • The Chrome UX Report (CrUX) surfaces histograms for all of the vitals of real world usage from Chrome, and a REST API is in the works
  • The small web-vitals JavaScript library is available for you to send metrics to your analytics provider of choice
  • A new Core Web Vitals extension will let you browse the web with a real-time view on vital results for your browsing, and will show the aggregate results from the CrUX Report in the future. This is a unified and much improved extension compared to my own!
  • Integration is coming to all of our tools: Lighthouse, Chrome DevTools, PageSpeed Insights, Search Console’s Speed Report

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.

If you (human) asked your computer you would be a centaur that would have gotten the answer!

Centaurs FTW!https://t.co/eZjx73bbJn https://t.co/AAUtAtFUCJ

— Dion Almaer (@dalmaer) April 19, 2020

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

April 2, 2020

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:

  • Load time:
    • First Contentful Paint (FCP): We see some content, looks like the page hasn’t errored out and is loading!
    • Largest Contentful Paint (LCP): I can see the most important bits of the page!
  • Interaction:
    • First Input Delay (FID): I am ready to interact with the page, and I can! (in the field)
    • Time to Interactive (TTI): In the lab, main thread has been free of long tasks for 5 seconds)
    • Total Blocking Time (TBT): In the lab, the total amount of time between FCP and TTI where the main thread was blocked for long enough to prevent input responsiveness.
  • Predictability:
    • Cumulative Layout Shift (CLS): Why is my UI jumping around?
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

April 4, 2019

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!

Next Page »

Primary Sidebar

Twitter

My Tweets

Recent Posts

  • I have scissors all over my house
  • GenAI: Lessons working with LLMs
  • Generative AI: It’s Time to Get Into First Gear
  • Developer Docs + GenAI = ❤️
  • We keep confusing efficacy for effectiveness

Follow

  • LinkedIn
  • Medium
  • RSS
  • Twitter

Tags

3d Touch 2016 Active Recall Adaptive Design Agile Amazon Echo Android Android Development Apple Application Apps Artificial Intelligence Autocorrect blog Bots Brain Calendar Career Advice Cloud Computing Coding Cognitive Bias Commerce Communication Companies Conference Consciousness Cooking Cricket Cross Platform Deadline Delivery Design Desktop Developer Advocacy Developer Experience Developer Platform Developer Productivity Developer Relations Developers Developer Tools Development Distributed Teams Documentation DX Ecosystem Education Energy Engineering Engineering Mangement Entrepreneurship Exercise Family Fitness Founders Future GenAI Gender Equality Google Google Developer Google IO Habits Health HR Integrations JavaScript Jobs Jquery Kids Stories Kotlin Language Leadership Learning Lottery Machine Learning Management Messaging Metrics Micro Learning Microservices Microsoft Mobile Mobile App Development Mobile Apps Mobile Web Moving On NPM Open Source Organization Organization Design Pair Programming Paren Parenting Path Performance Platform Platform Thinking Politics Product Design Product Development Productivity Product Management Product Metrics Programming Progress Progressive Enhancement Progressive Web App Project Management Psychology Push Notifications pwa QA Rails React Reactive Remix Remote Working Resilience Ruby on Rails Screentime Self Improvement Service Worker Sharing Economy Shipping Shopify Short Story Silicon Valley Slack Software Software Development Spaced Repetition Speaking Startup Steve Jobs Study Teaching Team Building Tech Tech Ecosystems Technical Writing Technology Tools Transportation TV Series Twitter Typescript Uber UI Unknown User Experience User Testing UX vitals Voice Walmart Web Web Components Web Development Web Extensions Web Frameworks Web Performance Web Platform WWDC Yarn

Subscribe via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Archives

  • February 2023
  • January 2023
  • September 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • November 2021
  • August 2021
  • July 2021
  • February 2021
  • January 2021
  • May 2020
  • April 2020
  • October 2019
  • August 2019
  • July 2019
  • June 2019
  • April 2019
  • March 2019
  • January 2019
  • October 2018
  • August 2018
  • July 2018
  • May 2018
  • February 2018
  • December 2017
  • November 2017
  • September 2017
  • August 2017
  • July 2017
  • May 2017
  • April 2017
  • March 2017
  • February 2017
  • January 2017
  • December 2016
  • November 2016
  • October 2016
  • September 2016
  • August 2016
  • July 2016
  • June 2016
  • May 2016
  • April 2016
  • March 2016
  • February 2016
  • January 2016
  • December 2015
  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015
  • January 2015
  • December 2014
  • November 2014
  • October 2014
  • September 2014
  • August 2014
  • July 2014
  • June 2014
  • May 2014
  • April 2014
  • March 2014
  • February 2014
  • December 2013
  • November 2013
  • October 2013
  • September 2013
  • August 2013
  • July 2013
  • June 2013
  • May 2013
  • April 2013
  • March 2013
  • February 2013
  • December 2012
  • November 2012
  • October 2012
  • September 2012
  • August 2012

Search

Subscribe

RSS feed RSS - Posts

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

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

Dion Almaer

Copyright © 2023 · Log in

 

Loading Comments...