 Alright. Let's begin. So first of all, welcome everyone. Welcome to this workshop for those of you. I can see that some comments that this is too early for you. So thank you so much for joining so early. I'm not an early, early riser so I can totally say salute to you guys. Anyways, let's begin guys. So your brand success is not measured by the amount of money the company has already made. It is measured by how much more money the company will make this year. Right. Correction. One month to say how many new users you're going to get this year. So that's the that's how your company success is measured. A slow website can fail you big time. Hi, my name is Vinit Talwar and I'll guide you on the path to supercharge your online presence or making your website faster. Okay. So what about me? So I've been working with various industry brands so far in helping them fix the attack. I'm a two time startup founder, build the companies from scratch. In my music tech startup I had a user growth of 100,000 users. I work with agency marketing tech at their companies and public speaker and also AWS certified. You can watch my previous videos on wordpress.tv. I've also already included the link here. Also, if you later on after the slides, you want to have contact with me. These are my contact details. I'm going to give a QR code in the end also so that you can basically contact me. Okay. I have some questions maybe just to understand the audience. How many of you are web developers here? Maybe just write in the chat that you have a developer or not. Okay. Perfect. Nice. Okay. That's good. Okay. Quite numbers. What about business owners? How many of you are business owners? Nice. Okay. What about SEOs? How many of you are SEOs? Like core SEOs, doing nothing but SEOs. Okay. Nice. Nice. Okay. And one last question. How many of you manage their own servers? I mean, these questions will help me optimize my talks accordingly. Okay. Not much people. Okay. No problem. My point is like, let's say if you're managing AWS hosting and stuff like that by yourself on client servers. Okay. I think I have the idea. Okay. Let's begin. So first of all, I would like to say that before, if anybody wants to follow the slides and they're like, oh yeah, that's too much. Maybe you can download the slides here. Ben, you wanted to add something about the slides, right? Yeah. So I think when you download the slides now, it'll ask you for an email address, which will help Benit get in touch with you. If you want to get the slides without sharing your email address, the slides will become available next week when the recording goes up on WordPress.tv. So if you want the slides later, you can wait until next week and I'll let you know through the meantime. But if you want the slides right now, go ahead, connect with Benit and you can download them here. Perfect. So first of all, thank you learn.wordpress.org. I mean, that's a really great initiative. I would like to say this is really great way to share the knowledge with you. If you really like this format, I would say do give a shout out to organizers and especially Ben with hashtag learn WP on Twitter or now X and also in this presentation, in the starting, we will be covering a lot of concepts and in the end, also a lot of concepts. So if, you know, if you're stuck and if you have any questions, please write in the chat and we will take the questions in the end. Also, this is an online format. So I may not see your faces. So I'm mostly relying on the chats just to see basically how you guys are handling it or how you guys are getting it or not. So yeah, keep your messages coming. So me and Ben have more ideas about you, right? And one more thing I want to say this, I want you guys to have fun because teams, you're going to see a lot of memes. And I think that's the best way of learning. Let's begin. So a typical website in 2022, not 20 or also 2023 and 2024, I'm afraid is feeling like a mission accomplished. Well, as a developer, our job is to give them a great user experience, but definitely not this. And this is my face when I come to a website who's asking me so many popups. I mean, many of you can relate me with this that, yeah, you're coming to a website and you see a pop up cookie box and you're like, oh my God. And then you see a support widget book popping up from the side, asking for chat. Okay. And then suddenly when you figure out how to close that, and then there is a ad playing in the background or some sort of auto play video playing. And then you're like, okay, close it. And then the moment you're scrolling more and you figure out, oh, there's a subscribe to newsletter box. I mean, the person visited first time on your website. Do not throw all of these things on their face. Only show the central thing, right? And at this point, after seeing all this, your user will be like, why they are here at the first place. Let's talk about buttons. Buttons are amazing creatures. There are three types of people in this word. Some who press them once and just wait. Second, who don't press them at all. And third, who press it like 100 times because of course it would make the traffic go faster, right? Increasing of frequency of pushing these buttons directly proportional to users level of frustration. And you shouldn't definitely do this like will fell from the movie F because by doing so, you're making a lot of people angry. See, people don't have patience at all. The goal is to have a better time to interactive than this, right? As page load time increases from one to three seconds, your bounce rate increases by 32% and so on and so forth. And this is the case study posted by think with Google. See, interactivity impacts rage clicks. See, you're not giving people websites. You're giving them experiences. Think of yourself as an architect. You're a website architect. If you if you want to give them good experience, you have to give them better interactive websites, better experience, right? Users expect experiences or the websites to be interactive in about 1.3 times the point when they are visually ready. If not, then rage clicks happen. So the moment the website opens in if it's faster, the user will stay or they might go. A bad website performance has a measurable business impact. Don't let your users wait. They really don't have the time. Still loading. Okay, let's talk about the game of firm. You know, whenever telemarketing guy calling me, Hi, sir, I would like to give you this credit card. You know, this credit card, then you know what? I stopped them and asked them so many questions that even get frustrated. I start like, you know, what are you talking? Which credit card? Sorry, what points? I mean, in the end, the guy end up getting frustrated and he just hangs up phone. And this is the kind your users are feeling if you're giving them bad speed or bad websites or website, which is really slow, you know, bad speed will have less download conversions or donation conversions, revenues, less sales. Speed is also a ranking factor on search algorithms. Google have already said it earlier. I mean, this is a tweet I really liked. I mean, this is the same experience that I talked about in the first slide, Marcus Brownie, the MKBHD also said, yeah, this is the website was it looking like? So John made I have also given some tips for this, the user experience. So basically all in all, Google really loves user experience. SEO is not really a black magic. Some aspects of SEO is relevant and high quality content guys and content accessible to search engines and good SEO signals. Basically core web vitals lies in this category, right? I'm going to talk about this lazy loading and the stuff later on also in the coming slide. This is just to give you an idea. And guess what? This is another tweet from John Mehta. He mentioned John Mehta is from Google, by the way, since the core web vitals are now in search and so he's saying that you could you are able to find them in your slides also. Basically he's talking about what core web vitals are. We're going to see in the coming slide. So well, well, well, that is true in the web's race, the slow are left unseen and unsold. That's right. If your website is slow, you're going to lose your users, right? If you really like the tweet, by the way, you can also tweet it on Twitter. My username is right there. Let's talk about core web vitals now. Okay. Core web vitals focuses on three aspects. Basically the loading, the interactivity and the stability. Loading means LCP to sum up how quickly your page loads. FID means how soon you can interact with the page and stability. Stability means how stable the page is as it is loading and as the user is interacting with it. Core web vitals meeting metrics are combined with other signals for search as well, which are also called as page experience ranking factors. Basically which are HTTPS, state browsing, mobile first and no inclusive interstitial. So Google really want you to speed up. Okay. Well, then we think about when we think about core web vitals, this is how our users see it. A fast website means a happy and loyal customers. Different stakeholders in an organization can have different priorities. Core web vitals can bring them all on the same page by focusing on optimizing user-centric metrics and the resuming and the resulting business growth and so on. But what is core web vital anyway? We're going to talk about it now. I mean, we already talked about it a bit, but we're going to see more in the detail next. So core web vital, as I mentioned, so these are the three metrics, LCP, FID and CLS. Now, basically LCP measures your loading performance, FID interactivity and CLS measure your stability. Okay. Now, if your LCP is less than 2.5 second, that's good. If it's less than four second, but more than 2.5 second, you need improvement. And if it's more than four second, it's really poor. And the same goes for FID. FID is less than 100 second is good. 100 to 300 needs improvement and more than 300, you really need an improvement. Same goes for CLS. Less than 0.1 second, it's good. Less than 0.25, you need improvement and 0.25, it's bad. Basically, just to give you an idea. And you can test these things with various tools, as I said. So another important thing in March of 2024, the FID will become INP. INP means interactive to next paint. Okay. INP is a pending code web vital that will replace FID in March of 2024. You can test with various tools. Basically, we'll be talking about that later on. And INP below or at least less than 200 millisecond means your page has a good responsiveness, so that's good. INP means think of it like, your first visit happened, but in the second visit of the page. So if I say it's in simple words, but yeah, it's still a pending metric. It's not live yet. But yeah, and INP above 200 millisecond and below 500 means that your page responsiveness needs improvement and more than 500, it's poor. Please fix it right away and you're losing customers. Okay, so these are basically the code web vital metrics and you saw the upcoming metric also. Okay, next. Just so you know, we don't have any questions yet. So if you have questions, you can put them in the Zoom chat. Yeah, guys, please, please rely on the chat. So just ask questions and this will help me. All right, so let's enjoy the fruit of a lifetime for a moment. This is it. Just this forever and ever. You could just put your phone, get on something else, but you keep waiting because in your mind, you think, oh, it will suddenly load. Maybe within the next five seconds. No, you should give up now because the page is not loading. But in your heart, you know that you have waited. So you wait, wait and just wait and the page doesn't load. This is a lifetime moment. Lifeline means it says there is an internet, but website still doesn't load. We have to prepare for this. Okay, but what is worse than no connection is a slow connection because a white screen is showing up. It's loading the page. Nothing loads up or you see a white screen or a splash screen. But your users hate you every passing second in this problem of an online first approach. This situation is called as li-fi. What is the solution? Basically going an offline first approach, going a progressive web app. That's not the scope of this topic. Maybe in future webinar, we can talk about them. But just to give you an idea, we have to prepare for that also. But why we are talking about li-fi now? Just to give you like how we can prepare and this will also help you improve your core web vital. Now, just to understand what is li-fi. Your phone or your computer sends a request. It goes to ISP, then it goes to servers. Then you get the reply from server through ISP in the world. But if something goes slow and your page is not loading, that is called as a li-fi moment. This takes time. This is where your users are getting frustrated. What is the solution? You fix your performance. You go for an offline first approach. You talk about caching and you fix your user experience. This is where you need to be a user, a core web vital compliant. Now, just to give you an idea, instead of this, you could be doing this. Okay, I mean, most of you guys have seen on Twitter or some other website, like a skeleton like view. I've given you two examples. So this is a screenshot from CSS end. Maybe instead of UX, like what you saw in the previous screen that everything is loading, maybe you just load the bare minimum first. Prepare your users for the first contentful pain within examples like skeleton loader. So load a skeleton loader and then your users know, oh, yeah, that's something coming up. You guys have seen on Twitter or other social networks, right? Okay, but how do I test the code web vitals? What are the tools available in the market? These are the tools available in the market. So, I mean, Pingdom, Chrome UX report, Search Console, Chrome DevTools, Lighthouse and web vitals extension. So FID was not then into these two previously. I think this is an old screenshot, but now you can test everything in all of these tools. But what I want to say is that GT metrics and tools and Pingdom are also interesting. You can also give it a try, but most of your stuff will be handed over by PageSpeed Insights. See, what I want to say is that make your users happy, not Lighthouse happy. Perfect 100 and 100 is awesome, but are your users getting what they need? See, these tests are just basically providing single numbers. However, real-time situation is quite different. You need to have a look at them. These are just metrics, yet important, but these are not just like life-changing things, right? Focus on getting your UX better, focus on not having heavy images and stuff like that. So, don't get stressed about them too much. That's also an important thing I want to say. If you thought your website is done, no, your website is never done. It always, always, always need an optimization. Now, if you ever went to a website doctor or a web developer, if they look at your core web vitals or your vitals, they would also say, yeah, it's not looking great if they're bad, but SEOs really love core web vitals. Okay, if you're fixed core web vitals, sure. But what about your crappy content? If you have a crappy content, then there's no point here, right? So, even if you fix core web vitals, your core of the website has to be strong also. Well, if you want to sum up core web vitals in just one slide, I would say that's pretty much it, because that's what core page speed is doing there. It's showing you all the problems, right? And this is what we're going to talk about. Yes, but how do I fix the core web vitals? Yeah, we need to talk about all these things, but how do I fix it? First thing first, get a switch to PHP 8. Yeah, why? Because only 30, so, first of all, before giving you a metric, before starting on that, only 30.9% have switched to PHP 8. 5.1% is using PHP 5.x, but the thing is right now, 7.4 also reached the end of life. So, from this picture, you can see that PHP 8 is... You can see the purple is 15%, red is 11%, and blue is 8.2%. So, you can see that around 0.3%, around 33% also is only using PHP 8, but the rest of others are still on old PHP. So, better switch to faster PHP. Thing is, WordPress only execute 25 MB of CSV, CPU instructions on a PHP 7, at runtime compared to just under 100 MB to do the same on older PHP versions, but that was the PHP 7 number, so, but get a PHP 8. That's one thing I want to say. Okay, next thing is switch to MariaDB. If you're still using MySQL, switch to MariaDB. It's faster than MySQL. Okay, now hosting. Free hosting do not use free hosting. If free hosting is a myth, don't let your website be haunted by specter of free hostings hidden coast. Well, that is true. Free hosting is just a myth. You don't have control to your website. You can't do anything about that. The person can close it anytime, and of course, you can't expect the performance in anything on the free hosting, but what are the type of hostings? Shared, dedicated, and cloud. And if you're a pro blogger, definitely go for a cloud hosting. So, yeah, the solution to fix another problem is go cloud. Don't let your users wait, guys. They don't have time. This is definitely not cloud computing. Okay, what else? DNS. Well, I could tell you a DNS joke, but it might take 24, take you 24 hours to get it. Right? Switch to a better DNS, guys. I mean, your domain provider is giving you a DNS, but of course, that may not be... I mean, let's not take names, but that may not be faster because, yeah, the DNS propagation takes a lot of time with them. I would really suggest go for a faster DNS, just like Route 53 or any DNS provided by any cloud provider, because they have servers all across the world, and your request could be going to nearest possible server for them. So, switch to a faster DNS. What next? Images. Do you feel this? Well, no, that doesn't mean the slide is not loaded. It's your images that's bailing you guys. So, at this point, okay, tell me how many of you thought, well, slides didn't load. How many of you thought the slides didn't load? Okay. See, this is the disappointment your user should never feel. Beware the loading icon. Wait, beware the loading icon. It's the silent sales killer. So, if there's a loading icon coming, that means there's something wrong with your images. Please test them, right? But what can we improve in the images? So, these are few trips and picks I would say you could use. One is lazy loading. You could use responsive images. You could use lighter formats. You could use image compression. You could use CDN. See, the responsive images in WordPress are part of WordPress core. Basically, it allows you to serve images that you really need, right? You can either serve width-based or pixel-based. You could prioritize the critical images. You can use lighter formats like SVG or images fall back for the video. For example, if somebody's on a 2G connection, anyway, nobody will be on 2G connection now, right? But let's suppose there is somebody do not have the network or it's like 3G. Maybe you could have a mobile-only version or a version based on your network type, right? Based on your connection also. Also, instead of showing them a video, maybe you could show them an image there, right? You can adapt based on user's effective network type. For instance, as I said, if you're serving a video slider or a GIF based on background of fast internet, you can serve from small internet connection, right? But you'll ask me, Vinit, how do we do that? So, there is this thing called navigator.connection.effective type. It's an effective type API that can come into handy in such cases, right? Okay, next topic we're going to talk about is lazy loading. You need to... So, they are... Okay, on your website, there are sliders getting loaded, right? There are some off-screen images. Now, what is off-screen images? So, when a slider is loaded, whatever you see on the screen, that's an on-screen images. When the slider is moving, the rest of others are off-screen images. The carousels are network heavy, causing cumulative layout shifts, right? But, I mean... Okay, there was a limited browser support for lazy loading in-pass as well. But now, I can see that from 2023 July, Safari has already added the lazy loading support also, but previously, it was not there. So, you can see that it came quite late, guys. Okay, I would say you can, first of all, leverage Power of WordPress Core and try to implement lazy loading in your theme. Alternatively, if you're not happy with the results, you can also use one of these libraries. And for lazy loading, it's just one parameter, as you can see, but you need to handle it in your theme also. Theme developers are recommended to basically, granularly handle these loading of these images already, okay? You can use basically this WP Get Attachment Image hook or another function, basically, with as the... For example, the underscore post underscore thumbnail to handle it in your template. There are detailed articles from WordPress documentation about lazy loading and how a theme developer can handle it. I would really recommend looking at them, okay? So, lazy loading is important. There are other things also you could do, for example, you can define height and width and images. This will stop showing this TLS error in your core web analytics metrics, okay? Right? I tell you a load performance job, but the images will fail you if you do not optimize them. Okay, so what is that we can do? You can use lighter formats like SVG or a WebP. You can use... You can serve with the next generation formats over there, okay? You can also integrate image compression in your workflow. Let's say you're uploading images for your blog post. You can have a compression solution over there or add it in your workflow. Maybe your marketing team, whenever they are creating content, you can ask them, you know what, guys, use some sort of compression tool and try to compress them because that's where... That's how you can get good results, okay? Now, what are the image compression tools available in the market? So, you can try one of these tools like TinyPNG, Smush or Optimizilla. And I really like this website also. You can give it a try and learn some more about image compression over there. The website's like TinyPNG, also providing you an API. Let's suppose you have a very big and very heavy website. You can also integrate TinyPNG API in your image uploading workflow as well. But of course, if you don't want to pay it, maybe just compress it earlier and then upload it. Okay, I also suggest that maybe define some sort of image guidelines for your team. What are the image guidelines? I mean, you can specify, do not upload an image more than 400kb, for example, or do not upload a big image in PNG just in WebP or JPG, JPEG, okay? So, these kind of guidelines also you can define for your marketing team so that they handle your image. Big C images are big culprit for your core web vitals and your metrics will come in the red, right? So, remember that. Okay, what can else you do? CDN. How many of you know what is a CDN? Can you reply in the chat? I mean, the link may be changed with me. I haven't verified last night. Some of you know, some of you don't know. So, a content delivery network basically allows you to serve your images from different locations of the world. And then you'll be like, what do you mean? I mean, how can you do that? So, okay, I will not go into the concept in detail, but think of it like you're uploading an image to a provider and that provider is making the copy of your images across the world in different data centers. And let's suppose you're based in Germany, let's say I'm based in Germany, Frankfurt, but my users are in Australia, okay? And whenever they make a request, the website request will come to my German server if I do not have an Australian server already. However, the images which are basically network heavy, the request will go to nearest point in Australia, okay? So, that's the simplest possible explanation of CDN I can give you. There are certain providers out there, like for example, Amazon have S3 and you can combine it with CloudFront. S3 is more like a storage solution, but that's pretty fast and you can combine it with the CloudFront. That's the CDN solution provided by Amazon. Distill Ocean has Distill Ocean spaces and there are a couple more CDNs like Akamai and Fastly also. Some of you mentioned Cloudflare in the chat, Cloudflare is also nice, I haven't mentioned it yet, but yeah, you can also use it. Now, this is an example of regions or regions, as you can see, in different areas, okay? The thing is another simple way you can say that you could... Okay. You could also use any image optimization as a service also. For example, there are some images CDN out there also, like I know that for the fact that Jetpack also has an image CDN. It's more like an image optimization as a service because they are taking your images, putting it across the board and letting your users access it faster, right? But then we need how can we integrate in our website? There are a couple of plugins out there, like in W3 Total Cache, you can also define a CDN connection which will serve your JavaScripts and CSS from different CDN points, which you can define it in CloudFront. And then there is another tool called WP Offload S3. It will help you offload your images, video, whatever you upload in your media library to the CDN service providers, which in turn will make copies across the board. So the thing is, I have one example also. When Trivago switched to images CDN, the total images size basically decreased by 80% for them, right? Okay. And also helped them improve the conversions. Now, next topic, fonts. Fonts are also your culprit. If you're loading multiple fonts, well, that would be... No, that's a joke. You should not do that. But if you're doing that, maybe you should handle it nicely. Okay. Now, what is... Okay. To sum this thing up, you know, GDPR policy, GDPR has... I mean, there are a lot of people got fined about using Google Fonts. Yeah, Google Fonts, because they are tracking you somehow with Google Font, I don't know. But the ideal way to host your fonts is to host locally. Basically, upload in your website and just handle it locally. And what else that can you do, which will help you improve your font? Basically, define font display equal to swap. Maybe don't use Google API, as I said. Host locally hosted font. By default, if a font is not loaded, browser will hide text up to three seconds for Google, Chrome, and Firefox, and infinite time for Safari. This is not ideal. The fix is wherever you declare this font face, font display equal to swap, as I said, just add this line and the browser will not switch fonts and this will not cause cumulative layout shift. This will help you sometime there. So what does this do? This tells the browser to use the system default fonts initially, like for example, whatever the font's in your Chrome or Firefox are, and swap it out once your actual font arrives. So this way, the page is not like loading, loading, loading, because then something is already loaded, the structure is already there, and it just switches the font in the end. Okay, okay, next topic, caching. You don't use caching at all. Tell me again how fast your website is. What kind of caching types are out there? Page cache, browser cache, object cache, database cache, transient cache, and so on and so forth. I mean, you could use one of these tools to implement it. Yeah, caching is actually a big topic. I mean, it cannot be just covered in one slide. Maybe we can cover it in future. What we're going to say is that you can handle caching with these plugins easily, like just install WB Supercache from Automatic and just enable the page caching. But caching is a complicated topic. Sometimes it can break your website also, right? And you also need to know how you can handle the caching basically nicely, okay? So that's also important. There are different types of caching. As I mentioned, we will not go more into the detail, but we will talk about some of them later on. So you can implement caching like this. Transient cache, I think we will talk about it in the coming slides. But how we can improve? See, UX is the key. A website, no matter how fast it is, it is not usable for users if it is not worth it. You need to plan out how many number of visitors you're expecting. What do you expect people to do on your website? Are you offering everything that your user is looking for? And basically, you should also test your website in another browser as you would access someone's random website as well. Also, figure out how much mobile users and what do you expect them to do also? You can also do some A-B testing. You can do a hotjar just to figure out if your users are getting what they really need. Caching is fine, page performance is fine. If the UX is not worth it, you will also lose out on users. Any questions so far, guys? I think because we're going pretty fast, I would like to ask any questions, guys? We have like six or seven questions that have come in so far. Let's see if something easy. So the most recent one from Marcos was, is not Reddit and Memcache some object cache technology? Exactly. I mean, that's what I said. Caching is a big topic. There's not enough time to cover it just in one slide, so I just only gave you an overview. Reddit and Memcache are the technologies or you can run an instance for that and integrate in your website as well. We are using Reddit for a website which has 9 million users just so that it can cache stuff. So yeah, this is an object cache technology. You're absolutely right. Any other questions? Some of the other questions are about previous topics. Do we want to come back to them at the end? Yeah, maybe let's take one more and then we'll go in the end. All right, Raina asks, how long after you launch a site do you evaluate user experience and make changes? Well, it's a never-ending cycle to be honest. As I said, a website is never done. I mean, you might want... It's not like you build the website and you just forget. You need to get continuously get users, so you just keep an eye. So whenever you make a change, you just evaluate for it, at least for some time. If the users are converting, maybe you want to do new stuff, new pages, new sections on the website or try and test, okay, with A-B testing, you can see if the user is clicking on this button or that button. If this graphic is good or that graphic is good, stuff like that. So honestly, it's a never-ending cycle, in my opinion. Okay, so maybe let's continue and just take rest of them in the later on. Okay, next important topic is WP query. I mean, we will not go more about that in detail, but just to give you some of you an idea, how we can improve that, just an idea. Okay, so as you know, a WP query is looking something like this. You can query in a post type. You can then define a relation, basically a taxonomy query and a query from a taxonomy and also do like a multi-taxonomy query with a relation end, right? But the thing is, queries are slow. Think about multi-dimensional meta queries. They are pretty heavy and multi-dimensional taxonomy queries. Oh, my God, just forget them. Consider you have a website with thousands and thousands of posts and you're making such complex queries. Your website will run really slow. But what can we do? How can we improve that? We're going to talk about that in the next slide. Okay, another thing, if it's a product site, let's say you have tens and thousands of products, over there also, it could be a problem. Maybe we could use a solution like Transient API or integrate Elasticsearch. Both of them can work. Yes, Elasticsearch also helps you improve your WordPress queries. Elasticsearch is not just search, it also helps you integrate in your WP query by passing a parameter. There's a plugin for that called Elasticpress. I think I don't have a slide for that, but just to give you an idea. But what else can we do to improve these queries? We can integrate the Transient APIs. So these are the three functions basically that saves your life. Okay, you can improve basically performance by caching things like full pages such as slow results from remote servers like Facebook or large database query in the multi-dimensional query. But whenever you're doing a transient storage. Oh, your mic just broke beneath and your audio cut out. No. We heard a buzz and then you disappeared. Can you hear me? You're coming back. You're coming back. Mic testing, mic testing. Hello, hello. Okay, that works. Hello, hello. Wait, let me try the headphone again. There's some interference or something. Yeah, now can you hear me? That's good. That's good. Okay, then I'm going to repeat this line slowly. Yes, thank you. All the transients are stored in options table. So basically think of it transients like let's say you made a query and the output of that query, you can store it in the transients. Transients are stored with a transient key and you can handle it with a timeout function. So this is also a method of caching the results from the database. And the results from transients can also be stored in either an options table or in a Redis. It depends on how much transients are you using. If you have thousands and thousands of transients, a very heavy website. I also recommend running a Redis cluster together with your WordPress website. So and pass your transients to the Redis. You can also do that very easily by simply integrating Redis and handling the transients. Your queries will automatically go to the Redis because your database will know that it's... I need to call these from Redis. Okay, in case of a multi-site, basically transients are stored in a WP site meta table. And in case of normal site, it's stored in the options table. And transients are basically created in multi-site with set site transient function. If you want to create a site-level transient, and with a normal site, it goes with a set transient function and get transient function. I'm not going there in detail, as I said, caching is a very big topic. Not enough to cover in one or two slides. So we're going to go on the next topic called JavaScript and CSS. The solution is you mark your JavaScript as async so that it won't block rendering. You might have seen this render blocking JavaScript in your page speed inside. So this is the kind of solution you might want to fix. So I'm going to talk about a few solutions, how we can improve our CSS and JavaScript, basically, to improve the performance of the website. Okay, so first thing is critical CSS. So even CSS can be render blocking, but how can I improve my first view or first contentful pane? You can define the concept of critical CSS. Now, what is a critical CSS? If I say in simple words, all the CSS that is required to load your first view or your hero element on your web page, including navigation and all, start by loading a skeleton and only load the CSS that just required inline. Yes, inline. So critical CSS has to be inline. There are a couple of solutions that you could use to implement critical CSS. JavaScripts, basically. Third-party code is responsible for 57% execution time on web. The reference is third-party web.today. That's a huge number. And based on top 4 million websites, a lot of CPU intensive scripts can delay your user interaction. Third-party should be taken care very well. For example, you should handle your tracking scripts with tag manager, right? And that's where this will help you handle... I mean, that's where you have everything at one place and you need to defer your scripts as much as you can and only load what you really need. See, idea is to have better time to interact with. You defer your scripts like, for example, defer Google Tag Manager. Yes, please do that. Defer all the JS libraries that you have added. Don't load them in header. Load them in the footer. Maybe define preload, preconnect, pre-fetch and DNS pre-fetch also. You minify your JavaScript. You automate your minification. You basically get rid of obese, expensive libraries like heavy libraries. Maybe don't use the CDN links because then there's another trip to the CDN is taking place. I've seen some websites using CDN, a lot of CDN websites. It could be possible that it takes time over there also. So either don't use it and if you use it, handle them via preload, preconnect, pre-fetch and DNS pre-fetch. Okay. That would be my suggestion if I would say, how to improve a JavaScript. Okay. You should deprecate what you don't need, just get rid of it, replace the JavaScript if you don't really need it and defer it, as I said. You need to load in smaller version. If it is possible, if not, no problem. You need to defer your extensive dependency. Okay. If there are dependencies that are outdated, maybe just update them. So there's this company called Zalando. They got benefited from updating their React version and they helped them improve the website speed also. Okay. You need to break your larger bundles into smaller ones, as I said, and you need to load it on demand. Basically, JavaScript download time and JavaScript execution time is also basically CPU expensive. Think about those small phones with 2G and if the JavaScript's loading above the fold, it's render blocking, right? Twitter is loading EmojiPicker on demand and not all loading it all the time. Then why do you have your WordPress Emoji library getting available? Most of you don't even know that, right? So if you're loading it on demand or only on the pages you need it, that saves you a lot. So in case of Twitter, when they loaded EmojiPicker on demand, it saved them 50KB. Similarly, you can split your code also and only send users what they really need. What else can we do? We can do compression. Compress everything. Use GZip, you use Brotli on your server and you can configure them on your web server. Twitter uses Brotli to reduce API responses. For example, with Brotli, you can decrease your file size or the size of a serving of an image or not image or your code or JavaScript by 90%. So Brotli is a compression mechanism. You need to use Brotli carefully, by the way. It can even make or break your website, but GZip is by default there, so this is fine. If you're not sure with Brotli, I would say don't use it at all. Okay, then next topic is minify. You need to minify your CSS. You need to minify your JavaScript. There are a few Google libraries out there also. You could use it. There are a couple of plugins that you could use, like auto-optimize and W3 total cache that you could use it also. Okay, so I talked about a preload, preconnect, prefetch and priority hints. This is how it looks like, guys. Okay, let's suppose you're loading a carousel. As I said, in your carousel, your first image is very important. Other images are not important. By defining importance equal to low or importance equal to high, you're telling your browser, yeah, load this first, do not load this now. Okay, this is called as purple pattern. Push, render, pre-cache and lazy load. See, you can reduce your network connection contention for fetches for low priority content by defining a script like this. And you need to deprioritize your scripts based on how important it is. For example, if your chat.js or your chatbot is not important, you can either put it on footer or you can also define it low importance so that it doesn't affect your core web vitals. Okay, so this is purple pattern or purple method is also helpful to improving the core web vitals. Now, what is a preconnect? So preconnect basically allows you to decrease the latency of your connection to a domain. Let's suppose you need to load a Google Tag Manager. So in the preconnect, you can define preconnect Google Tag Manager. So it will help you decrease the latency. Similarly, for JavaScript and CSS also, you can use preload and prefetch and these kind of things also. Now, for preload, I have one example. Let's suppose you need to load a font. So you can define similarly USC as script here. We're going to say link rel equal to preload as equal to font, ahref equal to font name and then importance equal to high, low whatever we want to say and then type equal to font and something like that. Okay, so now these priority hints that we saw high and low. This also applies for basically JavaScript also as we saw it here. Basically, this allows you to hit the browser how important the asset is and exposes a new attribute with value low or high or auto. This is how you can basically handle it and tell your browser this is really important or not important at all. Okay, we can prefetch the visible links also. See data driving driven loading with link equal to prefetch. We can also do basically to improve the performance of your website. A faster time to interact for your future pages. Basically, this will allow you to have a faster time to interact for future pages. I mean, this will also help you in your INP, the interactive interactive on next page, the code web vital metric also. And Google Analytics also shows you your top performing pages that uses to prefetch the pages. So when eBay prefetch is their top five search results, right, for fastest subsequent loads and increase in above the full times and meaningful fades. I mean, basically, it helped eBay improve sales a lot. eBay also uses productive prefetching. Basically, when you loaded five and it knew what next going to come. So they defined productive prefetching algorithm also. They implemented it in this search. Like, oh, yeah, what is that people going to type? So sometimes when you type something on Amazon, you can see that something else is already coming up. So that's productive prefetching. This is a case study I read about eBay and that's one quoting eBay. I mean, there are other sites also doing that. Similarly, you can also implement productive prefetching based on your analytics data or you know that, okay, these articles are getting better results. So you can also prefetch those articles that, okay, these articles are likely to get it better. So or likely to get more traffic. You can implement service workers to do that. A service workers are basically a scope of next talk. Basically, whenever we talk about progressive web apps. Okay, you can also prefetch your most click post also. So these are the different use cases that I defined. What you can do with pre-connect, preload, prefetch and pridines. I would say, guys, give it a try. It's okay if you don't get it at one point. Just give it a try and then evaluate the results. So these are just the ideas, as I said. For productive prefetching, there is this one more library called guest.js. That's also being used a lot. You can also try. This can help you to have a productive prefetching. Okay, one question that you would need to answer every time your optimized website hit its limits is basically, what can you do to improve it? And guys, trust me, improving the performance is not a shortcut. Next topic that we're going to talk about is tracking and GDPR. Yeah, tracking is basically the biggest problem or one of the biggest problems in a website's performance. Okay, we're going to talk about it now. We can do the tracking paste with GTM. Now you'd be like, yeah, that's the same guy. That's the same Batman. I mean, I load all the scripts in my footer versus all in GTM. No, that's not the same because in GTM, you can control it. Right? You can control which scripts you want to load it. First, which script you want to load it later. You can also implement with the GTM. Use any tool like one trust cookie board or any other GDPR plugin or tool, external tool to handle this tracking scripts loaded. Right? Let's suppose your users are in Europe. You can have it tied up with a cookie box. I've seen one trust is already doing that. If and until you do not accept the cookies, it will not load your tracking scripts. So indirectly or directly, it is also improving the website speed. So if somebody is saying that, yeah, I mean, that just fixes your GDPR. No, silly. That's also fixes your website performance also because you're moving your tracking script to GTM and specifically for Europe. It helps a lot because in Europe, the GDPR law says, yeah, you do not load the tracking scripts until the user's consent. Right? So you can control all at once and you can handle it at one place and you can tie it up with a cookie box. Important. We have to think it like this. OK, next topic is scale up and scroll forward. That's that's the million dollar question. Every web developer or web server owner has to ask. That's that's why I asked you guys in the starting. How many of you are server owners? OK, also managing the service. OK, so let's start with this guy. So for scaling servers, scale up and scale forward. How many of you know what is this approach means? Can somebody tie? How many of you know what is the scale up and scale forward approach? Nobody? Interesting. Ben, Ben, am I audible by the way? I have no idea. I think I do more server versus more CPU to the server. Yeah, in a way, you're right. Urgent scale up improves the CPU and server config. OK, and scale forward. So, no, OK, no worries, guys. And let me explain for everyone what is scale up and scale forward. Scale up means think of it like you're running your website in a 2 GB RAM web server, right? It's a 2 GB RAM, 40 GB storage and whatever. It's a simple T3 small instance from Amazon or I don't know about this solution, but let's say on EC2 cloud or Amazon, you're running a T3 small. From T3 small to T3 medium or T3 large, if you're going means you're putting more RAM. That means you're scaling up. Now, why do you scale up? The main reason is that let's say you're getting a lot of traffic. All you do is simply scale up. But scale up is actually not always the solution. First thing first, you need to fix your website. Scaling up can sometimes be a temporary measure also, right? Let's suppose you're getting a lot of traffic, but your website is crappy. You just simply scale up, but that's not the solution, guys. You need to scale up only and only when you hit the limits or your website is down. That's another case. So that's a temporary approach or in India, we call it Jugaad. Now, what is scale forward? Okay, think of it like this. You have a website of 10,000 visitors per month. You're running on, let's say 32 GB RAM server. You did everything to fix your website. But then you realize you have a lot of searches, right? Your search system is getting a lot of queries. And as search is one of the reasons your website is going down. What do you could do? Take out the search and make it outside this EC2 machine. So what do you mean by takeout, guys? So you get an elastic search instance and then integrate with your website. So instead of just putting a poor RAM, you just split it into two. Now your search is outside. Or let's suppose you see that your database is not able to handle because you were running database inside the EC2 machine as well. No problem. Take out the database, use an RDS. Now, using S3 in CloudFront is also in a way scaling forward, okay? You scale up this much, you figure out, oh, yeah, there are more issues. You could use ElastiCache. You could use ElastiCache also as a RDS and Cloud... ElastiCache also as a RDS, so you can also take out the RDS. So these are the different things you could do. You can see if you saw that if your one server is not able to handle, no problem, the two servers had a load balancer architecture, right? And you can go serverless also, if and if possible. If and when possible. But I know that's not always the case. Try to handle it with all these things first. Serverless is basically the maximum, ultra-maximum solution, right? So this is scale up and scale forward approach. If you guys know servers, maybe you'll be able to handle it. I tried to explain it, but if you have any question, please post it in the chat. I will try to take that question later on. Also, remember I talked about ElastiCache. So earlier also, let's say, let's suppose to handle a multi-dimensional queries. For that, there is a plugin called ElastiPress. You can give it a try. It helps you integrate ElastiCache in your WordPress website. Okay, next topic is profiling. Now, what is profiling? So profiling means finding the culprit in your WordPress website. What is going on if you need to figure out, but how can you do, how can you profile? It's very simple, WP Debug and WP Debug Log. Enable your debug mode, enable the log. It will tell you what's wrong with your website. And then there are these two plugins called Query Monitor and Debug Bar. They are really, really helpful. I don't know, how many of you have tried Query Monitor or Debug Bar? Only one, two, nice. So that's it. Profiling is not a big problem, guys, for you. Okay, for those of you who haven't tried it, you can give it a try, Query Monitor and Debug Bar. Basically, what it does is it shows you what kind of queries are running, what kind of stuff is happening on that page, and how you can improve it, which query is slow, which query is faster, what are the errors and these kind of stuff. And you can combine it with Debug Bar also. Then you see everything you have got. Okay. Okay. But important thing, you should run these things in your local box only, or your local environment, right? Local by flywheel, ZAMP, or whatever you use. It will... Okay, another thing, by profiling, you know what are your culprits. If it's a plugin that is a culprit, or if your team that is a culprit, or if there are some bugs in your code, right? If a plugin is slowing you down, maybe try to eliminate that plugin, right? Maybe look for a replacement, or you could also try to implement the solution by code if the plugin is too small. Unless it all comes down to your resources. You can also take a look at X Debug also, but in Windows I've seen it's pretty slow, but 99% of the users query, monitor, and Debug Bar are more than enough, okay? Now, let's talk about bloating. WordPress is actually pretty much bloated. Yes, I said it. It is pretty much bloated. Not the core, but the plugins. See, core have some bloats, but okay, not that much, but the plugins, plugins are coming a hell lot of bloat in your code. They're showing a lot of ads. They are showing you this nasty admin, nasty pop-ups. They are putting their sponsor links. Hello, Yoast. And so on and so forth. So maybe what you could do is you can look around in the code of your plugins and try to clean up the bloat. And sometimes you can even find out... If you Google, let's say, XYZ plugin name and clean up the boat bloat and you will see some articles cover it, showing you some functions. Like, how can you clean up bloat from, let's say, Yoast SEO or Total Cache or Jetpack, one of the pretty bloated plugins I must say. Okay, question to you guys. How many plugins are too much plugins? How many plugins are too much plugins? Okay, some saying 15, some saying 27 plus. Depends on how bloated they are. Nice. Okay, I have reduced the site width and very good. What plugins, how much resources did they take? Okay, the answer is one. Confused? Yes, if you have just one bloated plugin or one bad plugin that can actually kill your website. So there is no such number as how many plugins are too much plugins. If your website is running fast, it doesn't have a problem. It can even have as much plugins as possible. No problem, right? You can write your custom code in the plugins. That's also not a problem. But if you have one bad plugin, that would kill your performance because plugin is adding a lot of stuff to your backend, a lot of CSS, a lot of JavaScript. So answer is one. Okay, you need to use only plugins that are from your trusted plugin providers but make sure to check things they're doing in backup. Make sure to check their code. Make sure what kind of bloat they're adding. Try to clean up your WP admin. You need to register your unwanted widgets that you see or unwanted scripts that you have. You need to dequeue your scripts, okay? And do not use any plugin that are null or any null team, these kind of things because God knows what they're doing. Better to buy from an official source and stuff like that. Okay. Okay, you can also optimize your database. So there are WPCLICommerce like WP OptimizedDB. And that's all. And for any organization, what important is that they should have a performance budget. Now, what is a performance budget? A performance budget is just what it sounds like. You set a budget on your webpage and you do not allow the page to exceed that. That's it. So this may be a specific load time, but it is usually an easier conversation to have when you break the budget down into the number of requests or the size of the pages. A performance budget is a collection of limits you impose on various website metrics that impact its performance. Some performance budget may include total page size, total number of requests, FCP, LCP, etc., etc. So an organization must define a performance budget as well. Okay. Thing is, the website speed is more important than ever. It's a lot, okay? You're going to have problem and you're going to have a lot of problems, but this is how, but you're going to find a solution. And guys, this is how we will make the web faster. Thank you for your attention. It's a wrap. And we're going to take questions now. And if you want to download the slides, you can download slides here. You can come up with me. And is my screen still visible? I think no, the QBAR screen disappeared. There we go. Sorry. Yeah, let me fix it. Let me fix it. Let me fix it from current slide. Okay. Do you see my screen? Yeah, do you see this? Yeah. Perfect, guys. Now let's take questions. All right. So I have one, two, three, four, five, six, seven, eight, nine, ten questions written down. So we'll go through these in order. Okay. First of all, we had one from Arjan. Do those web vitals take customer geographic, for example, the availability of fast internet or their server location into account? Not really. Basically, I personally tested it. That's what I said to you first. These are just metrics. Don't stress out much. The right test is in your browser. So in your Google Chrome, you can also have a lighthouse test. That's an exact test for your system, for your internet type. So Google's core web vitals have servers all over. So you never know, right? I tell you how I got to know. So I was testing for a GDPR. Okay. I installed one trust and I set up the privacy and blocked all the script. Then I checked with core web vitals. Then I saw that, yeah, it's still not blocking the scripts. But when I checked from my local, I see the performance pretty fast. So what's wrong? That's how I got to know that they have servers located all over the world. You don't know where they're testing it from. So that's just an industry metric that just to give you a number. If you don't reach 100 or 100, don't stress out. If you're in green zone, that's fine. So target only for the zone. Don't target the numbers. Okay. So the right test is in your browser. Hello, can you hear me? Yes, I can hear you. Okay. All right. My AirPods is running on battery. All right. So we got a question from Miguel. Does the DNS affect the TTFB or time to first bite? Sorry, can you take up? I saw Miguel's another comment. You mentioned that about my word can be an application. He just made it public. Okay. Oh, okay. Does the DNS settings or the DNS server you use affect the time to first bite TTFB of a site? Absolutely. If you have a faster DNS, right? Let's suppose you're using a DNS server like Route 53 and all. It goes to your nearest server. So it saves your time. Even in milliseconds, it saves your time. So absolutely, this also affects the DNS resolution, also affects. So it all starts at the DNS level to improve the performance of your website. All right. We got one from Tanya. They compress images to 100 KB before uploading. It's very manual, but they think there's a better way. Can you introduce a better way? Yeah, I think I talked about tiny PNG API. So what you could do is implement tiny PNG API in your workflow. So whenever you're uploading an image, it will automatically be compressed. But that doesn't mean you give like a hefty images. Then it will cost you a lot. So try to have it in your workflow as much as possible, but have tiny PNG running in your WordPress backend. There are other plugins also, but honestly, I'm not a plugin fan. I, in our marketing workflow, we try to do it when the content is created. But if you're not, okay, it's fine to use tiny PNG API also. Great. So Ham asked, what would be an optimal implementation of skeleton loading and lazing loading according to you? Optimal implementation, that's a good question. I would say just handle it on your theme levels. Because if you're using an external theme, it might not cover. Maybe you need to handle your own implementation for that. That would be my suggestion. Just handle it yourself. The themes will not cover. All right. Miguel asked another question. For lazy loading, do we need to manually add the attribute lazy or the size of the image when using WordPress blocks? So far, I know the core support is already there, but it could be possible that your theme is not handling it. So you need to verify if your theme is handling it. Just manually check if your theme image is lazy loaded or not. If not, then you need to ask your theme developer to handle it in your theme or you can handle it yourself in a child theme also. There is a very interesting guide from WordPress documentation I saw on lazy loading, how a theme developer can leverage WordPress core's lazy loading capability. All right. I hope that answers the question. Yeah, if anybody wants to ask additional questions, drop them in the chat and we'll get to them. We have a few more to get through. So Istvan asks, for CLS, font display swap is enough in your opinion? Yes, that's not just for CLS. So other than that, there are other things also for CLS. But from the font side, that should be fine. But on the images side, you need to have a height and width defined. So CLS is also a bigger topic, but only at the font side, that should be fine. And also handle your fonts locally, don't use Google Fonts. I mean, you can use Google Fonts, but download it locally and use it in your from your server, from the privacy reasons. Yeah, yeah. OK, you talked about adding the important high and low to images and tags. Is this widely accepted already? Not all the browsers have the support you must verify it. So this is a recommendation from Google. I found out from the website, this website called web.dev slash vitals. So over there, they have talked about it a lot. So you need to verify it also whenever you're implementing it. All right, that question was from Selhan. We have another one from Istvan. Did you happen to encounter huge server processing usages when Prefit was activated? Prefit, sorry. Did you have to? Yeah, sorry. Not really, not really. So not much server processing I've encountered, to be honest. Because if you're handling, caching, et cetera, properly, I know I haven't seen too much server processing begatting. Right. Too much server processing. All right, I have two more questions. So if anybody else has questions, drop them in the chat and we'll finish after we get through these two more. So Elena asks, which solution is better? Scale up the same server or create a new server with bigger RAM and CPU and move the website? The scale up and scale forward is more like a trivial approach. So in philosophy, you have this like hen and chicken thingy philosophy. Similar with scale up and scale forward is the biggest question that companies or the website developers have to ask their the owners. Like, do we scale up? Do we scale forward? So you have to take this decision based on your circumstance also. Sometimes scaling up is more than enough. Sometimes scale forward is really needed because you need to imagine scale forwards can be more expensive than scale up. But if you're using S3 and CloudFront, okay, it will add cost to it. So you need to also take cost in the account. I think, did I answer the question? I think so. Yeah. Elena, if you have a follow up, do us know. All right. Miguel asks, is there some way out there to measure the resources each plugin takes, for example, how much they're affecting loading times? I haven't encountered any solution which can tell you the plugins loading time. Honestly, not. I have only seen in the query monitor, it tells you if a plugin is making an expensive query or a plugin is having some sort of issues. So query monitor and debug bar are pretty much the solution that I've encountered so far. All right. And we got one more question in the chat. So, Vinit, you can read that as well. It's from Rob Vanden. It says, adding width and height attributes to an image element causes issues with responsiveness sometimes. How would you handle this for images that use various sizes on different screen sizes? So I talked about it earlier also in my slide. So WordPress has a concept of responsive images. So WordPress core also have a very great documentation about how you can have responsive images in your site. So there's a thing called as SRC set. So take a look at the tutorial whenever you're building a team, try to leverage the concept of responsive images. So this will allow you to have image screen sizes based on your screen size within one element. It's a very nice concept. Give it a try. All right. And I think we covered all the questions. First of all, I want to thank you, Vinit, for presenting to us today. There was a lot of information, a lot of good information. And for all of us who attended, let's re-watch this recording. I don't think we could like absorb everything all in one go. So first of all, Vinit is sharing a QR code on the screen right now. You can download the slides today, go through those, review all the links and all the information. And then also next week, when the recording will be uploaded to WordPress.tv and to YouTube, I'll be emailing everyone through Meetup with the links to those. And that will also have the slide links again. So we'll be able to review all the information next week as well. All right. Well, thank you, Vinit, for speaking. We have eight attendees today. And I think that's a really good turnout. So thank you, everybody, for attending. And yeah, I'll look forward to seeing everyone in another online workshop in future. Thank you very much. Thank you, guys. Thank you for joining. If you have any questions, you can always contact me there. My contact details are also in the QR code. Thank you. Thank you, Vin, for hosting me. It was really nice. It's always my pleasure. All right. Absolutely. Bye, everyone. Have a good day. Bye, guys.