@import url("other.css") inside a CSS file (or inline <style> block) tells the browser to fetch and inline another stylesheet at that point in the cascade. Functionally similar to a <link rel="stylesheet"> tag, but with a critical performance difference: serial dependency.
The cost flow:
- Browser fetches the parent stylesheet.
- Browser parses the parent. Discovers
@import url("other.css"). - Browser THEN fetches
other.css(it had no idea this URL existed until parse). - Browser parses
other.css. May discover yet more@importrules.
Compare with declaring <link rel="stylesheet" href="other.css"> directly in HTML:
- Browser parses HTML, discovers BOTH
<link>tags simultaneously. - Browser fetches both in parallel.
In HTTP/1.1 days, the @import serial pattern was catastrophic -- each import added a full round-trip to render-blocking time. HTTP/2+ multiplexing reduces the connection-establishment cost but the discover-then-fetch dependency is still strictly worse than parallel fetching from the parser.
The right pattern: declare every render-critical stylesheet as a <link rel="stylesheet"> in HTML so the parser discovers them immediately. Reserve @import only for dev-time tooling that bundles before deployment (Sass @import, Webpack import 'styles.css' in JS) -- both of those compile away to a single concatenated file in production.
Common bug: a CMS plugin or theme adds an @import inside the inline critical-path stylesheet "for convenience." This silently delays first paint by one round-trip per import.