@defer: Deferrable Views, Triggers, and Prefetch In short: Before v17, Angular could only delay loading code at one place — the route. lets any part of a template load its own code when it is actually needed. If you wanted to delay loading a heavy chart sitting below the fold on a page the user is already on, you had to write it by hand: a dynamic import, a view container, manual component creation, and manual updates. makes it a few lines, and the build tool splits the code for you. The shape Four blocks, only the first required: — the delayed content. Its code goes into a separate file. — shown before loading starts. Keep it light; its code is not delayed. — shown while the code downloads. — shown if the download fails. The timing settings These exist to stop flickering, and they are worth getting right. — if the code arrives in 20ms from cache, showing and hiding a skeleton that fast is just visual noise. This keeps the placeholder up for at least half a second once shown. — means do not show a spinner at all unless loading has already taken 100ms. means once shown, keep it for 300ms. Together they remove the spinner flash on fast connections while still giving feedback on slow ones. The triggers This is where the feature earns its place. , , and need something to watch. They use the content by default, so those three need a block — or a named element: There is also , which takes any true/false value: One important thing: is not reversible. Once the condition becomes true and the block loads, it stays loaded. Setting it back to false does not unload anything. is a one-way door — it controls when to load , not whether to show. If you need something to appear and disappear, that is . Triggers can be combined with , meaning "whichever happens first": Prefetching The default triggers all cost time at the moment of use. means the user clicks and then waits for a download. separates downloading from showing : The code downloads when the pointer moves over the button. It appears when the button is clicked. Usually the code is already there, and the click feels instant. is the safe general choice for things likely — but not certain — to be used: What can and cannot be delayed The rule that catches people: everything inside the block must be used only inside delayed blocks. If a component appears both inside a and somewhere else in the same template, it cannot be split out — it is needed straight away, so it stays in the main download. The still displays correctly. It just achieves nothing: Related rules: Delayed components must be standalone . On the server , shows the . This connects directly to Chapter 7. To check whether a actually split anything, look at the build output — you should see a new separate file appear: If the main file did not shrink, something is loading it straight away. Where it is worth using Good candidates share a shape: heavy code, not needed for the first view. Chart libraries below the fold Rich text editors behind an "Edit" button Maps in a tab that is not the default Comment threads at the bottom of an article Date pickers, PDF viewers, code highlighters Anything in a popup or side panel Poor candidates: small components (the extra request costs more than you save), anything above the fold, and anything needed within a second of loading. "But don't we already have lazy loading?" You do — at the route. That is the point of : it moves the line from pages to parts of pages . The fact that makes this land: on most content-heavy pages, most of the code belongs to things the user may never see. A product page's chart, review widget, recommendation carousel, and chat button can easily be several times bigger than the page's own logic. Route-level loading cannot help — the user is on that route. All of it downloads before anything works. The second question — "so should I delay everything?" No, and this one costs real speed. Every delayed block becomes a separate download with its own request overhead. Delaying something small, then paying for a round trip when it is needed, is a net loss. Angular's guidance is to avoid deferring components that are visible in the viewport on initial load, because swapping a placeholder for real content shifts the layout under the user. The third question — versus ? They look similar and are not: --- --- --- Question it answers Should this show? When should this load ? Reversible Yes No — once loaded, stays loaded Affects download size No Yes Setting it back to false Removes it from the page Nothing happens on a panel that opens and closes will load once and never unload. If you want it to disappear, use — and you can nest them. The architect's view The question lets you ask is one route-level loading never could: which parts of this page does a given user actually need? On a content-heavy page, a lot of the code belongs to things a minority of visitors ever reach — a chart below the fold, a comments thread, a size guide behind a link, a chat widget. Route-le…