One of the things we do on an annual basis for our clients at Four Kitchens is an annual site audit — a high level kick-the-tires kind of site inspection. For Drupal sites, we check the logs for any glaring errors, check for overrides in Features, run some SEO and accessibility testing, and, of course, take it for a speed test.
If you run speed tests (like Google’s Page Speed Insights), you have probably seen a common, vexing error: “Render-blocking javascript and CSS.” What’s that?
Large CSS/JS assets can block rendering “above-the-fold” content. Modern browsers tend to allow concurrent downloading of 6 to 8 files at any given time (a few offer more, now). So developers aggregate and compress CSS and JS files so we have less to load, but that also means front-loading large — though compressed — styles and javascript files. This is a recipe for a log jam.
Here’s how to beat this speed bump. Using the methods described below, I’ve seen Pagespeed Insight scores on Drupal sites increase by 30% or more.
Javascript
For javascript, the solution is fairly easy: ensure the files are in the footer. In Drupal 8, this is already the standard, unless you have added some elsewhere. For your javascript to load in the header, you actually have to set: header: true in your theme’s library.yml file. (Also, be sure you are not loading any javascript that is not needed on the page.) In Drupal 7, you will need to move the files, perhaps using Advanced CSS/JS Aggregation or manually.
If there is specific JS that needs to be there as the page loads, you may want to defer it instead. Again, AdvAgg can help you do that, or you can defer it manually.
CSS
While moving files to the footer technically works for CSS as well, it introduces a new problem: the dreaded FOUC, or “flash of unstyled content.” Put plainly, the content is loading before the styles, so users – especially on slower connections – will see a very ugly site until the page is completely done loading. While not the end of the world, it makes for an unpleasant user experience.
What we do to counter FOUC is load a “Critical CSS” file first. Critical CSS is, as it sounds, any CSS that is crucial to making above-the-fold content appear close to the final product. Think layout, position, readability, sizing – particularly in the header … anything that will smooth a transition to the full CSS loading. These styles will be put in their own file (as straight CSS) and loaded inline, in the page’s <head>.
Place this in your html.html.twig file, in the <head>:
<style media="all">
{% include directory ~ '/path-to-file/critical.css' ignore missing %}
</style>
When you view your site, those styles will now load directly <head>.
Now, sifting through your CSS to figure out what is critical is a challenge in and of itself. I’ve tried using automated grunt/gulp tasks (critical, grunt-critical, grunt-criticalcss), that will take “snapshots” of styles that have been called for above-the-fold content only on a specific page, but those tools have their limitations. (For instance, you may build your critical CSS file from a snapshot of a wide view of your page, but then it may miss styles needed for a mobile version of the page. Or there are just too many variations page-to-page with a site with dynamic content.) It’s possible some of these projects have improved since I last checked, so it still may be worth looking into.
If you have (wisely) built your styles using discrete files for base, regions, components, etc, you *could* do a compile just of the your base, layout, header, and header component styles and that would put you in a good position to start building your critical CSS file. You could use a tool like Sassmeister to compile outside your normal workflow.
If you haven’t (or you have inherited a site will less precision), you may just end up taking that final, compiled CSS file, un-compressing it, and doing your best to grab styles for the header and top part of the body (taking special care for the homepage.) Like I said, it’s an imprecise science.
Once the critical CSS is in place, you can try moving the rest of the CSS in the footer. In Drupal 8, this means moving this line in html.html.twig:
<css-placeholder token="{{ placeholder_token }}">
Move it down to before the closing </body> tag.
In most cases, fine tuning what should be in the Critical CSS file takes a little trial and error.
Like with any style changes, make sure you review in a variety of browsers, devices and widths. Also, be sure to try throttling your page speed, under the Google Chrome web inspector’s Network tab. This allows you to simulate a slower network.
Note that you will need to maintain this new file. Any time you make changes to things included in the Critical CSS file, you will need to manually adjust it.
A final word of caution: you may very well be shifting around some structural stuff, and regressions can happen, especially at that level. Testing is very important — by you, and by the client, particularly on inherited sites. In a dream world, we’d have ubiquitous and comprehensive visual regression testing tools to catch anything that might have changed in the underlying load order of styles — but that level of safety netting is rare!
With all this in mind, you can plan for a critical CSS file for the next project that requires stellar performance: start out with all the javascript in the footer, prepare your CSS in compartmentalized Sass files that can be funneled to a critical CSS file, run speed tests throughout the project to see where problems are introduced, and, since you won’t want to maintain it during development, hold off until near-launch to generate your inline critical CSS file.
Making the web a better place to teach, learn, and advocate starts here...
When you subscribe to our newsletter!