JavaScript Start-up Performance

https://medium.com/@addyosmani/javascript-start-up-performance-69200f43b201

by chriswwweb • 9 years ago

304 130 9 years ago

medium.com

SCdF• 9 years ago

Ship less JavaScript.

Please do. The fastest code to parse is the code that doesn't exist.

amelius• 9 years ago

Except it doesn't make sense if the JS code expands to a number of machine instructions that would take longer to transfer over the network than the transfer and parsing of the JS code combined.

diogofranco• 9 years ago

Although it is hard to believe that JS code would be exactly the best compression for those machine instructions.

yunolisten14• 9 years ago

Ship less JavaScript

posted on a site shipping 456.1KB of packed JavaScript

M4v3R4• 9 years ago

Good point, but to be fair, author probably doesn't have any control over this, as this is default for all Medium blogs. It's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.

yunolisten14• 9 years ago

author probably doesn't have any control over this, as this is default for all Medium blogs

The author made a statement

Ship less JavaScript

They chose to post on medium, they could have posted the content anywhere. They chose to give us the above lesson, while ignoring it. Do as I say, not as I do.

it's another question why Medium decided it is a good idea to ship almost 80k lines of Javascript code for a page whose only purpose is to display a blog post.

Who cares? Why not simply stop using such shitty services?

tambourine_man3• 9 years ago

And yet another question is why would a technically apt person, and one obviously concerned with page optimization, choose to give up control of how their content is served.

Jakob• 9 years ago

Interestingly enough this is one of the websites where deactivating JavaScript results in a much _bigger_ payload (mostly because images are eagerly loaded without JavaScript and lazily with JavaScript activated).

- Bytes transferred without JavaScript: ~2MB

- Bytes transferred with JavaScript: ~600kB

yunolisten14• 9 years ago

Interestingly enough this is one of the websites where deactivating JavaScript results in a much _bigger_ payload

No. If you have JavaScript on and scroll through the article the page load is 2.8MB.

sosuke• 9 years ago

I deactivated JS and got a 240KB payload finished in 1.58 s. Chrome 56.0.2924.87 (64-bit)

I scroll through the page and no more data is transferred.

I guess what I'm curious about is how you see images at all since I don't get them unless JS is turned on.

dalore2• 9 years ago

At the median, developers shipped 410KB of gzipped JS for their pages.

Well I guess Medium isn't far from the median.

joshfarrant• 9 years ago

Well done.

bartread3• 9 years ago

I had to laugh at this but, and I'm not making excuses for Medium here, that is sadly lightweight compared with a lot of sites on the web.

Still, the "ship less JavaScript" comment rings true: people need to stop cargo-culting all the things into their front-ends. It's colossally annoying at the best of times, and the more-so when you're browsing over a 3G connection. You can basically forget using a lot of websites nowadays if you haven't at least got 3G, and plenty aren't that great on anything less than a 4G connection.

hacker_92• 9 years ago

"Precompiling JavaScript?

Every few years, it’s proposed engines offer a way to precompile scripts so we don’t waste time parsing or compiling code pops up. The idea is if instead, a build-time or server-side tool can just generate bytecode, we’d see a large win on start-up time. My opinion is shipping bytecode can increase your load-time (it’s larger) and you would likely need to sign the code and process it for security. V8’s position is for now we think exploring avoiding reparsing internally will help see a decent enough boost that precompilation may not offer too much more, but are always open to discussing ideas that can lead to faster startup times."

Surprised there was no mention of webassembly, which does exactly this.

tomdale2• 9 years ago

WebAssembly doesn't give you access to DOM APIs, so it's not like you could rewrite Angular in wasm, for example. Most load time/parse time discussions are in the context of web frameworks, but they're typically not able to benefit from the performance improvements of WebAssembly, particularly given the overhead of moving data into and out of the wasm context.

stupidcar3• 9 years ago

Access to DOM APIs isn't part of the MVP, but it is listed as a high-level goal[1] and is specced as a future feature[2].

[1] https://github.com/WebAssembly/design/blob/master/HighLevelG... [2] https://github.com/WebAssembly/design/blob/master/GC.md

dualogy6• 9 years ago

