1. Introduction to Rendering Methods and Strategies
So, hi, everyone. I'm so glad to be here and I hope that you enjoyed the talk that I will give today. My main goal of today is to tell you all the problems that we face while building sites, while rendering our web applications, that we end up having a bunch of web rendering methods to use nowadays, and I will show you the history behind them.
2. Server-Side Rendering and Static Site Generation
Server-side rendering allows for prepopulated HTML to be sent to the user, improving performance, CEO, and security. However, slow connections and increased server load can be challenges. Static site generation solves these issues by generating pages during build time and caching them in a CDN.
But what happened? They will not wait forever. So if your performance is not okay, they will not wait for your page to be rendered and that will not be indexed in the search engines. So what was the solution to this? Our next hero, the server-side rendering.
So you are getting the benefits from client-side rendering, but the first load will be really performant. And that's one of the benefits. We improve the performance in the initial load because we basically have the prepopulated HTML. We have better CEO because now search engines don't need to wait a lot for the page to load because it's just the first page. And then, we improve security because everything that we need to call to the APIs, the API tokens will be in the server, so you don't need to have in your API, in your client, the API tokens. That's really cool.
But what happens with this? Of course, if we were using server-side in the old times, we didn't have the interactivity that we have nowadays with the universal app that Next and Next provide. But nowadays, it's not a problem anymore. The problem is that we have bad and slow connections. So basically, if you are in Nigeria and your data server is in America, you will have, really, a bad metric for the time to first byte, the Core Web Vital. So basically, it will take still much to load for some people, so that's not good. But the real villain here was the increased server load. Now, it demands more performance from the servers to generate the HTML because they are the ones in charge of that. And the number of server was way higher because now each time a user enters on your site for the first time, they will call the server, and that means money for the business. So if you don't have a website that has real data or maybe something that is really changing over time, maybe you don't want this solution because it's not made for your site. Imagine a publisher or a newspaper. Maybe they just have a static content. That's where the Nest Hero came.
So basically, now we have a static site generation. A static site generator generates pages during build time. So when we develop our code and we push it to our cloud, basically, we run a process that will generate the page and that page will be cached and saved in the CDN. The CDN is a content delivery network that is close to your end user. It has multiple nodes across the world.
3. Rendering Methods and Build Time
This rendering method offers fast performance, cost savings, improved SEO, and enhanced security. However, it lacks interactivity and is not suitable for user authorization or data processing. The main drawback is the build time required for static site generators. Gatsby introduced the first site generation method, which generates important pages and dynamically renders others for optimal performance.
4. Incremental Static Regeneration
Now we have less build time because we only build important pages. We keep the benefits of static site generation for SEO and performance. Next introduced incremental static regeneration, which reveals only the changed parts of a website. This technique allows us to support dynamic data in static sites and provides faster real times. However, it had limited support in the beginning and was inconsistent for real-time updates.
And the benefits are quite obvious. Now, we have less build time because we are only building some pages that we think that they are important. And we keep the static side generation benefits because we have SEO and performance. This is really cool.
But what happened? Only Gatsby supported in the beginning. Not everyone was using Gatsby. And, of course, in the new community, no one. And we increased complexity. Because we need to manage to communicate with the marketing team, with the business team, which pages are important, which are not. And they start deciding which one will be the first or not. But the real problem was small changes. What happens if I change a title? That I will just try to run again the build process, remove all the cache pages that I created with the cloud worker, and again start the process. So what's the main point of catching everything if at the end I will remove everything and start again? So that's why Next decided to create incremental static regeneration. So it's a technique using static site generation to reveal only the parts of a website that have changed. Instead of regenerating the entire site every time.
So basically now we have a page that is already populated from the server. And we have a version 1 cache. When the user enters, it will start a revalidation process that will generate a new page and will be saved in cache for later. But the first user will see the stale version, that is the v1, and the next user that enter after the seconds that we specify in their validate process, they will see the new data. So now Vercel also made this available for Next so we can use it in the VUE ecosystem and this is just mind blowing. If you have the chance, you need to use this rendering method because it's just amazing.
But basically, the benefits of using this is now we support dynamic data in static sites. That sounds really weird because you will say, well, I will use the But if you have this kind of content, it is better to use incremental static regeneration. And we have availability because each time a user enters, we will see always the big one. Of course, we will not see the first time, the first data that you have in your database but we will see the page that you created in the beginning. And you will have faster real times because only the pages that are important will be built in the beginning and the others will be generated in the servers. Something similar to the first site generation. But the problem here was that it has limited support in the beginning, only Next was providing it. Of course, now Next, so it's okay. But what happened? What happened with this method is that it is inconsistent for real-time updates, at least in the beginning.
5. Incremental Static Regeneration and On-Demand ISR
The first visitor triggered the revalidation method, resulting in different versions of the page being seen by different users. To address issues like unavailable products in an eCommerce platform, the on-demand ISR was created. This allows you to trigger the revalidation process for specific pages, improving efficiency. Meanwhile, developers were working on a new solution.
So basically, the first visitor to a page triggered that revalidation method that I explained you but first, it's a full back page, so basically the V1. And another user was seeing the V2 of that page. So they were seeing different things. And if you have an eCommerce platform and you have a cart, maybe a guy was trying to buy something that was not available anymore. So that was a problem and for that, they resolve it, creating the on-demand ISR, the 2.0 of incremental static regeneration. Because now, you can call to the revalidation process from your actual API or Helm's CMS. So imagine that you are editing a page and you just publish can run the revalidation process only for the page that you want to change instead of waiting for the user to enter your site and start that process. That's what actually a solution. But in the meantime, all the developers were creating a new one.
6. Edge Rendering and its Benefits
Edge rendering is a technique where web content is served directly from edge servers. It allows for altering the rendered HTML at the edge before delivering it to the end user. This method works well with dynamic content, reduces network latency, improves scalability, and provides real-time caching.
And this next one was edge rendering. It's a technique where the web content is catch and serve directly from the edge server. It's similar to what we know as CDM, but this time, the nodes are servers and they can run something and have computed power. So basically, now we can alter the rendered HTML that we already built at the edge before delivering to the end user. And the benefits are amazing. It works better with dynamic content. You can have no real time data, reduce network latency because you will have always a server close to your end user, improve scalability because you have a network so you can start changing between servers if there is none available. And then you have real time catching. So basically, you are seeing like a static site, but in the end it's a server in the bottom.
7. Irenrendering and Route Rendering
We have the irenrendering 2.0, which allows us to choose different rendering methods for each route of our website. By using properties in Nuxt, we can define whether a route should be rendered as a static page, incremental static regeneration, or client-side rendering. This flexibility gives us control over how different sections of our website are rendered.
But the problem here is, well, what have them, if we have a project or a website that has so many different sections that we want to build with the same framework? Well, for that, we have the irenrendering. Basically, in the beginning, we were using this for combining server-side and client-side with the universal app. But now we have the irenrendering 2.0, what in Nuxt is called per-routes caching strategy. But basically, now routes can be a static page generating on demand, an ISR, or just single page app or client-side application or server-side rendering. We can choose per each route of our page, a slash admin, if we want to be client-side rendering, a slash blog to be a static site and we can decide which part of our website will be rendered how. The way of doing it in Nuxt is using these properties. Basically, you just define the route that you want to have as a static site or incremental static regeneration. So in the top, you can see the incremental static regeneration version that is SWR-to-true. And if you want to have only a full static site, you can put a static-to-true and SSR-to-false will be client-side rendering. By default, because in the beginning, Nuxt was server-side. But then we end up having everything at once.
8. Introduction to Jamstack Architecture
And what happened now? Well, there is a lot of rendering methods that I can cover in this talk. But in future episodes, we will see what is island architecture.
And that's why you choose a static site generation. And when I was building my website, I thought, okay, I want to create my frontend with Nuxt. I have it clear. But for the backend, I don't know what I want to do. Actually, I don't know if I want to create a backend. And that's why I meant Jamstack. Jamstack is basically an architecture that the couples the Web Experience Layer, what we can call the frontend, from the data and business logic, what we can call the backend. So, basically, now everything is the couple. And we have scalability because, of course, we are just creating a static site that will be hosted in some cloud. And the cloud will be making the bandwidth available for all the users. We have flexibility. We can choose the technology that we want in the frontend and in the backend. And that's what's my main goal. And performance, because we will have a static site on the end. And maintainability, because, of course, everything the couple is easier to maintain.
9. Creating a Repository and Previewing the Site
Basically, I create my own repository to save the content of my website. I select my plan, copy the command, select NUXT stream, NPM, and Europe. I call my repo View London and it will be served in the cloud. I install the packages, create SSL, run the SSL version of localhost, go to the content, and preview my site on localhost.
Basically, this is a story block where I create my own repository to save the content of my website. I create a new space, so I would just say, View London. And once I can find, wait, because yeah, better.
So, if I create the page, I would select my plan for free, I think. I don't know what happened with this when I'm sharing the screen. But, okay. So, now we can go to getting started, and it has a command, that will make all the boilerplate of the project for us. So, basically, I can copy it, ignore the API token, you are not seeing it. And then we will select NUXT stream. And select NPM, for example, but you can choose whatever you like. And Europe, because we are in Europe. And okay. So, I will say, View London, for calling my repo. And I will say that it will be served in the cloud, not locally. And once it's ready, I will say... What we will do is just install the packages. And run the project... Okay. No.
So, now I need to go to View London and install the packages. And once I have them installed, to connect with the shareblock, I need SSL. I will create a maxsert. But this is just for SSL. Ignore it. And then we can run the SSL version of our localhost. And once I have it, what I will do is I will just go to the content. And the content is where all my content lives, basically. And here we can see that there is a URL for the preview of our site. I just want to see my localhost. So, I will just put here really quickly localhost 3000 and save it.
10. Connecting Storyboard with Nuxt Application
Now that I have connected the storyboard with my Nuxt application, I can generate my page statically. By running the command 'yarn generate', the HTML is pre-populated with the necessary data, eliminating the need for API calls. This ensures a fast and efficient rendering process.
So, now that I have it, if I go back, I will see a 404 error because I only have the index page in Nuxt. And for having the index page, I need to add this last, this real path. And now I will have connected the storyboard with my Nuxt application and I can just change everything, and now, if I publish it, I want to generate my page statically. To do that, I will just go to Nuxt and say, okay, generate my page in a static mode, and now I want you to serve the output. And if I serve it, I can see now in HTML localhost. I can see in my network top, over here, that I don't have any API calls because everything is already pre-populated in the HTML generated after I run the command and yarn generate. So basically that was it.
Contact, Mock Data, and Edge Rendering
And I have this slide if you want to contact me or give me any feedback about the talk or everything that we talk about here you can contact me at dantraus in any social media. One of the ones from Lutz was do you recommend to mock data when you need to test a component that calls API? Well I used to do that a lot I would say. Nowadays with Storyblock you have already the JSON file that provides you with all the properties. When you're building websites, let's say you're building a website that is going to be used by thousands of people. You need to really focus on performance. What rendering method would you use? What kind of things would you use to inform? Yeah, actually nowadays what I think is edge rendering is really kicking. Every cloud platform is really pushing this kind of way of rendering our website.
And I have this slide if you want to contact me or give me any feedback about the talk or everything that we talk about here you can contact me at dantraus in any social media. And thank you so much. Thank you, thank you, thank you. That was amazing. Come on, have a seat, make yourself comfortable. We have quite a few questions coming in already. Let's jump into them.
One of the ones from Lutz was do you recommend to mock data when you need to test a component that calls API? Well I used to do that a lot I would say. Nowadays with Storyblock you have already the JSON file that provides you with all the properties. It's easier because you have like a boilerplate of the data you will have in the component when you are creating it. Because basically the component that you create in the Hello, CMS usually is attached to the properties that you will receive in that component. But of course in the beginning when I started creating my website for example, I created mock data to create my components and then started using the Hello, CMS afterwards. So why not? I like mock data. It's cool. I'm just going to quickly refresh mine because I've got some old questions. All right. Perfect. Let's go to the next question, which is... I forgot. Just give me one moment. I'm going to ask my question. While I wait for my phone to reload, when you're building websites, I know you spoke about your sites, but let's say you're building a website that is going to be used by thousands of people. You need to really focus on performance. What rendering method would you use? What kind of things would you use to inform? I know you covered this in your talk, but I just want you to go a little bit more into it.
Yeah, actually nowadays what I think is edge rendering is really kicking. Every cloud platform is really pushing this kind of way of rendering our website. And if I think in the long term, if I want to have a site right now that only have articles, it's okay to build it with a static site. But if you think in the long term, maybe you will have a section that will be an eCommerce. So it's always better to use edge rendering or something that will have a server to run from, because in the beginning of course you don't think about an eCommerce platform, but in the end you will have it if everything goes well, you know. So yeah, edge rendering.
Hybrid Rendering and Slide Design
Every site is one step away from being an eCommerce platform. Hybrid rendering allows us to choose rendering methods per route. There are many rendering methods to explore, and the future holds even more possibilities. The slides were created using Figma and inspired by a TV show. The speaker also received compliments on their design choices and was asked about their NUTS jewelry.
So every site is one step away from being an eCommerce platform, my takeaway.
Okay, we've got another question. Will hybrid rendering be the future of web content rendering? For example, autoselected rendering. I've never heard of autoselected rendering. Selected rendering? Autoselected rendering. But maybe it means hybrid rendering like how to select very truly. Makes sense. Yeah, I think it's really cool that the frameworks can do that for us, because we don't need to create a new project from scratch, only to build our project in that way. We can choose per route what we want. So yeah, hybrid rendering I think is also cool. But of course, edge rendering is not part of that, so it's like you need to be sure that you only want the ones that the hybrid rendering is providing you. Client side, server side, static or incremental. Yeah, there's so many. Yeah, there's so many... It's really interesting, because I thought I knew most of the rendering methods, but there was so many that I learned about today and seen the future of what's coming up. Yeah, the future ones are like... There's still so much that I need to learn.
Also, a big shout out for Anonymous. But 11 people upvoted. We really, really like your slides. I like your slide design. Oh, thank you. What goes into your design choices when you're picking slides? Well, actually, I made them myself with Figma. So I was sitting down seeing a series of unfortunate events, the TV show that it's based on, and I was drawing the faces of them. And then I realized, okay, maybe I can do something with this. And for that, I created the slides. That's awesome. That's awesome. Someone else asked, where did you buy the nuts jewelry? Is NUTS then the fashion business? Because, I mean, it's pretty cool. But you mean this one, isn't it? Like the earrings? I think so, yes.
Earrings, Nuxt, Rendering Tools, and I18N
I made my own technology earrings using a 3D printer. While you can't buy them, you can ask for them after the event. When starting with Vue, it makes sense to use Nuxt for its expertise in server-side applications. To choose the best rendering method, check your site's performance and consider the target audience's connection speed. Handling I18N with a static site generator can be challenging due to beta plugins, requiring separate pages for each language.
Yeah, I made it myself because I buy a 3D printer some time ago. So I decided to create my own earrings for technology. So definitely. But I'm not selling it. If you want, you can get but I'm not selling it.
After the event, after she's used the talk, definitely go upstairs, hound her for some earrings for yourself as well.
Someone else asked the question, does it make sense to not use Nuxt when starting to work with Vue these days? That's a good question. Yeah, of course, you can build your own SSR using the Vue plugin and things like that. But I think Nuxt got your back. If something happens, or if you need to upgrade, they will make it for you. So I always prefer to use something that they are building because I think that they are more experienced than me on creating server side applications. So I would choose Nuxt. Nice, stand on the shoulders of giants, my boy.
And also, in your talk, you kind of talked about all of the different ways to inform your choice about which rendering method, but there's so much to take in. And the next question is, is there any tools that you can recommend that helps people to make those choices for the best type of rendering for each route? Maybe we need to create one. Well, what you can do is... A startup. Yeah, no, but what you can do, of course, is check the performance of your site. Basically, if you have a static site that the only way to measure if it's going well is the build time, you will notice it quickly because your site is not deploying until one hour later. But if you have problems, for example, with server side rendering, that's how you can measure it with performance tools. Because basically, you can check the bad slow connection for people that are really far away from the servers and things like that. And for that, it's rendering will fix most of the problems that we have nowadays. Nice, nice.
Okay, the next one has an acronym that for some reason I don't really recognize right now. But how do you handle I18N with a static site generator? I mean translations? Well, yeah. Actually, that's a funny one. Because the plugin that we have nowadays in the models of the Naxaco system isn't working properly with static sites because it's in beta. But I hope that in the end will work. But basically, if you deploy a site with I18N, you will have to have all the pages generated per language.
I18N Deployment and Rebuilding App
If you deploy a site with I18N, you will have to generate all pages per language. Incremental static generation helps with this. There are no potential issues with not rebuilding your app completely every time you deploy, especially for publishers with outdated articles. Users can generate specific content on the fly. You can find more information and watch hip-hop dance videos on Instagram and Adventrals.
But basically, if you deploy a site with I18N, you will have to have all the pages generated per language. Yeah. So that's a lot. Incremental static generation will help with that. Nice, nice. We have an answer for everything. I'm loving this. Expert, expert.
And the last one. Are there any potential issues with not rebuilding your app completely every time you deploy? Actually not because if we think about huge publishers that have a lot of articles, most of them are outdated or maybe from the past. That ones are not important anymore. Maybe for a user that wants to see a specific content, they would generate it on the fly. So incremental static generation or the first generation was created because of that. Because, of course, you want to have 1,000 articles that you created lately in the search engines, but the others are kind of outdated. So it's okay to don't.
Awesome. And last question, just for fun, where can people find out more information about you and watch some of your awesome hip-hop dance videos? Well, the hip-hop is in Instagram only, but the other things in Adventrals, in Twitter, I'm more there. Awesome. All right, let's give a massive round of applause.