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?
Technically speaking, in-lining means to add on the same line. In terms of resource files like CSS and JavaScript, it means to have these elements directly on the markup page and not in a .js or .css file.
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:
<div style='color:dodgerblue;font-size:20pt'>Hello</div>
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.
But...
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.
Improves SEO
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.
My approach
Because this blog is custom code that I built myself, I had the freedom early on to decide how I wanted to handle my CSS and JavaScript needs. The approach that I took essentially aims to tackle all of the issues mentioned above one by one while at the same time allowing me to inline all of my CSS in order to get an SEO boost.
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.
Most of my CSS and JavaScript is currently stored in a database. I can edit each "file" just like I would a physical CSS file. Each page on the blog then has a mapping to each of the required CSS and JS files needed to render.
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.