jefflembeck
commented
9 years ago @JonDum Interesting ideas, so
Multipage Support - So, for this case, grunt-criticalcss is a multitask, so you can run something like:
product: {
options: {
outputfile : '_tmpl/_css/_critical/product.css',
filename : path.resolve( path.join( __dirname, "_dist", "_css", "all.css" ) ),
url : 'http://localhost/_views/tmpl-product.html'
}
},
listing: {
options: {
// write to tmpl, let copy bring it over
outputfile : '_tmpl/_css/_critical/listing.css',
filename : path.resolve( path.join( __dirname, "_dist", "_css", "all.css" ) ),
url : 'http://localhost/_views/tmpl-listing.html'
}
},and it will churn out a separate css file for each page.
As far as CSS Slicing goes, we might be using criticalcss a little differently than you do (not sure). When you first visit the site, we check if you have a certain cookie set. If you do not, we inline the criticalcss for that page, then we async load (using loadcss) the rest of the CSS for the site in one file (all.css maybe) and then set the cookie. If you have the cookie, we inline nothing and just load the already cached css file. There is a little extra double-download on the first page load, but I think that since the excess is in a non-blocking way, that you gain a lot by just having the css already DL'd and ready to parse for the next page.
Let me know if you have any more questions!
This thing is freaking awesome. Here are couple things I noticed that would bring criticalcss to the next level.
Multipage Support
Pass in an array of URLs (or .html files local to Grunt root) and have the option for criticalcss to either create a single bundle with all the common styles between the pages passed in, or spit out separate files, one for each url/page. Useful for sites that have multiple high-traffic landing pages.
CSS Slicing
Add an option to slice out and remove the selectors that are determined to be ATF from the source CSS file (thus saving kb that would be downloaded twice).