 So thank you very much for that introduction, just a couple of things I want to add more. So I'm a proud father of three boys and a husband to my lovely wife. I've been with WordPress for at least 13 years with the current company that I work for with Urban Insights for about 12 years. And I enjoy homeschooling, gardening, woodworking, developing WordPress plugins, playing chess, tinkering and messing up electronics and eliminating any inefficiencies wherever I see them. If you find me later on today or tomorrow and you want to talk about any of these topics or others, then please find me. So the agenda for today, we're going to talk about a little bit about the terminology. What do we mean by front-end architecture? What do we mean by enterprise performance? And then we're going to take a look at browser speed performance, front-end speed performance and a little bit about front-end architecture. If we have time, we're going to go into a few case studies and then you can have all the questions you want. So before I begin, how many of you are developers? How many of you have experience with decoupled architecture? And how many are you interested in tips and tricks for browser performance and speed performance? Okay, got it, thank you. So when we talk about traditional CMS and headless CMS, usually what we mean is that the back-end and the front-end is coupled within one framework, WordPress in this case, and WordPress is handling the data entry but also everything that goes to the browser. So it's like a complete solution packaged into one. When we talk about headless CMS, what we talk about is there's a back-end CMS and there's some JavaScript framework living on a different server somewhere that consumes the data through an API and then does its own thing. So both of them have their pros and cons. Usually when we want to pick a decoupled solution is because we want to go with the front-end solutions, techniques, technologies, all the new fancy stuff to build the new fancy stuff with the tools that are available for us and not get stuck in a monolithic solution. But it has its own problems so you have to weigh in project by project which is the best case for you. So just a little bit about enterprise great performance is because most of you or you'll have like a question, well, that's not the speediest solution or this is more performance or speed. Well, when we talk about enterprise great performance is not just speed, but we have to think about reliability, scalability, yes, speed and optimizations, very important. Continuity, compliance, support and maintenance, especially if you're an agency, right, integration, resource planning, performance testing, business continuity, cost and efficiency and user experience. Wherever I put stores, those are where WordPress shines in a decoupled solution. So and I'll show you the or I'll give you the slides later on. That's my opinion. The company I work for is an opinion but you can disagree with that. So we will focus on page speed optimization but we have to at least in the back of our mind think about scalability, reliability and integration because as an agency if you don't think about these then you're going to be plopping out websites and they're going to be coming back and they're going to be failing all the time. So whatever solution or technologies you pick you always have to keep at least these four things in mind when it comes to decoupled performance especially page speed. So I'm going to start with performance comes from planning and hopefully by the end I'll be able to prove this but I'm going to suffix this with a little extra. I think performance has to come from planning because at minimum planning should result in using the right tool for the right job based on the project requirements, constraints and objectives so and we'll talk about more of that a bit later. So when we talk about decoupled architecture performance then at least three things we have to talk about first so this is kind of a graph that I put together where we see the back end with its workings front-end JS server with a front-end JS framework set up and then the browser so sometimes you put the front-end and the browser together but just because we have to talk about the performance differently I put it in separate boxes so we have to talk about browser performance what constitutes as browser performance then we have to talk about front-end performance and front-end architecture and if we have time about a back-end performance or CMS performance optimizations but you'll find out or if you don't know already it's actually better to just hide the whole damn thing and the front-end and the browser should not even know about the CMS should not even know about WordPress as much as we like it because if you're thinking about scalability and reliability you'll have to pretty much use some of the big guys like Amazon Google servers and all that stuff to kind of shield the back-end performance but also the support security reasons to shield the back-end from anyone who's using your website or your web app okay so a little bit about browser performance metrics let me show hands who's familiar with these okay perfect so time to first bite when you use a tool and if you hit me up on Twitter or if you go to my blog there will be a blog post about using tools for measuring performance but this is browser performance because whatever you do on the back-end or on the front-end side eventually what you do will hit the browser right and the client for I guess perceived performance these are the things that matter for them these are the things that Google will measure on your website and that's how you get ranked in SEO when you know your client will these are the things that they will care about and which are first content will paint shortly is when so time to first bite I've grayed it out because usually the tools show you this but this is not browser performance is everything that happens before the browser they usually show it but it's a sign of something else so first content will paint is how quickly the content like text or image gets painted on the browser then we have largest content for paint which is like the biggest image biggest headline or whatever the biggest piece of content is on the page when does that show up then we have total blocking time is base basically while your JavaScript is running it's actually taking off your CPUs thread and nothing else can be done by that time basically your CPU is blocked unless you use something like a party town or something like other tools but usually it blocks your browser completely freezes it until the JavaScript runs so they care a lot about this this is a modern problem of websites now is that total blocking time is huge because of a lot of JavaScript so the next one is speed index is just how quickly the content is visibly populated then cumulative layout shift which is basically as the browser gets populated with the big pieces is anything else shifting which is horrible user experience so google cares about it a lot if you think about youtube or some other web apps they try to have placeholder content of great boxes here and there so there's not a lot of layout shift so that's another important one then time time to interactive which is like the fully interactive website and something called first input delay which is now becoming in 2024 it's going to be interaction to next paint which is sort of like yes you have the browser here are the buttons but you cannot click them yet or even if you click them it cannot process that yet so what is the time difference between you click something and then it's actually doing something right it's very important for decoupled architecture so how does this paint in the long picture right when browser when the website hits the browser usually there's a first time for first byte which is okay there's a handshake in there and you got the first byte back from the server right so that's very important but that's server performance then we have first content for paint and largest content for paint in this case it's exactly the same because the largest content for paint is text but if it would be an image it would need some time to load that in right then we have visual complete and then time to interactive so whatever you're building on the front end the the whole reason for it is to use the tools to get this better to make this shorter and the shorter and the faster you can get it then it was worthwhile to do to decoupling if not there's no point in it so this is just the bonus slide whether you're doing decoupled or non-decoupled on my blog I sort of put together a checklist of things to check if you are being dinged for first content will paint or cumulative layout chip what are things that you should check for this is not specific for the coupled website it's just things that you have to think about okay so when it comes to front end performance it really comes down to this we want to achieve browser performance for set project with requirements well because of set project and with because of set requirements we'll need to choose the right front end architecture for that project but because of the architecture the whole system will have different endpoints inputs or not and outputs and then enterprising that performance means is how do you shield or how do you pad those inputs and outputs with bigger services with amazon stuff and google stuff and whatever you can hire and you can pay for to make sure that your performance is not based on php the limitations of php or based on the limitations of big images or you know content delivery and everything else so if you get this these three things you'll get a and i would say you know if you architected right you will have enterprise great performance okay so how do we choose the right front end architecture that fits your project best so there's a list of questions of course this is not the complete list of questions the first list of questions comes from a client but then after you put your heads together you'll have to ask these questions at minimum with your front end team or dev team what architecture to pick so what browsers are you gonna be running that software in is it mobile more mobile or desktop what are their bandwidth constraints very important what happens if the back end the cms the wordpress side goes down what does the front end do right how does it react then maintaining it how quickly should a visual change in a in a wordpress back end be reflected on the front end sometimes if that's immediate sometimes you can just see the end the whole thing and you can you can wait days right unlikely but sometimes that's the case so based on that plus compatibility for instance is this really an spa that runs by itself or this more of a widget that runs in other people's websites so compatibility how do you how do you frame well how do you architect that framework right plus security stuff usability and so on and so forth eventually you'll come down to one of these it's either going to be a single page application with client side rendering think about youtube or any streaming platform it's either going to be a resource oriented client architecture or a jam stack which is statics in most most in most cases a static asset generation and we'll talk about this a bit later or the client side rendering with pre rendering or universal rendering with service side rendering with rehydration basically a next gsa so the first one is usually in our case when in when we work at urban inside is usually the options are is it an angular app a view app or something like that then is it a gatsby app where we push content generate content and serve it through netlify and cds so the first one is very interactive the third one is very fast when it comes to perceived performance and this is something that were it's the last one is the universal rendering server side rendering between hydration is next yes we're kind of this is where we're going next where it's kind of in between of these two different sides or different ends of the spectrum I should say so let's talk about single page application and the architecture of single page application so when we talk about single page application is what we what we usually talk about is that there's your browser the browser loads the very first call is one of the first calls is you get to load all the javascript that you're going to use and then that builds the app in the client's browser and everything from there on end is going to be api requests back and forth from the app that you built in the browser to the back end and where WordPress comes in of course is it's going to be your cms or you're going to store the data plus maybe api endpoints where the app to with angular that you built in the client's browser is going to be communicating back to the WordPress side and grabbing data from there so that is you what we call SPAs or you get the first assets first and then there's a second line of communication afterwards the issue with this is though when we come to browser perceived performance is that you get a really good first contentful paint however the time to interactive is a bit later because you get your first assets here right all the javascript all gets in here yay the metric the tool thinks okay this is a really fast server but your your app didn't do anything yet right so at that point what you have to do is build the app and while you're building the javascript the browser is frozen right it cannot do anything else so if you take a look at twitch or one of these streaming platforms what happens is it loads up and then things happen and then slowly things start popping in so if you're looking for web app building or dashboards it's very good or if you have to do serious computations in the client's browser it's a very good option but if you're looking for SEO or you know high scores for for google it might not be the perfect option for you but it's one end of the spectrum the other end of the spectrum is jam stack with static site generation so in this case the just like how back in the old old days the browser didn't do anything it just showed what the server put out right so in this case the website gets built on the server side it gets put together from what from the content that's coming from WordPress from template files and it matches them together and it puts out it generates an actual static html file for it and then you can use cdns or whatever to deliver it as fast as possible and that way you get really high scores for performance right but there's a back there's some negativities here as well so in this case what we usually use is gatsby with netlify and workpress as a back end there's some other of course like story block and some other cmss that were specifically built for this architecture which in some cases work better than drupal and workpress because they were built for this however we can have a discussion why we sometimes still choose workpress and drupal over other cmss that were specifically built for this so in this case what happens we gatsby comes and grabs the content from workpress and then it generates a static file and then there's a whole architecture put together to serve the static file as fast as possible to the client and then the client can still come back and communicate with other third-party services or even your workpress for to do what to do authentication search payment processing and all of the other stuff usually this is where the only the content comes from workpress when everything else you have to use other third-party services for so it's really good because the fcp comes in really fast and then maybe you don't even have javascript or you have some little javascript for hiding showing content but there's not a lot of communication through javascript back to the original back end because everything is there uh as you need it the biggest limitations of this is that if the client makes as in your client makes an update on the workpress side changes out the title or changes out the block the whole thing has to run again like you have to grab that content put it into the generator generate static file from it and then serve that static file so it's not immediate as in if they change the content usually takes one to two minutes depending on what type of generation you're doing to actually see the content live right if you can live with that then and you care about SEO and speed optimization then this might be the best architecture for you but there's some other limitations here like there's limited support for complexity and dynamic content but as long as you're like building a b2b website and you want it to be fast and there's not a lot of like dashboard these stuff they are going on or there's not a lot of big content that you have to load in separately afterwards then this is probably the best option for you so for back end uh performance like we can talk about all of those things on the on the left hand side however they will all fail i mean everything will fail because of scalability reliability and business continuity if you have thousands of clients visiting your website per minute right so you can build the fastest wordpress website you can build the fastest Drupal website and you can serve content really fast you're still not going to be able to scale if you're like serving a big museum and they do um like an awesome once in a lifetime thing and you have to sell tickets right so all of that now has to be shielded so almost always for enterprise great performance you have to shield the back end so all of these are still important but not enough for enterprise great performance so you have to either do pure static decide generation or offload the cms the cms content either to um if it's api then to an amazon api manager or a google server or actually your front end no longer talks with the back end anymore it talks to these services specifically so for the for this particular reason i developed fire boost i o which is basically it puts a layer in between your back end which could be wordpress and then it takes the wordpress api endpoints and mimics them in either firebase for google or mimics them on amazon api gateway where the front end is completely agnostic what the back end is it could be wordpress it could be drupal it could be anything else in case of wordpress is just the plugin that you install plus you have to have these paid services from amazon or google but basically at that point the api responses from wordpress gets cached and the front end only ever reads the cache there's no communication like the straight line of communication between your back and your front end there are like modern cms is do it but if we want a modern decoupled cms is like story block and others do it but if we want to compete with wordpress against that for this reason then we have to use services like this so am i convincing you that performance is coming from planning okay all right so we're going to take a look at a few case studies how many minutes do i have probably a few more okay so one website is good hire which is a wordpress website with gatsby here's the team who worked on it uh ben was project manager joe j and jimmy were the developers i want to give credit where credit is due so the structure is we use wordpress with advanced custom fields for structuring data who's familiar with advanced custom field okay uh you could use anything as just the fastest way how we could put together you know um Gutenberg blocks actually so acf we use acf to put together Gutenberg blocks right we use single sign on and some other third party services do that this website is hosted on pantheon the back end the wordpress side is hosting on pantheon really good hosting joe and then and then we're using gatsby on netlify uh as a single site a static site generator it then interprets the wordpress page content it uses graphql the plugin graphql for wordpress to consume the api of the wordpress website and use the data from the api and what we did is we built the Gutenberg blocks that you build on on your awesome back end when you log into wordpress that is actually has a one-to-one gatsby component to it so we only we let you use the gatsby we let you use the acf builder but that's only to to get the data into the database right then that comes out through the api and then uh we consume that through graphql and completely rebuild in uh react all the components on the front end and then we also had to do custom plugin that we had to develop for this is yes you can get the content but other than content there's many other things that you need to do as a website like redirection and like what happens with options it's not just the content on the page so the WP Gatsby plugin that we used so when you save a page it automatically triggers a hook in netlify and it regenerates the front end and it does everything that works if you actually update a page but what happens if you update it just redirect well we need to provide some custom plugins for that right so a few tips here is that you may need to extend the graphql plugin um like if you want to provide json ld data and some other stuff so it's not always easy if you have complexities in the website but if you're just thinking about content and generating static pages from the content you can get away really fast with that with all of those plugins that are there okay so this is actually a startup that i started with fabian this is any authors here anyone written any book everyone okay future future so i guess that would be exciting for you what you do here if you're selling your own book is this is uh an app where you put your isb ends and what we do we generate a little widget for you and go on go out on the web and find everywhere mostly where your where your where your book can be bought at and then we put we put that in a little widget for you because you know not everyone likes amazon right not everyone likes the other bookstores maybe you want to buy it from an indie bookstore and so on and so forth so some authors really like that and this is a widget for them and then of course you could just include that in your own website and everything goes from there so the architecture here was the generator that you saw or i call it generator basically this is a little vue j s app made as a shortcode that we inserted into the b2b website which is work press so we're on the work press website but then when you go up to this page there's this shortcode that builds this little vue j s one page app inside of that page and then everything that you do here gets stored back into work press through the work press api layer right the issue is that okay like we know your isb end we know who you are right we can even actually go out and find the books for you the schedule runs in wordpress actually we use sometimes serverless functions to go out on the web and find the isb ends on a huge list of books booksellers but then what do we do with that because that widget that we generate the one you see the next one right i can move here this can live on the website where we have no control over what's the traffic there we want to make sure that this widget always shows up this content cannot come from work press it has to come from a cdn it has to come from amazon s3 or something like that so this is why we use fire boost i o this is not yet released but if you're interested in this plugin then you can find me on x or once it's released you'll know about it i hope in december but basically what that does is uh again pushes all the wordpress api content off to google firebase in this case or api amazon api gateway so the embeddable widget that you get right now is an iframe hopefully is a script later is never communicating with the wordpress website it's only communicating with the amazon api gateway so that's more reliable right okay the third example is a wealth manager dashboard that the urban inside built with angular we have an nda i cannot talk who's the client and that sort of stuff but the team was tom morresco was the project manager and joe chris and gargay was um the developers they did an awesome job here so again wordpress is used because the b2b website is in wordpress so they're they're a little you know we sell this stuff here on the pages they want to be able to edit that really easily that's in wordpress but there's a lot of data there about the funds right so if you're a fund manager um and you're using the dashboard like why store that data again just go back to the wordpress website and grab it from there right so that's sort of like semi-static content we still go back to the wordpress website and grab it from there the the dashboard the angular dashboard does that and this is hosted on aws amplify uh there's some um this is a very heavy app in the sense it consumes a lot of different apis and sometimes the set of data that the app had to consume to generate the charts that it does is so big that we're actually having trouble uh api amazon api gateway um serving that data just because the json file was that huge right so because of that we needed to um set up some serverless functions where it's actually the serverless function grabbing that data through amazon api gateway and pushes it back to the to the front end not a lot of roles here for wordpress but still if you shield it right well enough it's a perfect tool and our clients loving so where does performance come from hopefully i got that answer all right um any questions i think you were first question is uh so like the first example that you use good higher so the question i have to repeat the question so the question was that in the first example for good high where the we used uh static uh site generation with gatsby what's the project scope in months i guess in that case um it was actually just four months or something like that because the data was there they already had a wordpress website and all they wanted was page speed performance improvement right and then i don't know if i should talk then they messed it up again because of third party javascript and analytic tools and all that good stuff and we have no control hey if your team needs it and it's gonna pack it on there anyway uh but that was a very fast moving project because the data was there the back end was there everything was there all we needed to do is cut workers head off and just build the gatsby side of it to consume it the problem was that that was an inherited project and we have like there were some architecture there on the wordpress side that we have never seen before they used sort of semi like well i guess i shouldn't talk about other agencies but it was very hard to consume that content if it would have been done just with um Gutenberg blocks it's super easy to consume the content but it was a mix of advanced custom fields Gutenberg blocks and the data was sort of messy from the get go so the time was actually lost sometime was lost to re architect that moved data back into Gutenberg blocks and then from with using um graphquiel sucked the data out of that uh structure and then provided to the gatsby part so that was a very fast moving project because everything was there we had the designs we have everything there we just needed to chop it off and move it into gatsby i hope that answered the question well it was probably more than that so three the main developers but there were qoA people and other people involved so um i was wondering fireboost will work with flutter not sure if i'm familiar with it flutter is currently one of the reasons it's a platform that includes applications that goes to websites as well as companies right so fireboost is just something that shields your workplace back end so if you are providing uh api endpoints to whatever and you don't want that whatever to go back and actually reach your wordpress website fireboost shields that and pushes as it's quite dumb to be honest it doesn't know what it does all it knows it takes all of these endpoints of wordpress and caches them on a firebase server right now yes we're i'm gonna do another one for drupal so it's a tool for specifically for wordpress or drupal right now and what it does is takes the cms's endpoints and replicates them one to one as is um on a server somewhere else where you can do scalability performance security and all that stuff at a mass scale yeah right so we rely on oh okay so the question was that if we have experience with containers yeah um we do i don't so but if you if you want that question answered then i can get the right team to answer that from urban inside yeah so there are there are specific things in aws that you have to do to increase performance or lower cost and we have actually gergay if you want to reach out to him he's the director of infrastructure who would know more about that any other question yeah so the question was how would multi how would fireboost i o work with a multi site uh and hundreds of changes per minute and that sort of stuff so fireboost would be working it's a plugin it works as a plugin so as long as i haven't tested with multi site it's still not out it's going to be out in december but basically what it does it's a plugin that whatever you do in work press it doesn't care about you can as you install as you update content if it's available on the work press api endpoint it will know about it and it will push it up to the server and um it doesn't necessarily care about the like how many times it updates because it just pushes that out so it's you might need a different level of service on google or amazon based on how many communication but i don't think that's an issue it's more of a consumption issue usually um it doesn't care about it it's just as soon as it finds an update hook and it finds the endpoints that were updated it pushes that out to fire uh to google uh firebase and um it's just there the specific reason why we have to use it and that that's when it got developed with that widget was that we have gonna have hundreds and thousands of books hopefully right for free and um we don't we don't want to manage that data in work press or get that data from work press the work press site individually can push that out to uh to google firebase as is and as long as your your json endpoint is okay on work press it will just replicate it there's there's not really a big performance thing there as soon as it hits it knows about it and pushes up you update it pushes up you update it's very dumb in that sense you don't have too many controls if you want to do controls you do that by managing your own work press api endpoints it can deal with custom endpoints it can deal with the endpoints that come with work press it doesn't matter if it's a custom endpoint you have to let it know about that and when you set it up but at that point it just reads oh there's a change i'm gonna push it up there's a change i'm gonna push it up so it should be no problem but to be honest i haven't tested it with a multi-site yet so that's probably in the future something thank you all for coming if you have more questions uh they will uh let me see us today and tomorrow so we can bring in if you're buying them here you can give a lot more information thank you very much thank you