Power to the Drupal themers! Which implicitly means more power poured into the Drupal 8 sites that they work on, right? And this is precisely the driving principle behind the revolutionary theming experience and the asset library system in Drupal 8!
Admit it now: are you still stuck with the never-gets-old “compiling SAAS into one single CSS file" (for your theme/module)” technique? Into the “one man show” type of library asset that should handle EVERYTHING?
Which means that you allow (just be honest!) for unused JavaScript, as well, to get loaded and to unnecessarily weigh your web pages down, right?
But what if you just... wrapped your JavaScript files in Drupal 8 asset libraries and:
- gained total control (and unmatched flexibility) over those assets (CSS and JavaScript files) that you attach to your Drupal 8 site?
- seized the chance to customize the way your asses get loaded on your web pages (they can get selectively included and thus load only when needed)
- ensured that other developers in your team can easily modify them
By far the most significant gain of the Libraries approach will be the significant front-end performance boost. Your JavaScript files will get attached/loaded only when needed!
And now, let me detail:
The Asset Library System in Drupal 8
It's you, the Drupal 8 front-end developer, who decides where (on which web pages) and when (selectively, only when needed) your JavaScript gets added/loaded.
But libraries aren't Drupal 8 specific. You get to leverage their power on a Drupal 7 site, as well.
The main difference is that D8 “spoils” you with a drastically improved theming experience.
It empowers you, via its YAML file-based system:
- to overwrite core libraries
- to specify dependencies
- to add your asset Drupal 8 libraries directly to templates
- to configure whether they'll get loaded site-wide or only on specific pages on your website
… and the list can go on.
Unlimited flexibility in handling your JS and CSS assets!
The Library Approach & The Style-Guide Driven Development
I'll go on now assuming that:
- you've already jumped in the component based design bandwagon
- you've adopted a “minimalist approach” keeping your Saas ideally light
- you've named spaced your components
- you've been compiling your Sass into a unique style.css file (one single asset library “overcharged” to import all there's needed to be imported)
Have I been accurate with my guessing?
Now in order to harness the power of the asset library system in Drupal 8 you'll need to have one file only per component. Which will automatically call for a restructuring of your Sass files!
Meaning that you'll need to migrate all that was shared between your components into some sort of Sass mixin and have the files imported under this format.
This way, you'll be declaring dependency on the libraries.yml file instead (instead of inside your Saas).
Now since we're still at the phase where you're refactoring your Sass, getting your individual CSS files properly optimized for the next step (that of configuring your asset library system in Drupal 8), I challenge you to make one key decision:
- you either define each one of your component CSS files as style-guided
- or you keep that unique style.css file, the one comprising all your JavaScript files, for the style-guide only and for all the other developers who might use the codebase after you
Define Your Asset Libraries in Drupal 8
Once all the preparations are done and your JavaScript is looking lean and “clean”, go ahead and create your Drupal 8 libraries right in your theme's libraries.yml file!
As mentioned: as a themer you'll be granted unlimited flexibility. Practically you get to:
- specify dependencies with core (making sure that the files corresponding to a component are all there, bundled up in its own dedicated library)
- you get to assemble all the CSS and JS files associated with one specific component into a library
Once you've defined your components library, just attach it to its corresponding components twig file. As simple as that!
The Asset Library System in Drupal 8 & CSS Aggregation
And finally, we've reached the very clincher for using libraries in Drupal 8 after all: their high impact on the way your assets get aggregated! And, implicitly, on the overall front-end performance of your website.
Practically your assets get loaded only when the components that they're attached to (blocks, paragraphs, regions, fields etc.) appear on those specific visited pages on your site.
And since your Drupal 8 site will aggregate these files each time a page, including different components from those of the previously accessed page, is requested, certain caching issues emerge.
A whole NEW aggregation file generated for this specific page, regarded as “brand new content”, means “no caching”.
And this is why to ensure that the very power of your asset library system in Drupal 8 won't actually “sabotage” your site performance you need to sort your assets into:
- JS and CSS files that will get loaded on all your web pages and which can be aggregated each and every time
- JS and CSS files which get loaded occasionally and are preprocess:false flagged, meaning that you'll be disabling aggregation for these particular cases
The Impact on Your Site's Front-End Performance
Basically, your overall page size will get... halved! The asset library system in Drupal 8 reduces your CSS and JS files' weight dramatically and give your site's front-end performance a major boost.
Not to mention the convenience of defining dependencies and having them all well-documented.
Have you already tried wrapping the CSS and JS files on your Drupal site in asset libraries? Feel free to share your thoughts on this too often overlooked performance optimization “trick” in Drupal 8.