Could hurt performance

[iLaurens]

My hypothesis is that default setup of this plugin could actually hurt performance. It adds the resource with the highest prio on the network queue. Delaying critical resources when bandwidth congestion occurs or the max connections have been taken. Basically takes away the benefit of lazyloading. If the hypothesis is proven, it would be better to add them as prefetch by default and optionally as preload

See: NOTE: relationship to prefetch -> https://www.w3.org/TR/preload/

[iLaurens]

@igrigorik what are your thoughts on this?

[igrigorik]

I don't think I have enough context here to make an informed comment.. what is the plugin preloading? Note the preload requires as, which specifies the type of resource being preloaded -- e.g. if you as=script then the priority of that resource is the same as fetching via <script>.

[addyosmani]

My hypothesis is that default setup of this plugin could actually hurt performance. It adds the resource with the highest prio on the network queue.

I don't feel I'm following. The default setup here is structured around a developer preloading scripts they know are going to be used for the current session or closely thereafter - this isn't different to how one would manually go about tackling the problem. We don't encourage preloading all resources to avoid excessive network congestion etc.

Perhaps you could share a code sample of where you think the defaults might steer folks astray? Right now, it's been doing what I would expect correctly in my own apps.

[zcoding]

+1
When i first time found this plugin i thought that it would help me optimizing the performance of my site. But actually i was wrong. This plugin is not what i need: I expected the plugin to load some async chunks only after the resources which current page needs are loaded completely. Then when i go to another page the resources of that page are already loaded.

[addyosmani]

Re-reading through this thread, it sounds like this is more of a documentation issue that I need to work on. The plugin has been written with enough flexibility to:

1. Preload resources you've observed to be discovered late in your network waterfall. The onus is on the developer using the plugin to make the right choice of what resources need to be loaded with a higher priority. It definitely isn't the case that we expect every script generated from your Webpack pipeline to fall into this category. It just may be the case that many of these are needed for your SPA to get interactive sooner so preloading them sooner may be beneficial.

2. Prefetch. While the plugin has preload in the name, I personally prefetch my lazy/async chunks while preloading my main bundles to ensure that I'm not running into too much network contention. We're definitely not trying to be too magical here with what is prescribed.

I'll take an AI to better reflect some of the nuance here in the README. In short, folks should be sure that preloading or prefetching specific resources are going to have a measurable improvement (with or without this plugin) - the plugin is there to help you avoid wiring challenges, in particular when your chunk names might be dynamically generated/done in a non-easily deterministic way.