Hey Everyone!

Today we’ll be talking about

• Metrics for Measuring User Experience and Performance - we describe what each metric measures and talk about how to improve it

  • Core Web Vitals - Cumulative Layout Shift, First Input Delay, Largest Contentful Paint

  • Responsiveness - Time to Interactive, Total Blocking Time, Interaction to Next Paint

  • Plus some other useful metrics!

• Tech Snippets

  • A Dive Into the Backends for Frontends Pattern (Backend)

  • What is Edge Computing? (Backend)

  • Build Your Own Redis (Backend)

  • A Deep Dive on Server-Sent Events (Backend)

  • The Evolution of Scalable CSS (Frontend)

  • Comparing 7 frameworks for building a Movie App (Frontend)

  • Analyzing Tech Debt (Engineering Leadership)

  • What do good OKRs look like (Engineering Leadership)

  • How to do One-on-Ones (Engineering Leadership)

Sick of biased news? Try 1440

If you wish all news could be no-nonsense, you'll want to check out a newsletter loved by millions, called 1440. It's a daily digest of all the most important info in culture, science, sports, politics, business, and everything in between—and better yet, it's the fastest way to an informed and impartial point-of-view.​

The folks at 1440 scour over 100 sources every morning so you don't have to. You'll save time and start your day smarter.

​Sign up for 1440 now and get your first five-minute read this minute. It's completely free—no catches, no nonsense, and absolutely no BS.

sponsored

Using Metrics to Measure User Experience

You'll frequently see developers throw around terms like TTFB, FID, CLS, TTI and more.

These metrics are useful for quantifying how users experience your website. Having a target that you can measure makes it much easier to see the positive/negative impact your changes are having on the UX. 

Some of these metrics are also part of the Core Web Vitals (Largest Contentful Paint, First Input Delay and Cumulative Layout Shift), so they’re used by Google when ranking your website on search results. If you’re looking to get traffic from SEO, then optimizing these metrics is essential.

We’ll go through 8 metrics and talk about what they mean. This list is from web.dev, an outstanding website from the Google Chrome team with a ton of super actionable advice on front end development.

Note - Whenever you're talking about metrics, it's important to remember Goodheart's Law - "When a measure becomes a target, it ceases to be a good measure".

Some of these metrics can be gamed to the point where improvements in the metric result in a worse UX, so don't just blindly trust the measure.

Time to First Byte (TTFB)

TTFB measures how responsive your web server is. It measures the duration from when the user makes an HTTP request requesting your web server to when she gets the first byte of the resource.

Your TTFB consists of

• DNS lookup

• Establishing TCP connection (or QUIC if it’s HTTP/3)

• Any redirects

• Your backend processing the request

• Sending the first packet from the server to the client

Most websites should strive to have a TTFB of 0.8 seconds or less. Values above 1.8 seconds are considered poor.

You can reduce your TTFB by utilizing caching, especially with a content delivery network. CDNs will cache your content on servers placed around the world so it’s served as geographically close to your users as possible.

CDNs can serve static assets (images, videos) but in recent years edge computing has also been gaining in popularity. Cloudflare workers is a pretty cool example of this, where you can deploy serverless functions to Cloudflare’s Edge Network.

First Contentful Paint (FCP)

FCP measures how long it takes for content to start appearing on your website. More specifically, it measures the time from when the page starts loading to when a part of the page's DOM (heading, button, navbar, paragraph, etc.) is rendered on the screen.

In the example Google search above, the first contentful paint happens in the second image frame, where you have the search bar loaded.

Having a fast FCP means that the user can quickly see that the content is starting to load (rather than just staring at a blank screen). A good FCP score is under 1.8 seconds while a poor FCP score is over 3 seconds.

You can improve your FCP by removing any unnecessary render blocking resources. This is where you're interrupting the page render to download JS/CSS files.

If you have JS files in your head tag, then you should identify the critical code that you need and put that as an inline script in the HTML page. The other JS code that's being downloaded should be marked with async/defer attributes.

