Now there is no configuration to decide what resources we want to push to the client.
So if it is returning client we are pushing all the resources even if he has it.
If the http2: push will be a function we could decide if we want to push and what.
It will be huge client optimalization.
Now we have something similar in shouldPrefetch and shouldPreload
Besides file and type we need request to check for cookies or some other headers and response to set some output.
This is just example how we could use new implementation.
(isReturningVisitor is some custom logic that check for client cookies)
render: {
http2: (req, res, file, type) => {
return isReturningVisitor(req) === false && type === 'script'
}
},
Than for example nginx can read the push headers and push the resources.
Nuxt can do even better out of the box.
New visitor
Returning Visitor
Of course it could be great if developer could overwrite default behavior or disable it.
I am working or PR on this
This would also allow pushing assets based on user agent 馃憤馃徎
@awronski Hey! How is it going? :relaxed:
@manniL Still experimenting, need more time. Will give you know.
propably I will do something like this:
http2: (req, res, assets) => {
[ ... ]
return array
}
it will be more powerfull. User will decide what links to return.
The automode (http2: true)will return only new assets as described in the second commend.
@manniL I see that there is already a undocumented option to filter push assets:
I will extend it to make it more flexible
Sounds good! Please make sure to not introduce breaking changes for it (even though it's not documented 馃檲)
@manniL It is not possible, because shouldPush accept only single file and I need to pass req, res and the array of all push assets.
The present signature is:
shouldPush(fileWithoutQuery, asType)
I need something like this:
shouldPush(req, res, publicPath, preloadFiles)
I can introduce one more option to http2 to make it backward compatible. But it will be very confusing for the users.
What do you suggest?
@awronski Thank you for the good idea.
I want to know a bit further what's the reason for using a batched shouldPush instead of current one ?
If it's really necessary, I suggest you add a new method pushAssets which is more semantic and won't break the compatibility and may add a deprecated log info in shouldPush.
Using the existing shouldPush function wouldn't allow for much flexibility. Passing all assets to a http2.push function would be great and it avoids breaking changes.
Using the existing
shouldPushfunction wouldn't allow for much flexibility. Passing all assets to ahttp2.pushfunction would be great and it avoids breaking changes.
@tillkruss Agree
@clarkdo Now you can only filter the assets that you want to push but you don't know the user state.
If we add a third parameter, which is a function pushAssets(req, res, publicPath, preloadFiles) we can conditionally push assets to the user (based on the cookie value, user type etc)
If the user has already some assets why to push them again. It will make the app faster.
If you agree, I will push the changes. I will leave the shouldPush as it is and and new option and document it.
Completely agree with Clark here.
@awronski That sounds like a good idea 馃憣. Please make sure to touch shouldPush and just add a console warning when someone calls it (in dev/debug mode).
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.