- [Narrator] As soon as your application is deployed
to server and available to for real users
performance becomes key, and this not only about
the user experience of individual users,
but also cost effective, because inefficient code needs more
resources to run, which forces you to scale up or out.
The suggestions in this video are loosely based on the
performance based practices from the Express website.
We will implement some of them in this chapter,
or I will at least explain them.
The environment varietal NODE_ENV, is not just
a convention to use to distinguish
between different configurations in your code.
It is also used by Express to make assumptions
when it comes to caching and login.
For instance when running in development, templates are
not cached, but compiled for each execution,
which makes sense, because this lets you work on a template,
and seeing the changes without
restarting the app every time.
Of course this comes with a performance penalty
and my test indicate that your application can run up to
three times slower in development than in production.
The two sunburst charts you are seeing here show
the CPU utilization of an application running in development
compared to one running in production,
and it's clearly visible that in development
the CPU is being more busy.
Each segment you see is a function on the step,
for example the little boxes on the upper left segment
on the first chart are just template compiling.
If you want to learn more about this
please look into my blog I've taken from a few years back.
It's also sited on the Express.js website.
Http lets the server and the browser negotiate
if the data sent to the server should be compressed or not.
To enable that on the server side
you need a specific middleware called compress.
After adding this middleware a browser that accepts
compressed responses and all modern browsers do
may be served a synced version of the html code,
which can of course drastically
reduce the data to be transferred.
Let's add this to our application real quick,
so I'm heading back to visual studio code.
First of all before we optimize that, I want to see
the current numbers, so I'm heading over to the website
and opening Chrome developer tools,
and there I will make sure that the cache is disabled,
and entrust reloading the page.
Now let's look at the request for localhost, and we see that
it has right now a size of eight dot eight kilobytes,
and the time is 475 milliseconds.
Now let's go into visual studio code and I'm opening app.js
and of course I have to install the middleware
npm install dash dash save compression
and on top of the page I bring in
const compression equals require compression
Now as for all middleware I have to of course also edit
to the chain of middlewares and I do that right on top.
After line 17 I add app.use compression.
Compression accepts a range of configuration settings,
but we go with the defaults here.
Now I'm starting the application again
npm start, and I'm heading back to the browser,
let's reload the page now, so let's remember we had
eight dot eight kilobytes and let's compare it.
The time stayed the same, but we see that the size is now
three times lower which is plenty.