For CSS stylesheets, you should do the same thing. Identify the critical styles that are necessary and put them directly inside a style block in the head of the HTML page. The rest of the CSS should be deferred.

Largest Contentful Paint (LCP)

LCP measures how soon the main content of the website loads, where the main content is defined as the largest image or text block visible within the viewport.

LCP is one of the three Core Web Vitals that Google uses as part of their search rankings, so keeping track of it is important if you’re trying to get traffic through SEO.

A good LCP score is under 2.5 seconds while a poor LCP score is over 4 seconds.

Similar to FCP, improving LCP mainly comes down to removing any render blocking resources that are delaying the largest image/text block from being rendered; load those resources after. 

If your LCP element is an image, then the image’s URL should always be discoverable from the HTML source, not inserted later from your JavaScript. The LCP image should not be lazy loaded and you can use the fetchpriority attribute to ensure that it’s downloaded early.

First Input Delay (FID)

FID measures the time from when the user first interacts with your web page (clicking a button, link, etc.) to the time when the browser is actually able to begin processing event handlers in response to that interaction.

This is another one of Google’s Core Web Vitals, so it’s important to track for SEO. It measures how interactive and responsive your website is.

A good FID score is 100 milliseconds or less while a poor score is more than 300 milliseconds.

To improve your FID score, you want to minimize the number of long tasks you have that block the browser’s main thread.

The browser’s main thread is responsible for parsing the HTML/CSS, building the DOM and applying styles, executing JavaScript, processing user events and more. If the main thread is blocked due to some task then it won’t be able to process user events.

A Long Task is JavaScript code that monopolizes the main thread for over 50 ms.

You’ll want to break these up so the main thread has a chance to process any user input. You’ll also want to eliminate any unnecessary JavaScript with code splitting (and moving it to another bundle that’s downloaded later) or just deleting it.

Time to Interactive (TTI)

TTI measures how long it takes your page to become fully interactive.

Fully interactive is defined as

• Browser displays all of the main content of the web page

• There are no running Long Tasks

• Event handlers are registered for visible page components

It’s measured by starting at the FCP (first contentful paint…when content first starts to appear on the user’s screen) and then waiting until the criteria for fully interactive are met.

A good TTI score is under 3.8 seconds while a poor score is over 7.3 seconds. 

You can improve TTI by finding any long tasks and splitting them so you're only running essential code at the start. 

Total Blocking Time (TBT)

TBT measures how long your site is unresponsive to user input when loading. It’s measured by looking at how long the browser’s main thread is blocked during the time before the web page becomes fully interactive (TTI).

Total Blocking Time measures how long the main thread is blocked while the page is becoming fully interactive where the measurement starts at FCP (when content first appears) and ends at TTI (when the page is fully interactive).

A good TBT score is under 200 milliseconds on mobile and under 100 milliseconds on desktop. A bad TBT is over 1.2 seconds on mobile and over 800 ms on desktop.

You can improve TBT by looking at the cause of any long tasks that are blocking the main thread. Split those tasks up so that there's a gap where user input can be handled.

Cumulative Layout Shift (CLS)

CLS measures how much the content moves around on the page after being rendered. It’s meant to track the times where the content will suddenly shift around after the page loads. A large paywall popping up 4 seconds after the content loads is an example of a large layout shift that annoys users.

CLS score is measured based on two other metrics: the impact fraction and the distance fraction. Impact fraction measures how much of the viewport’s space is taken up by the shifting element while the distance fraction measures how far the shifted element has moved as a ratio of the viewport. Multiply those two metrics together to get the CLS score.

Note - CLS measures unexpected layout shifts. If the layout shift is user initiated (triggered the user clicking a link/button) then that will not negatively impact CLS.

CLS is the third Core Web Vital so make sure you’re paying attention to your score if you want to rank high on Google.

You can improve your score by including the size attributes on images/video elements, so the browser can allocate the correct amount of space in the document while they're loading.

The Layout Instability API is the browser mechanism for measuring and reporting any layout shifts. You can read more about debugging CLS here.

