Just like any other good JAMstack site, we want our NUC site to be statically generated. So how do we go about doing that? Well, so far we've been using the npm run dev command in order to start our development server. However, this won't work for final deployment.
Instead, we need a command called npm run generate. Let's run that and see what happens. output slash public, and that one initial route was rendered with the crawler. Now, that's not quite right.
Remember, we had three routes. We had the home page and the two project pages. At the time of this recording, Nuxt is still in the release candidate phase, and so there's still a few bugs with it before they actually get to a stable release. What I found is that this is actually a caching issue with Nuxt.
So in order to get around this, I will go up here, delete my node modules directory, and then rerun npm install to reinstall all my dependencies. Right? Now let's try running generate again. All right.
This looks a little better. Now we have a home route rendered for us as well as her two project routes. Okay. So what has this generation actually done for us?
html files for each of our projects. Cool. output public. This is just for better platform support and to make it a little bit more like it used to be in Nuxt too.
Now when we open up the generated HTML files, we should be able to see our content statically inserted into the HTML. So on the home page, my name is in there, so I'll search for Daniel. And yeah, sure enough right here inside of an H1, we have that statically generated HTML. Pretty cool.
The same thing applies, of course, to the project pages as well. html inside of the Toast maker for, let's say, Toast. Yeah, once again, in the H1, there we have our content from StoryBlock. Very nice.
Now, in order to actually preview this in the browser, we need to run the npm run preview command. All right, now we have our generated site available at localhost 3000. I'll copy that and then open it up over in my browser. Awesome.
Here we have our statically generated page, and if we were to inspect the page source, we'd see once again that that content is statically generated inside of the HTML. Cool. Another thing we could do here is test out the performance of our site, since that's one of the benefits of having a site on the Jamstack. To do that, I'll use Google's Lighthouse tools.
I'll start by opening up a new incognito window, that way no browser extensions interfere with my score. And then let's visit our site again. In the DevTools, at the top here on the far right, we can see Lighthouse as one of the tabs available. I'll click on that, and let's first start off by testing our score on desktop.
Lighthouse will take just a moment, it'll reload our page, test things like how fast it takes to download the page, how fast it takes to paint the page, and so on and so forth. And as you can see here, performance on desktop is at 100%. So we get a perfect score for performance. Pretty sweet.
Our first contentful paint only took half a second, as did pretty much everything else on here. Now I will admit I cheated just a little bit. I had some styling issues. and my cumulative layout shift score was a little off before I recorded this video, but I added a few styles inside of the codebase in order to fix that.
So if you're getting any lower score here, check out the source code for this lesson and you can copy those same styles. Sweet. Now let's give it a try on mobile. I'll close out the DevTools and then open up the Lighthouse tab again.
This time let's choose mobile. As you might expect, it's harder to get a good performance score on mobile, as typically they are slower devices on slower networks. But our statically generated site scores almost just as well. In fact, here we have a 97, and if I was still in grade school, my mom would definitely be happy with that.
Though my dad might have haggled me a little bit over those lost three points. But for us, I'd say this is great. Just like any other good JAMstack site, we want our NUC site to be statically generated. So how do we go about doing that?
Well, so far we've been using the npm run dev command in order to start our development server. However, this won't work for final deployment. Instead, we need a command called npm run generate. Let's run that and see what happens.
output slash public, and that one initial route was rendered with the crawler. Now, that's not quite right. Remember, we had three routes. We had the home page and the two project pages.
At the time of this recording, Nuxt is still in the release candidate phase, and so there's still a few bugs with it before they actually get to a stable release. What I found is that this is actually a caching issue with Nuxt. So in order to get around this, I will go up here, delete my node modules directory, and then rerun npm install to reinstall all my dependencies. Right?
Now let's try running generate again. All right. This looks a little better. Now we have a home route rendered for us as well as her two project routes.
Okay. So what has this generation actually done for us? html files for each of our projects. Cool.
output public. This is just for better platform support and to make it a little bit more like it used to be in Nuxt too. Now when we open up the generated HTML files, we should be able to see our content statically inserted into the HTML. So on the home page, my name is in there, so I'll search for Daniel.
And yeah, sure enough right here inside of an H1, we have that statically generated HTML. Pretty cool. The same thing applies, of course, to the project pages as well. html inside of the Toast maker for, let's say, Toast.
Yeah, once again, in the H1, there we have our content from StoryBlock. Very nice. Now, in order to actually preview this in the browser, we need to run the npm run preview command. All right, now we have our generated site available at localhost 3000.
I'll copy that and then open it up over in my browser. Awesome. Here we have our statically generated page, and if we were to inspect the page source, we'd see once again that that content is statically generated inside of the HTML. Cool.
Another thing we could do here is test out the performance of our site, since that's one of the benefits of having a site on the Jamstack. To do that, I'll use Google's Lighthouse tools. I'll start by opening up a new incognito window, that way no browser extensions interfere with my score. And then let's visit our site again.
In the DevTools, at the top here on the far right, we can see Lighthouse as one of the tabs available. I'll click on that, and let's first start off by testing our score on desktop. Lighthouse will take just a moment, it'll reload our page, test things like how fast it takes to download the page, how fast it takes to paint the page, and so on and so forth. And as you can see here, performance on desktop is at 100%.
So we get a perfect score for performance. Pretty sweet. Our first contentful paint only took half a second, as did pretty much everything else on here. Now I will admit I cheated just a little bit.
I had some styling issues. and my cumulative layout shift score was a little off before I recorded this video, but I added a few styles inside of the codebase in order to fix that. So if you're getting any lower score here, check out the source code for this lesson and you can copy those same styles. Sweet.
Now let's give it a try on mobile. I'll close out the DevTools and then open up the Lighthouse tab again. This time let's choose mobile. As you might expect, it's harder to get a good performance score on mobile, as typically they are slower devices on slower networks.
But our statically generated site scores almost just as well. In fact, here we have a 97, and if I was still in grade school, my mom would definitely be happy with that. Though my dad might have haggled me a little bit over those lost three points. But for us, I'd say this is great.