 Hi everyone, thanks for coming to my talk titled The Speedy Go Live, a front-end performance checklist before launch. My name is Anthony Combin, and I'm a senior front-end developer based in Melbourne and working for Previous Next. In this talk, I'll be discussing quick, easy wins to increase front-end performance on your site. Ideally, performance considerations would be a project-long goal and not an afterthought. The techniques we'll be using in this talk can form a good basis for informing a wider strategy for performance in the context of building Drupal sites. It's a good idea to understand where the main performance bottlenecks in a site are. The Lighthouse and PageSpeed tools in Google Chrome are great ways to visualize where improvements can be made. Assets that tend to cause the greatest page weight are usually improperly sized or compressed images, external assets, and bulky JavaScript bundles. First up, we'll talk about images. First of that is responsive image styles. You can build responsive image styles using Drupal's image styles tools. You'll need the breakpoint and responsive image modules installed. Both of these come with core. With these, you can build appropriately sized images for each of your breakpoints, keeping images as small as they need to be and avoiding unnecessary resizing. You'll need to set up breakpoints yaml in your theme, specifying your custom breakpoints, and then, in the image styles admin, create an image style for each breakpoint. Set your dimensions for your image and save it with a descriptive name. Over in the responsive image styles admin, set your image styles for the breakpoints that you'll use them for. For example, in this design, a card will use both a different image size and a ratio between desktop and mobile viewpoints. By using these responsive image styles, we can use the smallest appropriate image and viewport. Compress images on upload, providing authors with automatic tools to keep image sizes down is a great way to keep size requirements in check, even better if they are invisible to the author. Asking authors to pre-compress any images they want to use is burdensome, and burdensome tasks tend to have low compliance rates. We can reduce this friction using the image-optimize module and installing server-side compression tools. I went into this in more detail in my blog post Better Image Optimization in Drupal, but depending on the tool and the settings we use, we can make some impressive gains. After installing your compression tool to the server and enabling your module, head over to the image-optimize admin tab, add your processes to the pipeline and either set it as the default site pipeline or add it to individual image styles through the image styles admin. This is a good option if you want a lossy compression as default and some individual images need a lossless compression. Profile images would be a good example of this. Fonts are another good candidate for low-hanging optimization. There are three things we can do to improve performance here. Locally hosting web fonts, sub-setting and using fallbacks. Locally hosting your web fonts improves your time to paint speeds by reducing the amount of HTTP calls made before rendering your text. For example, when calling a Google Fonts or fonts.com web font, the browser will first fetch the font CSS from the external server, pass the CSS and then make another request for the font. We can cut out this middleman request by self-hosting the font files and including the app font-based CSS in our already existing CSS. Locally hosting our fonts also give us the benefit of gaining extra compression by sub-setting our fonts by including only the glypses that we'll be using. Glyph Hangout is a great local tool for sub-setting with a high degree of control on output or Google Web Fonts helper for a simple way to both download a Google Font by self-hosting and easy sub-setting. Combine this with a font display strategy like Swap to improve perceived performance by specifying a fallback font. I would use an OS default font like Aerial or Helvetica to allow users to see text while the web font is loading before swapping it in once complete. The next area to tackle is our JavaScript bundles. With decoupled and progressive decoupling gaining a bigger place in our front-end workflow, work needs to be done to wrangle these often hefty frameworks into a manageable size. Tree-shaking can be used to include only the parts of the framework that we import. Webpack requires some setup in order to effectively tree-shake your application, but Rollup, my preferred tool, does it by default. Only bundling what is explicitly imported so we get that for free. We can also use code splitting. For sites with several JavaScript widgets, code splitting is a good option to cut down on package size by splitting out commonly used chunks and dynamically load them on demand. Both Webpack and Rollup have code splitting options. Webpack has the greatest browser support for dynamically loading chunks, but it achieves this by adding a ton of boilerplate to each bundle, which can wipe out the gains made by code splitting in the first place. Rollup uses ES6 module loading to achieve its code splitting, which has no support in Internet Explorer, but wide support in all other major browsers. We can get around this by outputting a traditional bundle specifically for IE, while allowing modern browsers to take advantage of the performance boost. We then add both output bundles to our libraries, adding the type equals module attribute to the codes that bundles for our modern browsers, and no module equals true to bundles that we want to deliver to legacy browsers like Internet Explorer. Finally, it's best practice to make sure you're only attaching assets that are used on the page. There's no point loading a pages CSS and JavaScript with slider or dialogue code that's not used. Try to attach the bare minimum styles to the theme's global library, and declare the others without adding them straight away. These can then be attached in the twig templates that require them. There are many, many other ways to improve front-end performance, but I hope this talk gave you some easy ideas to implement right away, and gives you some idea to continue to explore more. Thank you for listening. If you have any questions, I can be reached on Twitter at Tony Compton. Thank you. So we have about a minute remaining for any questions. Yeah, any questions? Seeing lots of thank yous, Tony. Thanks for listening, everyone. Questions, yeah? Yeah, we've got about 46 seconds left. That must have been very quick. Yeah, we've got a question from Griff about accessibility. Accessibility is another talk. I'll fire that up for another talk next time. Griff, thanks. All right, we're about to get the exit notice. Thanks everyone for coming, and we'll see you in the next session. Brilliant. Thank you, everyone.