Interaction to Next Paint (INP)

Interaction to Next Paint measures how responsive the page is throughout the entire page’s lifecycle where responsiveness is defined as giving the user visual feedback. If the user clicks on a button, there should be some visual indication from the web page that the click is being processed.

INP is calculated based on how much of a delay there is between user input (clicks, key presses, etc.) and the next UI update of the web page. To reiterate, it’s based on measuring this delay over the entire page lifecycle until the user closes the page or navigates away.

A good INP is under 200 milliseconds while an INP above 500 milliseconds is bad.

Interaction to Next Paint is currently an experimental metric and it may replace First Input Delay in Google’s Core Web Vitals.

For more details, check out the web.dev site by the Google Chrome team.

Learn Something New Every Day

Every morning, Morning Brew summarizes the top news stories and delivers them straight to your inbox so you can quickly get caught up on the way to work or over your morning coffee.

Unlike traditional news which can be boring and dense, Morning Brew is fun to read and easy to understand.

The best part? It’s completely free and only takes 5 minutes to read so you can get all the most relevant updates and move on with your day.

Over 4 million people read Morning Brew.

sponsored

Tech Snippets

Frontend

The evolution of scalable CSS - Managing CSS when you have a huge codebase can be a big challenge. Currently, the cool kids all use TailwindCSS and utility classes for writing their CSS in the HTML itself. This is a great article from Frontend Mastery that dives into how we got here. It delves into what were the original challenges with CSS and how we got from writing in stylesheets to CSS in JS to TailwindCSS (with many other best practices in between).

Building a Movie App in 7 Frameworks and seeing which is fastest - This is an interesting blog post that goes into building a basic application in 7 different frameworks: NextJS, Nuxt, Angular, Lit, SvelteKit, Astro and Qwik. They then compare the LCP, FID and CLS of the different implementations.

Backend

A Dive Into Backends for Frontends Pattern - Backend for Frontends (BFF) has become quite popular over the past few years as a design pattern for your backend. The basic idea is that you have multiple entry points to your backend where each frontend (desktop, mobile, IoT device, whatever) has their own tailored API (their own BFF). This is a great blog post that delves into this pattern and discusses how many BFFs you should have, how they should interact with downstream backend services, how you should think about code reuse with these BFFs and more. 

A Deep Dive on Server-Sent Events - In a previous article, we talked about how Shopify used Server Sent Events (SSE) to update a dashboard they built. Here’s an article that goes deep into SSE and explains why you’d use them over websockets, how they work and some cool features they provide.

What is Edge Compute? - Storing your static assets on a CDN is a great way to reduce latency for end users. Over the past few years, CDN providers have been adding far more capabilities, the most exciting of which is edge computing. You can write cloud functions to handle certain tasks in your backend and run these functions on CDN servers distributed globally. The article linked delves into this and when you should use edge compute.

Engineering Leadership

Analyzing Tech Debt - This is a great article on the MartinFowler blog that delves into tech debt in a startup context. When you’re first looking for product/market fit, you should just focus on getting to market as quickly as possible so you can validate/iterate product. After you find product/market fit, then you should start looking at code quality, testing, coupling, automation and other areas typically associated with tech debt. This article delves into areas you should investigate and some of the typical signs that your tech debt is becoming a bottleneck.

Managing People - How to do One-on-Ones - Leadership Garden is an awesome blog that gives advice for engineering leaders. Many people struggle with conducting "One-on-Ones" with questions around “what do we talk about?”, “how do I earn trust?”, etc. This blog post delves into what you should be talking about in your first three one-on-one meetings with a team member.

What do good OKRs look like? - Camille Fournier is the author of The Manager’s Path and she writes a ton of great content on Medium. She published a blog post last month delving into what good OKRs look like. The objective should express a high-level strategy with an opinion/statement of values. The key results should account for what impact you want to have and should not just be what work you want delivered. Good OKRs tell a story about what is important and they help people understand why they’re working on their specific project/deliverable.