Contact emails
alec...@chromium.org, mich...@chromium.org, sligh...@chromium.org
Spec
There is no official spec yet, but instead an "explainer":
https://github.com/slightlyoff/NavigationController/blob/master/explainer.md
https://github.com/slightlyoff/NavigationController/blob/master/advanced_topics.md
This "explainer" was initially put together by Alex Russell, and further refined in discussions with Mozilla (Jonas Sicking and others) and other googlers, thanked at the bottom of the explainer.
Summary
Motivation
The larger goal is to fix the offline web by replacing AppCache as a way of storing and delivering resources according to the needs of the developer, rather than the (in hindsight) poorly-anticipated needs that drove AppCache.
Compatibility Risk
This is a new API and Mozilla has recently issued their own Intent to Implement for this feature. As the spec isn't written, there's obvious risks of divergence in implementation behavior, but implementation will be informing the spec there.
Ongoing technical constraints
The implementation relies heavily on Promises, and as such will require them to ship. In addition, the implementation will be leaning heavily on existing worker and cache infrastructure and so may need to introduce new abstractions to them to support new use cases.
Blink side changes will mostly be around workers and add additional bindings and events to support the API. Much of the heavy lifting around resource delivery and install/upgrade will be implemented on the chromium side.
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes
OWP launch tracking bug?
Not yet.Row on feature dashboard?
Not yet, we should create one.
Requesting approval to ship?
No.
Yep, you're not the only one who says "cool! Wait..what about performance?"The simple response is that NC allows you to skip the network entirely when possible - meaning that even a little bit of slow JS can be faster than downloading a 50k image over a cell connection. It allows things like1) Making decisions about cache policy that are app-specific and not expressible in HTTP headers.For example, if a user does something that modifies a particular object on the server, often from JS you know which pages are instantly stale, at least from the perspective of the individual user who made the change... but the only way to handle this with HTTP today is to make sure, in advance, that those pages are short-lived, so the browser is forced to go hit the server again and get a fresh copy.2) Prefetching stuff out-of-band.For example, sometimes you know in advance, which resources are going to be needed for a particular workflow - for instance a set of images that are shared from steps 4 to 12 of a 14 step data entry task. You can begin fetching them explicitly so that when you get to page 4 the image is already ready. Today you might do that by trying creating Image() tags and hoping like hell that the image load isn't interrupted by page navigation.
3) Efficient in-browser page templatingWhen your app is written in a way where you're mostly serving static html and JSON, and rendering in the browser, you can deliver pages that are pre-rendered to the browser, possibly even assembling pages from shared fragments the way server-side templating systems do. In a way that maintains URLs. Today you'd do in-DOM manipulation during pageload (where it's tricky to avoid layouts + paints)You can mimic *some* of these workarounds using things like SharedWorkers and AppCache today, and there have been attempts (pre fetching/rendering, etc) by browsers to anticipate needs like these, but at some point a trap door like NC can give developers immense control in a way that is specific to their app, that we could never really anticipate.The key thing is that we're allowing the developer to weigh the balance of local CPU vs network latency in situations where the app knows better than the browser what requires a network connection or not.
2) Prefetching stuff out-of-band.For example, sometimes you know in advance, which resources are going to be needed for a particular workflow - for instance a set of images that are shared from steps 4 to 12 of a 14 step data entry task. You can begin fetching them explicitly so that when you get to page 4 the image is already ready. Today you might do that by trying creating Image() tags and hoping like hell that the image load isn't interrupted by page navigation.Would love to hear more details about this and how it compares to existing solutions like link rel=prefetch. I can imagine the differences, but I'd like to hear your thoughts on how NavigationController compares.
My primary concern for now is to make sure that the cost of checking whether a URL has an associated controller is minimal - in particular for all of the URLs which exist now and do not have a controller associated with it. Sites which don't use the feature shouldn't pay for it.
We have experienced slowdowns in the past on Chrome for JS eval in the critical path of network requests (PAC eval, WebRequest extensions) particularly when there are a huge flurry of requests at page load. It looks like you can run multiple instances of a controller at once which may help, but I don't know if IndexedDB or the new Cache object end up acting as a bottleneck in that case due to serialization requirements.
On Friday, August 16, 2013 12:39:28 AM UTC+3, sh...@mobify.me wrote:So, while there are performance implications of giving developers full control of resource loading, I really think it's the best solution going forward. One thing we all have to stop and realize is that when developers want to control resources, they manage to do it - just in non-optimal ways that also have big performance implications. One solution developers have and use is proxying pages and making modifications to resources before hitting the client, which can have big security implications, and does not have the advantage of making decisions based on device conditions. Another option developers have and use is writing alternates to `src` and `href` (such as `data-src` and `data-href`) and loading them after the DOM content is loaded, thus needing to wait for rendering to complete before loading resources. Another option is Mobify's Capturing API, which also blocks page rendering.So when thinking about giving the Navigation Controller the power to control resources on first load, its not a matter of blocking vs no blocking, its a matter of blocking vs the 3 options previously listed.
Those who are willing to accept sub-optimal performance "manage to do it" - yes. Responsive images (which is what you're hinting at), should be resolved via appropriate browser API's (srcset, picture, client-hints, etc). The best option, that is missing from your list, is "the browser does the right thing and does it without blocking the network or rendering stacks".ig
My primary concern for now is to make sure that the cost of checking whether a URL has an associated controller is minimal - in particular for all of the URLs which exist now and do not have a controller associated with it. Sites which don't use the feature shouldn't pay for it.
On Tue, Aug 20, 2013 at 9:20 PM, Chris Bentzel <cben...@chromium.org> wrote:
My primary concern for now is to make sure that the cost of checking whether a URL has an associated controller is minimal - in particular for all of the URLs which exist now and do not have a controller associated with it. Sites which don't use the feature shouldn't pay for it.
This should be very achievable; this decision could be moved fairly far up so outgoing requests can theoretically take totally different paths based on whether the associated document has a controller registered or not (i.e. one branch on one piece of document state is all that's necessarily incurred for documents without controllers attached).