Well such object references and also string handling (not first-class representation in asm.js/current-wasm either) is just a lot of pointer munging really --- realistically I don't see many of today's framework writers re-expressing their visions at that level, plus in the browser context you need them to be "safe pointers"/"references" managed carefully etc.. can of worms. wasm/asm.js' prime use cases are certainly in high loads of real-time numerical calculations, I'm not just talking games or shader-helpers (and sciency/other simulations whether in academia or commercial solutions) but also envisioning faster, neater in-browser apps evolving for all sorts of media (pics/vids/audio/360°/etc) handling/editing/munging etc.

s_m_mcguire2• 9 years ago

Not first class access, but you can call arbitrary JavaScript via FFI. An approach that worked fine for me was to use a simple object which holds your DOM handles via incrementing numeric IDs and pass them back to your Rust (or C++) code. I found the FFI overhead to be non-existent compared to the actual DOM work as well.

falcolas• 9 years ago

need to sign the code and process it for security

If they don't do this for JavaScript, why would they start doing this for compiled code? Unless they're expecting platform specific byte code, in which case V8 becomes superfluous (perhaps another win for consistency).

zwetan• 9 years ago

surprised about this specific part

"bytecode can increase your load-time (it’s larger)"

how come bytecode is larger than plain text?

I don't know the specifics of the V8 bytecode, but for the AVM2 which load pre-compiled ActionScript as bytecode, the load time is faster, faster than the JVM for example.

eberkund• 9 years ago

I'm guessing because for many operations that are a few characters to type in JS actually require many, many byte code instructions to represent.

geocar2• 9 years ago

I am surprised at just how much faster the iPhone is than the next nearest Google device (a laptop). I haven't used an Android device for a long time, but I hear the "Apple is overpriced" so often that I assume someone has been checking this out.

M4v3R4• 9 years ago

Actually this is probably thanks to Safari's JS engine. From the graph [1] it seems that Safari is roughly 3x faster than Chrome parsing and compiling JS code on the same Macbook Pro.

[1] https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_...

Klathmon3• 9 years ago

Yeah, Safari has stupidly fast startup times compared to Chrome. It's one of the big things that they are working on in their engine.

It's been a bit, and I'm going from memory here, so forgive me if i'm wrong, but...

V8 is introducing a new "interpreter" mode to help here so that the page can start being interpreted ASAP and no JIT overhead needs to force the system to wait until it's done a first pass. And in the long run they want to pull out 2 of the JITs in their engine to simplify the process and speed up the first execution (along with reducing memory usage, and simplifying the codebase to allow for faster and easier additions and optimizations).

It's a great move, but it means that things are going to get slightly worse before they get better.

The "old" V8 had 3 compilers, "Fullcodegen", "crankshaft", and "turbofan" [0]. The current V8 has those 3 + Ignition [1], so it's just adding more on now. But over time they will be removing crankshaft and fullcodegen and it will leave them with a really clean and fast engine [2].

If anyone is interested, [3] is a fantastic talk on this and other plans they have for V8, and it's very accessible for those who don't know a thing about JS engines.

