2020-06-04
2131
#css
Timothy Vernon
19597
Jun 4, 2020 ⋅ 7 min read

Improve site performance by inlining your CSS

Timothy Vernon Your local JavaScript developer.

Recent posts:

Vue.js logo over a dark, textured purple background. The article discusses using defineExpose and in Vue 3 to enhance component interaction and enable dynamic theming.

defineExpose and <style vars> in Vue 3 for component interaction and theming

Simplify component interaction and dynamic theming in Vue 3 with defineExpose and for better control and flexibility.

Clara Ekekenta
Nov 7, 2024 ⋅ 8 min read
How to set up TypeScript with Node.js and Express

How to set up TypeScript with Node.js and Express

Explore how to integrate TypeScript into a Node.js and Express application, leveraging ts-node, nodemon, and TypeScript path aliases.

Aman Mittal
Nov 7, 2024 ⋅ 10 min read
Cover image for es-toolkit, a Lodash alternative

es-toolkit, a Lodash alternative

es-toolkit is a lightweight, efficient JavaScript utility library, ideal as a modern Lodash alternative for smaller bundles.

Rishi Purwar
Nov 6, 2024 ⋅ 5 min read
JS Logo Over Blue Background

The ResizeObserver API: A tutorial with examples

The use cases for the ResizeObserver API may not be immediately obvious, so let’s take a look at a few practical examples.

Kevin Drum
Nov 5, 2024 ⋅ 9 min read
View all posts

