 everybody. How are we doing? Right. So, as Steve mentioned, my name is Mara Teal. I am a software developer at a company called Pagely. We do managed WordPress hosting. I am also working on our new platform called North Stack, which is focused on a serverless hosting platform for WordPress and all other sorts of sites. So, that's going to be really fun. We're kind of getting into the beta process now. But I really look forward to getting your feedback on it when the day comes that I can let you all into it. So, we're talking today about optimizing all the things. Now, how many people here are site managers? Okay. And developers? And none of the above. Okay. Cool. So, we've got a pretty good mixture here. I gave this talk at YoastCon, which is an SEO conference. So, part of this is going to start out more on the site management level. And then we'll get into some more heavy development type of concepts. So, I look forward to any of your questions at the end. I think we'll maybe focus a little bit on the Q&A, depending on what type of questions come up based on my presentation. And with that in mind, let's talk about what we are optimizing for. Who we're optimizing for? Why are we optimizing our sites? There are a lot of different answers to this question. Today I'm going to focus on bringing things to your attention that you could pay attention to on your site. So, not necessarily explicit examples on do this, A, B, and C, because every site is so unique and so different. Everyone's use case is so different. You might only have management level. You might only be able to add or remove plugins to your site. Or you might have server level access to change your setup. With that in mind, I want to give you some tools on different areas of your site you can assess to improve your site performance and optimize it. And first and foremost, what we're optimizing for, what we're usually all at word camps for, is for business. A lot of times we want to increase revenue, be that via ads, via views, getting paid for articles that we might write and want to post or different restaurant reviews, cat pictures, the like. We want to increase revenue. We want to get paid for our sites. We don't want to have to dump a ton of money in and get nothing in return. And we want to retain users. We want people to go to our site not once, but twice, but three times. We want them to keep coming back. We want to build trust with them. We want people to click on one page and then view the next, and the next, and the next. We want them to build a rhythm of going onto our site and staying there, not just bouncing out. Finally, we want to stabilize our hosting costs. And this is something that early on might be a little bit tougher to think about. If you have a smaller number of users on your site, if you have a smaller number of visitors, as you grow, your site performance becomes more important, because you're either going to improve the performance of your site, or you're going to pay more to throw hardware at it and pay more in your hosting costs. So keeping in mind site performance and optimization the whole way through is really important, not just for increasing revenue, retaining users, but for stabilizing the costs that are there, that are hard costs. You have to pay for a server to host your site. You might get away in the beginning with a $5 digital ocean server, but down the line, as people start visiting your site, as bots start crawling your site, as your site starts getting indexed by Google and it becomes more popular, you're going to have to think about that performance, because you need to be able to handle serving that site up to more users. So that brings me to my next point. We're really optimizing for humans. That's what this whole talk is about. That's why we're here. Our end user isn't necessarily a robot. If it is, let's talk later. I'm curious as to what you're doing. But generally we build our sites for humans. We want them to visit. Got a little ahead of myself. Let's see. I wonder if I'm out of range. There we go. Okay. So with humans in mind, we want to think about accessibility. It's a weird thing to be saying, oh, yeah, I want to optimize your site for performance. I want your code to run better. I want your site to be more accessible. Now that means that we're talking about the location of your site. We've got servers all over the world. And your user base might just be here in California. When you've got to host your site on a server that lives in Virginia and someone visits it in California, there's more time that it takes to transfer that data all the way from Virginia to California. So if you think about moving your site to a server that's closer to your user base, you can actually get a performance improvement right there. Let's talk a little bit about kind of the advanced level of it. But additionally, we're talking about improving our site and improving the performance for people who might be on limited data connections. If you're utilizing an older device that is slow to be able to load stuff, it might not have gigabytes of memory to perform all the JavaScript events that you want performed to load all of those events and play that auto-playing video. That might bog their machine down. And when you end up bogging someone's machine down, they lose trust in your website. And that brings me back to the business point. You want to retain users. And you retain users by building their trust in giving them interesting content. So that does kind of lead me to the next bit, which is what are we optimizing for? We are optimizing a little bit for search. We're going out there in the space world. The Googles know what we're up to. And search engines tend to crawl sites. And this is a lot of the time how we get new users. These bots, like I said, maybe you're not developing necessarily for humans. You might be developing for Google's AI, for Google's robots to crawl your site and see it. Google ultimately leads you down the path of getting users. So we want to assess the performance because search engines assess the performance of your site. Search engines ultimately want your site to be more accessible by humans, because that's their customer as well. Something to keep in mind there as we go forward. So where do we start? Well, there are several tools that we're going to talk about today. Google PageSpeed being one of them. We might want to assess the performance of our site. And these are some ways how. So we've got some tools like GTMetrics, Kingdom, WebPagetest.org. All of these things provide some metrics. So basically you visit the website, you enter a URL in, you enter your homepage in, and you get data back on how long it took to load, how many assets there were, how many assets were slowing things down even more, causing confusion and delay perhaps. It should be noted though that only the first three are free. I believe GTMetrics has a paid option as well. And Pingdom is only paid. They might have a free trial. But Pingdom provides some additional information that you might need later down the line. So I might recommend it again later on in this talk. But essentially what you can do is enter in your site there. And I have an additional note on those, which is the last three, GTMetrics, WebPagetest and Pingdom allow you to choose a server location to test from. So again, say your user base is in Canada, right? You live here in SoCal. You might want to test the site from a server closer to where your end user base is. And you want to be able to tell the testing service, do your tests all from this location. PageSpeed doesn't do that. They're kind of vague on what you're getting. But it will still provide some really useful insights. I want to take a moment and pause here and talk a little bit about the phrasing I'm using. So what is PageSpeed versus what is SiteSpeed? They're generally kind of used interchangeably, at least by me. And what we're talking about when we're talking about PageSpeed is that time to the first byte that the page starts to load, and then the complete time one single page on your site takes to load. SiteSpeed, as one could probably surmise, would be the collective average page speed based on multiple pages on your site. So that overall concept of how long your site might take to load on average. So this is a screenshot from webpagetest.org. And those are some performance results. And you'll see I've got an F up there. That's just one of the drawbacks of some of these services is it doesn't always know what's going on under the hood. This is surface level metrics of when your site loads. And you can kind of see that diagonal line. That is the waterfall view of each asset loading on the page. So we're getting some really interesting metrics. And based on those metrics, we can make some adjustments maybe to our site. Maybe we can say, oh man, I have a giant header image that's causing a really big gap in that line, in that waterfall. Do I really need it? Or do I want to have people be able to see my site sooner instead of hindering what they're viewing? And this is a view from Google PageSpeed metrics. So again, two free services that are pretty easy to use so you might as well compare against both of them. They'll have slightly different suggestions based on what they think is most important. And if you go to Google PageSpeed, put in a website and scroll down a little bit, specifically there's a section called Opportunities that list out explicit things on your website that you could perhaps improve to improve your performance in PageSpeed. So serve images perhaps in a different format. All of the images on my site I think are JPEGs because I'm too lazy to change them over to WebP and deal with supporting them. And I've got some cobbler shoe syndrome with never updating my own personal website. But using more modern image formats can greatly reduce the time it takes to load your site if your site is image heavy. Using those modern formats means smaller file sizes, which means that poor person on a 3G connection doesn't have to sit there as one image loads on the screen. That might take half the time with modern web formats. So where do we start? Where do we even go from here? Well, I want to start on the server personally. There's some interesting information out there about PHP versions explicitly. There's been a big push recently in WordPress to bump the minimum version from 5.2 to 5.6 where PHP is that underlying set of code that runs your WordPress site. It's kind of an important aspect of how a WordPress site runs if not the primary aspect. So PHP is important and even if you're like, whoa, whoa, I don't want to get into the code, you should still have an understanding of what your site is running. Ask your web host. They might have plans to help upgrade people. It's always worth exploring because I believe it was like in 2015 we started prepping for the change from PHP 5.6 to PHP 7.0. That was coming out soon. And Aaron Durbin actually did a lot of speed testing. He's a core contributor. And in these speed tests he found that site speed improved like 50% or it doubled. I'm sorry, I'm not good with numbers. But it doubled the speed and performance of the site just by upgrading the PHP version. And there weren't many drawbacks. There are especially not many drawbacks now. Everyone says, ooh, I'm afraid to upgrade. I might get errors on my site. Everyone's pretty prepared for it by now. We're talking about metrics from 2015. So there is no excuse for your site to still be on a version of PHP 5. PHP 5.1, 5.2, and 5.3 have all come out since then. PHP 7.0 isn't even supported anymore. So you should be running 7.1, 7.2, something at least up to that. So there's no excuse. We're also working cores working on a white screen eliminator that will help deal with upgrades that might break your site and give you that white screen of death. So there are many things going in place to help encourage people to be less afraid to update. You should update your site. You should check your PHP version because not only were there speed improvements from 5.6 to 7, but there were speed improvements from 7.1 to 7.2 that you can take advantage of just by saying, hey, will you update the PHP version of my server? Very little work to do otherwise. There we go. So, enough about the server. Let's go back to Frontend Land a little bit again and talk about using a content delivery network. Remember earlier in my talk, I mentioned moving the server closer to your end users. Moving that information closer because if I have to get information from here to the back of the room, it is going to take me longer than if I'm passing information between me and someone in the front row. Same concept with the computers. You're increasing that time that it takes to deliver information. And there are some wonderful free services out there like Cloudflare that can provide a CDN for your site. That can provide this giant network of servers that your information goes out to and then they'll serve it. That can also cut some costs a little bit because usually CDNs, because they distribute so much data, they've worked it out so that they can serve it for cheaper than perhaps your host serving from their one data center that they own and have to pay the electricity bill on. So it's something to keep in mind. We've got services like Cloudflare, Securi offer something, CDN network, Fastly, Pagely uses the Amazon Cloudfront service which provides that same Amazon infrastructure but content distribution for not only your images and your assets but full page caching. Full page caching is an interesting concept. Last year I was doing a whole talk just on caching so I'm not going to go too crazy with it today but full page caching is neat because what it does is it takes the end result of something, of a page load, takes all that HTML that PHP renders from the back end on the server level and says okay we're going to store this tiny little snippet of HTML, this resulting information and serve it to a bunch of users. We're going to reuse it. So instead of having to slog through and do a bunch of well if we're on this page and we have this related content that we need to couple together and ultimately output an HTML page we skip all of that processing time. We reuse it. So full page caching is extremely useful especially if you have a more static type of a site, a site that's meant to just deliver a bunch of content that might not change super frequently or isn't based on logged in users. Logged in users tend to need to see more dynamic things based on the permissions they need to access so you have to run PHP a lot of times to assess what access they should get and what they should be seeing. There are ways around that as well but there are a couple of CDNs that offer this, full page caching Cloudflare is again one of them, so is Amazon Cloudfront just naming a few. If you Google it you'll get a ton of information and then we've got WordPress plugins like W3 Total Cache WP Supercache, WP Rockets. There are so many out there that I haven't even kept up with that are really wonderful and available to you for free. So it's always something to keep in mind with. But you also have to keep in mind that e-commerce does not necessarily fall into this bucket of cash all the things. Because people need to have dynamically loading pages they need to be able to add things to their cart see live updates perhaps on what you have in stock. So e-commerce especially when we're talking about taking payments is not something that I want to go with full page caching for. I might want to cache chunks of information. But once you're at that level there are going to be more options out there. You just have to dig a little bit deeper and get a little bit more advanced. So let's talk about image optimization. What's out there? As I mentioned earlier image optimization is something that's incredibly important. That's something that showed up on my screenshot earlier. I know it was pretty small. But it showed up on my screenshot earlier of my own personal site because I'm not using formats that are super modern for my images. There are new image formats out there like WebP that might be better suited for images that you need to serve out to a ton of people that are larger perhaps. Or perhaps you shouldn't even be serving an image at all. Perhaps if it's something very simple you should be serving up an SVG that is a drawing essentially on the page that the browser can render instead of having to parse out pixels on its own from an image like a gif or a ping. These are all things that we kind of taken into account when we're talking about image optimization. Another thing I want to mention about image optimization is that you should be using something to compress your images. We're not just talking about formats when we talk about image optimization. We're talking about compression because there's a lot of extra data that goes along with your images when you shoot them on say your phone. You might have location data. You might have authored data. There might be extra information about what's in the shadows perhaps. Your camera captures so much that our naked eyes don't even always see. And when you're posting images on the web, we don't need to post all of that extra information. That just bloats the file on your device. So instead, we put them through compression engines. We put them through, there are some services like WP Smush, E-W-W-W. There is a service called Cloudinary. Some of these will work directly on your server and some of these will send your image over to a secondary server to their own servers and run them through and process them to better squish them and compress them without losing too much quality. Because sometimes you can get pixelation if you say I want to compress the heck out of this. Look into those services, especially if you are doing a photographer's website perhaps, because that's where you're going to see the most savings is serving up images that have been properly compressed, that are properly sized for a user's device. There's no reason I should be sending out a 2,000 pixel wide image to someone on an older iPhone, for example. That thing is not going to show up very well and it's just going to take forever to download and it's just going to piss off my end user. So I'm going to make sure to compress and thoughtfully manage those images. So you saw a little preview of this already. Let's talk assets. We're still in front of Inland, right? So we've got a bunch of assets that load on a website when someone hits our page. We've got JavaScript. We've got all of those images. And we want to optimize for that by limiting those frivolous scripts. WordPress plugins get dicey with this. Say you have 50 plugins and everyone says, oh, well isn't that bad for your site? Isn't that going to slow it down? Well, yeah, if each plugin is loading 10 scripts on every single page even though that plugin's widget doesn't show up on every single page. So it is something to consider. Each plugin might come with its own little snippet of CSS. That's something that we can concatenate into one bigger file if we're clever with our development and engineering. So image optimization is important. Or asset optimization, I'm sorry, is important. We can also do something to compress those external assets called minification. A lot of JavaScript files and CSS files have a lot of white space in them. As developers you like our code organized, but the machines don't care. The machines could care less that there is nice indenting in white spaces and really verbose variable names. So say you've got a JavaScript file, if you run it through minification, we can adjust some of the variable names that perhaps aren't used elsewhere. So the variable names go from my special variable to A and B and C, for example, and cut out extra bytes. So the end user doesn't have to load unnecessary bytes just for their machine to be able to process and output what we want it to do. So we turn out all of that white space. And some of this is kind of starting to get into the nickels and dimes of things. Perhaps you want to make sure your site is finally tuned and running as well as possible. This is where we get into the minification. And this is usually something that Google PageSpeed will recommend if you haven't done it already. So keep that in mind. There are a lot of times big things we can do. This, to me, tends to be a smaller thing, but a very important thing that you might as well check the box off and do this asset optimization. So where do we go from there? We've got our PageSpeed metrics. We've got our information from webpagetest.org. How do we assess that data? Well, I would recommend utilizing the Chrome developer tools. Firefox also has a great set of developer tools. And even if you're not a developer, it is safe to go in and look at these tools and play with them. They're not going to edit your actual site. What you'll want to do is right click perhaps on an element or go up from the file menu and do inspect elements. There is a keyboard shortcut. But off the top of my head I'm forgetting. I think it's Alt-Command-I, Shift-Command-I, something like that. And you'll see this bar pop up either in the bottom or the side of your screen that has a bunch of little headers. It'll show you all of the HTML, the DOM elements that are in the site. And then you have these great two tabs that I basically live in when I have to assess things on the front end called Network and Performance. And that Network tab provides this beautiful waterfall. So if you hit Reload on a page you're going to see each asset pop up there as your server is requested as the browser says, hey, I need this image. Can you start downloading it? You'll see a nice little bar that says the time it took to request it from the server and then the time it took to complete the download. You'll see that cascade as the entire page loads. It's pretty wonderful if you want to get into some of the nitty gritty. Or perhaps you're saying, okay, well, I minified all my scripts and I tried to serve up all the best images I could. What is taking everything, what's taking such a long time to load? I can't figure it out. I sit there, I stare at the page and it just sits there. It takes three seconds and then finally starts loading. Using this Network tab will show you those pauses, those hanging points. Perhaps there's a script that is being told to run synchronously. It's what we call a render blocking script up in the head of the site. This script tells your browser, okay, this I want loaded and you can't be loading anything else during this time. Again, it causes some confusion and delay potentially. There might be some sort of reason why the developer said load this synchronously, not asynchronously. So we always want to be careful with if we're modifying that. But again, as a developer I want to know these things. I want to be able to assess them and using the Chrome developer tools is generally how I go about that. Let's talk a little bit more on the advanced mode. We're starting to get into server stuff. We're starting to get a little nitty gritty here. Not all SQL calls are the same. I kind of want to start with that. We have our WordPress setup. It's based on this MySQL database. We make queries to that database. Those queries are calling for posts. They're calling for related posts. They're calling for tags. They're calling for categories. They're calling for meta that's additionally related to a post. And we're doing all of these as PHP runs. And say you have a lot of logged in users on your site. In the administrative area there are usually even more queries that we end up doing against our database. So we want to assess what's going on. We want to assess how many queries are happening. And there's a great plugin by John Blackbourne called Query Monitor. It's a free plugin on WordPress.org. And this free plugin allows you to see what plugins are querying what things from the database. That's wonderful because you can say oh, I just added this plugin. I don't know what's going on with it. My site slowed way down. When you're logged into the site and you're looking at this query monitor plugin, you can say oh, that's querying for all of the users. And I have thousands of them. I only need one person. How do I pull that data out? Maybe you need to cache the result from the database. Maybe you don't need to combine all of that information. A lot of times getting into managing SQL queries comes if we have control over our code base. So it's much harder to manage from the third party plugin aspect. But it's also wonderful that we work in an open source community. And therefore a lot of times as a developer, if I find a query that runs super slow because I'm managing a large website and I found this out the hard way, I can actually make a pull request. I can make code suggestions to other people managing other plugins. And we can all work together to improve the performance of the internet. So not all queries are created equal TLDR. You should check into that. But you should also use indexes. So PostMeta is this funny table of information. And it all has its own unique index with a key for every single PostMeta item. And then it also has the exact post that it relates to. So we've seen a lot of performance challenges with very large sites of page lead where someone's querying perhaps for a lot of PostMeta or a lot of related tags or categories. And adding an index to that table. Telling my SQL, okay, not only is this one index column important, but this other one is too. You should take your time and go through that data and be able to query against this column as well. Improves performance sometimes tenfold against specific queries. So not only are your queries important and you should assess them, but you should also consider what tools you have. If you can't modify the queries themselves, you might be able to make a modification on the explicit table. These are kind of digging deeper. So we're getting into the server, right? So we've got the server level stuff. This is just something I want to go pretty quickly over so we have a little bit of QA time. But essentially, excuse me, we've got a linux setup. That's the most common setup we have for our WordPress website. And it might be running Apache Engine X to route the traffic within your server. My favorite is generally just Engine X only. You could have a combination of Apache Engine X, you could be utilizing any sort of setup. But that's generally my favorite. There's an additional, there's a newer product called Engine X unit that we're utilizing on NorthStack, but I'm pretty excited about. But your server setup is something you could assess. Generally, Engine X to me is considered faster, but it also depends on what type of redirection you have set up. You've got that htaccess file, perhaps, doing specific routing that might be slowing things down. I want you to consider the performance of your server setup itself if you can, if you can dig that far. You might end up down this crazy rabbit hole of like, this is the best setup I've ever messed with. Or maybe tweaking this one thing makes all of my pages load 300 milliseconds faster. There's a lot we can kind of do with that. And finally, I've already harped on this a little bit, but the physical location of the server could be useful. It's a little tough in California, to be honest. At least I only work with the Amazon services, but I know that the West Coast generally has higher server costs than say if you want to host your website in Ohio. So it's kind of this cost versus performance balance. Again, we want to deal with hosting costs as best we can, but perhaps if you have a lot of traffic that's all in San Francisco, it's worth paying the premium price to host your site on servers in San Francisco. It makes you look better, it makes your client look better, it keeps people on your site because things might load just a little bit faster, so they're not as quick to click away. But location is always something we can kind of assess and check on. And to do some of this server-level assessments, I'm going to give you a couple of tools. My absolute favorite is New Relic, is generally considered this paid enterprise-type level tool. A lot of hosts will install it for you if you ask them to and pay for your own account on it. But something I recently discovered is a service called Datadog. It seems like it could give you similar metrics. Essentially what it does is it watches all of the queries, all of the server-level information, all of your MySQL queries on your WordPress installation. It gives you feedback, it gives you numbers, it says this is slow, these are all errors or warnings that are getting thrown, and lets you keep an eye on that. And it keeps all of that information in its own database so that you actually have metrics over time. You say, okay, this is the day I installed that plugin, or this is the day I updated that code. And can actually see the physical changes on it. And I'm going to give you a couple of tips. First of all, when someone visits your site, how long does it take to load? A specific page even, you can drill down. So Datadog does have WordPress-specific integrations, which I like. And it should be cheaper than New Relic. I don't want 100% vouch for it, but I do want to suggest you maybe look at it if you've looked at New Relic and thought, nah, that's a little too expensive for me right now. It lets you see other server-level metrics. It takes a lot more advanced setup, and you can explicitly filter based on different queries. You can look at PHP workers and the performance of those. You can perhaps look at your WordPress cron jobs and see if something's taking over and causing the server to hang. It provides a lot of interesting tools, and it's a free open-source option if you're really into server-level information and metrics. So I want to make sure to mention that. And along those lines, once we get into this advanced mode of scaling, I'm going to gloss over this a little bit, because I want to make sure I have a little bit of time at the end. But essentially, there's scaling that you can do when it comes to a WordPress. Once you get to a certain size, you might be taking in hundreds of thousands of visitors. Say you are running an e-commerce site. You might have a Black Friday sale, and your site needs to scale. It needs to grow. It perhaps needs to run a lot of time. It's a little bit more than a lot of time. So I'm going to look at what's code running on more than one server so that you can route traffic and deal with processing everyone's visits. So we've got horizontal and vertical growth. We could potentially run our database also on two servers if there are a lot of queries against it. Generally, I don't advise this. It's a dicey setup in some ways, but I don't complicate the data over. Generally, I focus on running the PHP and getting the performance out of that with running multiple servers and directing traffic there. So I wanted to make sure to mention there are lots of things you can do with hardware and setups. But again, you should have checked all of your boxes on, is your PHP even performing well? You can assess that with query monitor. You can assess that with New Relic. You can assess that just even watching the times go by in your browser as you attempt to hit a page. You can also assess it with unit testing. And that's a whole other talk in itself, too, so I won't go too far. But I'm going to say the word unit testing. I hope that the developers in the audience remember that. And finally, when I'm talking about scaling and when I'm talking about server location, I should talk about performance versus reliability. Because all of us want our sites to load quickly. We all want our sites to perform the best. We all want people to hit our site and be like, wow, that was fast. I didn't even have to sit there and wait. It just, boom, was right there. But there's a little bit of stability we should talk about. There is this concept of horizontal scaling and there's a concept of keeping your database on the same server as your site itself. Again, don't forget, your site needs to talk to your database so there are some milliseconds of delay as this communication happens. And if you move your database off to its own server, it has more resources to perform its own operations, but then there's more latency. There's more time in between that those two things need to talk to each other. That is considered bad for performance, you could say, but it creates a sense of stability. If something were to happen to the PHP server to the site that's serving up the code itself, if something bad were to happen, your database would still be intact. That's all of your information. That's your users. That's your sales. That might be additional metrics. That's all of your content. So we have this dynamic of performance versus reliability that I wanted to make sure to mention and share. We've also got a concept of premature optimization that I'm not even going to cover today because I'm running a bit out of time. But you should be optimizing your code and commenting your code. Sometimes you're optimizing your workflow more than you're optimizing it for the end user. So what else do you do? Monitor the performance. This is where I'm going to bring up Pingdom again. Remember that's that paid service. It will actually monitor the performance of your website, which is a pretty wonderful thing. You can go there and have historical data on how your site's been performing. GTmetrics will provide some of this monitoring for you as well. I believe that's a paid service, but they might have some free tier stuff in there as well. Consider third party scripts. Consider ad scripts that you might be running. Analytics scripts that you might be running. All of these can impact the performance of your website. So now I want to give a little bit of time for questions. I don't want to surprise you too much, but maybe hopefully we have, we have two minutes if anyone has anything in mind. Questions? We did scare you. I have to, uh-oh. Okay. As far as optimizing images, obviously the trend and the big thing is to have, especially portfolio sites or anything else is to have hero images. I'm sorry, I can't hear. You can't hear? Oh, sure. God. Hero images. There we go. You know, they're, they're big. They're colorful. They're, they're, you want them sharp and your portfolio, you want it sharp. Well, that makes a weighty picture no matter what you do. And so I don't know if there's a magical number of kilobytes that you just go, no, you just can't go over that or not. Or if it's just, you just got to get as low as you can and forget about it and, you know, not sweat it. So. So I did get that. So the question was, as far as image optimization, is there some sort of magic number of kilobytes? Say you've got some big hero images, some header images. You want them crisp and clean. You want them to look high quality. Is there something that we're specifically striving for? And I would say, no, absolutely not. There's this kind of gut feeling that I go with. Like this is what I could live with. And actually in your Chrome developer tools, if you want to test out someone who might be visiting your site, what it looks like for someone visiting your site on a slower speed, it has an option to toggle your speed and throttle it so you can experience the site like someone else might. So it's all, it's all thresholds that we kind of set for ourselves. And I would also recommend having alternative image crops or sizes that display on different devices. So there's no reason, like you might have one image size that shows up on a big desktop monitor, but there's no reason to serve that same image to someone on their mobile phone. That's time for one more question. Over here. So in your experience with regard to optimization, what is your trigger point for time to first bite and time for homepage full delivery? Okay, so what is my trigger point? What's my time between time to first bite to full page delivery? And frankly, I don't have one. I didn't even get into it in this talk, but managing DNS and having fast DNS resolution times are extremely important. So I would consider, it's all in what you think is a good threshold. I would run off of what PageSpeed even tells me that anything over like 300 milliseconds feels excessive, extremely excessive for that time to first bite. But frankly, I haven't been doing front-end development lately, so I don't have specific thresholds at the moment. We can chat later, though. All right, give it up for Maura. Big round of applause. I'll be at the after party if you want to find me.