The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
The network predictor used the HTTP cache as a database to learn browsing
patterns and make speculative DNS prefetches, TCP preconnects, and resource
prefetches. While this provided performance benefits for repeat visits to
frequently-accessed sites, it came with significant costs: I/O on every page
load, CPU overhead for prediction algorithms, memory for caching learned
patterns, and substantial IPC complexity with six message types coordinating
predictions between processes.
A large part of the functionality the predictor was meant to improve is now
available to webdevelopers. HTTP 103 Early Hints allow servers to explicitly
specify resources to preload while generating the response.
And Speculation Rules API will enable content authors to declaratively specify
prefetch/prerender behavior based on their knowledge of site structure and user
intent, providing immediate accuracy without a learning period.
The network.predictor.enable-hover-on-ssl preference is retained as it controls
simpler hover-triggered speculative connections that don't require the
predictor's learning system. This removal simplifies the codebase while
steering users toward more accurate, standards-based optimization mechanisms.
The one feature of the predictor which was never used was learning websites
that are opened soon after startup. There was no action taken based on this
info, and we could already predict this info based on the history database.
Differential Revision: https://phabricator.services.mozilla.com/D276437
This reverts commit 1efe30299a.
Revert "Bug 2002960 - Part 2: Tweak the branches in ScriptLoader::OnStreamComplete to avoid unnecessary operations. r=nbp"
This reverts commit e967997339.
Revert "Bug 2002960 - Part 1: Eagerly reflect the necko fetch count to LoadedScript. r=nbp"
This reverts commit b096c129a4.
Revert "Bug 2002954 - Add nsICacheEntryWriteHandle and PCacheEntryWriteHandle to expose the nsICacheEntry::openAlternativeOutputStream to content process. r=valentin,necko-reviewers"
This reverts commit ca6e20dc42.
This reverts commit c6b62c4029.
Revert "Bug 1997870 - Part 3: Split EncodeBytecodeAndSave into two steps. r=bthrall"
This reverts commit f6fed9057d.
Revert "Bug 1997870 - Part 2: Make BytecodeMimeTypeFor methods take const. r=bthrall"
This reverts commit 751adfcc4b.
Revert "Bug 1997870 - Part 1: Remove obsolete comment. r=bthrall"
This reverts commit cc15fbf365.
Add support for JS::ModuleType::Bytes in Worker and Worklet loaders.
Duplicate Unknown handling and restrict IsModuleTypeAllowed to JS and
JSON modules only.
Differential Revision: https://phabricator.services.mozilla.com/D270803
Given that the in-memory cache doesn't need any followup task, and also
the disk cache should reflect the latest fetch's condition for the fetch count
etc, we don't have to check the already-collecting-delazifications condition
on instantiation.
For example, if the previous fetch doesn't meet the minimum fetch count but
the current meet, the disk cache should be performed with the current fetch's
input.
Differential Revision: https://phabricator.services.mozilla.com/D270108
Valentin Gosu