Inline, internal or external CSS: what's the difference?
They differ in where the CSS lives, and in whether the browser must fetch something before it paints.
| Where the CSS lives | Holds up the first paint? | Cached for the next page? | Use it for | |
|---|---|---|---|---|
Inline (style attribute) | on one element: <p style="color:red"> | no | no | a one-off, never a site's CSS |
Internal (<style> block in the head) | in the page's HTML | no | no, it comes again with every page | rarely: a site built for it |
External (<link rel="stylesheet">) | in a separate .css file | yes, until the file arrives | yes | your site's CSS, in a few trimmed files |
When PageSpeed Insights suggests "inlining" or a plugin offers to inline your CSS, it means the <style> block, what tutorials call internal.
Moving CSS can change which rule wins. A style attribute always overwrites the normal rules in your stylesheets. Between a <style> block and a linked file there is no rank: with equal specificity, the later rule wins. Keep the CSS in the same spot in the head, make relative url() paths absolute, and the page looks the same.
Is inline CSS faster?
On the first view, yes, by one round trip. A stylesheet in the head is render-blocking: the browser paints nothing until it has fetched the file. Inline CSS comes with the HTML.
This website inlines all its CSS, so it makes a good test case: its template has one <style> block, 7.8 KB compressed. I moved that CSS into a separate file. Both versions loaded in Chrome, throttled like a phone, nine runs each, one evening in late October 2026: first this page, then a second article.
On Slow 4G the first paint came at 792 ms inline and at 1,424 ms with the file, 632 ms later. The cached file won back 48 ms on the second article (600 against 648 ms). Fast 4G gave 356 against 432 ms on the first view, and 224 ms both ways on the second.
The CSS in the HTML, and the same CSS as a file, in the test run of October 29, 2026.
On this site, a separate file would cost a round trip to the visitor who arrives from Google, and its cache would pay back almost nothing. That's one small stylesheet in a lab, on a CMS built for inlining, and a real phone on good 4G sees a smaller gap.
How do you check what your CSS costs?
PageSpeed Insights lists every stylesheet that holds up the first paint under "Render-blocking requests", with its size. One small file there: leave it. Many files, or big ones: trim and combine them, as corewebvitals.io explains with the WordPress and Shopify settings. Scripts are the other half of that list: defer them.
After the change, watch real visitors. In MarketingTracer, Speed > Diagnosis shows the first contentful paint of real Chrome visitors (75th percentile) next to your competitors. It covers the whole site over 28 days, so a fix shows up gradually. Sites with little Chrome traffic get no number. For single pages, the SEO audit has lab timings of the pages the crawl found.
When is a separate file better?
Almost always. Inline CSS rides along in every page's HTML, ahead of anything visible, on every view. And this site's 7.8 KB is small: on home pages that have render-blocking requests, State of CWV data puts the median at 8 requests and 110 kB, scripts included. One trimmed file, or a few, cached after the first page, is the better deal.
Critical CSS, or "Load CSS asynchronously" in WP Rocket and LiteSpeed, inlines the first screen's CSS and loads the rest later. The page styles itself twice and can shift, and every template change means a new critical CSS. Leave it off, unless you know exactly what you want from it.
In principle, no inline CSS. Optimize your CSS: no single file over about 15 KB compressed, and not twenty tiny ones either. Inline CSS isn't cached, so it's not a good idea. Our own CMS is the exception: hyper-aggressive prefetching, full-page caching in the browser and at the edge, static content only.