Date post: | 09-Aug-2015 |
Category: |
Social Media |
Upload: | aldenustream |
View: | 119 times |
Download: | 1 times |
Code compilation / build
Much less http requests
Tools: • concatenation • uglify / yuicompressor
http://www.flickr.com/photos/halfbisqued/2353845688/
Code compilation / build
Compile all the js that the current page might need:
Several smaller files
Compile all js that we need: One huge file
Create js groups according to page needs
http://www.flickr.com/photos/halfbisqued/2353845688/
Code compilation / build
Compile all the js that the current page might need:
Several smaller files
Compile all js that we need: One huge file
Create js groups according to page needs What is the problem with that?
http://www.flickr.com/photos/halfbisqued/2353845688/
Code compilation / build
The given feature is used on the page, or
The visitor might use it on the page
"the current page might need" One page gets n+1 new feature: The js compiled group for that page grows even more heavy
Do we really need it onLoad? Lots of unused code, that waits for the user: overhead, slows load time.
http://www.flickr.com/photos/halfbisqued/2353845688/
Async loading!
Load only the most necessary js onLoad!
Then, for every feature the user wants, load the js runtime.
http://www.flickr.com/photos/thenationalguard/8029811025/
• Feature based code, not page based code
• Small lag in UX, but faster page start
• Loose module coupling, better code
Code compilation / build
Compile all the js that the current page might need:
Several smaller files
Compile all js that we need: One huge file
Create js groups according to page needs
And what is the problem with that?
http://www.flickr.com/photos/halfbisqued/2353845688/
Dependency handling
The problem with predefined js groups:
http://www.flickr.com/photos/wongjunhao/2761709029/
• add js by planned use (add a feature, that can be used)
• add js by failsafe use ("this might come
handy" or "make sure to have this") • group is built at deploy