By Asha Laxmi

How and Why You Should Inline Your Critical CSS

By Asha Laxmi

A website stage setting

In the early days of the internet, websites were primarily used to show text based information. Slowly, our connection speeds have improved and users have been able to download high-resolution images and videos fairly quickly. Now websites do a lot more than just provide necessary information in the form of text. Websites are becoming more complicated, with CSS and JavaScript frameworks, plugins galore and more. With all of this in play, loading all the necessary files for all of this can take some time.

A faster website can result in a better user experience, which can make a huge difference in a website’s success. What can developers do to start making performance improvements? One thing that developers can do which helps greatly is to inline critical CSS and load non-critical CSS asynchronously. In this article, we’ll cover these points one-by-one and help you improve your website’s performance.

What is Critical CSS?

The critical CSS in your project is the CSS that’s used to style the above-the-fold content of your website. Above-the-fold content is what users see on your website first, which can include navigation and other elements. So it’s very important to properly style and render this part of the website as quickly as possible.

One thing that I would like to mention here is that your visitors probably use a myriad of devices with different viewports to visit your website. So, above-the-fold content is not going to be of much help by itself. To solve this issue, you should also consider any CSS related to the basic layout and typography to be critical as well.

Modern web development practices often recommend that you inline your critical CSS. It would be placed into your web page like so:

<!doctype html>
    <title>An Optimized Web Page</title>
    <style type="text/css"> (Your minified critical CSS would be here) </style>
     (Your markup)

Why is Inlining Necessary?

If you head over to Google PageSpeed Insights and analyze one of your web pages, you might see warnings about optimizing your CSS delivery by inlining critical CSS and loading render-blocking stylesheets asynchronously.

Browsers won’t render the above-the-fold content of your web pages unless they have loaded all of your CSS files. This can be a big deal when a lot of files need to be loaded.

Not all of your users will have a fast internet connection and waiting for the libraries, CSS and JavaScript to load before they can actually access the content they came for can be very frustrating. Even users with fast internet can lose connectivity in certain situations, like when they are passing through a tunnel. At this point, they would still be able to access the main content if your website has inlined critical CSS and doesn’t load other files before showing main content.

The image below illustrates the difference between a regular and an optimized web page. As you can see, the optimized version will allow users to access the content about 0.5 seconds earlier. The improvements will be more pronounced when there are a lot of extra libraries that need to be loaded.

Inline CSS loading stages

Should You Inline Critical CSS?

It depends on the situation. If you are not using any heavy frameworks or libraries and your own CSS files also have a small size, then you may not need to inline your CSS.

If you are using a framework like Bootstrap, you are probably not using all the features that the framework offers. In that case, you can just extract the critical CSS from the framework’s stylesheets and load the actual framework asynchronously. This should significantly improve your website’s speed.

While inlining, stylesheets can be cached. HTML often is not cached (it is often not a good idea to do so!). This means there can occasionally be a difference between the two. Keep this in mind when making updates! Also, the inlined CSS will result in some extra page weight every time a user loads your website. For example, if there is 30kB of inline CSS on every page of your website then 10 page views by a single user will cost the user 300kB. It may not sound like a big deal but data is expensive in some parts of the world (and on some 3G/4G data plans). Ensure that the CSS you are planning to inline is genuinely critical to your web page and you are not inlining everything.

Finding Critical CSS

Finding critical CSS manually will be a daunting and boring task. Fortunately, there are tools available that can help you do it quickly.

Using Grunt

If you are familiar with the Grunt build system, there is a plugin which makes this process easier — the popular grunt-critical plugin. If you prefer Gulp or using npm, see the next sections for how to do this process with those.

First, you need to install the plugin using the following command:

npm install grunt-critical --save-dev

You also need to create your Gruntfile.js. This will contain all the code to set various options for the plugin including viewport dimensions and the path to source and destination file. Here is an example:

