Front-end Performance and Drupal Having your cake and taking a few bites By Drew Bolles 

Be a web developer 

HTML, CSS, JavaScript, Browsers, Server Side Stuff (?) More JavaScript Any and all frameworks that deliver stuff to the web are an abstraction of these technologies. When in doubt, or trouble, or fatigue, return to the basics. The web stack 

Browsers are king 

Get to know your browsers The only requirements to connect to the web are an internet connection, and a web browser. Browsers are the gates to your sites and apps, and you should really get to know the keepers. https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ 

Your browser's job is to render the assets you give it. If your site is slow it is your fault 

Browser Anatomy Your browser reads the HTML it receives and turns that into the DOM. It reads from top to bottom, and any asset it comes across, it will try to download before continuing. This is why your CSS goes at the top, and your JavaScript at the bottom of the page. This is also why it’s important to minify and aggregate. The less code the browser has to go through, and the least amount of stops along the way*, the better. *in current HTTP protocol 

Always load responsibly Always serve the least possible amount of code. Favor systems that require you to turn on features, rather than turn off the ones you’re not using. The goal is to only send what is absolutely critical to render the page, and asynchronously load the rest. 

JS (and Filament Group) to the Rescue Load CSS To async your tags, simply add the `defer` attribute. <script src=”path/to/script.js” defer> 

Smarter Drupal asset attachment Make sure to only add a CSS or JS asset where needed. Don’t add things used on certain pages to your global assets. With Drupal 8 libraries, this becomes very easy to do. Twig makes it simple to load the library conditionally from the exact level that needs it. 

Example field template 

In summation ● Smallest amount of code needed ● CSS at top, JS at bottom ● Minify, uglify, aggregate ● Async load assets where possible ● Make sure assets are loaded only where needed 

Webpagetest.org 

Makes me sound smarter than I am A tool for measuring your site, under varied conditions, with visual reports of your asset waterfall, and the time requirements of each. The most invaluable tool in my performance utility belt. webpagetest.org 

Chapter Three’s Homepage 

Insert saying about measuring and cutting Performance is like the blueberries in blueberry muffins. You can’t bake it in after the fact. Performance needs to be a consideration during all phases of the project. Measuring the impact of decisions before they hit the production servers is imperative. Things like performance budgets are key to fighting the continued upward spiral of our web page sizes. 

How good is good enough? The Dream is 1k speed index (like golf, the lower the better) and under a 1 second start render. This is a very lofty goal, and in the wild anything under 2k speed index is acceptable, but could have a performance sprint done. Speed Index is the average time at which visible parts of the page are displayed. https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics /speed-index 

Images and their effect on the web 

At what cost The web is “prettier” today than ever before, but it’s also freaking huge. The average site now clocks in at 2.3MB, with images a staggering 1.4MB on average. Holy moly. As web developers, that’s our fault, and if our best excuse is someone paid us then shame on us. 

Education and minification Often clients are the ones uploading massive hero images, instead of following the guidelines your team meticulously crafted. I hear you. Routinely check your sites, find the bad images, and email somebody. Talk about image sizes in meetings, often, make it a priority. Find a desktop app that works, or a service to automate. Don’t settle for slow. tinypng.com, compressor.io, ImageOptim 

Not just max-width: 100% A responsive image solution is an absolute must in a modern, performant website. Minification is great, but serving up a 2000 width image to a person on a phone is still evil. Plus, it’s not so bad. https://www.html5rocks.com/en/tutorials/responsive/picture-element/ 

And another one 

Responsive images & Drupal Breakpoint and Responsive images are core in 8! Yay! 7 you’ll want to grab the breakpoints and picture contrib modules. They both allow you to define breakpoints, and map image cache sizes to them, generating the output for you. 

Drupal’s responsive image settings 

SVGs are the (present) future 

It’s all math, man SVGs are code, and your browser likes code, it likes it a lot. It sends code heart emojis. Drupal 8 uses and recognizes SVGs by default. Drupal 8 loves code, too. What should we use SVGs for? Icons, logos, anything that can be cleanly represented as a vector image. The lifestyle photos of the city skyline you’re pretty sure is your city are still better as jpgs. 

That’s right, SVG icons SVG icons are better than font icons. https://css-tricks.com/icon-fonts-vs-svg/ Smarter peeps than me have said it, but can confirm. The best reason I’ve heard in favor of font icons boils down to developer experience. Don’t choose tools that make yours or your team's life easier over your end-users’. 

Also, super easy in a build system Gulp task gulp.task('icons', () => { return gulp.src('icons/**/*.svg') .pipe(rename({ prefix: 'icon-' })) .pipe(svgmin()) .pipe(svgstore({ inlineSvg: true })) .pipe(gulp.dest('../')); }); 

Adding to Durps and using Add to your html.html.twig file: Then use as so: 

SVG icons tl:dr; 1. They’re code, so they get gzipped 2. Easy to build a SVG sprite of only the icons needed 3. Can be embedded to avoid an HTTP request 4. Relatively simple syntax 5. Complete control over each icon 6. Can do more advanced styling / animations 

Advanced-ish and Experimental 

Inling your critical assets Because the browser chokes on any asset it has to download, the absolute fastest way to render a website is to inline the CSS needed to render the in-view page and async load the rest. Sounds weird, and it is a little, but it works. https://www.smashingmagazine.com/2015/08/understanding-critical-css/ https://www.fourkitchens.com/blog/article/use-grunt-and-advagg-inline-critical -css-drupal-7-theme 

Drew Bolles @bollskis github.com/drewbolles Go make fast stuff