(sorry about the links to google sheets here, it's the only place I can seem to find the infographics)

[0] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[1] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[2] https://docs.google.com/presentation/d/1OqjVqRhtwlKeKfvMdX6H...

[3] https://youtu.be/r5OWCtuKiAk

edit: Removed comment about edge, it was more assumption than anything.

jinwood• 9 years ago

Its a combination of that and Apple's A10 chip being significantly faster than the top Qualcom chips at single thread: http://www.tomsguide.com/us/iphone-7-benchmark-results,news-...

DanHulton• 9 years ago

iPhones aren't simply faster at JS, they're faster at everything. Benchmarks run in the same app always come out drastically in the iPhone's favour.

Granted, this isn't a strict apples-to-apples comparison, but the differences are so drastic and always in Apple's favour. That, combined with the actual, physical differences in speed of the processors on the phone itself, indicates that it's not just Safari.

nallerooth• 9 years ago

JavaScript performance on Android have been lagging behind iOS for years now. (https://meta.discourse.org/t/the-state-of-javascript-on-andr...)

bartread3• 9 years ago

Yeah, and that's becoming quite an old thread (2015), yet the most recent comment is from Nov 2016, and if you read backwards from there it's a pretty strong indicator that the issues are still extant. It's a real PITA. My soon to be replaced (but I like the small form factor a lot) iPhone 5S from 2013 whups the ass off my OnePlus Two from early 2016 when it comes to JS and canvas rendering performance.

vegabook• 9 years ago

yes indeed. It looks like the iphone 7's time is around 150ms (Safari), whereas my galaxy s7 takes well over a full second (Chrome).

dingo_bat• 9 years ago

You should use Samsung internet. Much faster and smoother than chrome. Also supports ad blockers and has a nifty reading mode.

stupidcar3• 9 years ago

Apple have actually put effort into improving single-threaded performance. Whereas competing Android handset manufacturers have wasted effort on a internecine MOAR CORES = BETTER!!! marketing fight.

JustSomeNobody• 9 years ago

I've been a mac user for a few years and this year switched back to iPhone as well. I figure if JS developers don't want to address the speed issue[0], I might as well invest in a company that will.

[0] They are always too busy saying, "Just use React".

hesarenu2• 9 years ago

Would a few milli second or few seconds be worth it by paying like 3 or 4 times to a low end android mobile?

geocar2• 9 years ago

That honestly isn't the reason I got an iPhone, but you raise an excellent point: for a 600x improvement in speed, and less advertising, one only has to pay 4x the price.

mschuster91• 9 years ago

Hmm. Usually browsers cache the raw CSS and JS assets - could that be improved so that browsers cache the compiled CSS/JS? That wouldn't help for the first load, of course - but quite a lot for sites like newspapers which are not SPAs but bundle a metric ton of JS cr.p for each page load.

edit: Chrome actually does that, as mentioned in the article - but what about Chrome Mobile and Firefox/Safari/IE?

hacker_92• 9 years ago

From the article:

"Chrome 42 introduced code caching — a way to store a local copy of compiled code so that when users returned to the page, steps like script fetching, parsing and compilation could all be skipped. At the time we noted that this change allowed Chrome to avoid about 40% of compilation time on future visits, but I want to provide a little more insight into this feature:

1. Code caching triggers for scripts that are executed twice in 72 hours.

2. For scripts of Service Worker: Code caching triggers for scripts that are executed twice in 72 hours.

3. For scripts stored in Cache Storage via Service Worker: Code caching triggers for scripts in the first execution.

So, yes. If our code is subject to caching V8 will skip parsing and compiling on the third load."

underwater• 9 years ago

Soemthing I've wanted for a long while is the ability to warm the codegen cache. It should be possible to instruct the browser to load and parse JavaScript so that on subsequent page loads execution can begin immediately. This would work really well with the model that Sevice Workers are moving towards.

bzbarsky• 9 years ago

Firefox is adding something similar. See https://bugzilla.mozilla.org/show_bug.cgi?id=900784

jijji• 9 years ago

Why not have the js engine, i.e v8, parse and compile one time, and then refer back to this object code each time to eliminate the startup delay... Either an http header cache-control flag or something similar.

Klathmon3• 9 years ago

TFA says they are doing something like that already.

throwanem2• 9 years ago

I love that this article, which is quite good, appears on a site whose every page crashes and boot-loops multiple times in iOS Safari and has to be repeatedly reloaded by the browser, presumably running less of its code each time, in order to correctly render some text with images in it.

Sort of gives added point to the thesis, by providing a marvelous example of something you should never, ever do.

HalfwayToDice• 9 years ago

The website crashes this Macbook Air Mavericks too. Absurd.

throwanem2• 9 years ago

I mean, if I were on something older than an SE, I'd shrug and figure it was fair enough, since iOS devices do seem to age badly in my experience. But seriously...

jerianasmith• 9 years ago

Right,Generally programs store the crude CSS and JS resources - could that be enhanced with the goal that programs reserve the accumulated CSS/JS? That wouldn't help for the principal stack.

cramforce• 9 years ago

The article talks about that in great detail.

isoos• 9 years ago

Slightly related: pre-parsing code and loading already initialized application state is available for the Dart VM for a long time now, and the technology yields faster startup times:

https://www.dartlang.org/articles/dart-vm/snapshots

dchest• 9 years ago

and in V8 https://v8project.blogspot.ch/2015/09/custom-startup-snapsho...

czbond• 9 years ago

My take on the JS performance 1) wait for CPU’s of mobile to catch up with current JS flow [not acceptable, but easiest path ] 2) Web Assembly to create native experience or 3) something like Elm as a JS replacement (front end compilation). We know interpreted langs are slow - however JS is slow now where people see it most [Front end]… they don’t see the slow of “back end”. For example, if a user had to wait for “npm install” when they used the server the first time. The JS community has a great habit of adding “all the things” for significant bloat. [module for leftpad, and lots of go-arounds due to the language being bolted on for it’s current use rather than designed from the ground up]. It’s 6am in Cali…so take it with a grain of salt.

