CSS @import: Why It Delays Rendering and What to Use

Short answer: A CSS @import rule tells the browser to fetch another style sheet from inside a style sheet. The browser can only discover that file after it has downloaded and read the first one, so the requests happen one after another instead of side by side. Because style sheets block the first display of a page, this chain can delay everything. Replace @import with separate link tags, a combined file or self-hosted resources.

What @import does

CSS lets you include one style sheet inside another with a rule such as @import url(“other.css”). It is convenient, because it keeps related styles in separate files and allows one file to pull in the rest. Some themes use it to load a font from a font service. Some site builders and “additional CSS” boxes add it as well, and developers sometimes add it by habit.

The convenience has a cost that most people do not see. It affects how the browser plans its downloads, and the effect is largest on slow connections.

Why it is slow

A browser builds a page in stages. It reads the HTML and, as it reads, it starts to download the resources that it finds: style sheets, scripts and images. When the HTML contains several link tags for style sheets, the browser sees all of them at once and downloads them in parallel.

An @import rule hides inside a CSS file. The browser cannot know about it until the first file has arrived and been read. Only then does it start the second download. If the imported file has its own @import, a third one waits behind it. The result is a chain, as in this example:

The HTML arrives and points to main.css.
main.css arrives, and the browser sees an import of fonts.css.
fonts.css arrives, and the browser sees a font file inside it.
The font file is requested and arrives.

Every step in the chain adds a full round trip to the server. On a mobile connection with a delay of a few hundred milliseconds per request, three steps can add a second or more before the page can be shown. The pattern is easy to spot in the waterfall chart, where the requests form a staircase instead of a block.

Why style sheets block rendering

Browsers normally wait for the style sheets that are linked in the head before they paint the page. Showing content without its styles would cause a flash of unstyled text and a jump when the styles arrive. So style sheets are called render-blocking resources, a topic explained in the guide to eliminating render-blocking resources. An imported file is part of the blocking set. The page must wait for the whole chain.

This affects the metrics that users and search engines care about. A late start delays First Contentful Paint, described in the article on FCP, and it often delays the Largest Contentful Paint too, as covered in the guide to improving LCP.

Where @import appears on real sites

Font services. Code snippets copied from the web often begin with an @import for a font family.
Theme style sheets. Child themes in WordPress used to load the parent style sheet with @import. Current practice is to enqueue it properly, but old child themes still do it.
Custom CSS boxes. Page builders and customiser panels allow you to paste code, including imports.
Plugins. Some add style sheets to admin or front-end pages with an import.
Framework files. Large CSS frameworks may import their parts.

Search your style sheets and the style blocks in your page source for the text “@import”. If you use a preprocessor such as Sass, note that its own import is processed at build time and joins files before they reach the browser. That kind is harmless. The slow kind is the one that remains in the final CSS that visitors download.

What to use instead

Separate link tags

The simplest fix is to list each style sheet as its own link tag in the head. The browser discovers them together and downloads them in parallel. In WordPress, themes and plugins should add styles through the proper enqueue functions, which produce link tags.

One combined file

Combining files at build time reduces the number of requests. Many caching and optimisation plugins can join and minify style sheets, as explained in the article on minifying CSS and JavaScript. With HTTP/2 or HTTP/3 the number of requests matters less than it used to, but a chain of dependent requests is always worse than parallel ones.

Fonts through a link tag or self-hosting

If the import loads a font, use a link tag with a preconnect hint, or host the font on your own domain. The trade-offs are discussed in the guide to self-hosting Google Fonts and in the article about web font performance. Resource hints are explained in preload, preconnect and prefetch.

Inline critical styles

For advanced optimisation, the styles needed for the first screen can be placed directly in the HTML, and the rest loaded later. See the article on critical CSS. This is worth doing only after the simple fixes.

How to fix it step by step

Find every import. Search your theme, plugin and custom CSS for @import, and note the files they pull in.
Decide how to replace each one. Link tag, combined file or self-hosted font.
Make the change on a staging copy. Layout can change if the order of styles changes, because later rules override earlier ones. Keep the same order.
Clear caches. Purge page, CDN and optimisation plugin caches so that visitors receive the new files.
Compare the waterfall. The staircase should become a flat block, and the first paint should move earlier.
Test on a phone. Confirm that the page looks the same and loads faster on a throttled connection.

How much time can you save?

The gain depends on how long the chain is and how slow the connection is. A site with one import of a small file on a fast office network may see no difference at all. A site with a chain of three imports, tested on a mid-range phone with a mobile connection, can see the first paint move earlier by a second or more. The only honest way to know is to measure your own pages.

Record a baseline with a throttled mobile profile in your testing tool, and note First Contentful Paint and Largest Contentful Paint.
Apply the change.
Run the same test at least three times, and compare the median values, because single runs vary.

Be careful not to expect miracles. Replacing an import is one improvement among many, and large images, slow servers and heavy scripts often cost more. Its value is that it is cheap, safe when done carefully and permanent. Once the chain is gone, it will not return unless someone adds a new import, so mention the rule in your development notes and ask agencies and plugin authors to follow it.

If you cannot change the code, for example because it belongs to a theme that you do not control, ask the theme author for a fix, or switch to a theme that loads its styles properly. A slower first paint that you cannot influence is a fair reason to reconsider the theme itself.

Common mistakes

Changing the order of styles. Moving files around can change which rule wins and break the layout.
Replacing the import but keeping the chain. If a file still pulls in another file by script or by a font rule, the delay remains.
Combining everything blindly. A huge file with unused rules is also slow. Remove what you do not use, as discussed in the article on unused CSS.
Testing only on fast connections. The delay shows most on slower networks.
Forgetting the admin side. Imports in the visitor-facing part matter most. Do not spend time on the dashboard.

How Site AI Audit helps

Site AI Audit does not scan style sheets for @import rules. It measures the result visitors feel: the Google PageSpeed score, loading metrics such as LCP, CLS and INP, server response time, compression and page weight, together with checks for SEO, security and e-mail. Use it before and after a change to confirm that pages became faster. The first check is free, covers up to 50 pages and needs no sign-up. You can run a free check of your website or see the plans for weekly monitoring and alerts.

The bottom line

CSS @import hides files from the browser until it is too late. Replace it with link tags, a combined file or self-hosted fonts, keep the order of styles and check the waterfall afterwards. It is a small change that often makes the first screen appear sooner.

KKK

Is @import always bad?

In the final CSS that browsers download, it usually creates avoidable delay. Build-time imports in a preprocessor are fine, because they are combined before delivery.

How can I tell if my site uses it?

Search style sheets and page source for “@import”, or look for a staircase of CSS requests in the network waterfall.

Does HTTP/2 fix the problem?

No. It helps parallel downloads, but the browser still finds imported files late, so the chain remains.

Can I import Google Fonts with @import?

It works, but a link tag with a preconnect hint, or self-hosted fonts, is faster and more predictable.

Will fixing it change how my site looks?

It should not, as long as the order of the styles stays the same. Test the main pages after the change.