Next step in our journey after Part 1 Caching and Part 2: Aggregation of our ultimate guide to Drupal performance is all about Drupal theming and this will be our part 3
The next part will be some general tips and tricks about CSS/JS and then we will release a full blown article containing all parts. so lets cut the intro and get right into it.
Faster Drupal - Part 3: Drupal Theming
- Automate optimizing of CSS, JS & Images. The thing is, it really depends on the node packages that you use on your theme level and how you can take advantage of it, for instance, there are many (I MEAN MANY WITH ALL CAPS) packages that can help you achieve that using a build system such as gulp, grunt, webpack or new comers such as Parcel or rollUp.
- Avoid using unnecessary bootstrap packages as much as possible. Usually, Starterkit themes load bootstrap packages one by one, why not remove the ones you don’t need? WHY? JUST TELL ME WHY?
- Is your theme using fontAwesome or any other kind of font out of the box? But you are using SVG icons from your design file! Well… why not just remove the built-in icon font from your theme then?
- Fonts are nice, And it seems our designers usually like to use 12 billions of them in a single page, but you should never listen to your designer (Or should you?) Always remember to load fewer fonts and fewer font weights as much as possible.
- While we are on the fonts topic:
Control font performance with font-display - Resource - Are you the type that invents the wheel each time yourself? Then don’t use a base theme that comes with a lot of good stuff! we usually don't use half of those goodies. Create a new base theme off of Drupal core's "stable" theme and go with the bare minimum. Or use a proper Starterkit, strip off the unnecessary parts, get your own Starterkit and get rid of all the Drupal themes excessive wrappers and classes.
On this note, it’s a good practice to get your DOM size less than 1500 nodes (recommended from Google Page Speed)
For Drupal 7 also maybe just consider Fences module if nothing else works for you - Reduce the scope and complexity of style calculations
- Prioritizing Your Resources with link
rel='preload'
and yes you can use <link>
for scripts as well - Resource - When we were kids (Back in Windows XP era) you’d read everywhere that do not use inline styles for your HTML files, but now you should use inline-styling to avoid render-blocking CSS files. All the CSS Styles loaded from external files is considered render-blocking. Why You may ask?
In order for the browser to display your web page and use the styles you specified in the external CSS files, it has to load them first. This means that your web page won't be displayed until these files are loaded. In order to speed up the loading of your website, you can inline the parts from the external CSS files which are needed to render the above the fold content. After loading the page you can instruct the browser to load the rest of the CSS files via JS - There are many tools that you can use to achieve this but this one explains good enough and works: https://www.sitelocity.com/critical-path-css-generator
Also, check penthouse as well, Can be set up easily as a task runner task!
https://www.npmjs.com/package/penthouse - includes CSS for critical path above the fold in the HTML head.
Our very own Sven played around with both penthouse and critical and let me just quote him in our slack chat here:
critical
is a wrapper for penthouse
with the main advantage that it delivers critical css
for several breakpoints in one file.
Sven Berg Ryan
Note: To generate critical css, link_css module must be enabled, and you can not be using deter CSS loading in AdvAgg, otherwise you get an empty file. (Needs testing)
Critical_css module on Drupal
- Now that you have the critical CSS, the proper tool to load the rest of your CSS: https://github.com/filamentgroup/loadCSS
- Remove unused CSS, there are tools inside the IDEs that can help you with that, you should search this part yourself since it depends on your weapon of choice for coding, also there are node packages that you can set up but I’d still go with the IDE approach and do it manually, just to be safe.
- Use video tag instead of gif images (Yup, it loads faster)
- Avoid using
document.write
specifically for scripts injection - Resource - Images must not be delivered larger than they are actually displayed to avoid loading unnecessary data. Resizing images on the browser side to reduce their rendering size is not recommended.