At some point in your web development life, you probably heard that inlining your CSS is no good. You should avoid it at all costs because you'll just clutter up the markup.
But will you though? And does it actually matter if your <head> section is slightly more bloated at the benefit of having less resource files to load? And does it effect your SEO if you choose to go that route?
Those are the questions that we'll hopefully have satisfactory answers for by the end of this article. Because as with most things related to programming, it depends on alot of things.
What is inlining?
CSS on a webpage can be embedded using the <style> tag and, while most often added in the <head> section, it can technically go anywhere on the page and the browser will render it just fine. Though for consistency sake, it's best to place it in the <head> section.
On a more granular level though, inlining also refers to adding style rules directly onto an HTML element, such as:
That you should avoid at all cost. Not only does it give no contextual meaning to an element (by not using a className), but it's also hard to read and harder to update.
This article will mainly focus on adding CSS blocks directly to a page however, as it is the most common approach.
Why avoid it?
Traditionally it has been taught that inline CSS should be avoided at all cost because it makes the markup harder to read, it bloats the overall size of the page, and it makes publishing changes difficult as it could require you to recompile your web applications and republish. All fair reasons to want to avoid it.
In a standard software development model, keeping elements of a program separate is known as maintaining a separation of concerns. This makes the program easier to work with as you only have to focus on individual parts at any one time instead of the entire stack.
This allows for multiple people to work on a project simultaneously as well without the possibility of collisions. You can also have multiple CSS files generated for a single page and perform various A/B tests in order to gauge performance.
When you inline CSS, you also lose modularity. That is, the ability for CSS files to be used in multiple pages without having to maintain multiple sets of CSS.
Traditionally, these are the reasons why we avoid inlining anything.
Having, hopefully, painted a good picture as to why you want to avoid such archaic practices let's now turn the tables upside down a bit. Because things in the web development world change and change frequently.
I'll start off by saying that you should still not inline CSS directly onto a single element. The only time that I've done this, or have had to do this, was when I needed an element to have a particular style and when the CSS file structure was so convoluted that editing that one element would require more work than the allotted deadline given. It was a desperation move, and one that I later went back and addressed properly.
Inlining CSS onto a page however, is a different story, because you are still maintaining the same structure and className hierarchy. You don't lose the contextual meaning of the CSS, but you still aren't free of most of its shortcomings.
Reduce number of requests
One of the main reasons why you would want to inline your CSS onto a page, is because you are reducing the number of requests that the page needs to load. Every browser has a set number of concurrent network requests that is allowed. On Chrome for example that number is 6 requests concurrently.
If you are loading many resource files, then potentially your site visitors might not see any CSS until the browser has finished loading the previous files in the chain.
The first thing that the browser loads typically is the markup (HTML) itself, followed by the needed resource files. If the markup already contains the CSS for the page, then the Cumulative Layout Shift (or CLS) can be reduced.
The Cumulative Layout Shift is one of the 4 major components in Google's Core Web Vitals classification. Essentially it is a measure of your websites overall usability and performance.
While not 100% guaranteed to boosts your SERP in any way, it is widely known that Google will begin to favor websites that have high scores in their web vitals scale mentioned above.
When running a PageSpeed Insights test on this site, Google even suggests that certain content should be inlined in order to improve performance.
While this alone might not be enough to have you drop everything and restructure your entire website, it is definitely something that should be taken into account, particularly if you are a newer website looking to get on page 1.
While I won't go into technical details, because that would take far too long and perhaps more suitable for a future post, I will give a brief overview to give you a better idea of the process.
Those files are then minified and dynamically loaded onto the page at the server level before the page is sent back to the browser.
Essentially, I have my resources files separate (database records) and they can be edited by anyone with access (separation of concerns). And because they live in the database, there is no recompilation and republishing required when making changes. All updates happen in real time.
So should you inline?
By this point you should know the many cons that come with inlining anything onto a page. But you should also know the potentially benefits as well.
So the answer to this question really will depend on where you are in your websites development cycle. Because if you have 2-3 developers working on a single project, then ideally you want to keep everything separate.
And if you have a complex deployment and compilation procedure, then making tiny changes to your CSS could potentially cost more time than any benefit that you would get out of it.
And if you have the freedom to work with a custom codebase, such as myself, then you can indeed develop your own CSS management engine and get the benefits of both worlds.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date. Get informed of the latest happenings in the development world.
Another solid bundle for developers!
Start at $1. Pay what you want and get up to 18 Ruby books for your collection.
If you buy something through a link, we may earn a commission