 I'm Erlin from Serbolt, I'm the CEO and I'm also quite skilled developer, so I know my share of code. I've tried to keep most of the code out of this, but there will be a few lines. Serbolt's company started about five years ago in Norway, it's my company and the idea was okay, I hated slow websites and websites were just getting slower and that is still a thing or actually it's much worse today. And we started expanding abroad last year, so now I'm here to set up our services here in Singapore and have this talk, this is my first thing in Asia ever, so this is going to be fun, let me see if this works, okay. Okay, the internet is slowing down and that's a very much still thing, people are moving from low latency fiber connections at home to mobile devices that are much slower than their desktop computers, frameworks are growing, WordPress is growing, JQuery is growing, everything we plug into it is growing. So the volume of everything is growing, images are larger, everything is still growing and it's getting slower. The problem is also that computers, they haven't been getting much faster, they have become more scalable the last years, but in terms of the processing power they have to spit out a web page right when you want it, that hasn't improved much, it's a question of like 40-50% over the last few years. So e-commerce is kind of a big thing that has triggered our company to where it is today because time is money and having a slow e-commerce site is guaranteed to lose transactions, okay, people just leave. And for all the other users on the internet delivering a fast experience, delivering a web page right away at the click guarantees a good experience. So faster performance is good for everyone and every website can load in a second. How many of you have a website that loads in a second? No one. One hand, okay, it's probably static, right? Yeah. Okay, from my experience when people start working with optimizing WordPress and trying to make it faster, they have a lot of hope in things they are trying out. They believe that, okay, if I do this, maybe it's going to be fast. But there are laws of physics, okay? There are slow things and there are fast things and this doesn't change. It doesn't change with the plug-in. If something is big, it is slow. If something is a lot, it is slow. And long distances, that's kind of why I'm here because, okay, delivering hosting from Europe and trying to sell stuff to Singapore or other people in Southeast Asia is just stupid. So this is our current map. Singapore is coming up and running this week. The rest is very much working and we have customers basically all over the globe, also here in the region already. But they will get improved performance now that we are local in Singapore. Okay, more slow versus fast because there are a few things. Old hardware, old software, old PHP is obvious. It's a lot slower than the modern counterpart. Same goes for slow CPUs, slow databases, or an unoptimized hosting stack. And that is, this park here is very much of what we do. Okay, this is what you get from third world. You get the latest and best and the fastest. But the rest is stuff that you need to take care of yourself. Okay, many plugins is slow. It will always be that way and few plugins is fast. A poorly coded theme is slow and a specific theme that is just exactly what it is supposed to do is fast. So the last part here is especially something. The first talk I had about our product or about surbolts then called it is called fast pages in the region. I spoke a lot about errors and keeping an eye on the error log because handling errors is something that takes time. And that's true for PHP. It's true in the web browser. It's true for JavaScript. It's true for everything. So having a lot of bugs, warnings and exceptions will slow everything down. Okay, this is basically what's the difference between surbolts and other hosting companies. What most people do is to, okay, they provide a nice interface that makes it easy to install WordPress and get started and get your code out there. And then they layer caching on top. So what we have done is we do things on the network level. We maintain or we backport a lot of code and maintain our own Linux distribution. And we compile our own PHP and now just with the latest release of PHP 7.3, we got a 70% performance increase over PHP 7.2, which is quite hefty. And, okay, all these small percentages is what we have been hunting for five years now. And that also means when it comes on the database level that we, okay, we process two to seven times more queries per second than a normal web host does. Okay, there is a difference between performance and scalability. Okay, performance relates to just how fast that single page loads. And scalability is more about how many of these pages can we load at the same time. And the dynamics between performance and scalability are that, okay, improved performance will also give you improved scalability, but it's not the other way around. And if you increase the scalability, usually that goes at the cost of performance. So if you add more servers to do the same task, it will be slower than if you do it with one computer. More slow versus fast. I call it a misunderstanding because people do this all the time. They think that, okay, if I add another server, it will become faster. That is not the case. So virtual servers, they are slower than real servers because you spend energy virtualizing. Server clusters are slower than single server setups. Okay, they can handle much more traffic, but they are slower. And complex hosting setups, they are usually much slower than simple hosting setups. This is a real-life example. MyThemeShop, it's quite large shop. They have a lot of traffic. And this runs on standard Bolt-on-ZeroBolt. That is basically what you get if you sign up and buy the cheapest package. It's processing more than one million PHP hits every day. So that's, okay, it's continuous traffic. It's on Alexa top 30,000. And it does not use load balancing. It does not use a database cluster. It does not use a computing cluster. And on Black Friday, what happened was that they had some problem. They had a campaign running, and it wasn't updating right. So what we had to do was to switch off their full-page caching on Black Friday. And that worked perfectly without any problems other than it spended somewhat more resources on the server side. But for the user experience, it was pretty much the same. So no one got hurt, and it worked out perfectly. This is a quote from Patrick Menon, and he says that the server response time for the HTML itself is often the biggest problem and the hardest one to solve. And in the time to first bite, there are a lot of things that go into that. Like, okay, redirects, DNS, connection setup, SSL. But PHP is usually the biggest part of it. And fixing that is exactly what we try to do at Serbolt every day and what we try to address and speed up. Some of it can be fixed easily by using a service like CloudFare. But when it comes to the PHP and the database queries, you need something that does it the right way. So for us in Serbolt, Web Performance is all about the response time for the HTML. That is what we spend our energy on. So what do WordPressers usually do when they have this problem, when the response time of the HTML is low? That is what I'm going to spend the rest of this talk on because people tend to try caching. And there are in WordPress two types, or you have internal and external caches. Transients is a nice thing. And the external ones, okay, page cache and query cache, redis and such, we'll look into everything. Transients first. How do transients work? How many of you are developers? How many are using transients? Okay. Transients, they are basically good. But it's super simple. What you can do with them is to take a small part of something, wrap it in this code, and it stores it in the database so it can be used and be faster the next time something loads. You can store anything. So you can take a small piece of a page instead of taking the whole one. And it works without any external components. So it's just plain WordPress. And it can be auto-loaded. That's an internal mechanism in WordPress where the option stable is loaded and everything is just available. The problem is that, okay, for on-slow web hosts, this often becomes a problem because it stores everything in the options table. And the options table is much like WordPress registry. So if that table grows large, it can become slow. There's not much of a problem on our hosting, but it is a very common problem. So watch out for that. It's important to set an expiry date because then stuff will be cleaned up and it won't just grow out of proportions. And, okay, it can be slow if you are using old technology. WordPress Core comes without an index in the database. This is an index that just has to be there if you want WordPress to perform and you have a large options table. You can either just run this as an SQL query or we have a plug-in, the server optimizer, which does this for you. It's super simple and if you have an options table with like 50,000 entries, you will feel the difference if you are on slow hosting. So just do it. It does hardly use any space. It's just crazy that it's not default in WordPress. Okay, page caching. The caching user story. You see that the site is slow? Then you, oh, you Google, sorry, Google for a solution and Google says caching. Caching will make your website fast. Find a good caching plugin or a more complex caching mechanism, install it and configure it. The front page, a couple of times, and voila, the front page is much faster. You test the front page from Pingdom. Okay, first test was maybe not that good, but okay, let's try again. Second test, yes, bingo, this is fast. Let's hope it is like this for everyone, right? So how does this work? You send a request, checks if it is cached. If it isn't cached, it has to ask WordPress, which returns it, stores it in the cache, and then delivers it. Okay, and the second visitor that comes, instead of then querying the backend, we already have it in the cache, so these buttons are hard. And then it just returns the page directly. Okay, there are some things that cannot be cached, and we use admin Ajax to kind of work around that for dynamic elements. But does it fix performance? This is a tool we use, it's called Cyple, which can crawl the full web page. Okay, what most people do is, they use Pingdom, they use web page tests and such tools, but those tools, they test just one page. You test the same page and you test it over and over again. These tools allow you to crawl the full site and check how is performance across my whole site. And this is a major magazine that's using full-page caching to fix performance. And as you can see, there is a very small slice here that's actually fast. But we tested 1,500 URLs, and 81% are super slow. So it isn't working. Yeah, okay, it's 1966 pages checked, okay. The thing is, how do you test the performance? If you just test the front page, you just test the front page. That is the only thing you do. But okay, people are not just entering your site through the front door, right? There are many. Okay, they come through Google, they find an article somewhere. So actually, most people usually don't enter through the front page. There are more doors, and you have only with full-page caching made one fast door and the rest is still super slow. This is another example. Similar sites. This is typically what we see basically on any site. Just find a random WordPress site. Use your own site. Run a crawltest. This tool is called CO-Frog. It makes a very simple response time graph. This is from all these pages. These are the ones that are cached. So the average response time across all pages is 2.17 seconds. So this is a WooCommerce store. And here we have another example of a site that is Norwegian, the website of one of our clients, is running without caching and without a lot of optimization stuff. And it has an average response time of 0.5 seconds across all pages on the website. So no matter which of these pages you find in Google, it will be fast no matter what. You will land and it will be fast. This is how you like it to be, right? This is the same page from the previous slide, just tested with the site bulb tool, also showing that 100% of the pages are actually fast. So to test things properly, we say, okay, it's fine to use caching. Caching is a super nice tool. But when you are working with performance and you want something to become fast, you will have to be aware of how it does perform without the cache, because that is essentially what most people will get. So cache poster, very simple to add. So when you stuff your URL into Pingdom, just add a question mark and some random value and you will bypass, usually bypass your cache and get the real performance. This is the other thing that is important to know about caching, right? Because full-page caching, it works only on the second page load and it works until the page expires from the cache, which is quite often, because people usually don't cache it for that long. So for the cache to work, you will then have to be the second visitor to a page, which usually isn't the case for most websites, and you have to come then before the cache expires. So what about cache warming? That's something people often mention. Okay, we can warm up this cache. The problem is that cache warming is not something that is very easy to implement. It's quite hard. In e-commerce, you usually have a catalog of, okay, you have a store with a few thousand products. It will be very expensive in terms of system resources to actually stuff all those into cache and keep them in the cache, and it always also turns out to be hard to actually get them in the cache because, okay, the cache gets full and things drop out of the cache, so it doesn't work in practice. So when to use cache warming, if your site is mostly static, it's super nice, and if no traffic will hit PHP at any point. So because, okay, full-page caching will not work for a lot of, okay, for sessions for, I think I have it on the next slide, actually. Cart, checkout, account pages, sessions, admin, ADACs. So full-page caching won't help any of that, so what you're left with is, okay, it works for a very tiny percentage of your web users. So what should we do instead? And you will usually need a developer, but you have to identify, okay, your site-wide bottlenecks, and then you have to fix them. So a guy called Jono Aldersen, he talks about stuff like this, and he says that, okay, you have to make a list of the thousand things you know about your website, and then, okay, prioritize them, start from the top with the worst things, and then see how long you get down on the list. Okay, there are a thousand things you can do, and what's important for your site isn't necessarily what's important for your site, right? So it depends. There are a lot of different things you can do. So what you should do is, okay, you should test and fix the stack. If you move a site to Sirbolt, the whole workflow, everything you will have to do, is different than if you are on a tiny VPS where you will run into all sorts of other problems. Maybe the most important things that anyone can do is, okay, use MariaDB instead of MySQL, or the, what's it called? Yeah, MariaDB is basically a modern version, an upgrade, at least the PHP 7.1, or 7.1 is getting outdated this year, so 7.2 or 7.3. We only provide default servers now with PHP 7.2 and 7.3. We have some older, if you really need it, but, okay, invest the time, because you will be paid in performance. The site will be faster if you do this right. And testing and fixing the code, okay, that's kind of hard if you're not a developer, but you will need a developer if you want to make your website fast. So there are a lot of tools to, okay, you can use the query monitor to see, okay, are there a lot of queries that are slow. The logs, I mentioned those in the beginning, those are super rewarding, because if you have a lot of errors in your log files, and for instance on, is Black Friday a thing here in Singapore? Okay, big sales day, right? Everyone goes crazy in your webshop, and something breaks. What you need to do when something breaks is to check out the error logs. But if your error logs are already super full, they will be even more full on heavy sales day when everything is supposed to work but breaks. So keeping your error logs clean will make things faster. It will allow you to identify problems much faster when something breaks. And for the front end, you have the W3C validator, which is for, okay, for HTML, also for JavaScript and CSS. If you make code that validates, it renders faster, nicer, it looks better, it feels better, everything gets faster. So the few quick fixes, okay, add the index I mentioned on the VP options. Can do a big difference for some sites. And remove unused plugins. Clean up, clean up your mess. That is usually where we start when we move insights to SirVault. We just say to people, okay, get rid of everything you are currently not using, not just disabling it, but uninstalling. Because, okay, all code that is left in your code base is just in the way. So clean up. This is the hunting ensemble. It's a Dutch webshop where we moved in a lot of, or we moved it from another Dutch webshop that had set it up with, they had used two CDNs. They used memcached, they used varnish, a lot of performance plugins, and weak. And it was still slow. And it was still slow, this guy wanted to move. And what happened was, okay, before the response time was averaged around the second, and this was where they moved. So after that, they averaged like, okay, 200, 300 milliseconds in response time. Memcached. Memcached is usually used to store database queries so they can be reused. In WordPress, people tend to use Redis. So, yeah, but it's a key value store. So Redis and Memcached are similar products. So if you shouldn't start playing with it if you're not comfortable with it or know what it is, because it won't help you that much. There are other things you can do that are much more rewarding. No, but okay, this is basically what always happens. So move in, use proper hosting, remove all the stuff you don't need. And this can, okay, this graph drops. This graph, by the way, is available in Webmaster Tools still in the old version of Webmaster Tools. You can find it because this is Google's measure of how much time they spend downloading pages from your site. So in Google Webmaster Tools, just log in, find the old version, and it's in the menu somewhere. Okay, testing. This is, yeah, Google Analytics. That was your domain. Sitespeed sample rate. You have maybe seen in Google Analytics there is a Sitespeed report, which usually sucks big time because it doesn't have enough data. By default, it sets the Sitespeed sample rate to 1% or 5%, which means that every 100 or every 20 page will send a performance measure. And that produces terrible data because you get that random mobile phone, you get that visitor from the US when you're here. But if you set the Sitespeed sample rate to 100, it samples everything. There are some limits, but most sites don't push that much traffic that they will cap you. So you can safely do that. As I mentioned, the Google Search Console, check the crawl stats. That was the graph on the previous slide. So Sitebulb.com, that was the tool that produced those pie charts, and that can crawl your whole website. I think it's paid, but it's not that expensive, and you probably get the trial. The other one is COfrug. Yeah, this one is Sitebulb. Sitebulb is really cool because it also has a lot of other features, so it basically renders all your pages and can provide you a lot of insights across your whole site. So don't use caching when WordPress is slow without it. That would be our recommendation. So caching is made and should be used for scaling. So make sure your site is fast, and then afterwards add caching, and then you can take on the traffic if the traffic becomes. Because what happens if your site is slow on beforehand, the day you get some traffic, there will be dynamic requests, your site will break, it won't work anyway. And it doesn't deliver any better performance. Caching is a scaling tool. It's not a performance tool. When you make changes to your website, prioritize those things that apply to every page on your website first. Because if you consider also how stuff works for admins or for managers in the store, you will just get better results. If you can improve it for everyone, that's the best, and then do the other stuff later. Host your website close to your users. That's very important. We had a funny example with a CDN down in South Africa. They used StackPath CDN for their assets. And StackPath is nice enough. The only problem is that they don't have any CDN nodes in Africa. So that meant that their visitors from, to believe Johannesburg and Cape Town, they had to get the assets then from either South America or Europe or something. So of course, feel free to try out ServeBolt. The local stuff here. I expect it to be up and running during this week. So you can just sign up, make a bold experiment and test. It's completely free. Try to say hi on the chat. We don't have a local support team yet, so you might want to try that in the afternoon. Okay, thank you.