3 ms·
But couldn't you apply the same argument to many things which cause an initial slowdown (and possibly janking), such as static assets (which won't be cached and
by dmmalam 12y ago
But couldn't you apply the same argument to many things which cause an initial slowdown (and possibly janking), such as static assets (which won't be cached and may need DNS resolved) and JS which will be interpreted until it is jitted. Also the cpu caches will still be cold. Why is this different?
- nostrademons 12y agoSavvy web-developers employ techniques to eliminate those sources of jank as well, eg. static assets are base-64 encoded as data: URLs and inserted via inline JS after the page layout has loaded (note: this technique may not be necessary under SPDY), and JS is late-loaded via the defer attribute with clicks captured and replayed once the JS to service them is available. This is the reason for the jsaction library that Google recently open-sourced. The reason it's different from cold CPU caches is that all these sources of jank can cause a user or potential customer to say "Nope, I want a native app that loads instantly." You should care about sources of latency that are perceptible to the user, not ones that are invisible. We ran a number of tests and found that the time required to render a texture to GPU VRAM was user-perceptible on mobile devices.