Specifically, does the browser cache only the text content of the stylesheet — so it doesn't have to fetch it again from the network — or does it also cache an internal representation it has of the contained CSS rules after parsing, so neither fetching nor parsing of a cached file is necessary?
If only the text content is cached, what are the benefits of caching a stylesheet over inlining it (where it cannot be cached)?
Caching is aimed at reducing load time by replacing the typically slow network download with the typically fast local file reading. As such, is a generic solution (you can cache any kind of asset, from HTML to CSS, JavaScript, PDFs, Excel...) and it can accomplish great time savings (normally seconds, even minutes for really slow networks). It also plays well with dynamic HTML.
What you propose is a very specific caching solution for a very specific data set (the nodes of an HTML document together with the CSS rules that apply to them) that typically needs milliseconds to process and can be continually changing thanks to JavaScript. It looks really difficult to implement, it'll be confusing for dynamic sites (when a page loads, everybody expects to get the initial HTML state, not whatever you were doing last time) and there's hardly any benefit on it. I'm not aware of any browser that has even tried it. There're certainly JIT compilers for JavaScript code, but nothing remotely similar to this.
If only the text content is cached, what are the benefits of caching a
stylesheet over inlining it (where it cannot be cached)?
I'd say cache itself is a valid benefit, isn't it? Generating inline CSS means more work for the webmaster (you either need to write server-side code that injects CSS files or enjoy the maintenance mess of not even having them). It also increases the size of HTML documents.
Related
Less HTTP request the better it's, right ?
Regarding to Google best practice explanation, less unused css rules is also better.
The browser's CSS engine has to evaluate every rule contained in the file to see if the rule applies to the current page.
Even if a stylesheet is in an external file that is cached, rendering is blocked until the browser loads the stylesheet from disk.
In your opinion what's giving better performance :
One css file per page.
One general css that will be cached (even if there will be +70% unused css / but avoiding any other http requests).
Google speed best-practice
One of the important sentence to note from the Google best practice document is "Often, many web sites reuse the same external CSS file for all of their pages, even if many of the rules defined in it don't apply to the current page".
This needs to be taken into account as if the css file has additional code that is never going to be used if user does not visit the page for which this redundant code applies then we are certainly wasting the bandwidth which may not be a proper trade off for an additional HTTP request.
This leads to additional time to load the file plus the time wasted in evaluation of that redundant code.
Certainly using multiple files for just a single page (like different header/footer css files) would be a bad practice.
And as you know that there is not a perfect solution for any problem. You have to choose the best thing that suits your need.
So, I would say the decision to use multiple files or a single file is solely based on the overall structure of website and other trade offs.
Loading CSS is usually extremely quick. CSS blocking is something you will probably never catch. Whereas JavaScript could do so that you are visually aware that it's being downloaded. (white spaces while rendering the page).
In reality one CSS is good enough, because of a single HTTP request.
Optimization should go towards JavaScript, because this is where you can see the page slowing down. We are talking about a second-two of a difference or less here.
Here is a site where you can enter URL and it will check load times. In the graph below you can compare CSS load times.
Looking at the source of a website today I came across something that surprised me. They had the images included in the css file (see http://static.a.gs-cdn.net/webincludes/css/production-uri.css?20120521.1)
This surprised me, surely loading one large file with all the images embedded would take longer on a modern browser (ie chrome fires off lots a simultaneous requests for the content it needs) and make it harder to debug any css issues. Is that correct and are there any advantages to this approach?
There's nothing really wrong with including images in CSS, although it may be more efficient to use CSS sprites.
It makes sense to use CSS sprites for UI elements (but not content elements) because it reduces the number of HTTP requests.
This is a good article detailing a few of the pros and cons of such an approach.
Pros:
The biggest reason: it saves HTTP Requests. Other than pure document size, this is the #1 factor concerning how fast a page loads. Less = better.
Cons:
It's hard to maintain site with embedded data URIs for everything. It's easier to just update an image and replace it.
You should only use this in documents that are heavily cached, like your CSS should be. Having a CSS file that is 300k instead of 50k is fine if it saves 6 HTTP requests, but only if that CSS file is cached just as well as those images would be.
Personally, I never use it. It saves on HTTP requests, but bloats your CSS with things that are, in my opinion, not appropriate. For a clean separation of concerns, images should be just that - images.
Plus, you'll have a harder time caching all the resources - if you make one change to your CSS, that's all the image data getting re-downloaded for no reason.
Regarding inline v. internal v. external CSS, I understand the cacheing issues, and the tradeoff between multiple downloads and single downloads of larger files. What I would like to know is how rendering speed varies, based on the three places you can put CSS.
In other words, what takes the least time to actually draw the page? I assume that external is the slowest, because even if it's cached, the browser still has to retrieve the rules, parse them, and apply them to the current elements. I also assume that internal (in the page but inside style tags) would be second slowest, because there's still the process of parsing the rules and determining which rules to apply to which elements. And I assume that inline (applied directly via style attribute) is the fastest, because the browser can skip the process of matching rules to elements.
Anybody ever looked at this in depth? I know that I've had some rendering problems on large pages with complex CSS that could only be solved by going inline. (Please, no lectures on the evils of large pages with complex CSS.)
either way, once the actual rule text is loaded, it's run through the same css parser - there aren't different parsers for external v.s. internal css. it's all just css. External might be a bit slower to get applied because it'll require an extra HTTP request to fetch that file, but once it's transferred to the host browser, it'll parse just as fast as if you'd physically embedded the same rules in an inline <style> block.
I don't think you should care which mode is fastest. HTML, CSS and JS are not meant to be fast in any case.
I think you should worry about readability and maintainability, think about managing a webpage with styles directly applied inside HTML tags. You wouldn't be able to manage anything complex in that way.
What you are asking mainly depends on browser implementation (with respect to the css file that could be downloaded separately according to which solution we are talking about). In any case I don't think the difference is so much considerable just because they all need to be parsed by the same parser.
If a page is really too complex to be styled with a stylesheet and requires inline style then the problem should be solved not by having inline css but refactoring things at a different level.
In addition I would say that many performance issues could be caused by writing CSS just without any kind of structure, just adding things day by day without even considering having strict/clever selectors. Developing things while thinking about them (that is something that is usually left behind in web development, especially with front ends) usually is the best way.
I'm building a site with a lot of similar css between pages. I've decided that a good approach would be to have the css generated as strings by php functions (with parameters) and outputed as an internal stylesheet in every page that i serve. The benefits:
this way if i make a change it will reflect throughout the entire site without having to maintain duplicates
i can send only the necessary css for a certain page
it's better than having small css files and sending a lot of css headers at inclusion
the possibility that the content might be displayed before the stylesheet is loaded is gone
i can calculate dimensions by using parameters
i can create a layer that will minify the result received from these functions or serve cached minified css
I haven't seen this done anywhere else unfortunately so i'm thinking that this might be because of SEO. The generated internal stylesheet will be at around 15kb max (before minifying the stylesheet).
I need your opinion on this approach and your thoughts about the impact a long internal stylesheet will have on SEO.
Many thanks.
Not an answer to your question (which is interesting enough!), but most of your arguments for inline CSS are wrong. An external style sheet is always the better and faster solution.
The first point you can handle by adding a version number to the style sheet's file name
The second point is moot because an external file gets cached, so no additional requests
The third point is moot for the same reason
The fourth point won't really matter once the style sheet is cached
The fifth point can be sorted using inline CSS for only the properties that need to be
updated dynamically - usually a tiny fraction of the whole CSS code base
The sixth point I don't get.
Go for an external style sheet. Just make sure it gets served with the correct caching headers!
Like long blocks of inline JavaScript, they are ignored.
Bots look at the content, not the layout. If you want a better representation of what they see, try the Lynx browser.
Unfortunately they will not be cached on the user's browser either, as external CSS and JS are, making each page load slower. It is actually more efficient to have a large external stylesheet than server up related "css snippets" with each page.
Assuming by 'internal stylesheet' you mean inline CSS included using the <style> tag, I'd recommend against this. If you use an external stylesheet, visitors download it once on the first request, and it will then be cached. By including all of your CSS inline, you're adding page weight to every single HTML request.
Although it might seem more efficient to just serve CSS for the current page, or split your CSS into lots of different page-specific stylesheets; in practice it's usually better just to have one stylesheet. Serving this compressed and with appropriate expires headers will almost always be faster than the alternatives.
Regarding SEO, robots ignore CSS, so this won't have any affect. If you had so much CSS that it substantially slowed down loading of your page, in theory you might start having issues, but you would need an inhuman amount of inline CSS before this could even potentially be an issue.
To the extent of my knowledge, your CSS sheet plays a minimal role in SEO, what is more important is your HTML markup and execution.
Following the order of '< h1 > - < h5 >' for your heading tags, with accompanying '< p >' tags instead of '< font >' or similar approaches is what will effect a web crawlers ability to recognise and prioritise the content in your page.
While you can use CSS to hide paragraph that you only want to appear in search engines and similar techniques it has little importance compared to the HTML structure.
All benefits you said apply. Search engines doesn't care too much about CSS and javascript (of course, if your page takes too long to wrap and send, this will affect, but I don't think it is the case).
I've seen this kind of solution before, but people tend to avoid use scripting to serve, once you can use media queries instead, writing just only one external stylesheet. I think you should take a look on this.
However, I see you are trying to optimize the CSS sent. This is good, but talking about 80k for all sheets, makes me think if you are not over complicating the rules.
Well, as last opinion, you can cache many different responses and make use of "canonical" thing on page head.
As far as I know, these days there are two main techniques used for including CSS in a website.
A) Provide all the CSS used by the website in one (compressed) file
B) Provide the CSS for required by the elements on the page that is currently being viewed only
Positives for A: The entire CSS used on the site is cached on first visit via 1 http request
Negatives for A: if it's a big file, it will take a long time to load initially
Positives for B: Faster initial load time
Negatives for B: More HTTP requests, more files to cache
Is there anything (fundamental) that I am missing here?
Profile it. It depends on the way your users use your site.
If it's a web application and your users are likely to interact with it a lot and see most of the layout you designed, you probably want to use a single CSS which is loaded once and then stored in the browser cache. The first time overhead is negligible in this case.
If most of your users come with a cold cache and just look at two or three pages, separate CSS files will probably improve their experience.
You can't tell without having a look at what the users actually do.
Even a largish CSS file, gzipped, is tiny compared to a lot of other things (like images, movies, etc.) that get downloaded. The only real reason to break up CSS into separate files is to swap in special rules to make certain browsers behave (I'm looking at you, IE).
There is no A or B, it's always a trade-off between the two. For example: you'd want the front-page to load as quickly as possible, so you only request what's necessary. For the following pages you request the remaining CSS. A total of 2 requests.
In essence, you're creating packages/groups of related CSS. By dynamically combining and compressing these packages, you can create a maintainable structure of files. This also enables you experiment with the best combination of speed, performance, requests and bandwidth...
This whole story also applies to JavaScript files, since the same trade-offs can be made.
What's better?
Writing one css file
Writing more css files
What's better?
Tracking, keeping 1 css file updated
Tracking, keeping more css files updated
What's esier?
Making decisions what to insert into one css file
Deciding what to put in every of your css files
What's the cost of generating each individual css file compared to generating one global css file.