 My name is Alan Moore. I am a senior front-end engineer at 10UP. I'm going to be talking about advanced techniques to optimize front-end performance. This is where normally I would possibly show Ricky Bobby picture with him saying, I want to go fast. But that's how the user is. When a user visits a site that we develop or they visit a web app, they want to go fast. They don't want delays. They don't want anything getting in their way from seeing content. As developers, and this is very much a more developer-centric talk, we have to develop in such a way that there is nothing in the way for that content. You can find me on Twitter at creative alan. My personal blog is alanmoore.me or on GitHub at github.com slash alanmoore. We're a product of the world around us. News is delivered 140 characters at a time. Food is just a click away. If you've seen Domino's, you can now order a pizza through Twitter. So things come fast. And entertainment is available instantly and to all. These are just a few examples of how we can obtain anything and everything almost instantly. Our users expect the same results. Content should be delivered quickly and without obstacles or delay. Each passing millisecond represents one additional user who may never see your content or the content of your client. If I were to pull the room today, if I was to ask each of you, and I'm actually going to ask this, how many of you have visited a website or used a web app or maybe even an app on your phone in the last week and that app, that site, was slow and sluggish? Raise your hand. Were you frustrated? Were you aggravated? Do you think about that when you're developing? Do you think about how the user experiences that? That is our job as developers. We should always keep the user in mind. Some questions I ask is, what is the user expecting? What impression is being sent? Is the user able to easily and quickly find the content that they are looking for? Does the user feel as if I had them in mind? Or am I just trying to deliver a product to my client quick? How often do we really ask ourselves these types of questions? How often do we purposely navigate a site that we developed with the sole intent of ensuring the experience is great? What you discover or you may find could be shocking. And honestly, it could be embarrassing for some of us. So what does page speed and load time directly affect? The first is user experience. User experience is the overall experience of a person using a product such as a website or a computer application, especially in terms of how easy and pleasing it is to use. Of this definition, what sticks out the most to you? To me, it's this phrase, how easy or pleasing it is to use. Front-end performance directly affects the ease of use and the satisfaction that a user experiences. Personally, I would rather visit a website that may not be the most visually appealing, but it's easy to navigate and I can find the content versus visiting a site that may have contained the most latest design trends, but it's slow, sluggish, and the content is not delivered as it should. The second thing that is affected is user engagement. User engagement is what drives the web. User engagement is what allows each and every one of us to continue in this business. I want users to read my content or the content of one of my clients. I want users to see ads that have been strategically placed in position so they catch their attention. These ads, like them or not, is what brings revenues to either ourselves or our clients. In a sidebar on this, now that I work with clients who receive revenue from these ads, my thoughts on an ad blocker is totally different. I want users to share content on every social media outlet possible. I want users to read an article and become excited about the next one. I want them to binge read, kind of like we binge watch stuff on Netflix. I want them to binge read content. I want the user to be engaged. I want them to feel excited. I want the user to have a great experience. It's time that we get the blockers out of the way and deliver the content to the user as quickly as possible. And like it or not, a lot of times the blockers is the code that we write. So let's look at some techniques to optimize front end performance. What you're gonna see today is gonna be super high level, but I've got something at the end for you on that. The first thing we need to do, and this is not on here, is we need to do everything in our power to keep the head of our site lean and clean. The more the browser has to parse, the more the browser has to go through, the longer it's gonna take for content to be delivered and rendered on screen. So the first technique is asynchronous JavaScript. The async attribute when added to a script tag helps prevent parser blocking. This also effectively prevents the browser from stopping to download the script before it continues to parse a page. Scripts without the async attribute are fetched, parsed, executed immediately before the browser continues to parse a page. In a lot of instances, we do not always need to have JavaScript executing immediately. If it's for something that is further down the page, why should it execute immediately when the site starts to load? We now have the ability as a part of WordPress Core to add that async attribute to an on-Q JavaScript file and is simply using the script loader tag. I've got some information at the end on how you can do this. The second is prioritizing the critical rendering path. How many of you have ever run a page speed insights report on your site and it starts screaming at you about you having prioritized a critical rendering path or the above-the-fold content? There's a few of you. So you know what I'm talking about. The Google defines the critical rendering path or the above-the-fold content if you would like to use a marketing term as the code and resources required to render the initial view of a web page. The critical rendering path is what the user initially sees when a site is loaded. This is what we see in the browser when the site first initially loads or in the device. The ability to prioritize the critical rendering path is actually a lot easier than it used to be. The old technique was you had to manually do that. Now we can automate these tasks using grunt tasks, using some grunt modules, looking at URLs, whether it's local, on staging or on a production environment, running a process against those URLs, generating style sheets and then load them up in line in the head of our browser. Then we can use additional JavaScript functions to create the link attribute for your style sheet of your theme and allow it to load asynchronously after the DOM is ready. And the cool thing about this technique is that that JavaScript file that loads your style sheet is gonna cache your CSS file, which the browser already does. There have been concerns about that, but it will browse it, it will cache it for you so that each additional visit to that site, the user does not have to wait for that file to be loaded and parsed. As I said earlier, there's gonna be some additional information at the end on how you can implement this on projects. One side note for this is you can build these grunt tasks into your deploy scripts so that you're never actually committing CSS files that are not relevant to a site. So you can build into your deploy script for staging and you can build into your deploy script for production so that every time you push code, if you're using something like Git, you're using a Git workflow, when you deploy and you push, the module will run through your server and you will now have relevant CSS in the head that is for the above the fold. The critical render path has now been prioritized. User gets that quick. The third technique is lazy loading. Now this is something you've probably heard about a lot, but honestly, how many of us effectively use it? It's a pretty easy technique. It's a way that we can load images, videos, iframes, widgets, and even more content only when it's necessary. One thing that I get kind of aggravated when I go to a website is if they are using lazy loading, you scroll, image comes into view, but it's that white blank space and then image pops in. It's a bad user experience. Two ways we can overcome that is to add a fade or the way I prefer is to allow the image to load at a pixel ratio before it comes in the viewport. There are multiple lazy loading options as far as plugins available for you to use today, if you would like to implement this. One is by my company, TenUp on WordPress.org and it's called lazy loading. Another one is by one of our coworkers that is available on TenUp's GitHub account and it's called Swiftstream. You can implement those today and initialize the lazy loading on your site. The last technique is pre-fetch, pre-load, and pre-render. Pre-fetch and pre-render have been part of the HTML spec for quite some time, but they have only recently gained interest. Pre-load is still a future spec but also can be accomplished via JavaScript. So DNS pre-fetching is one version of pre-fetching. This notifies the browser that there are assets that are later needed from a specific URL so the browser can resolve the DNS as quickly as possible. So let's say I have a Twitter widget on my website so we know that we're gonna be loading up different images, content, links from Twitter. Using DNS pre-fetch, I can call twitter.com in the header and then only have to do that round trip once. So eliminate doing multiple round trips to that server. This is also good if you use Google's font CDN or other attributes such as ads where you're hitting it nonstop. If you were to run a webpage test and look at the waterfall and see how many times you were hitting a URL, this is a way you can implement that and remove a lot of that. Pre-fetching can also be used to acquire a particular resource that will be used in the future. This resource will be stored in cache until it is referenced later. This is useful for images, scripts or anything that is cacheable. Pre-loading loads a resource into cache so that it can be instantly accessed when needed. In essence, this is the same result we receive when we visit a site for the second time. The resources from that site have been loaded into cache which results in content loading quicker. The final one is pre-rendering. This pre-entitively loads all of the assets on a certain document. Then downloads all the resources before the browser even attempts to render the DOM. This is a technique that Google has been leveraging for years on their search engine. While these are just a few examples of ways that we can optimize front end performance, when effectively utilize and implement we will see more than increase in speed. We will see an increase in user engagement and we will see an increase in the satisfaction and the experience that the users gain from our sites. So I've put together some additional resources to help you guys out today. There are additional resources and more in-depth tutorials available at my site at this link right now, alanmoor.me, WCUS 2015. You can click this. There are, there's a good 2000 word blog post on how you prioritize the critical rendering path CSS with code examples, how to put together the grunt task and links. Thank you very much.