 My name is Alan Moore, and I am a front-end engineer at a company called TinUp. I am going to be talking about my titles in need for speed, performance-driven, front-end development. What we're going to be talking about is creating fast, engaging environments for our users that load fast in the browser. It's something that we all think about, and it's something that can at times be very hard to pull off. There are a lot of gotchas in the way when we start working with the browser, the technologies that we love to use, so we're going to look at some ways that we can overcome those. This is where you can find me on Twitter at creative alan. My personal blog is alanmoore.me. And GitHub, you can see things that I've contributed to. The list isn't super long, but github.com slash alanmoore. And as I've said, I work for a company called TinUp, and there's a great little website out there. It's tinuphiring.com, and yes, we're hiring. We're looking for quality system admins, web engineers, front-end engineers, people that work with accounts. Particularly right now, our biggest need is people in project management, people that have ability to lead teams and work with clients. If that's you, I would love to talk with you. My co-worker Adam is here also, and he would love to talk with you also. We are looking for quality people. We are fully distributed. We have 150 employees worldwide, and we would love to have you a part of our team. So let's get started. How society has shaped the web? So the first question I'd like to ask is, how many of you have ever visited a website? Preferably one that you did not write code for. And as you're going through the site, whether it's on a device, mobile device, or on your computer, you have that immediate user frustration where the site's slow, something isn't low, and maybe they have one of those great sliders and carousels that you should not have on your website, and you click the button and it doesn't do anything. And then five seconds later, it finally decides at its own time, at its own choosing, that it's going to progress for you. How many of you have ever had that situation? You're just like, ugh! I'm leaving your website. That's what I do. If your site loads slow, I'm gone. Because I want it fast. I want it now. Society has shaped that. I think of, you know, we can drive through a drive-thru right now, get a cup of coffee, keep going. I can drive through a drive-thru and get a Chick-fil-A chicken sandwich and keep rolling. And there's nothing that stops me. So how has society shaped this? From the dawn of time, people have sought after faster ways to do things, from means of transportation to pizza being delivered. We think about all these things. Today's web user is no different. Content should be delivered and rendered at the click of a button or at the refresh of a screen. Any type of delay will result in frustration and a quick exit. These are all instances from where the wheel was first developed, to horses, to the steam engine, to the first car to jets, to race cars, to the shuttle, to the TARDIS, and then the Great Ricky Bobby. These are all fast instances. We want things fast. Have you ever, if you think about in the realm of a race car, maybe a drag car, if you're driving down that straightaway, every obstacle in the way of the car is something that's going to cause it to slow down. That's the way that websites work, too. Everything that's in the way causes a delay. As developers, that's things we have to work on, front-end engineers and back-end engineers. That's why we're going to look at how the browser loads a webpage. So have you ever looked at how your browser loads something? Have you ever really investigated that, how it happens, from when you first navigate to a URL to the site fully paints and renders? Have you ever looked at how that browser loads? This is how it happens. You enter that URL, the browser starts to download an HTML file, and then it starts parsing through the HTML. And then it encounters something that it has to load, which it could be an image, JavaScript file, CSS file, et cetera. It could be more things. Well, in the case of all of these, it has to load the external resource, it's locally on that URL's server, or it's on a CDN or something externally. And in some cases, it has to parse that external resource, JavaScript file, CSS, for instance. And then it continues to parse the HTML until it encounters another resource that must be loaded. So the scary thought about this is, we have a tendency to load up all the things. Every cool thing that we can think about to put on a site without thinking about the end result, without thinking about what it can do to the site. The more JavaScript files you load, the more CSS files you load, the more images you load, the slower your site can load in the long run, especially if we're loading those in the header. It becomes render blocking. And that can be an issue, especially I've seen instances where I run a web page test as I'm doing an audit on performance for one of our clients. And before we ever hit that body tag, that first open and body tag, there are 70 external resources being loaded. This is prior to us even starting to write code, this is looking at their existing site. And that's already a way that I know we can provide a better experience for our client is get rid of all those things that are loading. We're going to first talk about the critical rendering path, and you probably see a newspaper sitting up here and you're like, why did he leave his newspaper up here? But there's a particular reason for this. So one of the great marketing terms that we've had come out in the last few years is the above-the-fold content. I want to have as much as possible in the above-the-fold. I want to have this slider in the above-the-fold. That term comes from this. It comes from the newspaper. If you think about through time some of the most important headlines that we've ever seen prior to the digital world coming into play with news, it was in the paper. The most important news of the day, the most important thing that we had going on was right here in the above-the-fold. So in the New York Times today, it's talking about China's global ambitions. It also talks about the president visiting a memorial in Kenya. Those are important news for our day. Those are the things that is the above-the-fold content. This actually translates over to the web also. For your clients, for your users, for yourself, the thing that you want to have the most, that you want to say first and foremost is right there when the browser renders. The above-the-fold content, the critical rendering path is the first thing that the user sees and experience. And that's something that we have ways of going about it to prioritize that up until about seven, eight months ago. It was something that I would probably consider very bleeding edge of the cutting edge. It was kind of scary how we're going to figure that out and get it there. But today we're going to be talking about ways that we can overcome that a little bit later on. I'm going to give you some code examples. So let's talk about what the critical rendering path is. Google defines the critical rendering path as the code and resources required to render the initial view of a web page. That is, as I said, the first thing that the user sees when they navigate to your website. That is the first thing in the browser, whether it's an iPhone, an Android device, or a computer. How front-end performance affects user engagement and experience. So, as I mentioned earlier, user frustration. It is very frustrating. We've all had those times where we've experienced that frustration. But have you ever thought about and really went through what your user is going through on your site? Set down and thought about. Now, if your area is user experience, then thank you. Because we need you. We really need you. Our company has, I didn't mention this area too, user experience. If you're in user experience, we would love to talk with you. That has made all the difference in the world when I think something makes sense. But then one of the user experience designers comes behind me and goes, hey, that's awesome. But let's correct that because the user is going to expect this and this can cause a problem. Speed is the same way. How the site loads is just as much a user experience issue as not being able to click a button on a site. Frustration is defined as a feeling of anger or annoyance caused by being unable to do something. This is how Webster's dictionary defines frustration. Front-end performance has a lasting effect. The content that ourselves or our clients are trying to present can be quickly blocked, passed by, or never seen when performance is a problem. This could be a breaking news story, a featured article, an upcoming event, an ad that brings in revenue and so much more. If you think in that light, front-end performance should never be the bottleneck. I think about a lot of the clients that I deal with on a day-to-day basis. A lot of our clients, I would say most of our clients, a lot of their primary revenue comes in through ad sales, whether it's a radio station that I'm working with, whether it's an online publisher, they have ads that bring in revenue. If the code that I write, if the site that I help to develop is performing at a slow pace, that's one less ad that will be seen. That's one less impression that the user will see. That's one less possible dollar that my client is making. That has a lasting effect. If you add that up over millions of visitors, that's a lot of money. Our job, our responsibility is to make sure that our clients make money off what we're providing them. If our job is, if we're the ones who make the money, if we're the ones who, that is our site, we want the same type of situation. We want the people who work with us and partner with us to see that as an important piece of the puzzle. Performance and accessibility. Performance has an even bigger toll on accessibility. I think about my time at NC State, there's one of my co-workers that I work with at North Carolina State University is here. There was a big push in that last year at North Carolina State University on accessibility of making every site that the university had be accessible to all. Performance has an effect on that also. Web accessibility refers to the inclusive practice of removing barriers that prevent interaction with or access to websites with people with disabilities. When sites are correctly designed, developed, and edited, all users have equal access to information and functionality. We live in a time where information is available to all and it should be for all. We must never block a user with a disability from accessing that information. Our development process must include a workflow that seeks to include users of all types on all devices. This is something that I still feel that as developers, we don't put the importance that we should on it. At our summit we had for the company I work with, one of our team-mates Dave Rawls spoke about accessibility. One of the things that he referenced that is important, it's very close to me, it's something that I find to be important, is accessibility, and a lot of people would think this isn't an issue, but it is. I'm going to speak from very firsthand basis and I'm very open and honest about it, is people with attention deficit disorder, ADHD, how accessibility, how sites affect them. That's something that I face and that's something that I deal with. If you were to go to my blog, you would see blog posts about life as an adult with ADD. Websites affect that, particularly websites where there's a lot of interaction, a lot of things going on at the same time. They affect me, they also affect performance at the same time. If those things start to lag, it's kind of a weird situation because if there's too much interaction going on, I get diverted, but if the interaction has issues and it moves slow and there's performance issue, it affects me the same way. But I also think of the user who has vision issues. I think of the user who may not be able to see it all. They have the right, just as much as I do, to visit that site and interact with that content and the code that I write should not be a blocker for that. What we do as developers should never be a blocker for that. Performance-driven front-end development best practices. A lot of these are based on the best practices that the company I work for has put together. They're also thoughts that I have. Also, as I go, if you have any questions, you have any thoughts, if you have any additions, please don't hesitate to speak up and add in. I love people to be involved while I'm doing my talks. The first thing is, if you don't need it, don't load it. This can span the globe from style sheets, JavaScript files, even content. Should you be loading a JavaScript file for a gallery on the front page of your site when the gallery is buried three pages deep? These are the questions we have to ask as we develop. We can use something like, a singular for items that should only load on a single page or a post. For those galleries, I mentioned something that we've been doing on my team as we create a custom conditional or hook that will check if the gallery is present. If that gallery is present, the JavaScript and the CSS will load up. That's one to two less files that have to load up before that content is loaded up. That's one less thing that the browser has to deal with in the long run. This is an example. This is an example that any theme that you've probably worked on or seen that has comments, this is the standard way to load up the comment reply script. If it is singular, comments are open, get the option threaded comments, then we're going to throw this in. It's something that we can really work on. This is something that I would also love to see. I'm going to go hit, hit, Adam, or the people in here that work on core. I would love to see a way that we could do this natively and WordPress for styles so that we don't have to load those up all the time or be able to throw those in the footer without having to just on cue it and let all the things go. You can do is singular for style sheets, but then I'm also dealing with the fact that I've got multiple style sheets. There's little issues either way. Wait till later. This is defer, async, use the footer. I spoke about this particular area at WordCamp Fili, and one of the statements I made, a guy came up to me after, what do you mean that we should do this? I get really upset with plugin developers who have a JavaScript file that they need and they don't allow it to go in the footer. They just throw it in the header and that's one more thing that I have to deal with. Or they give me a setting that says, hey, would you like to put this in the footer or would you like it in the header and it actually doesn't work? Or it tries to detect the content and that doesn't work. In our themes, our plug-ins, whatever we're working on, if we don't need that file thrown in the footer, if you don't need that JavaScript file and if you can async that JavaScript file, then do it. I'm going to show you a way that you can do that in some code examples. Natively in WordPress, using some new hooks that we have, some new filters, new actions that you can do this and it will not mess up your code and you'll still be able to on cue your JavaScript files just like normal. The bare necessities. The initial rendering. What is needed to make the initial render of a site load quickly and smoothly? Is it necessary for you to load the styles for your footer at the very start of your website if it's not going to be seen initially? Should you do that? That's more CSS that we have to deal with. If you don't need it, don't load it. I mentioned this earlier. This is one of the models I go by. It's great to be on the cutting edge but it's never okay to be on the bleeding edge of the cutting edge. What that means is it's okay to do cutting edge things but if it's on that bleeding edge side which means there's so many chances it can fail, then we shouldn't do it. I threw this in because what I'm getting ready to start talking about is still pretty cutting edge. It still can be considered by some on the bleeding edge of the cutting edge but it's something that I've got a very large project I'm working on. This is going to be something we're utilizing and it's something that could be a standard at our company very soon. This is called... loading the critical rendering path styles in line in the header and all else either in the footer or loading it asynchronously with JavaScript. Let's talk about how we can do this. I may smile a lot, it's something I'm really excited about because this is something that Google, if you do page speed insights, if you do the scores on your website, most websites that people run this test on, they fail this situation. The reason why is how many of you... So how many of you do front end development? So let's say that you're writing the CSS for a site. First off, do you want to have to manually determine what styles are critical for that initial render view? And once you do, after you've gone through that process of determining that, do you want to have to manually deal with two different stylesheets? If you make a change to this one, you may have to make a change with this one. And then with loading it in line, you've got to cut and paste that, possibly either put it in a header or put it in a function. And then every time you make a major change, you have to do that again. That's why I would consider this bleeding edge, but I'm getting ready to show you a way that we can overcome that. Thank you to the great people at the Filament Group. We have a new process that works either by itself called Critical CSS, or you can use it as a grunt or gulp task. And what this does is, when you add this to your grunt, and so all my examples are going to be using grunt, so just FYI as you look at these. When I add this process, this task to my grunt file, I can parse a local domain. It uses phantom.js, so it's a headless browser. So I put in my URL. I say, okay, I like my width and my height that we're going to prioritize to be 1200 pixels wide, 900 pixels high. I want to output a new file here. This is the file name is the CSS stylesheet that's being used for the site. We have a buffer just to make sure in case it's for file size, so we don't get an extremely large file size. And then ignore console. That's so if there's any console error logs, we can ignore that for right now and we'll go back and figure out those issues. So I can run this, and this is for a home page. And the cool thing about this is I can run multiple options. So if I want to do an article, I can generate a separate stylesheet for an article. And that way, if the user goes to an article or a gallery, they have all the styles that are necessary. So this looks well and good. We've generated some stylesheets, right? We've run that by, I normally create a separate task just called critical, so I can type in grunt critical. So this does not have to run every time I run my standard grunt task because that's going to take a little bit. And then when we run grunt critical, we get this. It generates stylesheets for each of these. It goes in, parses the stylesheets. And the cool thing about this is it takes into account media queries. It takes into account that so if you go and do page speed insights on your site, you're going to find that not only on mobile, but on desktop, the above the full content has been prioritized for both. So now we have stylesheets, right? But how are we going to deal with that? Here's what the stylesheet would look like, just a standard inline stylesheet. And then we would go and use a cool little function that the, that Filament Groups put out. It's called loadCSS. What this does is after your site has, thank you very much, some of the colors, maybe a little bit dark. Yeah. And I'll put this information and make it available to you guys. There's going to be a link for this. But with this, what this is doing, this is asynchronously creating a link to your stylesheet. When the browser goes through your site, it is not considered this render block. That's why we're inlining before this. These styles that we have here, these are just test styles. What I do with this is I have a PHP function that runs conditionals. And if it's the front page, it gives me the critical for the home. If it's a article, single, it loads up the stylesheet for that. And if it is a page, it gives me that. And so on and so forth. The more content, the more these are possible to have. Those are loading separate stylesheets. You're writing separate stylesheets. Yes. So what I'm doing is I have a standard stylesheet. I'm doing include once with a link to the, with a reference to the stylesheet. And then it includes an inline. I've got, I didn't show this and this because the fact is like it's a lot of code to show. But in that style, I will open up PHP and then do include once with a reference to the stylesheet. And then it will load all those styles within the style bracket, the style open and closing elements. And then run the conditionals also to check and make sure I'm getting the correct one. This is something that if you go to my website, Alanmore.me, you'll see something is actually happening there. The, if you go to an article, you'll see it's separate styles. They are minified. So I am part of my grunt task. The minify, the CSS min option, I minify the styles that are being generated so that I'm loading up minified at all time. And in a lot of our situations our company, the server is doing that for us, but this is another level of it. It's less than it has to deal with in the long run. And then this is low. The reason that I've had some questions as to why I'm using a function like this to create the CSS, the link to the stylesheet. The reason why is if for some reason something fails, if for some reason something does not get included in that critical stylesheet, I still have the stylesheet being loaded. And it's about a one to one and a half second delay after the site renders up that I get the stylesheet also. So there's no, at the end result the user is still getting everything they need. But I've prioritized everything that should be sent first and seen first. And then below that you'll see a no script option in case for some reason, as Adam mentioned yesterday, somebody has JavaScript turned off. And we have situations where that can happen. We have a link to the stylesheet. Any questions on this? Yes. So that's what this process does. The grant task does that for you. So what it does with loading up the headless browser, it looks at everything that initially loads in that screen resolution and it generates, pulls all the styles out of that and puts it into a stylesheet for you. That's why, that's why I didn't want to deal with this for quite a while. Because I didn't want to have to sit there and look at a site and figure out all the styles that I needed to make it work. This takes that need to do that out of it for me. So when you do that first generation you have the media period running, right? So it's based on a certain size. So when the browser is loaded on mobile, for example, are there different styles generated? No, it pulls all the media queries into the same file. So it has a media query attached to it? So you're not having to do something like match media? That's the max size we're prioritizing. So what I've done, so the 1200 by 900 that you see here is based on, not only is that a default, national average for browser sizes that the average user uses. Now, with your clients this should be a case by case basis based on the users they have to their site. So one particular site that I'm working on now, about 60% of their users are Android users and mobile. So it's very weird different sizes because one thing Android gives us is a lot of different screen resolutions. So we're coming up with a kind of average between that to prioritize. So it's not generating you're not getting one for mobile, you're not getting one for desktop, you're getting still one generated style sheet. And this is the way that we develop we do mobile first, so it's styles and then for that bandwidth up. Yes, ma'am. So what that's doing is with phantom.js instead of this actually loading up your browser it's loading what's called a headless browser, it's kind of it's loading up a browser you don't actually see it happen when this task right here runs. So when it says running critical home, it's running a task that pulls up a browser that's 1200 pixels wide by 900 pixels high and it's pulling all the styles that are needed in that size. So you're saying, okay, I want to generate styles that are minimal for this. So where I could find this to be very important is thinking in the realm of how we deal with tablets. Everybody's approach to dealing with tablets is it's a little bit different. Do I give the user who is on landscape on a tablet, do I give them a hamburger icon and off canvas menu or do I provide a drop down that doesn't even work correct on tablet because it's based on hover for a lot of people. So by doing this 1200 by 900, I'm going a little bit larger than the standard tablet sizes. That's also something that's a little bit smaller than the average laptop screen size and I'm prioritizing all of that. I could be that guy who goes, man, I have a 1920 by 1080 monitor or my new one that's coming in and that should be sitting in my house right now. That's 27 inches. That's 25, 60 I believe. I could be that guy who says that's what I'm prioritizing because that's what I have at home. There's a problem with that. How many of my users actually have that? Not a lot. So I prioritize based on what my clients users have or in an instance like my personal project on my, like my site I prioritize based on the national average. The national average of screen sizes. So 1200 by 900 is a little bit larger than that and it's a little bit wider than that. That way, if somebody has got a screen a little bit larger they're still getting all the styles and the sizes that they need. No. No, there's not. Because it's in the head, nothing has to be, it's being parsed just like HTML is. The browser sees it, pulls it, keeps rolling. It's not having to go through another file and parse that one. So it's beautiful. It's fast. And in this case too, I also if the file allows it for font files, so we don't have like a flash style content because you can deal with that with font files, I load my font files locally. I don't deal with an external CDN. As I said, if it allows that and the reason for that is, so let's take Google Fonts for instance. How many use Google Fonts? How many of you have ever looked at your browser and seen that link that is being added? It's a CSS style sheet. You open it up in your browser. Have you ever looked at that CSS style sheet and see what's happening? It's now calling, let's say you have two fonts. So you've got one that's for your body. Let's say you're using a serif font. And with that serif font you're providing a normal font size. Possibly you need to do like an italic with that. And then you're doing a bold. So that's three possible sizes that we have to deal with, styles. And then you're doing something for maybe a header, so a sans serif font. Same situation. Maybe normal, italic and then bold. So that's three. So that's six fonts we're dealing with. If you look at Google's style sheet that's six DNS calls that your browser is having to deal with. That's six outbound resources it has to go pull in and bring back in parts. So if I load it locally we don't have that situation. So and with this situation too, with this type of example, that's being pulled into that above the full content styles because it sees it. Especially like font awesome, you're dealing with that. You're having to call another CDN. We're getting rid of those. We're getting those roadblocks on. And your sys admins will love you because that's less bandwidth they're having to deal with. It's all right there locally. Any other questions? And slow me down I start talking fast. My southern comes out really quick and I start flying. And as I said the filament group there's a gulp version of this and I'll make sure I get you guys the links to all that. I'll put it up on my website. And we're going to talk about, I mentioned earlier about asyncing JavaScript. So this is something that we've all seen right on Q and R JavaScript files. This is something that I mentioned earlier. So this little word here where it says true this means we're going to throw it in the photo, right? Stop putting faults there if you don't need to. Please, please. Thank you. Sorry, and I move a lot. I'll just let you down. So this is the way that we will normally on Q and Javascript file. And we have a new filter as of, I believe this is 4.1 called the script loader tag. And what this allows me to do is a world of things. In this instance we're going to add a async option to a Javascript file. So what the first thing I do is we do a search for the handle. So I say if this is not theme script, please return the tag because I don't want to affect every other Javascript file that's being loaded on my site. That's being on Q. If that's the case just return the tag, don't break anything. After that we're going to do return script replace. And we're going to look for script. And I'm going to throw an async option in and then say hey, do this with the tag that I am calling. And then we add that filter. And I am able to then very easily add an async option to any of my Javascript files. I just use this with a client who and the reason I learned about this, I'm going to give props to one of our senior web engineers on my team on Mary Cadwell. She introduced this to me. We were working on a project for a client and they needed to load a Javascript file that had a data ID attached to it. And it needed to be the async. I'm like okay, so the way we do this normally is we do like add the Javascript file, like do script, throw it in WP footer. She's like yeah, but I got a better way you can do this. Let me introduce you to script loader tag. And she shows me, I'm like mind blown. Really, where did this come from? And I was able to pull the option that we added to their site options that had the data ID and then also async it, feed that into the script call and at the same time on cue their Javascript file. So I'm doing things in the native WordPress way. I'm doing things the way we should be doing it natively. And it also made me think about ways that I can go change things that plugin developers doing on my personal site. And make things async if I want to. This is a beautiful little tag that we can use. How many of you have used this before? Touch something new. Love that. Sorry, I decided when I get to do that. I love to pass the knowledge on. So tools to measure your front end performance. How many of you when you're developing, you're constantly looking at the performance of your site? How many of you maybe use a performance budget? Cool. Okay, two. That's good. That's good. How many of you know what a performance budget is? Okay. So performance budget is it's basically, as the word said, it's a budget for performance. We're looking at how our site loads. We're specifying what we want, how we want our site to load, how fast we want it to load. We're comparing it with other possible competitors. So if you're looking at, let's say maybe your ESPN, we would compare ESPN to possibly like Fox Sports. And they would be comparables. So we would base that performance on them and we would say, okay, we want this site to load in three seconds. I want the critical rendering path. I want the DOM to be rendered. I want the site to be rendered in this time. And we set that as performance budget. And as we're running tests on our site, that's our end result. And we're making changes based on that budget, based on that end goal. That's what a performance budget is. And these are some tools that I'm getting ready to show you that we can do that with also things that we'll be doing in the browser. So the first thing I encourage you to start using is your browser dev tools. One of my favorite options that Crom has is the timeline option. You can get a visual of how your site renders and paints. You can also see the blockers and the issues. But I also encourage you to break out of the Chrome bubble. A lot of developers use Chrome exclusively. And that's not fair to our user. We need to use Safari. We need to use Firefox. We need to use Internet Explorer. So, and not just Internet Explorer, the latest version. Older versions. You've got to think of all your clients, all your users. I have some projects that still have IE8 requirements. Very frustrating. That you have to still write code that deals with that. Especially when you're dealing with a lot of SaaS. A lot of JavaScript that does not always function well. How many of you are Mac users? You have no excuse not to be checking Internet Explorer. Go to modern.ie Get the virtual box or the VMware VMs for that. And start checking. Yes, it may eat up a little bit of your hard drive space. But that's okay. Your clients will thank you. Your users will thank you. And it'll make you a better developer at the end of the day. And yes, I know Edge is coming out. But with everything else that every other browser that Microsoft has put out, we're not guaranteed that it's still going to work right. We'll leave it until I see it. So, sorry. Test on all the things. While I'm developing, I test on multiple devices with multiple OSs. I have an Android tablet. I have an iPad. I have iPhone 5C. I have an older iPhone 4. I have a Windows machine. I have a now Raspberry Pi running Ubuntu. And then my VMs. This allows me to see what the user sees and experience. What they experience. I use tools such as XIP.io and browser sync with Vagrant to test against my local development environment on multiple devices. We should also test against multiple connection speeds. So, this makes me think of another situation Adam and I were talking about. So, at home I have a 50 by 5 connection. Really beautiful. It's fast. Not all my users have that connection. Contrary to what we think, there are still people that have dial up. There are still people that have that their only option is 3G on their phone. We have to test against those speeds. One of the cool things about a performance budget is you can do that. You can test against certain speeds. If you go to like web page test, you can choose a speed that it's going to perform that test against. So, we need to start testing against multiple connection speeds also. Not just how things are on your site on your connection at home. So, xip.io. Has anybody ever heard of this? Okay, so this is from the people who put out Basecamp. And what it is, is a domain name that provides Y-Card DNS for any IP address. An example is yourdomain.192.168.1.100.xip.io. So, what this is is your domain is what your local development environment domain is. This IP address is the IP address of the computer you're currently on. And then xip.io. So, it goes out, reroutes that, and you can now access this on any device that's on the same network that that computer's on. We tend to work with a vagrant environment called VVV. There's built-in support for this. It was added quite a bit of ways back. Now, when I say built-in support, that doesn't mean it's going to work for the local development instance that you set up. There's still work to be involved in that. One of the things you have to do is get into your engine x file. This is a scary thought for some people, but it's really not hard to deal with. Server name, local dev, asterisk, local dev, that way if I'm dealing with multi-site. And then, I can set this up. Local. All these little D pluses, this is looking for the IP address.xip.io. dollar sign. If you go to my website, I have a tutorial on how you can set this up using VVV step by step with files that you can just pull in off-get with some gist. Pretty easy to do. I use this quite a bit. Works really well. The other option I use is browser sync. Now, these two options, the reason I have two, xip.io versus browser sync is xip.io when I'm dealing with the large project with multiple developers where I may just be primarily working on front-end for theme, but they're working on plugins. This becomes a better resource for me because I don't have to deal with putting browser sync set up in every grunt file. This is set up in my vagrant instance. It's in my nginx file. I'm good to go. But if I'm dealing with just the theme, I'll use browser sync. This allows you to keep multiple browsers and devices in sync when building websites. Browser sync.io There's a lot of confusion on setup for this. I'm going to give you a little bit of information here. I'm going to be writing a blog post on my blog this week on how you can set this up using grunt. Pretty easy. Works really well. Browser sync. We add in a browser sync task. I say dev. It's looking for the browser sync files. It's the link to your CSS file. And then my domain. Your domain.dev watch task. I am watching my watch task this building to my grunt file. Pretty easy to do. And then I run I do like a grunt local. That runs up my watch task and my browser sync. And it opens up a browser for me and then I can open up that same link on any of my other devices. So what happens is in your terminal it's going to give you the URL that you will navigate to. And then I do this grunt register task local. I say pull my default which is all my CSS, my JavaScript. Do run browser sync and then run my watch task. Yes, sir. Yes. Yes, that's all. This is going to be the situation with any of these. You have to be on the same network because it's going to be looking within the network. Because you're going to be navigating to either a local host with a port or an IP address. Yeah. It would be really great if we could do it without having to do that. We haven't reached that point. You can also use something like Ghostlab is an option but the two options I just showed you, they don't require me to spend money. So I love that. Ghostlab is awesome though and it has a lot of these features built in. So, online tools. Such as webpagetest.org Google's PageSpeed Insights and SiteSpeed allow us to measure performance in live environments. We can also set a performance budget and track against it. Another great test site that I've been using is WhatIsMySiteCulse.com. Has anybody ever used that? It's actually it can actually hurt your feelings a little bit because you go run it and basically what it does is it will give you an insight into what it calls for someone to view your site on mobile networks around the world. You're looking at what it costs in America and you're like, this is awesome. Then you go look at a country where people are paying per gig or even sometimes in some situations per meg and you're realizing that the site that you've developed is costing them a lot of money. Which means they're probably not going to visit your site. So I encourage you to use tools like this when you're developing. WhatIsMySiteCulse.com WhatIsMySiteCulse.com WhatIsMySiteCulse.com So these are the online tools I said I use. Google PageSpeed Insights WebPagetest.org Insightspeed.io Google PageSpeed Insights is probably the one that most of your clients would use. It gives a good little like score and let's be honest we all like to get a score right? Most of us like we have some type of competitive nature and we want to get that 100. If you were to look at my site right now it's not going to have that 100. Because I've got some plugins that are loading up stuff. I'm getting ready to fix those issues. But my personal CSS that I've written, it's been prioritized. The awesome thing about Google PageSpeed Insights is it gives you a score from mobile and desktop. But on mobile one thing it does really like is it gives you a user experience score. So it tells you that you've got a 96 of a 100 possible with your user experience. And then it defines the things that are user experience issues such as tap targets being way too close together. Things like that. So run tests like this. And then WebPagetest.org This allows you to put in a URL. Run a test on your site. You can choose a type of browser. You can choose a location which will be a server location. And then you can also choose the speed that it's going to check it out. And you can choose how many continuous tests are going to be run on it. So you can say I just want to do one or I want to do six. And it's going to tell you what the load time is for the first test and then all subsequent tests. But it doesn't just stop saying your site loads at this. It tells you how long it takes before it starts making DNS calls. How long it takes for your site to render. How long it takes for your site to paint. And then it gives you this timeline and a breakdown of everything that is loading on your site. And that is scary in itself at times when you realize that I've got like 150 images loading on my site. And another cool thing it is you have a little check box that you can check and say I would like a video of what the user experiences. And you can watch that video of how that site loads on that browser at that speed and on the type of at that server location. So I really like that feature because it gives me real insight into what's going on outside of what I'm doing in my development environment. So I would encourage you to use that and then site speed I.O. Now site speed I.O. you can run some tests on their site. But they also have some grunt tasks and some gulp tasks that you can install and you can interact with page speed insights and web page test. You can put in API keys and you can run local grunt task against this before things actually ever hit a live server. So I encourage you to look at things like this. Check out some online tools. Use your browser. Let it become your friend. Test all the things. This is where normally you like put that all the things meme up. Test all the things. Don't write code without testing it and pushing it. Questions? Yes ma'am. Yeah, time to first byte. So that's the time to I'm trying to make sure I state this correctly because it's not the time to first render but it's the time between when your browser first it first makes that call it goes through. If you do an HTTPS it verifies that. It's that time to first byte the time to first that files are first being loaded and parsed on your site. I believe that's the correct definition for it. Yeah. Yep. Yep. Yeah. And that varies per if you so I was when I was making a transition on my site for hosting I was using a company I'm not going to name because I'm not going to go out and shame somebody but that time to first byte was like four seconds and it was driving nuts because I knew that my code was better than that and there was nothing that should be blocking it. I moved to another hosting provider where totally unmanaged and I set up my own server and set up how I wanted it set up and now that time to first byte is like point two seconds. Which means it's processing quick. So in some instances it's out of your control. Particularly if you're using a shared hosting environment and a lot of companies that's what they're having to use that's what they can afford that's what the everyday person can use. I mean honestly who wants to try to have to deal with setting up your own server? Who wants to deal with configuring engine X or Apache? So it's not always the code that you write that is that blocker. Sometimes it is out of your control. It could be a situation where you are on a shared hosting environment and there are also 7200 other sites that are being loaded on that too. Especially some of these where they say hey you can host unlimited domains and unlimited bandwidth and unlimited disk base and so somebody buys that and they're reselling hosting for $5 a pop and they're paying $5 for it and there's all these sites so that's a good question though. Any other? Yes sir. So I'll actually bring up a reference here. Let me get back here. So I just did a demo for dealing with the critical rendering path style sheets for our internal front-end team. One of the first questions I got is like is that CSS file going to be cached? The one that's being loaded loads CSS I'm like go to my website load the site up go to substitute page look at your network resources you're going to see if this is caching. So just FYI this will be cached. Caching wise so if I have the opportunity to use nginx and environment I can control I like memcache. And then there's a backcache plugin you can use Mark Jakewith has a new plugin out that it's like a helper for caching and I cannot remember what it's called right off the top of my head. I've got it on my site. But then you also can utilize things like w3totalcache some of the other plugins that are available on WordPress.org but if you do that make sure you set it up correctly because while they can be a help they can be a hurt if you don't set it up like it should be if you look and you dig through the like w3totalcache I use that on my personal site because I'm using Amazon's web services for cdn so I'll allow that to interact to pull files but it also will give you if you're using Apache it will give you the information you need to put in your hteaccess files and some instances it will do it for you it also will give you the information that you need to put in your nginx comp file so those things are very important caching is as good as how you set it up in the long run you can it can be as granular as you can do it let a plugin do it or you can make it as granular as you go in the extra mile and caching certain files for certain hours or certain day times so it's kind of a very broad range thing yeah so I would like to give you a better answer to that but it's a little bit difficult because there's so much but see me afterwards I'll give you my business card and I'll email you some links to even better resources yeah cool five minutes okay any other questions we have five minutes to go I'm glad Jason's helped me out with that because I said I'm very verbose I like to talk so I always need that helper yes sir what about images I like to use picture fill personally I like to use picture fill and set up either the picture element or use the image source set type option and load up different image sizes based on screen resolution there is a great plug in this available on dot org from the the responsive image group or community group and it's got picture fill built into it it's got the newest version of picture fill and it will do all that for you and as personally it's what I'm using on my site and then I go and I dq their javascript file and throw it in the footer and but it works really well what's the name of that footer um yeah I think it is it just it's responsive images see me afterwards I'll give you the exact name of it because I can pull it up in the browser and show you yeah but that's what I would do and so I do there's there's another cool um javascript um plug in called um lazy load xt and with lazy load xt you can lazy load your images iframes widgets also has a responsive images option too and we're actually using that on a project right now so we're getting the benefit of lazy loading images any other type of content that we want to lazy load such as um videos with a um responsive image option too it works really well yes sir I'm not sure of that because the the I haven't read that so I can't speak but I don't know why they couldn't index it because this content is still on your site all that lazy loading is doing is allowing it to become visually visible and loading that resource like the link is still there to it but it's not actually loading that resource until the time is there until it's ready for it so I can't speak as to if that's the actual case as far as what google is concerned with it now I could see that I could see that being a an instance um let me give you my card and I would if you have that link I would love to see it because that that's something we would have to think about definitely but I mean at the same time lazy loading can be your friend if you're dealing with content I think personally like my site and then client sites that I'm working on we have lazy loading setup especially if you're dealing with sites that are for publishers where they're loading up a ton of content and ton of images the image does not load either in some cases which I don't always like this case from a user experience perspective as the image like fades in as you initially start seeing it so I like to say let's start that load 50 pixels before it becomes visible on the browser and so the user knows no different but from the side of development and systems we're not loading up the content initially any other questions yes as far as like javascript so I say that I wish um developers would put all javascript in the footer but the truth is that cannot always be the case there are some files that need to be in the header like we need that in order for content to work but what I'm doing is and I wouldn't say do this for a client unless it's something that you've tested thoroughly is I set up from like my site I have what I call core plugin and that core plugin I'm looking for the CSS and javascript files that are being pulled from plugins and I'm dequeuing them and deregistering and then I'm loading them with this load CSS option where that link is being developed and added and then javascript files I'm putting it in WP footer because if I don't like I said if I don't need it why do I need it to be there to be parsed and if it already is being loaded in the footer then I'm just using like script loader tag and I'm asyncing it so that it's not be considered render blocking but you have to test all that thoroughly I test all my stuff very thoroughly locally before I ever touch the server and I have a staging environment too sorry that's not like this is what you should do it's a case by case basis and you run the risk of also why I say thoroughly testing you run the risk of breaking something so you have to make sure you test it thoroughly any other questions and with that the reason you want to test it thoroughly and it could be an issue if you have a deactivated plugin and forget that you've done that now you've got a 4-4 possible issue too ok thank you very much