CaptainCodeman
commented
7 years ago I added something similar in a custom build where I map the fragments to routes and then include those in the push based on the request URL.
Right now the first request to the server doesn't push anything, it only starts pushing things once the app-shell is requested, but I'm thinking it should push the webcomponents-loader, the app-shell plus the fragment that matches that route as we know all those are going to be used.
I'm not sure if it should iterate over the dependencies and push those as well (would probably end up trying to push too much and slow things down?). But, on the same subject, I notice that some files already appear to be pushed more than once - it could just be how webpagetest.org reports it and / or AppEngine's implementation, but things like polymer-element.html show up multiple times - so perhaps some knowledge of the app-shell and what would have already been pushed could help with that to de-dupe things?
Example: https://prpl-dot-captain-codeman.appspot.com/ https://www.webpagetest.org/result/170803_CV_1HT7/1/details/#waterfall_view_step1
Currently the push manifest is keyed only by static file paths. That's good for pushing your direct dependencies. But it doesn't solve the case where you want to proactively push a dependency that is lazily loaded only when a particular application route is triggered, since that requires the server knowing something about your runtime application routing logic.
If push manifest keys could be patterns to match against the request URL path, you could then configure pushes that you predict your application will lazily load, e.g.: