Three rows of the baseline remain and none of them is fixed by writing better JavaScript, because they all happen before the first line of your code runs: 4.1 s of LCP, 0.21 of CLS and 214 kB in 28 requests before the first card appears. During those four seconds, the Map index from 09-02, the leak cleanup from 09-03 and the virtual window from 09-04 do not exist yet: Lucía stares at a blank screen on her phone, on the train, on Slow 4G. This lesson is about what decides that time: what the browser downloads, in what order, and how much of it is actually used. You will see the critical rendering path and why CSS blocks while JavaScript may not, closing what 01-03 and 06-01 noted about defer, async and type="module"; you will measure the real weight with the Network panel and the Coverage tab; you will finally understand what a bundler does and why it exists, with a minimal Vite configuration for Nómada Tasks; you will close the reference 05-04 left open about tree shaking; you will split the code with dynamic import(); you will learn to preload with preload, modulepreload, prefetch, preconnect and dns-prefetch; you will make images and components lazy; you will fix the fonts, which is where half the CLS lives; and you will close with compression, HTTP caching and its relationship with the service worker from 07-05. At the end, the ten-row table, complete, with its "before" and "after" columns.

1. The performance that is decided before a single line runs
2. The critical rendering path
3. Why CSS blocks and JavaScript may not
4. Measuring the real weight: the Network panel
5. The Coverage tab: how much downloaded code goes unused
6. Row 10's problem: 28 unbundled ES modules
7. What a bundler does and why it exists
8. Vite for Nómada Tasks: a minimal, annotated configuration
9. npm run build: what it generates and what changes in index.html
10. Minification
11. Tree shaking: why ES modules make it possible
12. Code splitting with dynamic import()
13. The loading pattern: indicator, cancellation and failure
14. Preloading: preload, modulepreload, prefetch, preconnect, dns-prefetch
15. Lazy loading images
16. Lazy loading components with IntersectionObserver
17. Fonts: font-display, subsetting, preloading and fallback metrics
18. Closing row 3: where the CLS of 0.21 came from
19. Compression: Gzip and Brotli
20. HTTP caching, hashing and the service worker from 07-05
21. The performance budget in continuous integration
22. The complete table: the ten rows, before and after
23. What has not been solved and what it cost
24. Common Mistakes and Tips
25. Exercises
26. Conclusion

There is an uncomfortable asymmetry in web performance. The previous three lessons have optimized execution: algorithms, memory, DOM manipulation. But for anything to run, it first has to be downloaded, parsed and compiled, and that preliminary work has rules of its own.

Look at the real timeline of Nómada Tasks in the baseline, at Slow 4G and CPU 4× (which is what Lighthouse simulates by default and what Lucía really has on the train):

Not one of those milliseconds is fixed with a Map or a virtual window. Of the 4.1 seconds, your code runs for 310 (which 09-04 brought down to 31). The other 3.8 seconds are network, parsing and waiting.

The methodological consequence is the same as 09-01's, applied to another axis: the bottleneck moves. You optimized the render until it was ten times faster, and now the render is 1% of the first-load problem. Optimizing the render further would achieve nothing; what helps is downloading less and in a better order.

And there is a second, less obvious reason why downloading less code also speeds up execution. In 09-02 you saw that V8's parser is lazy: it does not fully parse a function's body until it is about to run, but it does have to walk the whole file to know where each function ends. A 200 kB module costs parsing time even if you only use one function from it. Reducing initial JavaScript is not just a network optimization: it is also a CPU optimization at startup, and therefore one for row 4 of the baseline.

The critical rendering path is the minimum sequence of resources the browser needs to paint the first pixel of content. Everything on that path delays FCP and, almost always, LCP.

Two ideas should come out of this diagram, and they are different from each other:

CSS blocks rendering. The browser paints absolutely nothing until it has all the CSS that applies to the page. The reason is common sense: if it painted earlier, the page would appear unstyled and would jump as soon as the styles arrived, which is called FOUC (flash of unstyled content) and produces an appalling CLS. So the browser prefers blankness to a lie.

A classic <script> blocks parsing. When the parser finds a <script src> with no defer and no async, it stops: it downloads the file, runs it, and only then carries on building the DOM. And since the script could call document.write, there is no way around it. That is the historical reason for putting scripts at the end of the <body>.

Nómada Tasks has one CSS file (css/styles.css, 18 kB) and one entry point (<script type="module" src="js/app.js">). The CSS blocks for 460 ms on Slow 4G, and the module does not block parsing but it does drag in the cascade of its 27 dependencies.

In 01-03 and 06-01 you already saw the table of defer, async and type="module". We bring it back here, extended with what matters for the critical path:

Three clarifications that prevent frequent mistakes:

async is not "better than defer". It is different. An async script runs as soon as it arrives, which means it can run in the middle of HTML parsing and block the main thread at the worst possible moment. And since it does not guarantee order, two interdependent async scripts fail intermittently. defer is the sensible default; async only for code that depends on nothing and nobody.

CSS can also be taken off the critical path. A <link rel="stylesheet"> blocks; but it can be marked as non-blocking with the media trick:

The second pattern works because the browser downloads CSS whose media does not match at low priority, and does not block rendering for it; on load, the onload changes media to all and the styles apply. It is a well-known and legitimate trick, but it is worth using sparingly: in Nómada Tasks it only makes sense for the print CSS.

Inline <style> does not block the network but it does take up bytes in the HTML. The critical CSS technique consists of inlining in the <head> the few styles needed to paint the visible part and loading the rest non-blockingly. It is effective —in Nómada Tasks it saves about 300 ms of FCP— but it requires generating that fragment automatically during the build, because maintaining it by hand guarantees it will go stale. We mention it as an advanced option and will not apply it: with an 18 kB stylesheet, the benefit does not justify the complexity.

You already used Network in 08-01 for debugging and in 09-01 to record the baseline. Here we use it as a measuring instrument, with a fixed procedure:

1. An incognito window.
2. Disable cache ticked. Without it you are measuring your second visit.
3. Throttling: Slow 4G.
4. Reload and wait for everything to finish.
5. Look at the summary bar at the foot and sort by Size and by Time.

The columns that matter, extending 09-01's table:

The Nómada Tasks summary bar today, already quoted in 09-01:

And the breakdown by type, which is what tells you where to work:

Three things jump out and all three belong to this lesson: 28 JavaScript requests, uncompressed and unminified, a 94 kB font that turns out to be the second heaviest resource on the page, and two images with no dimensions, which is the classic CLS generator.

A note about HTTP/2 and HTTP/3, because a half-truth is going around. It is true that with HTTP/2 many requests no longer cost what they cost on HTTP/1.1: there is multiplexing over a single connection and no six-parallel-requests-per-domain limit. But every request still has a cost: headers, a round trip if it is not within the congestion window, and —the important one for ES modules— a cascade by levels. And that cascade is exactly row 10's problem.

There is a tool in DevTools that almost nobody opens and that answers the most uncomfortable question: of everything you have downloaded, how much has actually run?

You open it from the command menu (Ctrl+Shift+P → Show Coverage), press the reload button, and a table appears with one bar per file: in red the code downloaded and unused, in blue the used code.

The honest procedure has a nuance: Coverage measures up to the moment you stop the recording. If you stop right after loading, you will see a sky-high unused percentage that does not mean "dead code" but "code not run yet". The correct reading is:

• Stop just after the LCP to find out how much code is surplus on the critical path → that is what needs splitting.
• Stop after using the whole application to find out how much code is genuinely dead → that is what needs deleting.

The result for Nómada Tasks, stopping just after the first card:

62% of the JavaScript Lucía downloads on the train does not run before she sees the first card. And two files —the planning report computation and the rich description editor— add up to 76 kB at 100% unused: they are code only needed when somebody presses a button that most visits never press.

That is the plan of the lesson, and it comes from a measurement, not an intuition:

1. What is never used: delete it (tree shaking, section 11).
2. What is used later: load it later (code splitting, section 12).
3. What is used always: compress, minify and cache it properly (sections 10, 19 and 20).

Until now, Nómada Tasks has been served as-is: the browser receives app.js, sees its imports, requests those files, sees their imports, requests the next ones… It is clean, it is exactly what 05-04 taught, and in development it is wonderful. In production it has one concrete problem: the cascade.

The browser cannot know that it needs util/format.js until it has downloaded and parsed view/card.js, which in turn needed view/board-view.js, which needed app.js. On Slow 4G, each level costs a round trip of about 280 ms. Four levels are 1.1 seconds of pure waiting, with barely any bytes downloaded.

And on top of that, the 28 files carry comments, long names and whitespace, because they are readable source code. The 214 kB are, in large part, air.

This is not a defect of ES modules: it is that they were designed to express the dependency graph, not to be the optimal delivery format. The tool that translates one into the other is the bundler.

A bundler reads your entry point, walks the entire graph of imports, and produces one or more files optimized for delivery. Along the way it does several distinct things that are worth not conflating:

Of all of them, the one that on its own justifies the tool's existence is the second. This, which has always worked in Node, does not work in the browser:

The browser only understands paths: ./x.js, /x.js, https://…. A bare specifier like web-vitals means nothing to it. Import maps exist to resolve that by hand, but as soon as you have five dependencies with their own dependencies, maintaining them is unfeasible.

And an important clarification, because it is a constant source of confusion: bundling does not mean "one single file". That was the 2015 model, when HTTP/1.1 penalized requests heavily. Today the goal is "few files, well chosen": a core that is always needed, and separate chunks for what is only needed sometimes, each with its own hash so the cache works at a fine grain.

An overview of the tools, to get your bearings:

We choose Vite for a reason that fits the module: in development it bundles nothing, it serves native ES modules exactly as before (which is why it starts instantly and reloading is immediate), and it only bundles when building for production. The code you have written across nine modules does not change by a single line.

Five decisions in that file that are not cosmetic:

• target: 'es2022'. Transpiling to ES5 "just in case" is an expensive mistake today: it inflates the bundle by 20–30% and adds polyfills that no browser with ES module support needs. Nómada Tasks uses private fields (05-03) and Object.groupBy (06-06); es2022 keeps them as they are.
• sourcemap: true. Without source maps, a production error is an unreadable stack trace with one-letter names. The maps are generated as separate files and are not downloaded unless DevTools is open, so they cost the user nothing. Ship them, or at least ship them to your error-tracking service.
• manualChunks with judgment, not out of habit. The reason for separating model is not size, it is rate of change: the view is touched every week and the model every few months. Separating them means a deployment of the interface does not force users to download the model again.
• cssCodeSplit: true means each entry point has its own CSS, and the CSS of a dynamically loaded chunk is loaded with it.
• chunkSizeWarningLimit: 80 is literally row 10's budget from the baseline, put into the tool.

And the package.json scripts:

The first thing to learn to read in that output is what is and what is not on the critical path. The first three JavaScript files (index, model, vitals) are requested by the HTML: they are the critical path. reports, editor, planner.worker, ca and en do not appear in the HTML: they are chunks that will only be downloaded when somebody asks for them, and that is section 12's doing.

And the generated index.html. This is the starting point:

And this is what Vite writes into dist/index.html:

Notice what it did without our asking: as well as replacing the paths with the hashed versions, it added two <link rel="modulepreload"> tags. That eliminates the cascade: the browser discovers the three JavaScript files while parsing the <head>, and requests them in parallel, without waiting to parse index-8f3a1c.js in order to discover that it needs model-2b7e40.js. It is section 14, applied automatically.

The result for row 10, measured with Slow 4G in incognito:

Read it carefully, because every row teaches something different. Bundling without minifying barely saves bytes (5 kB) but cuts almost a second: what was killing the LCP was not the weight, it was the cascade of 28 requests across four levels. Minification is what does save bytes, almost half of them. And code splitting removes another 46 kB, which is what the Coverage tab had flagged as "downloaded and unused".

A workflow change worth accepting explicitly, because it has a cost: from now on, the application is no longer opened by double-clicking index.html. There is a build step. In development you use npm run dev (which serves native, unbundled modules with instant reloading) and in production npm run build + npm run preview. We will come back to this cost in section 23.

To minify is to rewrite the code so it takes up less space without changing what it does. Vite does it by default with esbuild. Specifically:

A real fragment, before and after:

Three important things about this:

Exported names are not shortened (except with advanced configuration), because another module can import them by name. Only locals are shortened, and that is where most of the text is.

Minifying is not obfuscating. With source maps enabled, DevTools shows you the original code while debugging. Minification is not a security measure and must not be used as one.

Compressing and minifying are different things and they add up. Minifying reduces the text; compressing (section 19) reduces the bytes that travel over the wire. The 44.08 kB of the minified index travel as 14.93 kB with Brotli.

From 214 kB to 19.4 kB over the wire. And not a line of source code has changed yet.

In 05-04 we said: "tree shaking and bundlers will be covered in 09-05". The moment has come.

Shaking the tree is removing from the final bundle the exports nobody imports. The name comes from the image of shaking a tree so the dead leaves fall.

The interesting part is why it can be done, and the answer connects with something 05-04 explained for another reason: the imports and exports of ES modules are static. They must be at the top level, they cannot go inside an if or a function, and their names are literals. That restriction, which at the time may have looked like a nuisance, is exactly what allows a tool to know for certain, without running anything, which exports are used and which are not.

With CommonJS that is impossible:

The concrete case in Nómada Tasks is util/format.js, which since 07-06 creates nine Intl formatters:

Of those nine functions, the critical path uses three: shortDate in .task__meta, readableHours in the column counter and compareText in the sort by title. The other six are used by the report and the exporter, which are no longer on the critical path. Tree shaking removes those six functions and their formatters, and that is a good part of the 14 kB lost at that step.

Now, the four conditions for tree shaking to actually work, because it fails far more often than people think:

1 · No wildcard imports where you can avoid them.

In practice, Rollup is smart enough to shake many import * cases when the usage is analyzable, but it only takes passing format to another function for it to have to keep the whole thing. Named imports never fail.

2 · Beware of module side effects. If a module does something when imported —registering a handler, mutating a global, creating an expensive object— the bundler cannot remove it even if you use none of its exports, because it does not know whether that effect matters.

The way to declare that your modules are clean is the sideEffects field in package.json:

That says: "all my code is side-effect-free except the CSS files and the entry point". Without that declaration, many tools assume the worst and keep too much.

3 · The library has to be published as ESM. A dependency that only ships CommonJS cannot be shaken. web-vitals publishes ESM, which is why its 2.6 kB are only what you use of it. It is a real criterion when choosing dependencies.

4 · Dead code has to be genuinely unreachable. If a function is used in a branch that only runs in development, it is still referenced. That is what build-time constants are for:

And a way to check that all this works instead of assuming it: the rollup-plugin-visualizer report we configured in section 8.

It opens a treemap where the size of each rectangle is the module's weight in the final bundle. It is the tool that answers "why does my bundle weigh 140 kB?", and the answer is usually a dependency you did not know you were dragging along.

In 05-04 you met dynamic import(): it looks like a function call, it returns a promise, it accepts variable paths and it can go inside an if. There it was presented as syntax; here it is the tool that takes 46 kB off the critical path.

The rule for deciding what to split comes straight from the Coverage table in section 5:

Split whatever satisfies all three conditions: (1) it is heavy, (2) it is not used on the first screen and (3) it is triggered by a concrete user action. If any of the three is missing, do not split it: you will add a wait without saving anything relevant.

In Nómada Tasks there are exactly three candidates.

The reports module weighs 18.2 kB minified and drags in the worker from 09-02. Marta uses it once a quarter.

Notice a detail Vite resolves by itself: the Planner creates its worker with new Worker(new URL('./planner.worker.js', import.meta.url), { type: 'module' }). That pattern, presented in 09-02 as "mandatory if you use a bundler", is exactly what allows Vite to discover the worker, compile it as a separate hashed chunk (planner.worker-c40d7e.js) and rewrite the URL. With a string path, the worker would not have been included in the build and would give a 404 in production.

It weighs 24.4 kB and only appears when Iván presses "Edit description" on a card. It is the textbook case.

Two interesting decisions in that fragment:

• The promise is cached, not the module. promise ??= import(...) guarantees that two quick clicks do not launch two downloads: the second receives the same in-flight promise. It is a pattern worth automating.
• Failure has a dignified exit. If the chunk does not download —network down, a deployment mid-flight— the plain <textarea> is still there and the user can type. That is progressive enhancement, the same principle as 07-06.

Each language weighs about 1.9 kB. Downloading all three to use one is throwing away two thirds, and it is the case where import()'s variable path shines:

The detail to understand is the one in the comment: a bare import(variable) is undecidable for the bundler, which would not know what to include and would fail at run time. import(\./texts/${code}.js`)`, with the fixed part visible in the literal, lets it compile every file matching the pattern as an independent chunk, and pick one at run time. It is a restriction you have to know about.

Besides, English resolves with no download because it is the default language and its texts are in the main bundle. Only Marta, whose browser is set to Catalan, downloads an extra 1.9 kB.

The result of the three splits:

58.3 kB for 100% of visits, instead of 104 kB. And the saving is not spread evenly: whoever only consults the board —most people— downloads 58 kB and that is it.

And a word against over-enthusiasm, because over-splitting is a real mistake: every import() is a round trip. If you split a 3 kB module that is needed half a second after loading, you have traded 3 kB for 280 ms of latency on Slow 4G. That is a bad deal. Split big, late chunks, not everything that can be split.

Loading on demand introduces something that did not exist before: a visible wait in the middle of an interaction. It has to be treated like any asynchronous operation (05-06, 07-03), and it is worth having a single helper so as not to repeat the same wiring.

Three details that separate a correct lazy load from one that causes trouble in production:

When it fails for good, the cached promise must be cleared. If you keep it, every subsequent attempt will receive the same error forever, even after the network comes back. It is a subtle and very common bug.

A new deployment invalidates the hashes. If a user has had the tab open for two hours and you deploy a new version, the editor-7e1b93.js their index tries to request may no longer exist on the server. That import() will fail with a network error that looks inexplicable. There are two mitigations: keeping the old files on the server for a few days (the simplest, and what most people do), and detecting the failure to offer a reload:

The indicator must be accessible. aria-busy="true" tells screen readers that the region is updating; a CSS class with an animation says nothing at all to anyone who cannot see the screen. And if the wait can exceed a second (09-01), you also need explicit text.

The browser is fairly good at prioritizing, but it can only prioritize what it knows about. Resource hints exist to tell it about things before it discovers them for itself.

The difference between preload and prefetch is the most commonly confused and easy to remember: preload is "I need it for this screen, now"; prefetch is "I may need it later, when you have nothing better to do".

Applied to Nómada Tasks:

And the prefetch, which in Nómada Tasks is better done from JavaScript, when the browser is idle (09-02):

That import() with no await and no use of the result is idiomatic: it exists solely to get the chunk into the HTTP cache. When the user presses "Edit description", the module will already be there and loading will be instantaneous.

And the three rules that stop hints doing harm:

1. Preload little. If you preload five things, none of them is a priority. preload works because it displaces resources in the queue; preloading everything is preloading nothing.
2. Never preload something you are not going to use on this screen. The browser warns in the console ("The resource was preloaded but not used within a few seconds") and rightly so: you have spent critical-path bandwidth.
3. crossorigin on fonts is mandatory. Fonts are always downloaded in anonymous mode, so a preload without crossorigin causes two downloads of the same font. It is the most common mistake with preload and it doubles the weight of the most expensive resource on the page.

Nómada Tasks has few images —the workshop logo and each assignee's avatar— but enough to illustrate the four attributes that matter.

What each attribute does:

Four warnings that avoid the typical mistakes:

loading="lazy" on the LCP image is shooting yourself in the foot. It deliberately delays the resource that defines your main metric. It is by far the most frequent misuse of this technique, and Lighthouse detects it and flags it.

width and height work even if the CSS changes the size. Putting width="180" height="48" does not fix the size if you have img { max-width: 100%; height: auto; }: modern browsers use those two numbers only to compute the aspect ratio and reserve the right space. That is exactly what CLS needs and it does not interfere with responsive design.

The format matters more than lazy loading. Converting the PNGs to WebP brought Nómada Tasks's two images down from 41 kB to 9.2 kB with no visible difference. AVIF would have brought them to 6.8 kB with less compatibility. Before arguing about lazy, check the format.

For large images, use srcset and sizes. Serving a 1,600 px wide image to a 360 px phone is throwing away three quarters of the bytes:

loading="lazy" only exists for <img> and <iframe>. For components —a map, a chart, a heavy panel— you need the IntersectionObserver from 07-06, combined with the import() from section 12.

In Nómada Tasks there is one clear candidate: the workload-by-assignee panel, which draws a bar chart and lives at the bottom of the sidebar, almost always off screen.

Two conditions for this not to make the experience worse, and both come from the previous lesson:

The space must be reserved. If #workload-panel is 0 px tall until the component mounts, mounting it will push everything down and add CLS. The solution is to give it in the CSS the height it is going to have, or an aspect-ratio:

The rootMargin must be generous. With 300px, the download starts when the panel is three hundred pixels from appearing, so by the time the user gets there it is already mounted. With no margin, they would see the empty gap for half a second.

Web fonts are, by far, the most underestimated resource. In Nómada Tasks, a single font weighs 94 kB: more than all the critical-path JavaScript after optimizing it. And it is also the main source of CLS.

The problem has two faces that must be kept separate:

• FOIT (flash of invisible text): while the font downloads, the browser hides the text. The page looks empty even though the HTML is ready. It kills FCP and LCP.
• FOUT (flash of unstyled text): the text is shown in a fallback font and swapped when the web font arrives. It does not kill LCP, but if the two fonts have different metrics, the text reflows and that is CLS.

swap is the sensible default: it guarantees the text is visible from the first moment. optional is the choice if CLS matters more to you than the typography —the browser decides, and on slow connections it simply uses the fallback, with zero shift.

A complete font includes thousands of glyphs: Greek, Cyrillic, Vietnamese, mathematical symbols. Nómada Tasks writes in Spanish, Catalan and English: it needs basic and extended Latin, and little else.

From 94 kB to 21.4 kB. It is the single biggest saving of the whole lesson, and it does not touch a line of code. Three rules: always use WOFF2 (the .ttf, .eot and .woff formats have been surplus for years), use variable fonts when you need several weights, and check that the subset includes what you write: the Catalan names with ŀ, the typographic quotes and the · separator symbol Nómada Tasks uses.

The browser does not discover the font until it has downloaded the CSS and worked out which elements use it. That is two round trips of delay. That is why the critical font is preloaded, with the crossorigin from section 14:

Preload one single font: the one used for the main text. Preloading four variants is a textbook case of a counterproductive hint.

Even with swap and preloading, the swap shift remains: the fallback and the web font have different widths and line heights, so swapping them reflows the text. The modern solution is to declare an adjusted fallback font with the real one's metrics:

With those four properties, the fallback text occupies exactly the same boxes as the final one, and the swap stops moving anything: the FOUT still exists visually (the letterforms change) but the CLS drops to zero. The values of size-adjust and friends are computed by comparing the two fonts' metrics; there are tools that generate them, and adjusting them by eye is not reasonable.

CLS measures how much the content moves without the user causing it. In 09-01 we noted 0.21 and in 09-04 we learned to see it with Layout Shift Regions in the Rendering panel. Recording with the Performance panel and looking at the layout-shift entries, the 0.21 breaks down like this:

And the three fixes, each from a different section of this lesson:

The card shift (0.13 → 0.00). It is not fixed by loading earlier, but by reserving the space: a skeleton with exactly the height the columns are going to have. Since the list is virtualized (09-04) and each card is 116 px, the height is known in advance.

A note that connects with 09-01: a skeleton does not count as content for LCP. It helps CLS and perception, not the metric. Do not add it believing it improves LCP, because it does not.

The font shift (0.05 → 0.00). The adjusted fallback with size-adjust and ascent-override from section 17.4.

The logo shift (0.03 → 0.00). width="180" height="48" on the <img>, from section 15.

The remaining 0.02 is a tiny shift in the summary bar, which goes from one line to two when the number of tasks exceeds three digits. It is below the 0.1 threshold and fixing it would require fixing the height of an element whose content is genuinely variable. It is a conscious decision not to chase zero, in line with 09-01: the last points cost a lot and add nothing perceptible.

Minifying reduces the text; compressing reduces the bytes that travel. They add up, and compression is the server's responsibility, not the bundler's.

The browser announces what it accepts and the server chooses:

Over the built Nómada Tasks:

Three things to know:

Compress at build time, not on the fly. Brotli at maximum level (11) is slow to compress and fast to decompress. Compressing every response on the fly forces you to use a low level; generating the .br files during the build gives you level 11 for free. Almost any server knows how to serve a precompressed file.js.br if it exists.

Do not compress what is already compressed. WebP, AVIF, WOFF2, PNG, JPEG and MP4 already carry their own compression. Recompressing them wastes CPU and sometimes increases the size.

Check that compression is on. It is the most common and most invisible deployment failure: in the Network panel, if the transferred size and resource size columns match, there is no compression. In the Nómada Tasks baseline, the 214 kB of JavaScript appeared identically in both columns. That single observation was worth 150 kB.

The fastest visit is the one that downloads nothing. HTTP caching achieves that, and the hashing from section 8 is what makes it safe.

The two headers that govern the matter:

With ETag, when the max-age expires the browser asks and the server can answer 304 Not Modified with no body: you save the weight, but not the round trip. With immutable, there is not even a trip.

And here is the deep reason for hashing. index-8f3a1c.js carries a digest of the content in its name. If the content changes, the name changes. That allows a strategy with no compromises:

That is what makes the manualChunks from section 8 valuable: if you only touch the view, model-2b7e40.js keeps its hash and users do not download it again.

There is a real conflict here that has to be resolved, and it is the kind of thing that breaks deployments. The sw.js from 07-05 precached a hand-written list:

After npm run build none of those paths exists: they are now /assets/index-8f3a1c.js and friends. The cache.addAll would fail entirely, because addAll is atomic: if one request fails, nothing is stored. The service worker would not install and the application would lose offline mode without anyone noticing until a user got on the underground.

The solution is to generate the list at build time. With a small plugin of your own, which also illustrates how the tools hook together:

Three deployment warnings worth their weight in gold:

• sw.js with Cache-Control: no-cache, as 07-05 already said. If a CDN serves an old sw.js for hours, your users are frozen and there is nothing you can do from the client.
• Do not precache the lazy chunks. The reports-*.js that only 4% of visits request must not be downloaded when the service worker installs: that would be exactly the problem we have just solved, moved elsewhere. It is cached on request, with staleWhileRevalidate (07-05).
• Keep the previous deployment's files around for a few days. It is section 13's mitigation for the import() calls that fail in tabs left open during a deployment.

In 09-01 it was said that quantity budgets are far more stable than time budgets, because they do not depend on runner noise, and that they would be covered here. Let us set them up.

Level 1: the byte budget, checked with a script of your own over the build output.

Real output over the build from section 9:

Level 2: Lighthouse CI, which you already configured in 09-01, with the assertions now tuned to the table's targets:

Notice the four new assertions and why they are rule-based rather than time-based: uses-text-compression detects that somebody has turned Brotli off on the server, unsized-images detects an <img> with no dimensions —section 18's CLS— and font-display detects a @font-face without swap. They are binary and stable checks, exactly the ones worth setting as error.

And the complete workflow, following 08-06's cheap-things-first order:

The last step saves rollup-plugin-visualizer's treemap as an artifact of the run. When the budget fails three months from now because somebody added a charting library, that report will tell you which one in thirty seconds.

This is the closing of the contract 09-01 established. Same procedure —median of 15 runs after 5 warm-up runs, CPU 4×, Slow 4G, incognito, the same reference laptop, the same board of 600 tasks from a fixed seed.

And the breakdown of row 1, because it is the one that sums up this lesson's work:

And the Network panel's summary bar, compared with 09-01's:

Nine green ticks and one amber warning. The warning is worth looking at, and above all the bill.

Row 7 did not reach zero. The target was "0 ms on the main thread" and the result is 52 ms: 3.3 ms to serialize the outbound trip, about 45 for the return trip with the full report and a few more to receive it. Taking the computation off the main thread does not eliminate the cost of crossing the boundary, as 09-02 explained with structured cloning. It could be brought down further by using a transferable ArrayBuffer for the numeric data, but that would mean hand-serializing a structure that today is a readable object. Fifty-two milliseconds are one dropped frame, not a frozen interface. It is a conscious decision, not an oversight, and that is how it should be documented.

The remaining 0.02 of CLS is the summary bar going past three digits, and it is already explained in section 18: chasing zero would require fixing the height of something genuinely variable.

None of this is measured in the field. All these numbers are lab numbers, on a specific laptop with simulated throttling. The web-vitals setup you installed in 09-01 is still the only way to know what actually happens to Marta on her phone. The lab/field distinction from 09-01 does not disappear because the table has gone green.

And now the bill, which is the part almost nobody writes down:

All of that is real complexity, and not all of it was justified in advance. If Taller Nómada had six tasks instead of six hundred, almost none of this module would have been necessary: the render cost 1.4 ms, there were no perceptible leaks and 214 kB on a decent network is half a second. The discipline from 09-01 was not about optimizing everything, but about measuring first to know what was worth doing, and that discipline includes the opposite decision: not doing anything when the measurement says it is not needed.

If you had to keep only three things out of the fifteen you have done, the three with the best benefit-to-complexity ratio would be: fixing the layout thrashing (310 → 179 ms, half an hour of work, zero added complexity), bundling and minifying (4.1 → 2.8 s of LCP, one configuration file) and subsetting the font (72.6 kB less, one terminal command). All three are infrastructure or ordering changes, not architectural ones. Virtualization and the worker, which are the most impressive, are also the ones that leave the most debt.

• Optimizing execution when the problem is loading. During the 4.1 s of the baseline, your code had not run yet. Measure where the time is before deciding what to touch.
• Putting a classic <script> with no defer in the <head>. It stops HTML parsing. With type="module" the problem does not exist.
• Using async believing it is "defer but better". async does not guarantee order and runs as soon as it arrives, possibly at the worst moment.
• Reading Coverage right after loading and calling "dead code" what is only "code not run yet". They are two different questions and require two ways of stopping the recording.
• Believing bundling is "putting everything in one file". Today the goal is a few well-chosen files, separated by rate of change and by moment of use.
• Transpiling to ES5 "just in case". It inflates the bundle by 20–30% and adds polyfills no browser with ES modules needs.
• Disabling source maps in production. They are not downloaded unless DevTools is open, and without them a real error is unreadable.
• Assuming tree shaking works. It fails with import * used opaquely, with modules that have side effects and with dependencies that only publish CommonJS. Check it with the visualizer.
• Over-splitting. Every import() is a round trip. Splitting a 3 kB module trades 3 kB for 280 ms on Slow 4G.
• Using a bare import(variable). The bundler does not know what to include. Leave the fixed part visible: import(\./texts/${code}.js`)`.
• Not handling a dynamic import() failure. A new deployment can delete the chunk an open tab is about to request. Detect the error and offer a reload.
• Caching the promise of a failed import(). Every subsequent attempt will fail forever. Clear it when the retries run out.
• Preloading too many things. If everything is a priority, nothing is. preload works because it displaces other resources in the queue.
• preload of a font without crossorigin. It causes two downloads of the most expensive resource on the page. It is the classic mistake.
• loading="lazy" on the LCP image. It deliberately delays the main metric. Lighthouse detects it and tells you off.
• Images without width and height. It is the number one cause of CLS, and the two numbers do not interfere with responsive design.
• Serving a full 94 kB font to write in English. Make a subset: 21.4 kB with the same glyphs you use.
• font-display: block or auto. Invisible text for up to three seconds. swap at minimum, optional if CLS rules.
• Believing a skeleton improves LCP. It improves CLS and perception; LCP measures content, and a skeleton is not content.
• Not checking that compression is on. If "transferred" and "resources" match in Network, there is no Gzip and no Brotli. It is worth 150 kB to check.
• Recompressing WebP, WOFF2 or MP4. They are already compressed: you waste CPU and sometimes make them bigger.
• Caching the HTML or sw.js. The HTML points at the hashed names; if it is cached, users stay on the old version forever.
• Leaving the service worker's precache list hand-written after adding a build step. addAll is atomic: one non-existent path and nothing is installed.
• Precaching the lazy chunks. You would download at startup exactly what you had just taken off the critical path.
• Tip: always measure with Disable cache and Slow 4G. Without that you are measuring your second visit on fiber.
• Tip: separate chunks by rate of change, not just by size. That is what makes the cache work at a fine grain.
• Tip: save the visualizer report as a CI artifact. When the budget fails in three months, you will have the answer in thirty seconds.
• Tip: set binary assertions as error and time-based ones as warn. "Compression is missing" is deterministic; "LCP 2.6 s" may just be the runner having a bad day.
• Tip: write in the code the number that justified each optimization, with its date. Two years from now, whoever reads VirtualList deserves to know it was added to go from 7,812 nodes to 1,194.

Exercise 1 — Diagnosis from the Network panel. A colleague deploys Nómada Tasks on her own server and shows you this summary bar and this extract, measured with Slow 4G in incognito:

Identify four distinct problems, say exactly what you base each claim on, and propose a concrete fix for each. Then estimate which of the four will have the biggest impact on LCP and why.

Exercise 2 — Deciding what to split. Taller Nómada wants four new features. For each one, choose between "static import", "import() on activation" and "import() with preloading in requestIdleCallback", justifying it with the three conditions from section 12 and with the cost of a round trip on Slow 4G (~280 ms).

1. A 2.1 kB form validator used whenever any task is created.
2. A 186 kB PDF exporter used by 3% of visits, always at the end of the session.
3. A 34 kB emoji picker for comments; 40% of visits use it, typically within the first thirty seconds.
4. A 6 kB accessibility module that installs keyboard shortcuts and runs as soon as the page loads.

Exercise 3 — Closing a CLS of 0.34. Nómada Tasks's new statistics panel has a CLS of 0.34, broken down like this according to the Performance panel: 0.18 from a cookie notice banner being inserted at the top, 0.09 from a chart loaded with dynamic import() arriving, 0.05 from the font swap, and 0.02 from a logo <img>. For each one: (a) explain why the shift happens, (b) write the concrete fix with its code, and (c) say whether the resulting CLS would meet the ≤ 0.1 target. Then answer: why does a shift caused by the user (pressing "See details" and having a panel expand) not count towards CLS?

Solution 1

Problem 1: there is no compression. You can see it directly in the Size column: transferred and resource match on every text file (44.1 / 44.1, 17.9 / 17.9, 9.1 / 9.1), and the summary says 291 kB transferred · 294 kB resources. With Brotli, those 71.1 kB of JS and CSS would travel as about 21.6 kB.

Problem 2: the lazy chunks are being downloaded. reports-5a3f18.js and editor-7e1b93.js appear in the initial load at High priority. That means the HTML references them, almost certainly with <link rel="modulepreload"> tags added by hand "to make them faster". They are cancelling out exactly the benefit of code splitting: 42.6 kB of critical path that 89% of visits do not use. The fix is to remove those two modulepreload tags from the HTML and, if you want to get the editor downloaded early, do it from requestIdleCallback as in section 14.

Problem 3: the font is not subsetted and arrives extremely late. 94 kB and 2,100 ms, at Highest priority, is the complete font with no subsetting (section 17.2). Besides, if it takes 2.1 s it is because it was discovered late, while parsing the CSS. A double fix: pyftsubset to bring it down to ~21 kB and <link rel="preload" as="font" crossorigin> in the <head>.

Problem 4: the cover image is the LCP element and has Low priority. It is the heaviest (78 kB), it is a PNG and it is the last to arrive, at 2,900 ms. Low indicates that it carries loading="lazy" or that the browser deprioritized it because it did not know it was important.

Which weighs most on LCP. Problem 4, no question. The LCP element is the cover image, and it arrives at 2,900 ms; no other fix can bring LCP below that moment. Converting it to WebP (78 → 22 kB), serving it sized to the viewport and raising its priority moves it up to about 1,100 ms. Problems 1 and 2 are next in importance, because they free up critical-path bandwidth that the cover image was having to share with 42.6 kB of useless JavaScript. It is a good illustration that network optimizations interact: taking weight off one resource speeds up the others.

Solution 2

The cross-cutting reading: the decision does not depend on size alone. Cases 2 and 3 weigh very differently and both are split; cases 1 and 4 also weigh differently and neither is split. What rules is when it is needed and with what probability.

Solution 3

(a) and (b), shift by shift:

The cookie banner (0.18). It is inserted into the normal flow, at the top, after the page has already been painted, and it pushes everything else down. It is the most damaging case possible: a large displacement, affecting the whole screen. Two fixes, and the second is the good one:

The chart loaded with import() (0.09). Its container is 0 px tall until the component mounts, and mounting makes it grow all at once. It is exactly the warning from section 16:

The font swap (0.05). When the web font arrives, its metrics differ from the fallback's and the text reflows. The fix is section 17.4's: a fallback @font-face with size-adjust, ascent-override, descent-override and line-gap-override, plus font-display: swap and a preload with crossorigin.

The logo (0.02). The space reservation is missing:

(c) Does it meet the target? Yes, comfortably. The fixed banner eliminates 0.18, the chart's min-height eliminates 0.09, the adjusted fallback eliminates 0.05 and the logo's dimensions eliminate 0.02: resulting CLS ≈ 0.00–0.02, well below the 0.1 target. It is worth measuring rather than assuming: the DevTools Rendering panel with Layout Shift Regions visually highlights any shift that is left.

Why a user-caused shift does not count. The CLS specification ignores shifts that occur within a window of 500 ms after a user interaction (a keypress, a click, a tap). The reason is that CLS aims to measure surprise, not movement: if Marta presses "See details" and the panel expands, pushing the content down, that is exactly what she asked for and it does not disconcert her. What ruins the experience is content jumping while she is reading, making her press the wrong button.

Two practical consequences of that detail. First: do not try to "hide" your shifts behind a fake interaction, because the goal is the real experience, not the metric. Second, and more useful: if an expansion takes more than 500 ms to happen after the click —because there is an import() in the way— the shift will count, and there you do have to reserve the space. It is one more argument for the previous point's min-height.

09-01's contract is closed. Ten numbers measured, ten numbers measured again with the same procedure, and a table that is no longer a list of complaints but a record of decisions: LCP from 4.1 to 1.9 s, INP from 480 to 42 ms, CLS from 0.21 to 0.02, longest task from 1,180 to 41 ms, render from 310 to 31 ms, recalculations from 96 to 1.5 ms, report from 940 to 52 ms of blocking, memory from +37.7 MB to +0.4 MB, nodes from 7,812 to 1,194, and initial JavaScript from 214 kB in 28 requests to 58.3 kB in 3.

You understand the performance that is decided before a single line runs. You know the critical rendering path and why CSS blocks rendering —so as not to show an unstyled page that would then jump— and why a classic <script> blocks parsing, with the complete table of defer, async and type="module" that closes what 01-03 and 06-01 noted. You know how to measure the real weight with the Network panel —Disable cache, Slow 4G, the Size column with its two values that give away missing compression, Priority and Initiator— and with the Coverage tab, which gave you the uncomfortable figure everything else follows from: 62% of the downloaded JavaScript was not running before the first card.

You know what a bundler does and, more importantly, why it exists: not to "put everything in one file", but to resolve the bare specifiers the browser does not understand, to eliminate the discovery cascade that cost 1.1 s across four levels, and to give files hashed names that make eternal caching safe. You have a real, annotated vite.config.js, with target: 'es2022' instead of over-transpiling, source maps enabled, and manualChunks separated by rate of change rather than by size. You know what minification does (214 → 118 kB) and what tree shaking does (118 → 104 kB), and why the latter is only possible because ES module imports/exports are static —05-04's restriction that now makes sense— with its four conditions for actually working: named imports, declared sideEffects, ESM dependencies and genuinely unreachable code.

You know how to split with dynamic import() applying the three conditions —that it is heavy, that it is not used on the first screen and that a concrete action triggers it—, with the report and its worker, the rich editor and the translations off the critical path: 46 kB less for 100% of visits. And you know how to do it properly: the cached promise that is cleared on failure, the partial literal that lets the bundler discover variable paths, aria-busy on the indicator, a dignified degradation when the chunk does not arrive, and detection of the new deployment that invalidated the hashes. You know the five resource hints and when to use each, with their three rules: preload little, never something you will not use on this screen, and crossorigin mandatory on fonts.

You know how to make images lazy —loading="lazy" except on the LCP one, decoding="async", fetchpriority="high" only for the LCP element, width and height always, WebP before arguing about lazy loading— and components, with IntersectionObserver and a generous rootMargin over already reserved space. And you know what almost nobody looks at: that a font can weigh more than all your JavaScript, and that font-display: swap, a subset from 94 to 21.4 kB, preloading with crossorigin and a fallback font with adjusted metrics are worth more than many hours of optimizing code. With those, and with image dimensions and a skeleton that reserves the cards' space, you closed the CLS from 0.21 to 0.02, knowing besides that a skeleton does not count for LCP and that a user-caused shift does not count for CLS.

You close the module with the infrastructure: Gzip and Brotli generated at build time rather than on the fly, without recompressing what is already compressed and always checking in Network that they are on; HTTP caching with a one-year immutable for hashed assets, no-cache for the HTML and for sw.js, and ETag for the rest; the reconciliation with the service worker from 07-05, whose hand-written precache list stopped working as soon as there was a build step and is now generated during the build, without including the lazy chunks; and 09-01's performance budget finally turned into something that breaks continuous integration: a script for bytes and requests —stable, deterministic and cheap— plus Lighthouse CI with its rule-based assertions, and rollup-plugin-visualizer's treemap saved as an artifact for the day somebody adds a 90 kB library without noticing. With the final honesty up front: row 7 stayed at 52 ms rather than zero, the 0.02 of CLS is a decision and not an oversight, all of this is lab and not field, and every improvement has had its bill in complexity —a build step, ninety lines of virtualization, a broken Ctrl+F, a destroy() in every class— that with six tasks on the board would not have been justified.

And this is where the module delivers something that is in no table. For Nómada Tasks to respond the way it does, you have had to build by hand, piece by piece, a very specific set of mechanisms: a declarative render that describes the screen from the state (06-06), a reconciliation by stable key that reuses nodes instead of destroying them, a centralized state with explicit invalidation and a version cache (09-02), a systematic cleanup with destroy() and AbortController so nothing is left dangling (09-03), a virtualized list that keeps the node count constant (09-04), and a code split with lazy loading, preloading and failure handling (09-05). That list is no coincidence: it is, almost point for point, what a modern framework gives you out of the box on day one. React asks you for a key in lists —which is literally your data-id—, Vue rebuilds only what changed, Angular ships code splitting in the router, and all three manage for you the lifecycle and the cleanup you wrote by hand. The difference is that now you know what problem they solve, what it costs to solve it and what you pay for not solving it yourself, which is exactly the position from which you can judge whether they are worth it instead of adopting them out of habit. That perspective is where the next module begins: Why Frameworks Exist.