Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll
Preview
Start a free Courses trial
to watch this video
Fact is, JavaScript loaded in the browser is FAST! It's the sending of code that needs to be optimized. The more libraries we add, the more code we write, the more we increase file size the more we decrease performance. Thankfully there are solutions and best practices that help us keep our JavaScript optimized and fast.
Optimization Tools:
Further Reading:
Why You Should Avoid Using document.write, Specifically for Scripts Injection
Related Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign upRelated Discussions
Have questions about this video? Start a discussion with the community and Treehouse staff.
Sign up
[MUSIC]
0:00
Loading a web app into the browser is very
different from launching an installed app.
0:04
Your users for good reason expect web apps
to be as responsive as installed apps.
0:09
So that means we need to make the delivery
of your app code as fast as possible,
0:15
and that means keeping
your JavaScript lean.
0:20
Remember our performance budgets?
0:24
Before we get into optimizing JavaScript,
I wanna take a second and
0:26
talk about polyfills.
0:30
Polyfills are small libraries that fill
a gap in browsers that don't support
0:32
the features we need them to.
0:36
While they are a great resource,
they are also a performance killer.
0:38
Many developers take an easy way out and
simply bundle all the code for
0:42
all the users.
0:46
But this is a disservice to users
who don't need the overhead.
0:47
To really optimize their experiences,
0:51
we need to be smarter
about loading polyfills.
0:53
There are a number of ways we can do this.
0:56
But to read more I linked to
an article in the teacher's notes.
0:58
It's a comprehensive overview of the
problem and a well thought out solution.
1:02
When building UIs, it's not uncommon
to see developers using large library
1:07
tools like jQuery and jQuery UI.
1:12
While jQuery is a widely used and
respected and
1:14
well known Java Script library,
opinions are changing.
1:17
They're all alternative solutions for
1:21
many of the things that we
used to use jQuery for.
1:23
Let's imagine that we
are working on a project and
1:27
have been asked to add a day
picker with a calendar UI feature.
1:29
We all know that browsers by themselves do
not support this interaction natively, and
1:34
let's not forget about
the mobile experience as well.
1:39
Let's also imagine that we currently
do not have jQuery in our application,
1:43
and are being extremely responsible
about our performance budget.
1:47
Let's build a simple view that
only loads jQuery resources.
1:52
To keep this a fair fight, I have already
downloaded a customized build of jQuery UI
1:56
to only the day picker widget and
supporting features.
2:01
But don't forget jQuery UI has
a dependency on jQuery itself and
2:04
a host of other files you see loaded
here in the head of the document.
2:08
Loading this into the browser
locally without gzip compression
2:13
we see 206k of data.
2:16
Thinking about say our 800K budget,
that's significant was we haven't
2:18
even started to write any code yet
to support this feature.
2:23
Instead of using jQuery,
2:26
let's build this feature using only
resources we need to accomplish this task.
2:27
Let's also see if we can keep
this below 50K initially and
2:32
less than 20K when g-zipped.
2:36
For this project we will make use of
the native HTML5 input type date.
2:38
A date picker specific library called
pikaday and another date picker specific
2:43
library called moment that helps us
normalize the JavaScript date object.
2:48
Let's set up a view that loads only these
resources and see where we weigh in.
2:53
For only loading the raw resources and
the necessary DOM for the new feature,
2:58
we are at 68K.
3:01
Before we get into feature development
there is one thing we can do to
3:03
optimize this for mobile users right away.
3:06
There's no reason for sending the pikaday
library to mobile users since
3:09
they will not be using this widget UI.
3:13
So let's update our code so
that the header request is removed for
3:15
mobile users.
3:18
Now for mobile users, we are around 46k.
3:20
Just for clarification, document.write
may not be the best solution here but
3:24
it works for our example.
3:29
Please see the teacher's notes for
robust solution on writing down elements.
3:31
Now the JavaScript feature itself, we have
a new JavaScript file called feature.js.
3:35
In here we have a handful of
functions to support the design spec.
3:41
I won't go into full detail here about
the functions in the feature file, but
3:44
it is included in the course and
it is well commented.
3:49
Loading this into the browser
we see that we are at 76K for
3:52
a fully developed feature.
3:56
We are well below the 200K we started
with and we can even make this smaller.
3:59
In the next lesson we will look at
some common yet powerful compression
4:04
processes that will really drive down
the total weight of this feature.
4:08
By breaking this feature
down to its essential parts,
4:14
we have really scaled back the amount
of code needed to deliver this feature.
4:17
So far we are looking really good,
but we can do better.
4:21
In the next video, we will improve
on this by introducing some
4:25
really powerful code compression steps,
and a Gulp build pipeline.
4:28
You need to sign up for Treehouse in order to download course files.
Sign upYou need to sign up for Treehouse in order to set up Workspace
Sign up