All language subtitles for 006 Running a Test Build & Reducing Code Size_Downloadly.ir_en

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.