Comments (2)
Hey @tristanbes!
Sorry for getting back slowly. Thank you for this! I was implementing this feature as a non-expert on this stuff, and was indeed lacking feedback from people that know more than I do. Let me reply a bit out of order:
- The prefetch strategy is missing and can't be handled globally or per entries
I purposely left this completely unimplemented, because it's a but more complex. As you correctly said:
if you know that a visitor is likely to visit page B after visiting page A, it would be interesting to apply either the prefetch strategy
I haven't given this much thought. I think your idea makes perfect sense... but it also might make sense to do this entirely in the controller - e.g. have some service where you can basically say "Hey! prefetch all the assets from entryB
". I'm honestly not sure which is the more "proper" place. So, indeed, maybe we add it both places.
- Because it can hurt web performance to push large assets using the link header
Can you tell me more about your understanding of this. Again, my expertise here is low, which is why O created the original PR (PR's push conversation... but in this case, I got no "push back", which is why it was merged as-is"). My initial impression had been that preloading all the assets was basically a way to tell the browser, just a little bit earlier (before parsing and finding them in the HTML) that it should start downloading those assets. However, the:
it will likely prevent the browser from scheduling everything smartly
part makes me pretty sure that I'm missing the point on something.
- Because it's not flexible enough, sometimes you just want to preload the resource and not push it (which require http2) with the nopush attribute
If you were trying to give some recommendations to someone that's not too familiar with all this stuff, when would you recommend "wanting" a push versus a nopush? There are kind of two goals with this feature: (a) to make it technically possible to add all the preload, nopush, etc attributes and (b) to create a framework so that users (who may not be experts on these new features) can make "reasonably good" decisions. Just adding some ability to add nopush
accomplishes the first, but not the second.
- The key is confusing, preload is not true when you have HTTP2 protocol. It will push the asset to the client and not preload it. Only if you're stuck in HTTP1.1 protocol, it will "only" preload it.
Hmm, this is interesting. So for example,
Link: rel=preload; </app/script.js>; as=script;
This same header will behave differently based on if the server supports HTTP2 or not? It will either preload or push, which, are two different things and should probably be used in two different situations? If so, that's a very complex thing to try to get right. It makes me think that nopush
should be the "default" way this behaves:
Link: rel=preload; </app/script.js>; as=script; nopush
(this would "preload" but not push, in all cases, right?) and then have the user specifically opt into push because they know they want it and can support it.
In general, your proposal (2) makes sense to me... I think :). It leaves me with a few other questions:
A) Will users sometimes want different preload, prefetch behavior on CSS vs script tags?
B) What about fonts & images embedded in CSS? Those are currently not preloaded
C) If it is as simple as "here's the behavior I want for all assets for a specific entry point" (this is my question A), should the configuration for this belong in YAML (like your proposal)? In Twig when rendering the assets? Or even in Encore (webpack.config.js
) when setting up your assets (i.e. addEntry()
)?
Thanks for your time!
from webpack-encore-bundle.
My turn to apologize, I took some days off :)
If you were trying to give some recommendations to someone that's not too familiar with all this stuff, when would you recommend "wanting" a push versus a nopush?
Here are a couple of use cases for when to use Push:
Instead of inlining elements in your HTML (such as small CSS or JavaScript) separate them into their own files and Push them to the browser instead. This allows you to better leverage browser caching.
Push is also great for utilizing think time in a more efficient manner. As a server generates a website’s HTML file no further requests can be made by the browser as it must wait until the HTML file is received before knowing what to request next. However, depending on your server’s think time you can use it to your advantage by pushing necessary resources to the browser along with the HTML file, once generated.
Here are a couple of use cases for when to use Preload:
Loading critical CSS that is discovered late
Loading above-the-fold images referenced within a CSS file
Loading fonts references within a CSS file
Only resources served from your domain can be pushed, while you can preload resources from any domains.
Preload and push are not using the same cache
Preloaded resources goes inside a memory cache, that is only for the current page/browser tab
Pushed resources goes inside a push cache that is linked to an HTTP/2 connection which is purged when the connection is terminated. Since an HTTP/2 connection can be re-used across multiple tabs (not true for all browsers), the resources from this cache can be used across browser tabs.
Flow chart to help decide which strategy to apply:
This same header will behave differently based on if the server supports HTTP2 or not?
My current understanding of this is yes, it will behave differently. It depends of wether the webserver or CDN supports push or not. If it supports it, it'll push the asset, if not, it'll tell the browser to preload it.
It will either preload or push, which, are two different things and should probably be used in two different situations?
Yes, it'll either preload or push them depending of the capability of the server/CDN.
If you server does not support push, then you would use preload
instead of push. In this case, there is less difference and potential negative impact using this strategy than when you have to choose when to preload and when to push when you server support push.
It makes me think that nopush should be the "default" way this behaves
I'm not sure about this, but I have no points in favor or against it.
A) Will users sometimes want different preload, prefetch behavior on CSS vs script tags ?
I'm not sure I understand the question, can you elaborate please ?
B) What about fonts & images embedded in CSS? Those are currently not preloaded
The current "best practice" of this is to preload webfonts/images that are referenced inside external CSS because they are discovered "late" by the browser;
C) If it is as simple as "here's the behavior I want for all assets for a specific entry point" (this is my question A), should the configuration for this belong in YAML (like your proposal)? In Twig when rendering the assets? Or even in Encore (webpack.config.js) when setting up your assets (i.e. addEntry())?
I think it should be either in a .yaml
configuration, or inside the .addEntry()
method.
I also think we need a way to override this configuration when you call {{ encore_entry_script_tags() }}
with extra parameters.
Note that the prefetch
strategy can't be handled via those methods, it needs to be handled when calling it on the twig template: {{ encore_entry_script_tags('entry.a', { strategy: 'prefetch' }) }}
that will output
<link rel="prefetch" href="https://example.com/dist/runtime.js">
<link rel="prefetch" href="https://example.com/dist/app.0.js">
<link rel="prefetch" href="https://example.com/dist/app.1.js">
Note that today, it's not working, nothing is outputed in the HTML like reported on my issue.
To conclude, those problematics are complex to apply (like any fine-tuning), so a global config or preset to cover most cases, in my point of view, is very difficult to implement.
from webpack-encore-bundle.
Related Issues (20)
- Webpack Encore context directory issue
- Yarn warning when updating webpack-cli to v5 HOT 1
- Missing entrypoints.json when installing from scratch on Symfony HOT 1
- import js & css files from TwigExtension with stimulus controllers HOT 5
- Unknown "encore_entry_link_tags" function HOT 4
- Add Twig function and filter for Stimulus Outlets integration HOT 2
- Move Stimulus helpers to UX repository HOT 1
- Unable to preload links: feature not supported HOT 4
- 2.0 not usable with symfony 5.4 (twig-bundle conflict) HOT 1
- recipe update not working HOT 3
- Error when reusing Symfony web server SSL certificate HOT 1
- preload + integrity hash + cloudflare HOT 2
- assets base_path parameter not considered by encore_entry_link_tags and encore_entry_script_tags functions HOT 5
- TagRenderer EntrypointLookupCollectionInterface , encore_entry_script_tag issue HOT 4
- PreloadAssetsEventListener does not use integrity hashes HOT 6
- Package installation is broken on SF 5.4 is broken HOT 1
- Deprecation with Symfony 6.4: Symfony\WebpackEncoreBundle\CacheWarmer\EntrypointCacheWarmer::doWarmUp() ... HOT 2
- package.json not updated
- ock content hash
- encore_entry_link_tags incorrectly querying manifest.json
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpack-encore-bundle.