Home / Newsletters /

#223: Core Web Vital Tooling

Core Web Vital Tooling

Core Web Vitals is how Google measures the performance of any given site and you might’ve already heard the buzzwords like LCP, FID, and CLP. But — these are actually really useful metrics to figure out how to improve performance. So here they are again:

  1. Largest Contentful Paint (LCP)
  2. First Input Delay (FID)
  3. Cumulative Layout Shift (CLS)

In my head, I find it useful to translate these into questions:

  1. When can we see the content?
  2. When can we interact with the website?
  3. Is the website content stable yet?

Chris writes:

When I first got into caring about performance, it was all: reduce requests! cache things! Make stuff smaller! And while those are all very related to web performance, they are abstractly related. Actual web performance to users are things like how long did I have to wait to see the content on the page? How long until I can actually interact with the page, like type in a form or click a link? Did things obnoxiously jump around while I was trying to do something? That’s why Core Web Vitals are smart: they measure those things.

That’s why we need to think about performance from three different perspectives. So, for example: you might have a super fast LCP (meaning that the content is available very quickly). But! You might have a ton of ads and images and videos being loaded on the page which might impact the layout (CLS). This happens to me most frequently on large news websites — I try to click a link and then the rug is pulled out from beneath me and I’m now clicking a different link. Gah!

All of these different metrics for performance can be measured with a bunch of new tools, including SpeedCurve and Calibre, where Karolina Szczur wrote about their importance:

If you’re not tracking and improving your Core Web Vitals, your Performance Score will be lower. A worse Performance Score means lower search ranking and worse user experience for your customers.

Us web developers have to familiarize ourselves with this stuff if we want to make our websites fast and our customers happy.

Here’s another distinction that is worth wrapping your mind around. When doing performance testing, there is what is known as RUM (“real user monitoring”) and synthetic (e.g. run tests in a headless browser). Both of these are useful!

I mention this because I’ve seen some chatter recently talking about how one-or-the-other is the only one that matters. First, when it comes to Web Core Vitals, the metric First Input Delay (FID) can only be measured by RUM, so RUM is clearly important there, but also because, ya know, measuring actual users performance is important because that is real information about how your real users are experiencing your site. But once you have RUM, that means you’ve already shipped code to production. Synthetic data is the only kind you can get while you’re, say, running performance tests against Pull Requests, which is also a damn fine idea.

In Defense of Tables and Floats

John Macpherson wrote this great piece that gives an odd bit of advice: let’s keep using tables and floats!

So after more than 20 years of being put through the ringer, you might think we should avoid tables altogether. If you’ve never shipped a table-based layout, you’ve undoubtedly heard war stories from those of us who have, and those stories are never kind. It’s like we’ve sort of made tables the “Internet Explorer of HTML elements.”

But that’s not totally fair because tables do indeed fill a purpose on the web and they are indeed accessible when they are used correctly…

In the past when I’ve paired with folks on a front-end problem, I’ve found it interesting that so many of them tend to believe that tables are bad for accessibility and bad for the web. But as John writes, that’s just not true. If you’re using tables for layout, then yes. But for a table-esque component? Well, that’s just great. That’s what the table element is designed to do!

Tables are designed to handle data that is semantically related and is best presented in a linear-like format. So, yes, we can use tables today in the year 2020, and that will likely continue to be true many years from now.

This is what sort of worries me about CSS Grid a little bit because once we have all the power in the universe, every problem looks like it should be solved with Grid. John then argues that the same thing can be said with floats, like in this example with the pullquote below:

Floats are a perfectly valuable option here! And it’s useful to remember that ye olde techniques of the past are still going to be valuable for the future, too. Just not in the same way.

Editing SVGs in the browser

Here’s a fabulous and rather intense SVG path editor that works right in the browser. Yann Armelin broke down how to use this great little web app over on GitHub so it’s worth reading that before you begin. I think the most interesting part of this design that might be missing from other SVG editing tools is this COMMANDS panel on the left-hand side:

By selecting or hovering over these options you can then see how that relates to the path of the SVG itself, which is handy if you want to just nudge a line over a tiny bit. It’s pretty neat.

Wanna see more options?

Tools to Visualize and Edit SVG Paths

Anima – Turn any design into clean React code components

It’s time to stop coding UI from scratch: Anima saves you time by translating design into workable React code. Clean, reusable code components that developers actually like to use. Read more about Anima in our last article and get started for free.

An ode to the Mac

I love the design of this fancy blog post from the team at Sketch. It doesn’t really have anything to do with web design at all but is simply a big love letter to the Mac. What’s important here I think is just how gosh darn lovely the typesetting and illustrations are:

A lot of websites today look remarkably similar, and that’s for many reasons I expect. And yet even the pretty ones are similarly pretty, I think. But this blog post is remarkable because it captures the design of early Apple advertisements and reminds us that there’s so very many graphic design resources we can take inspiration from to make our websites so much weirder.

If you’re into more trips down early Mac memory lanes, Jason Snell has been doing a 20 Macs for 2020 series that’s been fun to read.

Little things on my personal site

Speaking of interesting designs, the other day Chris updated his personal website and walks us through his decisions when it comes to typography, CSS, and copywriting:

It’s my own personal playground with no other goal than making the site represent me to have a little fun. It’s not a complete re-write, just some new paint.

As you’d expect, there’s a bit of nifty CSS going on there, particularly with the blogroll at the end. Chris created this effect in Sass by using the nth-child selector to mix up the colors:

li {
  &:nth-child(4n) a {
    color: $blue;
  }
  &:nth-child(4n + 1) a {
    color: $yellow;
  }
  &:nth-child(4n + 2) a {
    color: $red;
  }
  &:nth-child(4n + 3) a {
    color: $purple;
  }
}

It’s a relatively simple trick but the effect is lovely — the perfect sort of CSS trick, if I do say so.

CSS and Accessibility

Way back in 2017, Manuel Matuzovic wrote that “it’s actually possible to make a website inaccessible in just three lines of CSS.” And in that post he links to outlinenone.com which argues against this bit of CSS that I see commonly still today:

/* yikes, don't do this without SETTING focus styles */
a:focus {
  outline: 0;
}

With just three lines of CSS, users will now be unable to tab through the UI and make selections with a keyboard. But as Manuel writes, there’s a lot of small decisions we have to make that can have an enormous impact on the design of a website; color contrast, typography, font-weight, semantic markup. The list goes on and on.

It’s also interesting that 3 years later, and despite the changes to the CSS language and the web design tech landscape in that time, all these small accessibility lessons are still just as important as ever.

Also, here’s a great post by Holly Tuke on the 5 most annoying website features she faces as a blind person everyday. It’s a really good reminder that accessibility is vital to our day-to-day work, and vital for our users, too.

Build an app, win a Tesla

Build an app for your chance to win $180,000 in prizes! Winning apps will appear in the monday apps marketplaces, available to the 100,000 teams that use monday.com.

Get a FREE builders account now!

[Chris]: I recently wrote my piece (peace?) regarding the whole discussion lately about WordPress and Jamstack. That was cathartic. The two are at odds slightly, as they are both things developers might reach for to build a website which might be mutually exclusive in terms of hosting and services reached for… but I also find this true:

I don’t see developers out there biting their fingernails trying to decide between a WordPress or Jamstack approach to building a website.

I’ve reached for both in the past and have had that “yep, this was the right choice” with both before, which is, I suppose, my main point.

Here’s some other WordPress-specific blog posts I’ve bookmarked lately: