

Lazy Loading Assets - ultimatedelman
http://blog.mightyspring.com/post/91287181277/stop-what-youre-doing-and-lazy-load-your-assets

======
theandrewbailey
Browsers have optimized for "eager" loading. Link your images, CSS, and JS
just like you did when you first learned HTML, then configure your server's
caching headers. For JS, there's the async attribute.

------
dustingetz
Article presents incorrect information as truth.

Optimize for cache hits, then no requests happen!

~~~
ultimatedelman
That may work for a high-traffic site like Google, but what about sites that
aren't in the Alexa top 10 (or even 1000)? ;)

~~~
dustingetz
if your user goes to your site twice, he has your assets in cache.

~~~
modelm2hb
It's not good practice to rely on a user's cache. If they visit your site
twice in a span of a day, they may have already cleared their cache or pushed
your files out with other sites' files.

This article demonstrates a pretty good method to reduce unnecessary byte
transfer which will ultimately speed up page loading.

~~~
theandrewbailey
Caching is still a good idea, because if a user decides to browse to another
page on the same site in the same visit (or refresh/post a comment), a
significant fraction of the data required for it has already been loaded. If a
user does come back, there's always a chance that your stuff will still be in
the cache.

------
wprl
Lazy loading leads to more requests, which leads to more latency, slower apps.
Better to handle this stuff as a build step with RequireJS or browserify.

~~~
ultimatedelman
It leads to more requests, but after page load, and only when you need the
code. Why load code your app isn't necessarily going to use?

~~~
danielschaffer
Because you're making dubious gains saving a couple KB of bandwidth by
sacrificing the responsiveness of your app when you introduce an additional
round trip for each new piece of code. It may look fine for you, but there are
plenty of people that don't have super-low latency, high bandwidth internet
connections.

~~~
trypwire
It's important to understand that there are tradeoffs with lazy loading.
There's a spectrum, right?

On one end, you could serve all of your js bundled with browserify on the
first page load, which, for SPA's will frequently block rendering until the
entire bundle is downloaded, parsed, and executed. If your bundle is small,
who cares? Once your app grows to a large enough size, that initial delay
might no longer be worth it.

On the other end, you could serve almost no assets with the initial page load,
and request what you need when you need it. Your initial render will be
blazingly fast but any first interaction might be slowed by the latency
involved in going to get the relevant assets needed to execute the
interaction.

Somewhere in the middle you may find a solution involving sending half of your
assets initially and requesting the other half when you need them.

It's not helpful to write off various methods of asset loading because of
assumptions about latency, bundle size, or DOMContentLoaded event delay. The
important part of this article is that it speaks to the various approaches to
this problem. I'm guessing the author took the time to weigh the pros and cons
of these approaches, chose this one which particularly works for him, and
wrote about it to share his findings.

This isn't a trivial problem with one solution. Dig into the performance of
your apps while wearing multiple hats and take what works best for your
situation ;)

~~~
danielschaffer
Well put. My (and, I think others) concern with the article is that it
advocates splitting all your code into separate files (great for
maintainability and managing your code base), but then loading each of them
individually on demand (probably a bad idea for all the reasons everyone's
mentioned). I'm a lead dev on a fairly large JavaScript app, and we've taken
that middle route - we use build process with Grunt and RequireJS to compile
our 300+ individual script files into a handful of concatenated files divvied
up by page/component. Our application is large enough that loading everything
at once (even concatenated/minified/gzipped) doesn't make sense, but
RequireJS/the r.js optimizer made it really easy to both figure out our usage
pattern and consolidate our core set of modules. The process we use creates a
different version of our app script for each entry page, and then each page
has its own separate module that can be loaded on navigation.

~~~
trypwire
Definitely, and I think your concerns are valid, but if you found that loading
each file on demand yielded the optimal performance for your app, wouldn't you
go with it? Additionally, I think the method the author is presenting can be
very well suited to both partial bundles and individual files. For what it's
worth, you and I are in similar positions and it sounds like we have very
similar approaches with our own apps. As long as readers understand that this
is one possible solution to a nontrivial problem, I'm happy with it.

