In a CSS file the browser loads directly with a <link> tag, what rules govern where the @import at-rule may appear, and what does it cost at runtime compared with composing the same files at build time?

## What @import does `@import` is CSS's own file-inclusion mechanism. Written inside a stylesheet, it tells the browser to fetch another stylesheet and apply its rules as though they appeared at that point: ```css @import url("reset.css"); @import url("tokens.css"); @import url("components/card.css"); ``` It can also carry a media query, so the import only applies under matching conditions: ```css @import url("print.css") print; ``` On the surface this looks like exactly the file organisation you want: one entry stylesheet in the `<link>`, with the real structure expressed as an ordered list of imports. The order of the `@import` rules *is* the cascade order of the files, which makes the entry file a readable statement of architecture. ## The placement rule `@import` is only valid near the top of a stylesheet. It must precede every style rule, and the only things permitted before it are `@charset` and `@layer` **statement** rules — the form that declares layer names without a block, like `@layer reset, base, components;`. Anything else in front of it makes the import invalid, and an invalid `@import` is dropped silently: no console error by default, no missing-file warning, just styles that never arrive. ```css @layer reset, base, components; /* allowed before @import */ @import url("reset.css"); /* applied */ body { margin: 0; } @import url("components.css"); /* ignored - a style rule came first */ ``` This catches people when they append an import to the bottom of a growing file, which is exactly where a hurried edit tends to land. ## Why runtime @import serializes work The browser discovers subresources by parsing. When the HTML references `main.css`, the browser requests it. Only once `main.css` has arrived and been parsed does the browser learn that `reset.css`, `tokens.css` and `card.css` exist — and only then can it request them. If `card.css` itself imports something, that is a third round trip. Compare that with declaring the sheets directly in the HTML: the parser sees several `<link>` elements at once and can request them in parallel immediately. `@import` converts a parallel fan-out into a dependency chain whose depth equals your import nesting. On a fast local network this is invisible; on a high-latency mobile connection each extra hop is a full round trip added before the page can render. This is why "never use `@import` in production CSS" became folklore. The rule is right, but the reason matters: the problem is not the at-rule, it is *discovering files late over the network*. Whether that latency is worth optimising for a given page is a performance-strategy question in its own right; the mechanical fact — imports are discovered serially — is what you need to be able to state. ## What a build step changes Every modern CSS toolchain resolves `@import` at build time. The tool reads the entry file, follows the import graph, and emits the concatenated result as one stylesheet (or as a small number of chunks aligned with routes). The browser then receives a file with no `@import` rules in it at all. That inverts the tradeoff completely: - **Authoring**: you keep one file per component, one file per token group, one entry file that reads as an ordered table of contents. - **Delivery**: a single request, no discovery chain, and the concatenation order is exactly the order you wrote the imports in — so the cascade behaves precisely as your entry file describes. The configuration and behaviour of any particular bundler is that tool's own subject; the architectural point is only that composition moved from run time to build time, and that the entry file's ordering survives the move. ## Practical guidance Use `@import` freely as the source-level composition mechanism when a build step will flatten it. Avoid it in stylesheets shipped raw to the browser, and if you must ship raw CSS, prefer several `<link>` elements over an import chain so requests can go out in parallel. Whichever you do, keep the entry file *only* imports. The moment a real rule appears in it, two things break at once: any import written below that rule is silently discarded, and the file stops being a readable map of the project.