Performance when combining specific page styles AND global style in the same page

Question 1

Yes, what you are doing is perfectly valid and common

CSS is perhaps a bad example, but the same principle ( load the last one in via ajax btw )

Like say, images.

We are on page 1 of our website and we know 99.999% of the time our visitors are going to click to page 2, and we know that on page 2 we have some large images to serve, yes, then we may load them silently AFTER page 1 has loaded - getting ready, then the site 'feels' fast as they navigate. A common trick in mobile web applications/sites/

So yes:

It is the same principle for ANY type of file that you may want to 'pre cache' for subsequent requests.

Load the page
while the visitor is 'reading' the loaded page, pre fetch files/data that you expect they may request next. ( images, page 2 of result data, javascript, and css ). These are loaded via ajax as to not hold up the page 'onload' event firing - a key difference from your example

However, To answer your goal - allow for the loading of the pages to be as fast as possible

Doing this, or any kind of 'pre emptive loading' technique, is minimal to 'speed of delivery' if we are not serving static files from a static server, a cookieless domain , and ultimately a Content Delivery Network.

Achieving the goal of allowing for the loading of the pages to be as fast as possible, is the serving of static files differently from your dynamic content ( php rendered et all )

1) Create a subdomain for these resources ( css, js, images/media ) - static.yourdomain.com

2) Turn off cookies, headers and tune cache headers specifically for this sub domain.

3) Look into using a service like http://cdnify.com/ or www.akamai.com.

These are the performance and speed steps for serving static content. ( hope no suck eggs, just directly related the question and if anyone is unfamiliar with this )

The 'pre emptive loading' techniques are still great, but they are now more related to pre loading data for usability than they are for speed.

Edit/Update:

To clarify 'speed' and 'usability speed'.

Speed is judged by software often as when the page 'onload' event fires ( that is why it is important to load these 'pre emptive resources' via ajax.
Perceived speed ( usability ) is the how quickly a user can see and interact with the content ( even though the page load event may not have fired ).

Edit/update

In a few areas of the post and in the comments was mentioned the loading of these additional 'pre emptive' resources via javascript/ajax.

The reason is to not delay the page 'onload' event firing.

Many website test speed tools ( yslow, google .. ) use this 'onload' event to judge page speed.

Here we delay the page 'onload' event.

<body>

... page content 

<link rel="stylesheet" href="/nextpage.css"  />
</body>

Here we Load via javascript /some cases Ajax ( page data ) and do not preventing the page load event

<body>
.. page content

  <script>

    window.onload = function () {

       var style   = document.createElement( 'link' );
       style.rel   = 'stylesheet';
       style.type  = 'text/css';
       style.href  = '/nextpage.css';
       document.getElementsByTagName( 'head' )[0].appendChild( style );

   };

   </script>

( this, as a bonus, also gets around the compatibility problems with having a <link> tag within the <body> as discussed in your other threads )

Question 2

UPDATE:

Please mind that the answer which the questioner marked as accepted cannot be recommended -
don't ever do this!

Any kind of "pre-loading" of CSS files doesn't make any sense, as you should never split up your CSS into several files!

My original answer:

So what is your real question in the end?

In my humble opinion your doing it all wrong - sorry!

Usually an author intends to

give a site a consistent look/ appearance
keep the maintainability as easy as possible
avoid FOUC (flash of unstyled content)
minimize number of (HTTP) requests
support cache mechanism to reduce bandwidth/ data volume

just to mention some of the most important aspects.

All of them are disregarded by your approach.

As you are using the link element within the body element, I assume you are using HTML5. Because in other HTML versions this would be invalid.

But also in HTML5 I would not rely on this. Have a look at the 2 versions:

Compare the section (at the top) "Contexts in which this element can be used:".

As the information from the CSS is most needed by the browser to render a page, it should be one of the first things loaded.

Have a look at the article:"How Browsers Work: Behind the scenes of modern web browsers" and especially at the section:"Rendering engines".

So loading another style sheet will force the browser to redo all the work, beside the additional HTTP request, which in particular on GSM connections may cause "trouble" because of the greater latency.

And if each page of your site really has such an amount of individual style rules then I would say it is a "design flaw".

One of the "design principles" is: As much as necessary - as little as possible!

Another (big) advantage of using just one style sheet is that it is cached by the browser after the first load. And as the CSS of a site normally doesn't change too often this is a great advantage which by far outweighs the disadvantage of some more KB to load on first page visit (btw independent of the entry/ landing page)!

Conclusion:
I really cannot recommend to use your approach!

Put all your styles (normalize, basic, media queries, print) in one single file which you load via <link> in the <head> of your document.

That's the best you can do.

Question 3

Since min.css contains all styles properly minimized, just use that

Why ?

1.The browser will make less requests

2.The file will be cached after fetching for some 2 or three times by the browser. Tremendous decrease in page load time !

3.The browser doesn't have to go through the specific page's css, which in turns decreases the time needed for a page to render

4.Easy maintainability of code. If you want to update css, just prefix some query variable, so that browser fetches the updated css

I think , the above reasons are enough for you to use just the min.css

Also, don't forget to set a reallyyyyy long cache expiry date, if you would do as I've recomended

Edit: As OP didn't understand point 2, I'm gonna make myself and the point clear.

The browser will not cache the css file in it's first encounter, because it thinks : 'Hey, Let's not cache this immediately. What if it changes ? I will see to that, the same css is being reloaded atleast 2 times, so as to reap the benefit of caching'

There's no point in caching the css, when it is first loaded. Because if the browser does that, then there will be huge amount of cahce on the user's system. So browsers are clever enough to cache the files that are frquently loaded and unchanged.

Question 4

What you're describing is a pre-fetch/lazy-load pattern with resources loaded in anticipation of becoming relevant in the future - for instance, a basic login page with minimal styling that starts loading site css in the background.

This has been done before, among other things, in PageSpeed Module. In fact, it's more aggressive yet requires less development effort! A vanilla landing page (like a login screen) utilizing only a small subset of styles could take advantage of prioritize_critical_css that inlines relevant rules into the html and loads css at the bottom of the page! Unlike your original scenario where two consecutive requests have to be performed, the render-blocking effects of not having stylesheet in the head are being offset. This improvement is well-perceived by first-time visitors using mobile devices, who are subject to higher network latency and smaller number of simultaneous http requests allowed.

A natural progression of this would be to lazy-load sprites, webfonts and other static cacheable content. However, I'm inclined to speculate that the benefits of having well-structured separate css are probably superficial, and you would generally do well with minifying styles into one file. The difference in loading time between a 5 and a 50 kilobyte file is not tenfold, it's negligible, since website performance does not depend on bandwidth anymore. As a side note, you'll never have to worry about dependency management (i.e. remembering to include rules relevant to specific elements on your page), which is not easily automated for html+css and gets quite hairy for big projects.

If you focus on the cardinal rule of static resources - aggressive caching - and remember to fingerprint your assets so that deployments don't get messy, you're doing great! And if you address perceived performance with a well-placed throbber here and there...

Performance when combining specific page styles AND global style in the same page

Structure

First request

Following requests

UPDATE:

My original answer:

Why ?