View
265
Download
0
Category
Preview:
Citation preview
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
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
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
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
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
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
Recommended