The cosmetic filtering data embedded in the content scripts has been
extracted in corresponding JSON files. When a list is enabled, the
corresponding cosmetic filtering data from the JSON files, if any, is
persisted into the extension's local storage.
The cosmetic filtering-related content scripts will load the data
from these JSON files on-demand only and matching cosmetic filters
will be extracted, then the result is cached in the session storage,
ensuring there is no longer a need to perform lookup for the rest
of the browser session.
As a result this further reduces the time to First Contentful Paint.
Related issue:
https://github.com/uBlockOrigin/uBOL-home/issues/557
To minimize delay to First Contentful Paint. The idea is to avoid
complex data structures such as Map in order to speed up first content
script execution. Use stringified arrays where practical and
instanciate those arrays from their stringified representation only
when there are actual cosmetic filters to apply.
Related commit:
https://github.com/gorhill/uBlock/commit/6039ef2b6d
Related issues:
- https://github.com/uBlockOrigin/uBOL-issues/issues/5#issuecomment-1575425913
- https://github.com/w3c/webextensions/issues/403
Currently, there is no other way to inject CSS user styles than to
wake up the service worker, so that it can inject the CSS styles
itself using the `scripting.insertCSS()` method.
If ever the MV3 API supports injecting CSS user styles directly
from a content script, uBOL will be back to be fully declarative.
At this point the service worker is very lightweight since the
filtering is completely declarative, so this is not too much of
an issue performance-wise except for the fact that waking up the
service worker for the sole purpose of injecting CSS user styles
and nothing else introduces a pointless overhead.
Hopefully the MV3 API will mature to address such inefficiency.
2023-06-04 11:32:55 -04:00
Renamed from platform/mv3/scriptlets/css-specific.js (Browse further)
