My main goal is to allow for the loading of several pages to be as fast as possible. For this I want to take advantage of both, the cache and one "special technique" that, as a fallback, relies on the standard cache.
On the backend I have the following structure. There's a main page in the public_html and several subpages, each with specific css rules different from each other. The creation of all the minimized files is done by a script, so no extra complexity there. For simplicity, let's assume that this is the structure, although it's more complex:
/public_html
/index.php
/style.css ~50kb
/min.css ~100kb
/subjects
/index.php
/style.css ~20kb
/min.css ~10kb
/books
/index.php
/style.css ~20kb
/min.css ~10kb
...
So when the user enters first time on a subpage, they will receive this html code:
<!DOCTYPE html>
<html>
<head>
<link href="/subjects/min.css" rel="stylesheet" type="text/css">
</head>
<body>
All the body here
<link href="/min.css" rel="stylesheet" type="text/css">
</body>
As you can see, the user loads all the css code needed for that page in the header, in a small file. Note that /subjects/min.css is MUCH smaller than /min.css which would make this first request to load faster. Then, after the full html and css has correctly loaded, the /min.css will start loading. This file contains all of the subpages style.
Note that it's appropriate to put the <link> within the <body> tag, and even if it didn't work, there's no problem since the page-specific style is already loaded. Why am I loading this here? Keep reading:
For the second and subsequent requests on that session, the user will receive this html code:
<!DOCTYPE html>
<html>
<head>
<link href="/min.css" rel="stylesheet" type="text/css">
</head>
<body>
All the body here
</body>
The /min.css should be already cached from the first request. However, if for any reason it's not, it will load now the full minimized style, as in any normal website. This would be the fallback case.
Is this a valid scheme? Why haven't I seen anything like this before? Does it contain any logic error?
These are the main problems I can see, not strong enough in comparison to the benefits:
Notes about the comments:
The browser will make less requests. This is true, in this way the browser does one extra request. However, it's after loading the html and css, so this will not affect in a great manner the html.
Cache. Yes, I'm doing my best to catch the file. A point could be made against cache of the <link> if it's inside the <body>, though, because I don't know if it behaves differently about the cache, I only assumed yes in the question.
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.
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 )