Evaluat is in private access. Demos open through July. Book a slot

Web Vitals & Metrics

Web Vitals & Metrics from the Evaluat team: articles on real-browser performance testing and Core Web Vitals.

Two page layouts compared. Before, an unsized image loads and pushes the text below it down, scoring a Cumulative Layout Shift of 0.20, rated poor. After, a reserved placeholder box holds the image's space so the text stays put and CLS is 0, under the 0.1 good threshold.

How to improve CLS: a step-by-step optimization guide

Almost every layout shift is the same bug: an element that loads without a reserved box, so everything below it jumps. Cumulative Layout Shift is the easiest Core Web Vital to fix, because the cure is nearly always to reserve the space in advance. This guide is the practical playbook: the fixes in priority order, the code for each, the font trick most teams skip, and how to confirm the number held for real users.

Ahmad Farzan ·

Two Interaction to Next Paint timelines compared. Before optimization a long task creates a large input delay and INP is 520 milliseconds, rated poor. After breaking up the task and yielding to the main thread the input delay nearly disappears and INP drops to 180 milliseconds, under the 200 millisecond good threshold.

How to improve INP: a step-by-step optimization guide

Most teams trying to improve INP optimize the click handler, and most of the time the handler is not the problem. A long task was already running on the main thread when the user clicked, so the interaction had to wait. This guide is the practical playbook: the fixes in priority order, the code for each, the modern API most sites have not adopted yet, and how to confirm the number actually moved for real users under load.

Ahmad Farzan ·

Two Largest Contentful Paint timelines compared. Before optimization the resource load delay phase is large and LCP lands at 4.3 seconds, rated poor. After starting the LCP image early the load delay nearly disappears and LCP drops to 2.3 seconds, under the 2.5 second good threshold.

How to improve LCP: a step-by-step optimization guide

Most teams trying to improve Largest Contentful Paint reach for a smaller image, and most of the time the image is not the problem. The browser is starting it too late. This guide is the practical playbook: the fixes in priority order, the code for each, the two 2025 techniques most sites have not adopted, and how to confirm the number actually moved for real users under load.

Ahmad Farzan ·

An Apdex score sorts every request into three buckets against a target time T: satisfied (at or under T, counted in full), tolerating (between T and 4T, counted as half), and frustrated (over 4T or errored, counted as zero). The formula, satisfied plus half the tolerating divided by the total, produces one user-satisfaction score between 0 and 1, shown here at 0.875.

What is an Apdex score? Measuring user satisfaction in performance testing

A load test can come back full of green percentiles and still not tell you whether the people behind them were satisfied or quietly giving up. An Apdex score answers that in one number from 0 to 1: you set a target response time, and it reports how many requests left users satisfied rather than merely tolerating, or frustrated.

Ahmad Farzan ·

Core Web Vitals at load: a page holds a good 2.1 second Largest Contentful Paint for one user, but as concurrent virtual users rise, LCP climbs and crosses the 2.5 second good threshold, ending near 3.4 seconds at 500 users.

Core Web Vitals at load, explained

A page can score green in a single-user Lighthouse run and still ship a red Largest Contentful Paint the moment real traffic arrives. Core Web Vitals change under load: the server slows, time to first byte grows, and interactions wait on a busy backend. This guide explains why each Vital moves under load, and how to measure them at concurrency.

Ahmad Farzan ·

Interaction to Next Paint: a visit's interactions drawn as stacked bars of input delay, processing, and presentation time. Most stay under Google's 200ms good threshold while one slow interaction passes 500ms and sets the page's INP.

Interaction to Next Paint (INP), explained for engineers

A page can pass every functional test and still feel slow on the second tap. Interaction to Next Paint is the Core Web Vital that catches it: the latency of your slowest interaction across a visit, timed from the click to the next frame painted. Here is what INP captures, what drags it past 200ms, and how to test it under load.

Ahmad Farzan ·

Core Web Vitals lab versus field data: a lab test is one synthetic point that scores good, while real-user field data is a wide distribution whose 75th percentile crosses the good threshold and fails, because real devices, networks, and traffic vary.

Core Web Vitals: why lab scores differ from real users

Your Lighthouse score says 98. Your Core Web Vitals report says the page is failing. Both can be right. A lab test measures one synthetic load on a fixed device and network; field data is the spread of every real device, connection, and click your users bring, including the traffic a lab never simulates. Here is why lab and field diverge, and which to trust.

Ahmad Farzan ·

A right-skewed histogram of response times. Most requests cluster fast around a 100-millisecond median, with a long tail of slow ones stretching right. The mean, about 420 milliseconds, sits on the sparse downslope where almost no requests land, while p95 at 2,800 milliseconds and p99 at 5,200 milliseconds sit far out in the tail. The average describes no actual user.

Why average response time misleads you: reading p95 and p99

Your dashboard says average response time is 420 milliseconds. Half your users see 100, one in a hundred waits over five seconds, and the average describes none of them. p95 and p99 read response time from the slow end, where the failures you run a performance test to find actually live.

Ahmad Farzan ·

A performance test report read in three passes: did it keep up (active users, throughput, error rate), how slow was it really (response time percentiles, Time to First Byte), and what did users feel (Core Web Vitals, Apdex). The eighth metric, a per-URL and per-session breakdown, shows where it broke, flagging a checkout page at a 4.2 second Largest Contentful Paint.

8 metrics every performance test report should include

A performance test report full of green averages can still hide a checkout that buckled at peak. The numbers that catch it come in three passes: did the system keep up, how slow was it really, and what did users feel. Here are the eight metrics that answer those questions, and the benchmark that shows each is healthy.

Ahmad Farzan ·

The four phases of Largest Contentful Paint shown as a timeline from navigation start to LCP: Time to First Byte about 40 percent, resource load delay under 10 percent, resource load duration about 40 percent, and element render delay under 10 percent, with a good LCP at 2.5 seconds or less.

Largest Contentful Paint (LCP), explained for engineers

Your Largest Contentful Paint is the moment the biggest thing on the page, usually the hero image, finishes rendering, and Google treats it as a Core Web Vital. This guide explains what counts as the LCP element, the four phases LCP breaks into, why your lab and field numbers disagree, and how to fix and measure it under real load.

Ahmad Farzan ·