I've been playing around with Filament's Critical CSS (https://github.com/filamentgroup/grunt-criticalcss) and have a question about it's usage.
As I've been using the tool, it generates a "critical" sheet for every page I point it at so that I can inline those files into my HTML via a <style> tag in the <head>. This all makes sense.
However, once the user visits any of my sites pages, they'll have the main sheet fully cached. At this point does it make sense to stop inlining the CSS, as the user already has the CSS loaded, and instead link to it via a traditional tag?
If you're certain that the user has the stylesheet cached this would be a valid approach, assuming that parsing a cached stylesheet or inline styling of critical css will take the same amount of time.
You however can't be certain that it exists in the users cache. As the critical css also exists in the stylesheet this isn't a problem, but it will make rendering the page slower.
The only way to know when it might be useful is to parse your access logs, try to find how often the stylesheet is also requested when a specific page is requested by a specific user. Using that you can create a probabilistic model on when it's useful to inline critical css. This seems like too much work for a small gain. I'm guessing that using inline critical css is most useful for landing pages or pages that go viral.
Yes, Inline CSS usually now is only needed when you want it to take complete precedence over an external style-sheet you do not control of a .JS file that makes unwanted changes which overwrites your style-sheet as well. Doing this also helps with performance, band-width, etc., etc.
I am going to answer here as it is best to do so instead of in comments.
The problem that you're having is strange in the matter that you are wanting to cover all possible bases with two separate, but tied issues.
Firstly, your performance gains. Since you want to have higher performance doing inline styles is the technically correct answer. There are some minor gains because you are not doing a request. All requests that go out take time and depending on the time it takes for the server to communicate each request you will see a possible performance drop. This is why some requests that are much larger are considered excessive and Google generally informs you to sprite the image or some other form of connection.
The other part is you want ease of accessibility and want to be able to update quickly which is what would be provided by an actual CSS file. You would need to at some point call this CSS file so that it can be cached into the browser as you expect. You can do some cookie checks and depending if the user has been to the site or not they will have a specific call, but here is the major issue:
At some point you HAVE to actually load it. You will have to make the call. Whether it be on the first load or the last at some point for it to be cached it actually has to be retrieved. You will spend a ton of time checking each variable if they don't have it they will need to have the style sheet loaded. If you are already required to load it at some point then it comes down to never really needing to do inline styles. And if you have inline styles you never really need to load it.
You could potentially do a PHP include of the file and have it pull in that way. You would just include the file between a style declaration and it would populate the CSS that way. I wouldn't say that is the best way to do it, but it is possible. It can be done. I still stand by saying inline is not the right way to go. Technically yes it can help. Reality... no. I have not seen it be beneficial ever in my time. If someone wants to show me one that is fine, but I doubt I will use this practice unless it is last resort.
Keep in mind this final thought. Most cases inline styles are styles that are meant to be final styles; ones that end overwrite original external style sheets that we as developers can not edit ourselves (or do not want to change for other reasons).
Google is great and they provide great research, but research is meant to be considered and not always used exactly as they write. It is to provide insight. Not usually a guide into the way.
Related
As mentioned in google page insight tools
For best performance, PageSpeed Insights recommends inlining the critical (above-the-fold) CSS of your page directly into your HTML.
Wanted to know how efficient this is, code structure wise. As it would increase the lines of code on each of the HTML pages. Is there any other efficient way to eliminate this instead of inlining the css directly into the HTML page?
It would be trivial as far as size goes (we're talking bytes or maybe a few K in extra size) but your maintainability goes out the window when you're inlining all your css in every page. This is of course ignoring caching -- you'd only download it once, and then subsequent pages would benefit from the cache.
If you're determined to go this route, use a tool like Less to render out the necessary CSS through a build process. That way, you can still keep a centralized, easily maintainable CSS document, but it can take advantage of inlining at build-time.
The question is very simple and even tho I might get downvoted into oblivion for it, I can't find a good search query for this.
If I link images, stylesheets, scripts and other things with the full website url (http://url.tld/css/style.css) instead of path (css/style.css) , are the visitors affected negatively? Is there any difference?
The html page is on the same link as the resource, so we're not talking about external resources.
This only makes a difference if you change your domain name. You cannot simply transfer the scripts over but have to change each line or the include of those files then.
One small thing to keep in mind: Your string will be longer and so your file will be a very bit bigger in size but it doesn't really matter.
Either won't affect visitors. Specifying the protocol might cause problems in the future if your users can switch between http and https. Specifying the folder also means changes when you move the site. So best to use relative
I like the idea of encapsulating my CSS into separate files. This also brings the added advantage of being able to easily minify the CSS. But I know performance is negatively impacted by the overhead needed to pull these separate files from the server.
To address the latter point, people often suggest inlining the style or at least putting the CSS in the HEAD of the html document. I'm not going to inline because then editing the style becomes a nightmare. I can consider putting it in the head to increase performance, but I do not want to put it in there minified. I won't be able to read it, and it will be a pain to have to adjust the CSS once minified.
So my question is, What is the better option -- in terms of performance -- between these two?
Minified external CSS file
CSS placed in the HEAD but not minified
You are not considering browser-side caching in your evaluation. It is almost ALWAYS better to serve up CSS in an external file for cases where you will be using the same CSS file throughout a multi-page website. The reason for this is that once the CSS is downloaded on first page visit, assuming you have expiry headers set properly, the browser will not need to download the CSS on subsequent page loads until the expiry TTL is passed. This even holds true across multiple user sessions on a website, such that if a user visits the sites some days/weeks later, they may not need to download the CSS at all. If you served up in-page CSS, it would need to be downloaded on every page load.
Also minifying is typically not that big of a performance boost, as most server to browser connections will perform text compression on transmitted content anyway.
Of course it is also usually much easier to maintain CSS in an external file as you have pointed out.
The best option would be to:
Minify them all and bundle them in the server side with something like bundles for Asp.Net or brewer for nodejs, that way you remove the overhead you mentioned above.
To expand on my comment:
Generally, when optimising web page loading, you want to minimise the number of HTTP requests that the browser makes as these are expensive, time-wise; even requests for small files require the browser to send its request to a server, wait for the response, and then act accordingly. From that perspective, the best thing would be to put all the code for your page into a single file. However, this would be a page maintenance nightmare, and it also fails to take into account caching of resources by browsers, as covered by #MikeBrant.
A single css file (potentially composed of several concatenated minified files) is a good compromise between separation of style (css) and content (html), and performance. The same applies to javascript. You can also consider using a content delivery network (CDN) for Javascript if you're using a common library like JQuery as the user's browser may already have the library cached from visiting another site. Google's CDN serves a number of useful libraries.
Generally, you'll get far bigger performance gains from optimising images, enabling server compression, and removing extraneous javascript than you will from minification or inlining CSS. Images are almost always the "heaviest" elements of a page, and it is often very easy to reduce image size by 20-50% and maintain decent quality.
As part of my job I maintain/develop an internal web application. It has relatively few users and just isn't that big. I've got a global CSS file that contains some re-used styles, but 90% of my page-specific styles really really ARE page-specific; they are things like pseudo-column widths (a lot of my output is just non-tabular enough to make tables a poor choice). I have taken to just throwing a <style> block at the top of these pages.
I know this is frowned upon, but every time I read about the reasons for separate CSS files the only one that really stands out is caching. In this case that doesn't matter; it is WAY down on the list of things I would do if I needed to speed up the application. Are there any other reasons, or can I stop feeling guilty?
every time I read about the reasons for separate CSS files the only one that really stands out is caching
Really?
Every time I read about their usage, the fact that you can change something in a CSS file and all pages that include it will have the change is the most important reason to use them.
Having your CSS centralized is a good thing even if your specific pages have different specific rules. It helps you unify the basic CSS structure across the site and when looking for how a specific effect was achieved it will be easy to locate.
These are all worthy reasons to use CSS files, well above any caching/performance reasons.
I face a similar problem, in that most of my styles are very much page-specific. However, my site is far from small, so I had to find a solution.
What I ended up doing was creating a folder css/pages, and naming each CSS file the same as the page that uses it. Then, my PHP "template" can just check if(file_exists("css/pages/".basename($_SERVER['PHP_SELF']))) and add the relevant <link/> tag, resulting in minimal effort on my part.
Just because your site is small is not a valid reason to disregard efficiency, although I have to say I'm a bit of an efficiency nerd so I'll probably be more pedantic over that :p
Ultimately, there's nothing "wrong" with just putting page-specific CSS directly in the page, just make sure that anything that is used on more than one page is in a file so you don't have to repeat yourself.
In my opinion if your app only contain a few web pages(3-5 pages) then you can go ahead define it at the top of the web pages. If your app is going to grow into more that 3-5 web pages then global CSS will help with maintainability and scalability.
Makes for cleaner mark-up, quicker load. Really applies to template and dynamic development. Don't be afraid to use it. It's not like you're going over to the dark side.
I have a more general design question relating to css and websites. I know that it is good computer science to normalize code as much as possible and avoid duplication. So it would stand to reason to me, at least in theory that one would do the same when organizing stylesheets for a website.
So when I started on my most recent website I started out with this same philosophy. It worked ok for my first few pages and while I was only testing in firefox...
However as my site grew and as I added pages, multiple layouts (and browsers) I found this philosophy broke down really quickly. Ultimately over time I have moved to the following approach:
I have a very limited top level css file for each master page layout in my site, it contains classes for well known styles across that layout as well as css for the master page.
I keep specific css styles for each page.
I keep specific css styles for embeddable page elements / controls
I ended up taking this route so that I could trust that changes on one page wouldn't accidentally break other pages in the site resulting in a lot of regression bugs.
What do other people do when approaching this? Is this a good / bad approach... I do see cons to this approach, some pages are very similar so making a significant change means changing more css code, I also feel that the pro's outweigh this on a daily basis.
What do other developers think about this philosophy? Good? Bad? Just curious really...
To me its one of those situations where I weighed the difference between my ideals (I try to keep very tight code), and the frustration of changing requirements on one page breaking 20 other pages because I changed a div width by a few pixels (upsetting a float on another page for instance).
Thanks for your input
Just like any other type of code, if you are duplicating your CSS code all over the place, you are asking for trouble. Maintenance is going to get harder and harder for you as time goes on.
The best way to not have issues with a change on one page affecting other pages detrimentally is to have a style guide that drives your UI layout and design. If your style guide defintes the HTML and CSS classes to use for a given design element, then they will all always be displayed the same across all pages. If a specific page's element needs to be changed, you change the HTML to use a different class and then build new CSS for that class (and add it to your style guide for reuse). The style guide also allows you to make sure that your HTML is uniform across all developers working on the site, which means even less of a chance of CSS changes causing problems as you do more development.
Another point you need to remember with CSS is that every one of those .css files you create and reference on a page is an HTTP request. If every page and control has its own CSS file, you are really hurting your users' experience on the site by bogging down the total request download time for every single page request. It also makes it less likely for their browser to cache the .css files because the cache has a limited amount of space, so if you keep filling it with more and more .css files, they are going to get dumped from the cache more quickly. Yes, you can combine .css files programmatically in a handler so your page only makes one request per page, but then you have additional server overhead and the caching issue still remains (unless you have a single request for all .css files on your site, which defeats the purpose of what you're trying to do here anyways).