17 Replies to "Improve site performance by inlining your CSS"

  1. Except that’s not how it works. The very last element on the page could be styled position: fixed; top: 0; by a loaded stylesheet, which would place it at the top of the page, to be seen initially on first load. The browser cannot and does not render until all styles are available, because iclt cannot know this until that point At best, you break even placing the critical styles inline; at worst, you slow things down by transferring more data because you have those critical styles in your stylesheet as well.

  2. Typical bad styling advice by a newbie JavaScript developer. I’ve heard it all before! The reason we have web standards is because someone already tried it this way in the 1990s and ran into nightmarish problems with keeping code clean and reusable.

    Performance on the nanosecond scale is useless if your code looks like spaghetti bolognese and cannot be maintained!

    If you’re going to give advice that goes against the current standards you should at least try to solve for all the reasons there is a standard in the first place!

  3. This laughably bad advice and it seems that the author has never worked on a on a large team project if he thinks that inline styles are practical.

    Simply minifying the stylesheet is enough but the main thing is making the code maintainable and reusable.

  4. We did a full circle. All these years being told not to use inline css for maintainability and all of the sudden it’s the latest trick for more performance.

  5. It’s also good to inline all images using base64 encoding. Each image request also takes network time and as image files are much larger than CSS files, this speeds page load time :o;

  6. all resourses – CSS, JS, images – are cached by browser… so they are loaded from server only first time page is loaded. Moving all that stuff as inline onto index significsntly increases traffic because they are downloaded literally with every request again and again… it’s BAD advice.

  7. It’s a shame so few people know how to use css. I’ve seen people use a dozen elements to do what could be easily accomplished with a single properly styled element. So their css file becomes an unmaintainable mess and blows up. You do things correctly, your case file will be small and there will not be any issues.

    So many of the problems in the modern computing age are just problems caused by doing something in a dumb way and then trying to fix the resulting mess by doing more things. It never occurs to people to look at why they ran into issues in the first place. Fix the problem, don’t implement a solution to fix the problem.

  8. The next logical step from your conclusion would be to put your critical styles back into an external stylesheet on order to benefit from the long-term browser cache, in order to not have to load extra data whenever you load another page of the website (or the same page, since most html pages have a max-age of a few minutes, compared to the months to years given to stylesheets).
    As the result, the true solution to the Above-the-Fold/Below-the-Fold issue is to use two css files, one being critical and loaded on the spot; the other being defered.
    Some CSS preprocessors even include tools to help with this issues.

    It is to note that there usually are a lot of things that can be optimized in a web page before going to such a length, including minifying resources (which this website doesn’t do), placing non-critical scripts at the bottom of the page (which this website doesn’t do), and NOT loading 50 different script files (Which this website does, half of them coming from this domain or wp.com)

    1. Thanks for the comment, we’re aware of our performance deficiencies and are working to improve them. We’ll pass your feedback on to our lead developer.

    2. I came to this post through my recent exposure to full page block editing pushed more aggressively by wordpress. I always believed minifying, consolidating, moving all the design and interaction stuff extern and the head is the road to performance victory. But I must come back from that.
      1} content onthe web is short lived.
      2} Network and devices got incredbly fast
      3} not all webpages are the same
      4) extensive engeneering costs time and money.

      Did you notice this page to be slow, Aralcis? Or did you assume it most because of lack of minifying and other optimzed stuff? I didn’t notice a bit and reading this on an old android phone over an ok network.

      As an age old sligtly ADHD developer I confess myself a convert. I used to take many hours squeezingout the last byte, carefully watching network turnarrounds and rendering times in browsers devtools only to realize they have little or no effect on the viewers experience.
      As designer / developer we have to churn out designs at a fast pace fir a shortlived medium and for day to day sites this whole optimize thing made sense only in the dark ages of the web. Webapplications are a different thing btw.

  9. I understand how external CSS style sheets can affect page performance, but there was a reason why CSS mostly became an external file. This entire article failed to address that important reason, which was to provide the logistic power to alter styling to a large number of posts or pages by changing one or a few CSS files.

    That was one of the main reasons to place CSS into an external style sheet, so we would not have to manually change hundreds of pages/posts. This important element in styling web pages should never be ignored.

    Use of inline CSS should not be manual, meaning inserted into a specific webpage, unless it is used on a very limited number of pages, because to change the inline CSS becomes a manual nightmare for a large number of pages. This is why website developers use external CSS files, PHP include functions, etc (especially to insert inline CSS styles on the fly), because they know the arduous suffering when having to alter or fix CSS entries on a large website, but then these methods do require network calls.

    Don’t misunderstand the purpose of my post. I totally agree to the concept of critical CSS, which refers to only the CSS needed for the “above the fold” paint (loading) of a web page, but something needs to develop that addresses the requirement of large CSS files or many CSS files and page performance and speed. To date, all I see are spot fixes and nothing is resolving, in its entirety, the ongoing issue of page performance.

    In addition, do not forget the server end of things. I currently moved my business website to a hosting service that is the best in the market, very fast SSD servers and the page speed of my site has increased dramatically. So for page performance there are a lot of parts to address to ensure you have the best performance possible, but remember, replacing external CSS files is not going to work using inline CSS.

  10. Dumping STYLE into the markup remains one of the DUMBEST things you can do in HTML/CSS, and pissing and moaning lame excuses about “render time” rarely justifies the practice. If not for the one or two corner cases in which it makes sense — multi-page site with differing banners of the same style across pages for example — I would see it stricken from HTML entirely.

    This idiocy about how much “faster” it is doesn’t hold any weight once you navigate to sub-pages, as putting it in the markup instead of external misses your chance to pre-cache! the more pages of like style you have, the faster and faster this derpitude blows up in your face.

    I am SICK TO DEATH of going into client sites where this mind-numbingly dumbass practice of slopping style into the markup was attempted to “speed up a site” when it’s basically a band aid on a bullet wound.

    MAYBE if people stopped using 90k of HTML to do 10k’s job, half a megabyte of CSS in a half dozen separate files to do 48k or less in one file’s job, and multiple megabytes of scripting spread out over dozens of files to do 64k or less in two file’s job, they wouldn’t be diving for dumbass broken trickery like this.

    ESPECIALLY now that we can push.

    And for the LOVE OF CHRISTMAS, futzing around sending a screen media sheet to PRINT (hurr-durrz) where it would likely conflict with or screw your print capabilities, and then using JavaScript to fix it destroying accessibility in the process? /FAIL/ at web development so epic, I lack the words in polite company to truly convey my opinion. And even there you’ve got one of those onevent attributes that have no business in any HTML written after around 2003 when we stopped giving a flying purple fish about Netscape 4.x!

    But then even your cryptic two-letter classes in your example throw up huge warning flags that your approach to writing HTML is utterly banjaxed.

    Hopefully not as incompetent as the skin for this site, but in all likelihood that’s the case. Endless pointless static scripting in the markup, endless pointless static style in the markup, gibberish to nonexistent semantics, tags and attributes that have no business in any HTML written after 1997… hardly a shock it’s vomiting up 149k of markup for 20k of paintext and zero content media, not even 32k of HTML’s job.

    Also this is 2020, you can stop saying type=”text/css” on a STYLE tag.

    The sheer ignorance, incompetence, and ineptutude shown in using HTML and CSS properly these days is why stupid trickery like crapping CSS into the markup with the STYLE tag is nothing more than a cheap trick that does more harm than good. It’s bailing wire and bubble gum fixes to try and make up at the end of the process flaws and bloat that shouldn’t even exist in the first place.

    I’m sick of it. I’m sick of having to tell clients SUCKERED by this type of chazerie that to REALLY fix things their entire site needs to be thrown out and started over.

  11. How does react change this story? Now that react has to manage that extra data might the time to mount and render be impacted and in turn increase the overall page load time vs a style sheet?

  12. Mr. Vernon is way ahead of the game with his suggestions versus the backlash here. I came to this website to view this ONE page. Over 23 stylesheets were downloaded into my space and over 6mb of God who knows what (it’s still going). I feel abused. Viewing this page should have transferred about 150kb, I didn’t order a boat. Some of these guy’s need to stop being emotional and start using their heads. I pray for more inline styling except for the obvious that should go in the .

Leave a Reply