Front End ArchitecturePerformance Focused Theming

Jason StanberyFront End Architect

Performance Topics→ Base Theme Selection→ Content Images→ Theme Images

→ Styles→ JavaScript→ HTML

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

Goals→ Minimize payload→ Minimize http requests→ Minimize render blocking assets

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?

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.

Base Theme Impact on Performance→ Payload size→ JavaScript Library Dependencies→ CDN Delivered Assets

Images→ Theme images

Tracked in version control Live in your theme directory

→ Content images Referenced in the database Live in your files directory

Theme Images→ Greater amount of control→ Sprite all the things→ Optimize all the things

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

Better then Sprites?→ Font Icons

Smaller in size Can be sized up

without getting pixelated

Easy to change color

Content Images→ Challenges

Limited control of image selection Limited control of number of images Design and comps often dictates complex

pages

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

Styles→ Mobile First→ Aggregate the CSS→ Compress the CSS→ Reuse Styles

Why Mobile First?<div id="test"> <h3>Demo Block</h3> <p>Sample content.</p></div>

#test { background: none; height: 250px; width: 250px; padding: 10px; } h3 { color: #aaa; } p { color: #bbb; } @media (min-width: 600px) { #test { background: url(screenshot.png); } }

Write better styles→ Beware of Sass

inception (overly nesting your selectors)

→ DRY styles→ Know how to use your

tools properly

Reduce http requests for styles→ Use the theme’s .info

file→ Use a preprocessor

Or don’t→ Every page is cool

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

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

JavaScript Organization

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

drupal_add_js→ Add external JS files→ Add JS inline→ Prevent caching of JS files→ Set JS to defer

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

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

Questions?Tweet me @jasonstanbery

Thank You