| 05:25 | <MikeSmith> | mathiasbynens: thanks massively for making https://github.com/operasoftware/devopera-static-backup |
| 05:27 | <MikeSmith> | mathiasbynens: the MAMA data alone is still really valuable |
| 05:28 | <MikeSmith> | mathiasbynens: case in point https://cdn.rawgit.com/operasoftware/devopera-static-backup/master/http/devfiles.myopera.com/articles/572/langlist-url.htm (which I am looking at for trying to figure out what languages to prioritize in the language detector in the HTML checker) |
| 05:35 | <annevk> | Woohoo, :any-link is finally landing in Firefox (sans prefix) |
| 05:36 | <annevk> | No more :link:hover, :visited:hover and such |
| 06:21 | <mathiasbynens> | MikeSmith: thanks, and sorry for breaking those URLs |
| 08:09 | <annevk> | JakeA: I think https://github.com/slightlyoff/ServiceWorker/issues/920#issuecomment-233603440 misses a few things that slightlyoff mentioned |
| 08:10 | <annevk> | JakeA: in particular, the without SW scenario doesn't allow for creating the renderer and the fetch to happen in parallel, which is what's being suggested |
| 08:11 | <annevk> | JakeA: in particular, this is about a new tab scenario as I understand it, not navigation within an existing tab |
| 08:12 | <annevk> | JakeA: also, in part it is about the navigation fetch always returning new data, whereas all the subsequent fetches (and pushes) that follow from that are more likely to come from the cache |
| 08:13 | <annevk> | JakeA: furthermore, the with SW scenario doesn't acknowledge the implicit step 1.5, which is making the navigation fetch (and which cannot happen in parallel with creating the renderer since it needs the SW to be there) |
| 08:30 | <JakeA> | annevk: ah, my "With SW" was showing how things happen today, so showing the problem not the solution |
| 08:30 | <JakeA> | Let me make that more clear |
| 08:33 | <JakeA> | annevk: yeah, I'm looking at solutions that could improve this for general navigation, new tab, and maybe even homescreen launch when the browser isn't running |
| 08:34 | <annevk> | Well if the browser isn't running we don't even have a network thread |
| 08:35 | <annevk> | The interesting bit I think is that when navigation happens we might have a network thread/process ready to go, but no render+SW thread/process |
| 08:36 | <JakeA> | Right, and loading that part of the browser first can be optimised to get the request out early. Renderer & SW not so much. |
| 08:36 | <annevk> | This is really only the case for top-level browsing contexts and maybe isolated nested browsing contexts going forward |
| 08:36 | <annevk> | So to some extent having an API in service workers to handle the navigation case differently doesn't feel like scenario solving to me as much |
| 08:37 | <annevk> | But again, maybe there are architectures where the overhead can be much less or non-existent |
| 08:37 | <JakeA> | But my first render is still blocked on CSS, which is a subresource |
| 08:38 | <annevk> | Yeah, but if that's cached and the network roundtrip takes 200ms+, you're still waiting |
| 08:38 | <annevk> | We can assume subresources are in the cache since we also assume the SW is installed |
| 08:39 | <annevk> | But the navigation is what can retrieve the interesting cookie-bound data |
| 08:40 | <JakeA> | In Facebook's case it doesn't |
| 08:40 | <JakeA> | The navigation returns a shell, but it prompts the server to start preparing the user-sepcific stuff |
| 08:40 | <JakeA> | specific* |
| 08:40 | <JakeA> | Unless I'm mistaken |
| 08:42 | <annevk> | Yeah, it sounds like they mostly care about knowing as soon as possible on the server that the user is there |
| 08:42 | <JakeA> | I'm just worried about solving this only for Facebook |
| 08:43 | <JakeA> | The closest thing we have right now is <link rel="preload">, but we want that before the renderer |
| 08:43 | <annevk> | The <link rel=preload> analogy continues to confuse me |
| 08:43 | <annevk> | All we have to go on is a navigation request |
| 08:45 | <annevk> | I actually think slightlyoff's approach is not that bad, modulo naming and optin-optout |
| 08:46 | <JakeA> | Currently the page loads, then they fetch(url) the user data. They want that fetch(url) request to happen sooner, but still receive it via the same mechanism. That's very similar to <link rel="preload"> |
| 08:46 | <annevk> | It should basically be an opt-in to the "user is going to see your app real soon now" |
| 08:47 | <annevk> | I guess it's similar, but rel=preload only makes sense if you already have a document, which we don't |
| 08:48 | <JakeA> | But we might have. And if the navigation request doesn't produce a document, the preloads can be dropped |
| 08:48 | <annevk> | We might have? |
| 08:49 | <JakeA> | A document |
| 08:49 | <annevk> | How? |
| 08:49 | <annevk> | The whole premise is that we don't |
| 08:49 | <JakeA> | Most navigation requests result in the creation of a document |
| 08:49 | <annevk> | Sure |
| 08:50 | <JakeA> | And if our preloads are associated with that potential document, they can be later associated or dropped if the document doesn't appear |
| 08:50 | <annevk> | I don't understand this |
| 08:52 | <JakeA> | Take https://wiki-offline.jakearchibald.com/wiki/Fictitious_entry - it serves a page shell then populates it via fetch(articleDataURL) |
| 08:52 | <JakeA> | That fetch is delayed by the renderer, SW, and executing the JS on the page |
| 08:52 | <annevk> | The scenario we're concerned with is where the user wants to go to example.com, example.com's SW is not booted yet, example.com's document is not created yet, example.com's browsing context process is not done yet, and yet example.com wants to know as soon as possible on its server that the user is coming to them |
| 08:53 | <JakeA> | <link rel="preload"> can make that sooner, just after parsing the page. But what I'm proposing is a way to declaratively say "When you start a navigation to this article, you need to preload articleDataURL" |
| 08:54 | <JakeA> | We're roughly talking about the same thing, but I'm worried that making this a simple ping is scenario solving |
| 08:55 | <annevk> | I don't think the user booting up an app and the OS letting the app's server know that is happening is scenario solving |
| 08:55 | <JakeA> | But a preload achieves the same, but in addition the response is useful |
| 08:56 | <annevk> | I don't think the response was thrown away necessarily |
| 08:57 | <JakeA> | It wasn't in slightlyoff's proposal, but it's a total hack. You end up having to rely on persistence in the global scope |
| 08:57 | <annevk> | That does sound problematic if true |
| 08:57 | <JakeA> | Sure, the SW will *probably* still be alive for the request that needs it, but surely that's a horrible hack |
| 08:58 | <JakeA> | fetchEvent.preflightResponsePromise would be on the fetchEvent for the navigation request |
| 08:58 | <JakeA> | But it's a completely different request that wants that response |
| 08:59 | <annevk> | Yeah, I think it would make more sense to have a startup event or some such |
| 08:59 | <JakeA> | But you'll end up with the same problem |
| 08:59 | <annevk> | That way we also only need to do it for the initial navigation to an origin (+ scope I guess) |
| 09:00 | <JakeA> | You do something in the startup event that you want to pass to a later fetch event… you'll end up using the global |
| 09:00 | <annevk> | JakeA: wouldn't you you just update the relevant storage data |
| 09:00 | <JakeA> | This is what led me to <link rel="preload">, as it (should be) designed to handle these races |
| 09:01 | <JakeA> | Storage is async. Won't it race? |
| 09:02 | <annevk> | JakeA: it's not really clear how preloading assets helps with races if you need to do something more complicated than just returning blobs to the document |
| 09:03 | <JakeA> | annevk: My routes proposal lets you do network stuff and then get a fetch event for the more complex stuff |
| 09:04 | <JakeA> | If we want to go that far |
| 09:04 | <annevk> | But a simple startup ping that you can cache does too |
| 09:05 | <JakeA> | I don't see how you can do with without a high chance of missing it due to races, especially given the time gap between these two events |
| 09:05 | <JakeA> | Even with cache transations |
| 09:05 | <JakeA> | transactions* |
| 09:05 | <annevk> | But they're not for the same resource |
| 09:06 | <annevk> | So either way it's complicated |
| 09:06 | <annevk> | You're assuming a very simple setup that seems unlikely in practice |
| 09:07 | <JakeA> | Navigation starts, preflight ping happens, SW starts up, startup event fired & ping added to cache, fetch event for navigation - served from cache, fetch event from user data - try to get ping response from cache |
| 09:07 | <annevk> | (There might be perf benefits to routes in general though. I wonder if there's been measurements on that yet.) |
| 09:08 | <JakeA> | Given cache writing is async, that seems really racey |
| 09:08 | <annevk> | But is it really just a fetch event for user data? |
| 09:09 | <JakeA> | What else is it? |
| 09:09 | <annevk> | The startup ping could have some information, of which parts of the response are used for further fetches |
| 09:10 | <JakeA> | I don't see how that changes the issue above. You're still storing that response and pulling it out later |
| 09:10 | <annevk> | I wouldn't expect a 1:1 correspondence at all, that seems a lot more like scenario solving |
| 09:10 | <annevk> | I'm not saying the race isn't there |
| 09:11 | <annevk> | I don't see how your solution solves it unless you assume 1:1 |
| 09:11 | <JakeA> | Can you describe the situation you're thinking of? |
| 09:12 | <annevk> | From the UDP scenario they described it seems very clear it's not just a normal resource they're looking for |
| 09:12 | <annevk> | It's just some data |
| 09:12 | <JakeA> | I don't understand the difference |
| 09:12 | <JakeA> | Isn't data a resource? |
| 09:13 | <JakeA> | If I request some JSON, I'm still requesting a resource |
| 09:13 | <annevk> | You're assuming the document needs to know the same stuff the service worker needs to know |
| 09:13 | <JakeA> | I'm pretty sure I have what you're thinking about covered, but I don't know until you describe it |
| 09:14 | <annevk> | Whereas you might well have a bunch of logic in the service worker on startup that updates various assets and such |
| 09:14 | <JakeA> | Do you mean: When a navigation happens I want another request to another url to happen and I want to handle the response in the service worker only, eg put the data in IDB |
| 09:15 | <annevk> | To put data in IDB, to make further requests, etc. |
| 09:15 | <annevk> | I don't necessarily think the request needs to go to a different URL btw |
| 09:17 | <JakeA> | In my proposal you'd saying "for this navigation, perform this preload", and for that preload you'd set up a route that goes to the network then defers to a fetch event |
| 09:18 | <JakeA> | But yes, that's more complicated if we just want to do the ping thing |
| 09:18 | <annevk> | And the document actually needs to make that fetch |
| 09:18 | <JakeA> | Nope |
| 09:18 | <annevk> | Oh, I think I see |
| 09:19 | <annevk> | Because it's a preload it still roundtrips through the SW? |
| 09:19 | <JakeA> | Yep |
| 09:19 | <annevk> | Fair |
| 09:19 | <JakeA> | That's how preload works already |
| 09:19 | <annevk> | So yeah, for routes I think it would be interesting to know the perf benefits beyond startup |
| 09:20 | <annevk> | Sure... But preload isn't normally triggered before there's a document |
| 09:20 | <JakeA> | Yeah, so that'd be the new bit |
| 09:20 | <annevk> | Also, preload is rather handwavy defined still |
| 09:20 | <JakeA> | very much so |
| 09:20 | <annevk> | There's a cache somewhere and I'd like igrigorik_ to define it |
| 09:20 | <JakeA> | Also, needing this + routes just for the Facebook case is pretty heavy |
| 09:21 | <JakeA> | Yeah, I want to know if it's the same cache H2 push uses too |
| 09:21 | <annevk> | Hmm, I guess it sits somewhere close to the HTTP cache if it goes through SW |
| 09:22 | <JakeA> | (I guess not because preload is document-associated and H2 push isn't) |
| 09:22 | <annevk> | Definitely would have to be defined in Fetch |
| 09:24 | <JakeA> | <link rel="preload" preempt skipserviceworker> where "preempt" means the UA can assume this preload exists next time the user navigates to this page, and skipserviceworker skips the SW, would solve the Facebook case |
| 09:25 | <annevk> | Now that is scenario solving |
| 09:26 | <JakeA> | preempt is useful in lots of other situations, but maybe skipserviceworker is yeah |
| 09:27 | <JakeA> | preempt means you could be warming up connections to other origins before the renderer |
| 09:27 | <JakeA> | spinning up their service workers for foreign fetch if needed |
| 09:28 | <JakeA> | But yeah, my only usecase for skipserviceworker is this Facebook one (or at least the only case that I can think of right now) |
| 09:29 | <JakeA> | But doesn't <link rel="preload" preempt skipserviceworker> fulfill all the same usecases you've presented here? |
| 09:29 | <annevk> | No, it doesn't actually give the serivce worker a handle on the response to do further things with |
| 09:30 | <JakeA> | No but the page can |
| 09:30 | <annevk> | That again assumes the page needs to have the app logic |
| 09:31 | <JakeA> | Sure. It could postMessage it to a service worker, or to many service workers. Seems ok |
| 09:32 | <JakeA> | What it doesn't allow is linking the preload to a range of urls |
| 09:32 | <JakeA> | The routing proposal could easily allow that. It's just much bigger. |
| 09:32 | <annevk> | Requiring postMessage() seems cumbersome |
| 09:33 | <annevk> | The server and SW having some kind of startup signal seems like a useful primitive to have |
| 09:33 | <JakeA> | *if* you want to do something with the response, and *if* you only want to do that within the service worker |
| 09:33 | <JakeA> | The SW already has a startup signal. A fetch event with mode navigation when there are no other clients. |
| 09:34 | <annevk> | True |
| 09:36 | <JakeA> | I'm not totally against the idea of a "get ready" server ping. But once you start wanting to do something with that response, it sounds more and more like another preload, especially as the code gets really ugly if you want to use that response in a fetch |
| 09:39 | <annevk> | Yeah |
| 09:41 | <JakeA> | Need to get a handle on what the minimum viable solution is here. Maybe server ping is ok |
| 09:44 | <annevk> | Yeah, but also, can other UAs do networking without a renderer, etc. |
| 09:44 | <kochi> | MikeSmith: is it okay for me to have power to put a label on GitHub issues on https://github.com/w3c/webcomponents/issues ? |
| 09:47 | <kochi> | MikeSmith: probably it's because I'm not a member of https://github.com/orgs/w3c/teams/webplatform, I guess. |
| 09:48 | <kochi> | aha, GitHub has "Request to Join" button on that page! |
| 09:48 | <annevk> | MikeSmith should definitely add you 😊 |
| 09:49 | kochi | waits for it :) |
| 10:36 | <JakeA> | annevk: does this make sense? https://github.com/slightlyoff/ServiceWorker/issues/920#issuecomment-233603440 Trying to get clarification on what the MVP is |
| 10:52 | <annevk> | JakeA: makes sense |
| 10:53 | <annevk> | JakeA: also interesting is whether subsequent navigations need to do the same or not |
| 10:53 | <annevk> | JakeA: or just with cold start |
| 12:44 | <JakeA> | Good point, will add that |
| 13:13 | <MikeSmith> | kochi: I have as the team contact for the Web Platform WG to add you |
| 13:14 | <MikeSmith> | I think she is waiting on an OK by the chairs |
| 15:05 | <annevk> | Domenic: I'll try to get to the adoption stuff by tomorrow |
| 15:06 | <annevk> | Domenic: I think we've given those reluctant long enough to come up with an alternative now |
| 15:08 | <gsnedders> | things I'm not a fan of: seeming subroutines in the spec magically jumping totally elsewhere |
| 15:09 | <annevk> | gsnedders: we accept patches |
| 15:09 | <annevk> | (and I agree) |
| 15:10 | <annevk> | Also, parameters that are not named upfront |
| 15:11 | <annevk> | Directly using a JavaScript property or method |
| 15:13 | <Domenic> | annevk: sounds good! |
| 15:13 | <gsnedders> | annevk: should I file a bug? |
| 15:14 | <annevk> | gsnedders: if it's not URL |
| 15:39 | <gsnedders> | huh, no telemetry far as I can see for encoding usage? |
| 16:25 | <annevk> | Pretty sure we measured things in that area |
| 16:26 | <annevk> | Blink did for API at least |
| 22:57 | <Domenic> | MikeSmith: bugspam on the WHATWG component from Minhhoang1208 <hoangminh120814⊙gc>, ban please? |