[1] https://cdn-images-1.medium.com/max/2000/1*dnhO1M_zlmAhvtQY_...
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.
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.
[0] They are always too busy saying, "Just use React".
posted on a site shipping 456.1KB of packed JavaScript
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?
- Bytes transferred without JavaScript: ~2MB
- Bytes transferred with JavaScript: ~600kB
No. If you have JavaScript on and scroll through the article the page load is 2.8MB.
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.
Well I guess Medium isn't far from the median.
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.
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.
[1] https://github.com/WebAssembly/design/blob/master/HighLevelG... [2] https://github.com/WebAssembly/design/blob/master/GC.md
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).
"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.
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.
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...
Not that it discounts the massive advantage to apple on perf.
Basically the state of the art of Android is where the iPhone 5S was. Is that phone even on sale now?
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';
const foo = await import('../foo.js');
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).
edit: Chrome actually does that, as mentioned in the article - but what about Chrome Mobile and Firefox/Safari/IE?
"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."
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.
How do ES6 modules solve this? You do realise they are mostly sugar?
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.
Please do. The fastest code to parse is the code that doesn't exist.
Sort of gives added point to the thesis, by providing a marvelous example of something you should never, ever do.
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.
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.
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.
This is not mentioned or discussed despite all the thoughts on how to speed things up. Anyone know what Safari is doing?
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.