This document provides guidance on front end architecture for performance focused theming in Drupal. It discusses selecting a lightweight base theme, optimizing theme images with sprites, delivering appropriate sized images for device breakpoints using Picture module, aggregating and compressing CSS and JavaScript, and adding scripts to the footer for delayed loading. The document also covers optimizing HTML markup, using preprocessing to improve styles, and bonus techniques like advanced asset aggregation modules, CDNs and lazy loading images.
3. Theming for Performance
→ This is a guide
→ This isn’t 100% accurate in
100% of the cases
→ This can’t and won’t cover
everything
→ I’m not a performance “expert”
→ Some Science
→ Some Voodoo
→ Some WTF
5. Base Theme Considerations
→Is it a completely custom design?
→What tools are out of the box?
→Is this a consistent starting point for all projects?
6. Base Theme Selection
→Choose a blank canvas themes
Light weight themes
• Don’t require you to overwrite everything.
• Don’t load unused styles and scripts.
• Don’t make assumptions about your design and
functionality.
7. Base Theme Impact on Performance
→Payload size
→JavaScript Library Dependencies
→CDN Delivered Assets
8. Images
→Theme images
Tracked in version control
Live in your theme directory
→Content images
Referenced in the database
Live in your files directory
10. Sprites
→Combine images into one
image
→File size is often less then
the sum of individual files
→One http request
→A lot of tools for sprite
generation
11. Better then Sprites?
→Font Icons
Smaller in size
Can be sized up
without getting
pixelated
Easy to change color
12. Content Images
→Challenges
Limited control of image selection
Limited control of number of images
Design and comps often dictates complex pages
13. Mitigate Content Image Risks
→Serve an image appropriate for the device
Picture module, picture module, picture module
• Works with image fields
• Works with wysiwyg images (via text filter & dev
version of picture module)
• Works with views images
• Uses Image Styles to resize images per breakpoint
17. Write better styles
→Beware of Sass inception
(overly nesting your
selectors)
→DRY styles
→Know how to use your
tools properly
18. Reduce http requests for styles
→Use the theme’s .info file
→Use a preprocessor
Or don’t
→Every page is cool
19. JavaScript
→Similar to CSS, but different
Scripts not required for rendering can be in the footer
External scripts should be not aggregated
Scripts used on most pages should be on all pages
Scripts on few pages but frequently visited pages
should be on all pages
20. JavaScript Organization
→Similar to CSS, but different
Styles is organized by component, so should
JavaScript
• Logically break up JS in the same way you would
styles
• Don’t just have a script.js file
22. drupal_add_js
→theme_preprocess_html function
Easiest way to add scripts to the footer that you’d
normally add to the .info file
Even though it runs on every page, make sure it’s in
your option array
→Used in custom modules to add JS to pages when
module runs
25. HTML
→Control mark-up
Tpl files
Fences module
Views field wrapper
→Reusable styles
Preprocess to add
classes
Field Formatter Class
module
Field Formatter CSS
Class module
26. Bonus Points
→ Advanced Aggregation Module
Tons of Advanced Features
→ Magic Module
Less Features, but possibly all you need
→ CDN
Cut down the roundtrip request time by serving static
assets from a CDN
• CloudFlare Free!!!
→ Lazy Load images outside of the viewport