So now that we did add environment variables
before we get to deployment,
it's time to do a test build on our local machine
and see if we're happy.
And for this, I opened the terminal again.
and now when I wanna run this build command
which builds our application for production.
And if you run NPM run build
this production optimized build is being produced.
And we also get useful information shown to us here.
We see, for example, which pages are built for the server,
which pages are 100% static,
this with the empty.here
and which pages are dynamic
but were statically pre-generated.
And we see that output here and that's all looking good.
We got the starting page pre-generated,
our 404 was added for us automatically.
Contact page is 100% static
because we don't fetch any dynamic data here.
And then we got posts and deposed detail pages,
which were also pre-generated.
But here we see an issue.
This is red because this posts detailed page.
These pages are too big,
they contain too much JavaScript.
We could deploy it, it wouldn't break
but this is a clear indicator
that we might be doing something in those pages
which is not optimal.
We might be shipping too much code.
And very often that means
that you're using some third party package,
some third party library that is too big.
So therefore, before we deploy something,
let's fix this issue.
And for this, let's have a look at the detail page.
Now this slag page here is certainly not too big.
It doesn't have a lot of code.
We also can ignore any code,
which is only needed in getStaticProps or getStaticPaths.
That code will only execute during the build process
and on the server anyways.
That will never end up on the client
and the code here this size refers to the client side code.
So we can't ignore the server side code.
So this component should be fine.
Therefore, let's explore the post content component.
Here, we all don't have too much code on our own
but we are using a couple of third party packages
react markdown, and this syntax highlighter.
And now you would have to dig into those packages
and find out how big they are.
And I can tell you that our problem here
is react syntax highlighter.
This is huge.
If you visit the react syntax highlighter GitHub repository,
then you actually find out
that they tell you that it's quite big
and that they offer a light build
because the react syntax highlighter
can have a very large footprint.
But the solution is simple, we can use the light build
basically as it is described down there.
The difference between the light version
and the version we're currently using
is that this version out of the box
supports syntax highlighting
for all possible programming languages.
That might sound nice, but it is quite redundant
and it adds a lot of JavaScript code.
In reality,
we are probably not going to include C++ code snippets here
if we are blogging about web development.
And hence using the light build
and explicitly stating the languages we wanna support
is probably the better choice here.
And that's what we can do.
We can also import the styling in a slightly optimized way.
So therefore what I'll do here is I'll import PrismLight
as Syntax Highlighter, instead of prism
and I'll import my styles differently
by diving into style/prism/atom-dark
and then importing atomDark like this.
This will also only import that style then
and no other styles.
And now we need to import the languages
which we wanna support.
And we do this by importing
from react-syntax-highlighter/ dist/cjs/languages/prism/
and then we have different options
like JavaScript for example.
And then we could import this as js, whatever you want.
And we could, of course also duplicate this.
And for example,
all the import css if we wanna support this as well.
And you can simply add all the languages
you wanna support.
So all the languages which you'll use
in your code snippets typically.
Then you just need to register those languages
simply by calling SyntaxHighlighter.registerLanguage
and then the identifier, for example js
that's the identifier
which I also use in my markdown code here.
So we need to import that identifier.
And then as a second argument, that imported language
and I'll repeat that for css here.
And with that, we should have a much lighter footprint.
If we now run NPM run build again
with those changes applied, it will build our site again
and produce all those files again.
And now we'll see that this is much smaller.
It shrank from 320 kilobytes to 114 kilobytes.
And it's also worth noting
that these sizes are before compression,
but Node.js will compress these files.
So once they are served, they are much smaller
and therefore that should be fine.
Now let's also test if that looks good though.
So let's start the def server
to see if our change has broke something
and go to Posts,
and then that post, which has that code snippet
and that still looks all right here if we have a look at it.
So that is working.
Now we have that syntax highlighting
but with a smaller footprint.
And that's why checks like this are important
and why you should always validate your code
and see if you can improve it.
And even here you might find over third-party packages
which have a even smaller footprint.
You might find different ways of highlighting syntax.
There might still be ways of improving these even more
but we already gained a lot here
and we now have a size that's okay.
And therefore now with that,
I think we're ready to actually deploy this.