preload-webpack-plugin
preload-webpack-plugin copied to clipboard
Toggle preload/prefetch based on chunk.initial (or a callback)
The current plugin requires that you choose between a single rel: 'preload' or rel: 'prefetch' value that applies to all of the <link>s.
The problem is that rel="preload" is appropriate for subresources that are used immediately, and rel="prefetch" is appropriate for subresources that are lazy-loaded or used on a subsequent navigation. It's possible to have a mix of of those two types of subresources in different webpack chunks.
I'm in favor of changing the way rel works as follows:
- If a string
relvalue is specified in the config, then always use that for all<link>s. - If no
relvalue is specified in the config, then usechunk.initial ? 'preload' : 'prefetch'to determine therelvalue for each<link>. - If a function
relvalue is specified in the config, then pass in the file path and chunk and use the return value to determine therelvalue for each<link>. (This is similar to whatassupports, but instead of being passed just the file path, you'd also pass in the chunk.)
CC: @addyosmani
Thanks for filing this issue, @jeffposnick. You're correct that the current implementation enforces a "choose one or the other" decision and there are opportunities supporting a mix of the two could enable that are worth us exploring. I'm quite open to us looking at a better model.
I'm in favor of changing the way rel works as follows:
If a string rel value is specified in the config, then always use that for all s. If no rel value is specified in the config, then use chunk.initial ? 'preload' : 'prefetch' to determine the rel value for each . If a function rel value is specified in the config, then pass in the file path and chunk and use the return value to determine the rel value for each . (This is similar to what as supports, but instead of being passed just the file path, you'd also pass in the chunk.)
On first glances, this proposal sounds quite reasonable to me. I might have a little more feedback once we've been able to try out an implementation against a real Webpack project to see whether our assumptions above hold well. Would you be open to trying out the above in a branch? 😄