Web Performance

For a long time "slow" was a feeling rather than a number. A customer would say the product was slow, an engineer would open the same screen on their own machine and report that it seemed fine, and the conversation stopped there. Neither person was lying. A screen that paints in one second over office fiber on a new laptop takes six seconds on a three-year-old phone on a subway train. The experience of one page differed wildly and there was no shared number to hold the two accounts against each other.

It wasn't that measurement didn't exist. Early on, browsers reported a single moment — the point at which the page was considered fully loaded — and that moment got called speed. The trouble is that it often disagreed with what a person experienced. The article can be fully visible while a tracking script at the bottom keeps running, so nothing registers as complete. Or the page registers as complete and then a large image arrives and shoves the layout around. Once a number improves while support tickets stay flat, nobody can use that number as evidence again.

So measurement split from one figure into several. The approach now is to cut the encounter into three moments: when something worth seeing appears, how quickly a tap gets answered, and whether the page stays still while you read it. Each comes from a different cause and gets fixed a different way, so bundling them into one score leaves you unable to decide what to touch first.

Splitting them also splits "it's slow" into three distinct reports. The first screen never appearing, a button not responding, and text sliding away while you read it have their fixes in completely different places. The first comes from downloading too much up front, the second from the browser being busy with other computation and unable to accept input, the third from an element arriving late into space that was never reserved for it.

The second split is where you measure. Running a fixed set of conditions on a machine you control and collecting what actually happened in real users' browsers give different answers. The first compares before and after cleanly — run the same code ten times and the number barely moves — while the second shows what customers are living with right now, across a scatter of devices and networks, which is why it gets read at the slowest quarter rather than the average. Look only at the first and everyone on a slow phone or a slow network drops out of view entirely. That's why teams who verify on office hardware keep talking past their own support queue.

Which of the two you trust also decides who gets to close a ticket. A fixed-condition run is repeatable, so it settles arguments between two versions of the code; field data is noisy but it is the only thing that answers whether the person who complained is better off. Teams that keep both usually promise a target on the field numbers and use the lab run to decide the order of work.

Performance stopped being an internal matter of taste when the numbers got attached to money. Studies at many companies found that pushing the first screen from one second to three visibly increased the share of people who left before it arrived, and once search engines began folding speed metrics into ranking, marketing started reading the same figures. From then on, slow was treated as a revenue and traffic problem rather than an inconvenience.

The terms underneath split three ways: the metrics that fix what gets measured, the techniques that bring those numbers down, and the problem that makes a page degrade the longer it stays open. The order is real. Without measuring you don't know what's slow, and without knowing you apply techniques at random.

The metrics divide up the moments a user goes through. There are four — the first three cover what happens on screen, the fourth covers the stretch before that, on the server and the network.

1. Largest Contentful Paint (LCP) — how long until the biggest block on screen is drawn. Usually that block is the hero image or the headline, and its arrival is the moment people feel the page has loaded. Under 2.5 seconds counts as good. Past four seconds, a large share of people who clicked an ad hit the back button before seeing anything.
2. Interaction to Next Paint (INP) — how long after a tap or keystroke the screen responds. The stretch where a button has been pressed and nothing has happened shows up here. Past 0.2 seconds people press again, and the same request arrives twice. Double-posted comments and double-charged payments come from exactly this, so slow paths at minimum emit an immediate acknowledgment of the press.
3. Cumulative Layout Shift (CLS) — the accumulated amount that elements jump while you're looking at the page. A late image or banner elbows its way in, the sentence you were reading slides down, and a different button is now where you were about to tap. It makes people press things they never intended to, which is why it feels the worst of the three.
4. Time to First Byte (TTFB) — how long after the request until the server returns its first byte. The browser can't draw anything during that stretch, so if this reads one second, all three metrics above start one second in the hole. When time refuses to come out of the page no matter what you do on the front end, this is usually where it's hiding.

The first three travel together under the name Core Web Vitals, covering loading, responsiveness and stability. That bundle is what search engines mean when they say speed affects ranking, which puts engineering and marketing in front of the same three numbers.