module.exports = function(grunt) {

    critical: {
      extract: {
        options: {
          base: './',
          width: 1024,
          height: 768,
          minify: true
        src: 'path/to/initial.html',
        dest: 'path/to/final.html'

  grunt.registerTask('default', ['critical']);


Inside our wrapper function, we use the grunt.initConfig method to specify all configuration options. In this case, I have specified a base directory in which the source and destination files are to be written. I have also set the minify option to true. This gives me a final minified version of the critical CSS that the plugin extracts. The src property contains the location of our source file which is to be operated against. The dest property contains the location where the final output needs to be saved.

In case the dest file is a stylesheet, the resulting CSS is saved to a file for use in future. However, if the dest property is a markup file (HTML, PHP and so on), then the CSS is inlined and the existing stylesheets are wrapped in a JavaScript function to load them asynchronously. A noscript block is also added for users who have disabled JavaScript. There are other options available as well. You can access the full list of options on critical’s documentation.

Now, you can just run the plugin by typing grunt into the console:


If your initial file had the following markup:

<!doctype html>
    <title>The Optimizer</title>
    <link rel="stylesheet" href="link/to/stylesheet">
     <div>All the markup stuff</div>

It will now look like:

<!doctype html>
    <title>The Optimizer</title>
    <style type="text/css">Minified Inlined CSS</style>
    <script id="loadcss">
       JavaScript to load styles asynchronously...
      <link rel="stylesheet" href="link/to/stylesheet">
     <div>All the markup stuff</div>

As you can see, this plugin does all your work for you. Now, if you analyze your web page using PageSpeed, you should get a better score. In my case, the score changed from 86 to 95.

There are other plugins available for Grunt that achieve a similar feat — grunt-criticalcss and grunt-penthose. However, when using these plugins you will have to specify the stylesheets from which to extract the critical CSS.

Using npm Modules

Critical is the npm package created by Addy Osmani, it contains the functionality that the grunt-critical plugin uses. You can use it without Grunt to extract and inline critical path or above the fold CSS from a web page using JavaScript and npm. To install the package, you need to run:

npm install critical --save-dev

Once the package has been installed, you need to create a JavaScript file in the project directory and put the following code in it.

var critical = require('critical');

  inline: true,
  base: 'initial/',
  src: 'homepage.html',
  dest: 'final/homepage.html',
  width: 1366,
  height: 768

You can specify a bunch of options to create your optimized web page. Setting inline to true will generate an HTML page with CSS inlined, otherwise a CSS file will be generated. The width and height option set the dimensions of our target viewport. There are a lot of other options like minifying the inlined CSS which you can find on the critical npm package’s documentation. The markup of the optimized web page will look similar to the output by the grunt plugin.

Another npm module that is available for you to use is the critical-css module. This module generates the critical CSS from the supplied URL. The generated CSS can be further processed using a callback function because the grunt plugin is based on this package.

Using Gulp

If you are more comfortable working with Gulp, Addy Osmani recommends Gulp users use the Critical npm module directly. The example he provides on the Critical GitHub page for Gulp users looks like so:

var critical = require('critical').stream;

// Generate & Inline Critical-path CSS
gulp.task('critical', function () {
  return gulp.src('dist/*.html')
    .pipe(critical({base: 'dist/', inline: true, css: ['dist/styles/components.css','dist/styles/main.css']}))

The Critical team also have a sample Gulp project showing this in action.

There is also a gulp-critical-css plugin to generate critical CSS. However, this one works by extracting certain selector types from your CSS, rather than by detecting above-the-fold elements and so on.

More Resources

Another tool available is the Critical Path CSS Generator by Jonas Ohlsson. All you have to do is enter your page URL and then supply all the CSS from which you want to extract the critical CSS. Clicking on the “Create Critical Path CSS” button after that will output your CSS.

The article on CSS-Tricks outlines how you can use CSS preprocessors to author critical fold CSS. Additionally, SitePoint has also published an excellent article about optimizing critical rendering path in the past that you can read to gain a deeper understanding of the topic.


Whether you should or shouldn’t inline critical CSS depends on the visiting pattern of your users and the structure of your website. If your website is a one pager and visitors are not going visit it frequently, or if you’ve got a complex site with frameworks and plugins, inlining critical CSS can improve performance significantly.

The only concern about inlining is that it adds additional page weight for each visit. This can be mitigated by using cookies and sending critical CSS only during the first visit while still loading the full CSS file asynchronously and then caching it. It is a little complicated but you get the best of both worlds.

Have you tried inlining CSS in your own projects? How significant were the improvements? Do you have any advice for fellow developers? Let us know in the comments.

  • M S i N Lund


    Just stop.

    First thing:

    Google PageSpeed Insight is useless for this.
    The only way you can get it to STFU about inlining css, is by inlining almost all your css on all your pages.

    And we all understand just how stupid that is.

    Only an idiot follows all the recommendations of services like that, blindly.
    Especially when they go STRAIGHT OPPOSITE of what we know about how the web works.


    They, (and you) don’t seem to understand how caching works.

    External css, done right, is fetched only once , and then reused for every page-load on every page on your site.

    Inlined css, on the other hand, is never ever cached.
    This means the same css will be fetched again,
    and again,
    and again,
    and again,
    and again,
    and again,
    Wasting resources for every single person using your stuff, including site-owner and end users.

    Never inline css.


    You will only create extra work for anyone coming after you, who will have to de-bloat your crappy design, like its some old fan-site from the 1990’s, after this idiotic “Inline Your Critical CSS”-fad has gone the way of the flash landing page.

    Step one, when you inherit an old crusty site, that needs to be refreshed and speed up:
    Check for inlined common resources, like css and js, etc that can be lifted out and cached between page-loads.

    What you DONT do, is sit and cram stuff BACK into the html, like some F noob!

    No wonder the web is getting slower and buggier by the day, with tutorials like this.


    • Asha Laxmi

      Thank you very much for politely explaining why no one should inline critical CSS. :)

      Now, could you please reread the last paragraph under “Should You Inline Critical CSS?”. If you pay attention, you may notice that I have clearly mentioned that only the CSS that is genuinely critical should be inlined. I have even put that part in bold.

      In the conclusion, I have also mentioned that “This (The isssue of repeatedly serving a page with inlined CSS) can be mitigated by using cookies and sending critical CSS only during the first visit while still loading the full CSS file asynchronously and then caching it.”

      As you said, only an idiot follows all the recommendations of services like that, blindly. So, please don’t follow the guidelines blindly. You should be able to tell which CSS is actually critical by experimenting a bit.

      Have a nice day!

      • M S i N Lund

        Oh, so you wrote an article about how to load a gun, put it to your head and pull the trigger.
        …but you put “And make sure you don’t hurt yourself” in bold right there in the article, so its all good.

        Here is the problem:
        Everything on your site is “above the fold”, its an antiquated concept.
        And all your css is “critical” somewhere, otherwise you could just remove it.

        So effectively, you are telling people to not cache any css, which is obviously wrong.

        And then you are telling hem to use some cookie-hack, that you cant be bothered to explain, to avoid the stupid thing you just told people to do.

        It would seem that the cookie-hack, is the most important part of your article, because its is needed to negate the bad effects from the bad advice in the rest of the article.

        Have you actually used it?
        Do you even know how to do these things, or have you just read similar tutorials from people who also don’t know?

        I think you know exactly what will happen when noobs read articles like this.

        They will follow the steps you describe, but not the steps you don’t describe.
        And they will trust you know what you are saying.
        And we will have more sites with zero cached css.

        Great job!

        • Nitij Kumar

          As a personal rule I never trust authors who have not done the research themselves before putting their thoughts into words.

          Btw, your comment is pretty bad-ass though, kudos to that :D

          • Asha Laxmi

            Hi Nitij,

            Do you know how I created the filmstrip that I have included in the beginning of the article?

            I researched. That’s how I could find out which CSS should be inlined to load the top part of the website with its basic structure quickly. Instead of waiting for all the resources to load first, I just inlined the critical CSS and loaded rest of the libraries later.

          • Nitij Kumar

            The meaning of research is to thoroughly study and dig the finer details about how anything works. I would definitely feel more confident in having the so called critical inline css in my code if I can see the various examples and associated metrics in terms of performance and code complexity.

            Apart from the above in a team environment introducing things like these could prove to be catastrophic if all the devs and designers don’t know the meaning and effective implementation know-hows.

            All things aside, I would never sacrifice code maintainability over tiny performance gains which we could implement using dirty hacks which could jeopardise the application flow in a production environment.

          • M S i N Lund


            The problem is that some devs gets bored when things work and then have to much time on their hands to fuck with things.

            So they start to move things back and forth.

            – Gotta break out all the CSS to speed things up!
            …oh its all done already?
            Ok, then, lets start putting it back in again!

          • DJ Funky Ju

            so how do u speed up? or ‘f*ck with things’?

          • luxlucetintenebris

            No. You didn’t research. NEVER inline CSS. Stop writing ignorant articles that ignore best practices and pretty much everything you wrote is wrong. Do NOT ever inline CSS and learn about caching.

          • DJ Funky Ju

            why? can you please teach us?

          • The Informer

            let’s just rewind the web to ’96 then and start using tags again

            now I have a hankering for grey backgrounds and tags

            let me get my animated gif collection out and browse geocities.

          • M S i N Lund

            Yeah, especially authors that cant manage to respond to factual critique.
            Regurgitating broken advice, and calling people who call them out “troll”, is just pathetic.

            And thanks =)

        • M S i N Lund

          There are changes made to the above comment, after i posted it.
          Changes I didn’t make.

          At least a chunk of the end is removed/changed, and possibly others changes too.

          And apparently I can no longer make changes to it, to add this disclaimer.
          Posts are accepted without error, but just thrown away.

          Definitely not cool!

    • Mike McLin

      I think these authors clearly understand how caching works. There are many situations where this technique is very useful. Look at almost any web app these days. The majority of the app is hidden behind a login. It potentially is a large SPA app. Why wouldn’t you load in the critical CSS for the homepage, knowing it is the common entry point for all your visitors, plus they won’t be viewing it multiple times. Instead they will login and utilize your web app.

      Critical CSS is a tool. It’s not always right for the job, but it’s not evil either. Learn your tools, and figure out when they are appropriate.

      • M S i N Lund

        This article is about inlining CSS.
        Which is bad.

        Splitting css and delivering it depending on the situation, is something completely different.

        And what do you mean by “SPA apps”?

        If you mean single page app(apps) lol,
        there is no reason to inline the css there either, since people can open pages in new tabs/windows or arrive at different urls. (unless the site sucks massively)

        You will need to have potential shared resources cachable to benefit from all that functionality the browser gives you for free.
        No need to reinvent the wheel.

        • Mike McLin

          We understand how the cache works. The thing in question is “should we have wait to load the entire CSS in order for the user to start seeing content”. If you can’t think of a situation where it might be beneficial to add a trivial amount of CSS to the weight of a page in order to boost the initial boot-time, then I don’t know what else I can say. Sure, they might have to load that extra 10 lines of inline CSS every time, but WHO CARES. It’s a trivial amount in the grand scheme of things. Does this mean Critical CSS is always applicable or is incapable of being implemented in a negative fashion? Of course not. But, it also doesn’t mean that it can’t be useful.

          The ironic thing is that inlining CSS seems to be the way of the future for more complex front-end apps. Looking at something like Angular 2, which is based on components, emulating shadow DOM and lazy-loading modules… All of this couples styles with components, and the styles are just dumped into the DOM inline as the component modules are loaded.

          • Jason Sobell

            The thing is that there are so many ways and times to load CSS, with pros and cons to each. You quite rightly mention waiting for the “entire CSS” to load, yet it’s even more than that as any load that’s a blocking request to the server may well justify the inlining of at least some of the initial CSS.
            SPAs introduce completely different methods and requirements for ‘inlining’ CSS, in that the styles for SPAs are typically bundled in a single file, yet even then you can choose to break up your bundles to allow your initial landing functionality to be presented quickly, while a larger bundle of functionality loads in the background, or… you can load the styles on demand simply by telling your bundler not to include them in any bundle.

            By the way, I was able to understand perfectly well what you meant by ‘SPA apps’. I use that term regularly, and don’t feel the need to criticise you for it!

            There are so many devs with myopic views of solutions and pedantic attitudes. Choosing every little detail and niggle to berate people isn’t smart, just childish, and makes authors think twice before posting more assistance and subjecting themselves to another batch of abuse. No wonder the web dev world is such a hodgepodge of immature tools and (lack of) standards at the moment…

            The key thing about this article is that it brings up the *consideration* of in-lining your CSS. If you understand when to use it, and why you are using it that situation, then you can make an informed decision as to whether you need it or not.
            The article does a decent job of explaining that, so people should stop criticising the fact that the idea of inlining exists, and instead use the article as a prompt to question whether they need it or not, and if they do… well the article provides examples and tools to help you.

          • Mike McLin

            Yeah, I think we as developers take a generally good concept (caching CSS for example), and then create a self-imposed law that anything else must be incorrect (e.g. snippets of uncached CSS). The end result is ignoring a potential real performance gain by instead enforcing a micro-optimization (not allowing a small snippet to go uncached) that has no real world effect. When you look at the most visited site in the world, which is Google, which is a SPA and which also inlines 100% of their CSS, some devs need start asking some questions… Why are they doing that, and I’m doing this? A lot of this revolves around mobile optimizations. Interestingly enough, most people believe the issue with mobile is slower download speeds, which is generally inaccurate. Tim Ruffles gave a fascinating talk about this at AngularConnect with real world examples (which can be found on YTube).

    • alirobe

      I think more important to how the web works is how the humans work on making it better.

      I don’t disagree with your critique, but I wonder if taking a less abrasive tact might deliver a better resolution?

      Everything we do on the web is a compromise. Everyone agrees on the goal. Discussing ideas maturely is the best way to developing a mature approach to this compromise.

    • kirilloid

      If someone get 90% of their CSS inlined and doesn’t see a problem than neither tutorial nor furious comments can help this person.
      Not every site is a startup with cool design and trivial promo landing page. A project can easily get 300KB CSS and very small part of it will be used on any page.
      Yes, caching exist, but so does effect of the first visit.

      • M S i N Lund

        And you think showing people like that how to inline their CSS, and telling them they should inline their CSS, and telling then that inlining CSS is the new cool thing that everyone is doing, and that google thinks they should inline their CSS,
        …is wise?
        That couldn’t possibly add more bloat to an already bloated web?

    • M S i N Lund


      Apparently someone on this site has the power to change the text in people comments.
      And they are doing it without notifying anyone.

      I DEFINITELY did not use the word “naive” anywhere in that comment, and yet I now find it in 2 places.

      It looks like someone replaced the word stupid or possibly idiotic, with “naive” , for some reason.

      And i have noticed random changes in other comments here too.
      Suddenly whole chunks of text is missing, or changed from one day to the next.


      How fucking DARE you put words in MY mouth?
      If you edit peoples comments, OF COURSE your have to make a note about that in the text.

      This is a BIG problem, if you cant understand that.

      • M S i N Lund

        Addition 2:

        Apparently that comment can no longer be edited by me.
        As I tried to add the Addition-part to the end, and marked the places where it was changed by someone else.

        I saved it without any error-message, but the content didnt change

        So other can now edit that comment, but not me?

        Either diqus sucks badly, or someone working for this site does…

    • Good point MatsSvensson0.

      I don’t inline myself. I prefer saving code in a CSS file or JS, then refer to it. On multiple pages you will end up reusing the class. Caching will save time for your visitors too.

  • Marek Králík

    The only CRITICAL CSS you need is the one that is already a part of all modern browsers – The default styles! Just make sure, your page looks good without styles and you are good to go. // Member 00′ internet? I member. Brought to you by memberberries.

    • Joe Lloyd

      Yeah I member 00′ internet, but member 90’s internet?

  • Christian Z.

    “lose” not “loose”

  • Two thoughts.

    1) Great stuff. Thanks. But perhaps the real problem is sites are being designed and developed for best case scenarios, instead of typical/average? That is, too many sites, relative to “typically” are over designed, over engineered, etc.

    2) The tools look great! But how do you use them with a CMS where pages are dynamic? Or can you not build out in the browser and instead have to have a static HTML mock-up/demo first, on which to test?

  • Asha Laxmi

    Hi John,

    I have mentioned that you can use cookies to load inlined CSS only on the first visit in the conclusion.

    No doubt that the other articles are excellent but this article is titled “How and Why You Should Inline Your Critical CSS” and it describes three different ways to do just that. :)

    • Sorry, I just skimmed through to see if there was anything in the article I didn’t already know so didn’t bother to read the conclusion. But really, explaining this aspect of the technique should be more than just a footnote.
      But anyway, I’m not the one who doesn’t fully understand how the concept works. The article obviously didn’t make the cookie/cacheing aspect clear enough from reading the other guy’s comments.

      • Asha Laxmi

        I just wanted to focus on different techniques to inline critical CSS while quickly going over rest of the concepts because anyone looking for inlining critical CSS will most probably have at least basic knowledge of cookies and caching. :)

        As far as I can tell, this other guy is a troll.

        Have a good day!

        • Snd

          Thank you for writing this article. Could be helpful for someone. BUT calling the other guy a troll is a big no-no since he has some valid arguments which we (as a community) should be discussing. Dismissing other peoples opinions by saying they are trolls is not going to help in the long run. Rather, use this insight to write an in-depth article about IF we should be inlining our CSS.

        • Julien Charette

          He isn’t a troll. He may be a little harsh but has MANY valid points.

  • After going through the article, The page speed score improved from 86 to 95. above 85 means you already received a good sign from google for page speed insights. I don’t think if there is any benefit out of it .

    After generating the code I see the code

    The Optimizer
    Minified Inlined CSS

    JavaScript to load styles asynchronously…

    All the markup stuff

    I see that the css is loading asynchronously in header part, so you are using js in head tag which is not a good practice. All js cutom code and external js files should be loaded at bottom.

    If you even write this code in before close the body, the style sheet should be loaded in head tag. If we follow this, we are making people bit confused for editing code for any changes.

    I would like to hear your thoughts about this.

    • Jason Sobell

      The CSS is normally loaded in the header because it’s applied to the content as the page loads, and the javascript at the end because it applies itself to the content of the DOM which has already loaded.
      So if you want to load some CSS *before* the page loads, you have to do it in the header, and if that requires you use javascript in the header to load that CSS, then there is no issue with that.
      It’s an interesting case of understanding why the recommendations exist :)

    • kirilloid

      > js in head tag which is not a good practice.
      Why is it so? It is the same blind following of the guidelines: “JS in head is bad, mkay?”
      external JavaScript resources in the head blocks loading¹ of all other resources including other stylesheets files, but small piece of inline JavaScript doesn’t add any performance penalty².

      ¹ – actually parsing, browsers are a little clever about that, but the point is the same anyway
      ² – okay, few hundred bytes, still much less than inlined CSS

  • M S i N Lund

    Nope, you cant do that in the browser.

    You need to add a bunch of extra server-side logic.

    ..and you need to send that cookie with all requests.

    …and it has to mantain a huge can of worms worth of different versions of css.

    …and you need a hack in the browser to caaaarefully sneak in the cached css, so that google doesn’t complain no matter what you do.


    Its all very ugly and hacky.

    Here is an example of the madness:

    Try inlining your entire css in the head.

    Google will now give you 100% thumbs upp.

    It just perfect acording to Google, even if 99.99% of that css is not used on the page.

    Now also try to add a link to the same css in an external file, anywhere on the page.

    Google will now complain that “99%”, or so, of the content above the fold cant be rendered without waiting for that file.

    Even though the page clearly has 100% of any needed css.

    Apparently you cant have any css in the external file, thats already in the inlined.

    …so you have to tailor such files especially to match any inlined css, on each page.

    …many files!

    But that also means you cant cache those files to replace the inlined css.


    It never ends.

    So then you have to find away to sneak that css in from behind, somehow, without awaking ol man google sleeping on the porch with a shotgun.

    So now your css is dependant on javascript…

    Workarounds, for workarounds, for workarounds, for workarounds, for workarounds…

  • Ami Reynoso

    Hi Asha! Really liked your article. I’ve given a talk about this subject at a recent CSS Conf. Would love to share the slides with you, and talk about this if you’d like. :) Regards.

  • Gábor Farkas

    I think it’s important to note that besides page performance, there’s the aspect of security, and it’s actually advised not to allow any inline CSS in your page. Content Security Policy headers also support enforcing this. (Too bad that angular-material for example adds inline styles at runtime by default, and you cannot easily pre-build them)

  • Hey Asha,

    I didn’t see this discussion until today. Just wanted to tell you: Don’t pay any attention to @MatsSvensson0:disqus. He’s a complete jackass who refuses to accept any technique that goes against the brainless and stupid idea that web development must be centered around the antiquated “separation of concerns”. Sadly, he still thinks it’s 2002 or something. And don’t worry, he doesn’t mind me calling him a jackass. We’re best of friends. ;)

    And too many people in this discussion did not give you any credit for your last few paragraphs where you clearly stated:

    Whether you should or shouldn’t inline critical CSS depends on the visiting pattern of your users and the structure of your website […] The only concern about inlining is that it adds additional page weight for each visit. This can be mitigated by using cookies and sending critical CSS only during the first visit while still loading the full CSS file asynchronously and then caching it. It is a little complicated but you get the best of both worlds.

    That quote basically addresses all the issues that the “separation of concerns” zealots have brought up, so I have no idea why anyone would think this article is being overly dogmatic. Maybe the only thing that could have been addressed is http/2, which I believe will make critical CSS obsolete, as someone else pointed out. But if PageSpeed Insights still hasn’t made that adjustment to their suggestions, then it’s safe to say that inlining critical CSS is still a best practice.

    • M S i N Lund

      Everyone feel free to ignore Louis Lazaris.
      He has some problems, both with reading and writing, apparently

      I criticized something he wrote somewhere else, and now it seems he is stalking me, following me around just to make personal attacks.

      Some people just cant handle criticism.
      And when they cant make an argument for their case, they start to make crap up and argue about that instead.

      And I do mind jerks following me around lying and insulting me.
      So I will make a exception just for you Louis, and give some back.
      You are a hack, as a writer, and judging from what you write, probably also as a programmer.

      And as a person, you got the right description for yourself:
      “a complete jackass”.

      Now please run off, and wrote something about the joys of your latest trendy crap.
      I’m guessing: flash landing pages are back in style, or something?

      • I’m saying that because you’re always a jerk to everyone you disagree with (I was the CSS editor on SitePoint for 2+ years, in case you forgot).

        I was always nice to you in my responses and I even offered for you to write counter-articles and we’d pay you to do it. Instead, you choose to sit in the comments anonymously and dump on other people’s work, even when they’re in the right, and even when they’ve obviously given alternative suggestions in the article (like in this one).

        And for the record, I don’t think your suggestions are all wrong or complete nonsense. I just think you’re a jerk when you give your suggestions and you need to learn to be civil. When I was employed with SitePoint, I didn’t mind being nice to you and keeping my job. Now that that’s not an issue, I feel comfortable telling it to you as it is. And I’d say the same thing to your face if you were in the same room as me.

        So my advice is: Stop being a jerk and just give your advice nicely.

        In a case like this, the author clearly made some concessions in the article itself, and you didn’t even acknowledge this. And those concessions clearly address the issues you brought up. I’m guessing it’s because you didn’t read the article. I don’t mind that so much, but if you weren’t so arrogant about it I wouldn’t care.

        • M S i N Lund

          Nope, simply not true.

          Im not “always a jerk to everyone you disagree with”.
          And you’re definitely not ” always nice” in your responses.

          But that’s just the kind of ridiculous generalizations people like you resort to, to “win” an argument.

  • M S i N Lund

    Thanks, and ouch =)

    I’m looking forward to http/2 too.

    I guess there will be good job-opportunities cleaning out all that inlined CSS, in a not too distant future.

    I’m just worried it will lead to even more file-bloat, and make people think its now OK to have frameworks spew a meeelion css/js-files all over the place.

    Will it just be a smoother funnel down the throat of the browser?

  • M S i N Lund

    Apparently someone on this site has the power to change the text in peoples comments.
    And they are doing it without notifying anyone.

    I DEFINITELY did not use the word “naive” anywhere in one of the comments here, and yet I now find it in 2 places.

    It looks like someone replaced the word stupid or possibly idiotic, with “naive” , for some reason.

    And i have noticed random changes in other comments here too.
    Suddenly whole chunks of text is missing, or changed from one day to the next.

    To who it might concern:

    How the hell DARE you put words in MY mouth?

    If you edit peoples comments, OF COURSE you at least have to make a note about that in the text!

    This is a BIG problem, if you as a editor/author/whatever cant understand that.

    • M S i N Lund


      After testing a bit, it seems the very comments changed by someone else, are now locked from being changed by me.

      If i try to add a disclaimer about it being edited, the post is accepted without error, but just thrown away.

      Needless to say, this is very disconcerting. =(
      Or at least it should be needless to say…

      Wow, if this is the way you treat comments on this site, you probably should just turn them off completely.

    • Hi M S i N Lund, as far as I can see in the backend, no edits to your comments have been made. Both the channel editors and myself understand that it’s unacceptable to make a moderating edit without a disclaimer. If you have a screenshot that demonstrates otherwise I’ll investigate further, but at this point I don’t think anything untoward has occurred.

      • M S i N Lund

        My comment below, that starts with “No Stop. Just stop.”, did not contain the word “naive” anywhere in the text when i posted it.
        Its a word I don’t like, and seldom use.
        And it obviously don’t fit in at least the first sentence.

        I now see it twice in the text.

        Can you see it?

        And just a few seconds ago I edited it and added the string “TEST TEST TEST” to the end.

        But I cant see that text in it now.

        Can you see “TEST TEST TEST” anywhere in it?

        At first I thought it might be a caching problem, or something but I tried opening it in several browsers, and its definitely not the text i posted that is visible now.

  • Clark Winkelmann

    What’s funny is, you could apply that to the Sitepoint website as well. You should add critical CSS to save the space for the top ad.

    Every time I load one of your article, I start to read and suddenly a big ad appears right under the title, and I lost where I was and need to scroll again…

  • The Informer

    Yeah, I am NOT inlining SHIT. not css, not js. the only thing going into an html file is HTML. the rest is getting put into css and js files respectively. and grunt and gulp can GFT. I’m a php programmer. none of this nodejs cr@p thanks.

  • M S i N Lund

    Your “site” is ONE page with less than a dozen lines of text and pretty much zero functionality.

  • registration_stinks


    I am not e.e. cummings, and


  • M⃠ ⃠S⃠ ⃠i⃠ ⃠N⃠ ⃠L⃠u⃠n⃠d⃠

    My comments on this page still remain edited by someone, not me.
    And i still cant change them back and save the edits.

    And I’m only locked out from the comments that have been changed.

    For example; that word “stupid” has been changed to “naive” in several places.

    This is the only website where my discus-comments have been edited, and where I cant save changes.

    So, yeah…

Get the latest in Front-end, once a week, for free.