txprog• 9 years ago

I'm confused.

One of the idea behind CDN for javascript/css is to leverage caching by reusing the same resources across websites. But then optimization tools said we should bundle everything into one javascript, which delay the loading time, but defeat the initial purpose.

I wonder if the caching could be more intelligent, by recognizing libraires bundled into the "big" javascript that website delivers, and parse only the new content.

whatever_dude• 9 years ago

It's not black-and-white. More of a balance kind of thing.

Bundling everything together is best, unless the cases where it isn't and you need some kind of file to be shared globally. Not necessarily in a global WEB context; just the site's own context works too. You want assets to be cacheable.

Regardless, big libraries on CDN's don't make as much sense nowadays as it did maybe 5 years ago. It's not like everybody is still using jquery. There's too many different mainstream libraries, with too many versions.

efxzsh• 9 years ago

What about https://svelte.technology/ ?

spankalee2• 9 years ago

I'm always shocked at how reluctant sites are to actually ship less code, and I think some of this comes down to a needed shift thinking in what an application is, what modules are and how to use imports.

One thing I've heard recently is "My app is big, so it has a lot of code, that's not going to change so make the parser faster or let me precompile".

The problem with this is thinking that an app is a monolith. An app is really a collection of features, of different sizes, with difference dependencies, activated at different times. Usually features are activated via URLs or user input. Don't load them until needed, and now you don't worry about the size of your app, but the size of the features.

This thinking might stem directly from misuse of imports. It seems like many devs think an import means something along the lines of "I'll need to use this code at some point and need a reference to it". But what an import really means is "I need this other module for the importing module to even _initialize_". You shouldn't statically import a module unless you need it _now_. Otherwise, dynamically import a module that defines a feature, when that feature is needed. Each feature/screen should only statically import what it needs to initialize the critical parts of the feature, and everything else should be dynamic.

In ES2015 this is quite easy. Reduce the number of these:

    import * as foo from '../foo.js';

and use these as much as possible:

    const foo = await import('../foo.js');

Then use a bundler that's dynamic import aware and doesn't bundle them unnecessarily. Boom, less JS on startup.

calvin2• 9 years ago

You still need good solutions for bundling assets because network connections aren't free.

The approach you advocate can have adverse side-effects to web performance. It would help with the initial load time due to reduced initial JS, but if you end up loading a few or dozens of additional JS modules asynchronously you're talking about a lot of extra HTTP requests. Over HTTP 1 that's a big problem, and even over HTTP 2 each additional asset sent over a multi-plexed connection has overhead (~1ms or more).

ehsanu1• 9 years ago

Where's this ~1ms overhead for an additional asset on a HTTP2 connection coming from? Do you have a reference to a benchmark or something that demonstrates it?

spankalee2• 9 years ago

I did say use a bundler :)

saosebastiao• 9 years ago

Ship less JavaScript.

Except for the fact that it is nearly impossible without a dedicated team for optimizing your code. Because javascript is so hard to optimize and eliminate dead code. With es6 modules that could potentially get better...but good luck with getting the rest of your libraries (and the 5 bajillian level 2+ dependencies that they require) on board with that.

A decent first step would be for nodejs to deprecate commonjs and only use es6 modules, and force libraries to update or be deprecated. So lets have this discussion 10 years from now.

sotojuan• 9 years ago

With Webpack 2 or Rollup and a judicious attitude towards dependencies you can get most of the way there.

rounce2• 9 years ago

A decent first step would be for nodejs to deprecate commonjs and only use es6 modules...

How do ES6 modules solve this? You do realise they are mostly sugar?

spiralx• 9 years ago

No, ES6 modules aren't just syntactic sugar over CommonJS modules, they are a different type of module entirely. One big difference is that ES6 modules have a static structure so that you can determine imports and exports from the source code alone, unlike AMD or CommonJS modules which determine their imports and exports dynamically at runtime. Import and export statements can only occur at the top-level of a module and don't accept expressions of any kind, so they can't be conditional or accept parameters.

This means if your application is only using ES6 modules then newer bundlers such as Webpack 2 and Rollup can perform "tree-shaking" - statically analysing your codebase to determine what code paths are used, and then pruning dead code from the final bundle.

So if your code imports something like Lodash with hundreds of functions but you only call one of them, then only that one function will be in your final bundle.

afghanPower• 9 years ago

I think more people should look into Clojurescript with it's advanced optimizations which I believe could help achieve the goal of "shipping less javascript".

kebolio• 9 years ago

Would have like to have seen Firefox's particular handling of this, but it seems like the author's definition of "browsers" (plural) == Chromium.

gleb• 9 years ago

I am surprised iPhone 7 looks to be 4x faster than 6s. Is this running the same iOS version?

hawski• 9 years ago

I'm wondering how desktop and Android Firefox compares to provided performance figures.

atonse2• 9 years ago

Ship less JavaScript.

Not at all the message I got from this. Because judging by Safari on mobile and desktop, clearly the issue isn't Javascript, it's that for whatever reason, with all the insane resources behind V8 and Android, they're simply unable to get their interpreters to reach the speed of Safari or Edge.

I'd understand if nobody could make JS go fast, but clearly Apple and MS are proving in real-world-ready code that JS can be quickly parsed and executed.

kbutler• 9 years ago

Yes, Safari seems to beat everybody, and Apple's mobile processors excel at single-thread performance.

However, Edge doesn't appear to have an advantage - the graph shows chrome on a Thinkpad T430 beating Edge on the same hardware.

Also, it shows the Nexus 5X (Qualcomm 808 processor) beating the Pixel XL (Qualcomm 821 processor).

Is this accurate? Seems fishy, but I haven't run any benchmarks.

https://cdn-images-1.medium.com/max/800/1*dnhO1M_zlmAhvtQY_7...

rtpg• 9 years ago

given Android's execution model (closer to a desktop OS, with many things running in userspace, constant context switching) compared to iOS's "one thing running at a time" model (closer to a game console OS), my guess is that Android benchmarks are less reliable.

Not that it discounts the massive advantage to apple on perf.

Touche2• 9 years ago

No, iPhones are super high end phones, no amount of engineering resources is going to make a $200 Android phone have as fast of JS performance.

atonse2• 9 years ago

$200 Android phone? Look at the Pixel XL and the Galaxy S7 Edge. They're also about 10x slower than the iPhone (hard to tell since the numbers aren't precise enough but it's a HUGE difference).

Basically the state of the art of Android is where the iPhone 5S was. Is that phone even on sale now?

steveadoo• 9 years ago

I'm not sure the Angular 2 AOT bit belongs here. Angular 2's AOT just parses your HTML into the backing angular component classes. It's still all Javascript that has to be loaded and parsed.

r1ch2• 9 years ago

I don't think things are going to get better until browser makers (or Google) start forcing things. It's fine to say "Use less JS" but without an incentive, things aren't really going to change.

Looking at how HTTPS adoption has grown with Google giving HTTPS sites an SEO boost and Chrome giving scary warnings, I wonder if the solution isn't to do the same with JS. Throw in some SEO incentives for pages with minimal JS and see what the market does.

moxious• 9 years ago

The market is already incentivized; if the performance of your site is lousy, people won't like it. I think fiddling with SEO incentives is too big of a hammer to swing at what is basically a very narrow technical problem, overall JS parse volume.

r1ch2• 9 years ago

The sad thing is people are so used to this modern web crap that I don't think they will stop using it. The Facebook "we crashed the app and users never stopped coming back" experiment comes to mind. Sure, technical users like anyone on HN will probably know what it could be like, but a lot of users likely have no idea how fast the web can be. A site that takes 2 seconds to load is "fast". 5+ seconds to load an article on mobile while the page is jumping all over the place is "normal".

tbrock• 9 years ago

Wow, I definitely feel this. I just switched from an iPhone to an Android device and it does seem like a second class phone experience.

The gap between all recent Apple phones and even the best of the best Google and their partners offer with respect to mobile web perf is staggering.

abalone• 9 years ago

Worth noting: Safari 10 is 3X faster at parsing than Chrome 55, according to their chart. (See the MacBook Pro lines.)

This is not mentioned or discussed despite all the thoughts on how to speed things up. Anyone know what Safari is doing?

JavaScript Start-up Performance

Related Stories