Techniques are the hands that bring the numbers down. Four of them, each removing a different kind of waste.

1. Caching — storing a result once and serving it again on the next request. Files that don't change, like a logo, are kept so a browser that already has one doesn't fetch it twice; expensive responses, like a list view, are held briefly on the server and reused. Putting that storage physically near the user is a content delivery network (CDN). A user in Seoul no longer makes the round trip to a server in the United States, so TTFB drops noticeably.
2. Compression — making the bytes smaller so they move faster. Text files repeat themselves a lot and shrink well; a one-megabyte script commonly comes down under 300 kilobytes. It barely helps on photos and video, which are compressed already, so those belong to the next item. It often turns on with one line of server configuration, which makes it the best effort-to-effect trade on this list.
3. Image optimization — sending only as much image as the screen needs. The most common mistake is a 3000-pixel original sitting in a 300-pixel slot; changing format and deferring images below the fold belong here too. Images are more than half the weight of a typical page, so this is where results appear fastest.
4. Prefetch — fetching what will be needed shortly, ahead of time. If people move from a list to a detail view constantly, the detail view's code can be pulled down while the list sits idle. But prefetched bytes share bandwidth with the bytes needed right now, so fetching indiscriminately makes the first screen slower instead.

The problem category is about getting worse over time. A memory leak is resources that were finished with but never released, piling up until the browser turns sluggish. Metrics taken the moment a page opens will never catch it; it surfaces in the afternoon, in products where the same tab stays open all day. For a collaborative document tool, where nobody closes the tab, this generates more complaints than first-screen speed does.

The three groups link in one direction. Metrics point at what's slow, you pick the technique that fits that spot, and you confirm with the same metrics afterward. Skip the order and you usually spend the time making something that was already fast a little faster.

"LCP is four seconds and two of those are TTFB. The rendering side isn't where we start."

The delay is in the server response, not in the drawing.

"CLS jumped to 0.3 after this deploy. I think we didn't reserve space for the banner."

A late-arriving element is pushing the existing layout around, so hold the space in advance.

"The lab score is 90 and the field numbers haven't moved."

Only the fixed-condition measurement improved; nothing changed on real customers' devices and networks.

Ravi was the first person at Pagedeck to raise these numbers. Search traffic had been flat for months, and while digging into why, he found that half the visitors arriving through document share links left before the screen appeared. Theo measured it: LCP was over five seconds on mobile, and nearly two of those were TTFB.

The order of the fix was the order of this page. Shared document responses moved to regional serving first, which cut TTFB, and then images inside documents were resized to the dimensions actually displayed. Those two changes brought LCP down to 2.8 seconds. Mia argued for stopping there. Squeezing out the remaining 0.3 seconds would have cost about as much time as shipping the next feature, and the bounce rate had already moved visibly between the two deploys. Performance work has no natural end unless someone decides in advance how far to go.

The most common misreading treats performance as an internal technical project. How many seconds a screen takes looks like a matter of code and servers, so the assumption is natural. What the number actually moves is traffic and conversion. A slow first screen loses the visitor an ad just paid for before they see anything, and search engines fold the same metrics into ranking. Filed as a technical project, this work loses every scheduling argument to feature development. It never seems urgent, it slides to next quarter, and meanwhile accumulated images and scripts make the page a little slower every month. Touch it a year later and there are ten places to fix, with no way to tell which deploy caused what.

Taking the score as the goal is the other frequent one. Measurement tools report out of 100, so "let's get above 90" is an easy target to set. That score is one measurement on one device under one network condition. The fixed conditions make it good for comparing before and after, but users outside those conditions aren't in the score at all. Chase it and you end up working through whatever the tool penalizes, while the experience on a slow phone stays exactly as it was. So the score is for ordering the work, and whether things improved gets confirmed against numbers collected from real users. What usually happens on a team with a score target is that they strip out whatever the tool deducts for and leave the heavy images alone. When the two numbers disagree for long, trust the second.