When using the AMP toolbox optimizer, we should be able to tell when certain parts of the runtime are not necessary for a given page. We could consider making a lightweight runtime with a smaller set of code that handles a large percentage of pages, and a full one including all the features.
One example of feature not often needed for transformed pages is the client-side static layout logic (applyStaticLayout) in layout.js along with the corresponding CSS in ampshared.css. Another example is some CSS needed for amp-accordion in ampshared.css.
This would need to be included for anything doing client-side rendering (amp-list, amp-mustache, amp-script), but may be omitted for some number of more simple pages.
Some things can also have a lightweight stub implementation in the lightweight version, without breaking the synchronous nature of their heavyweight implementations. For example, url-replacements-impl.js, viewer-impl.js, pull-to-refresh.js (only needed if in a viewer), font-stylesheet-timeout (only needed if using a custom font), document-submit (only needed if amp-form is present).
We could potentially create a variety of binaries, but I think to keep things simple, we could create just two variants. The criteria for which features to include/exclude from the light binary are not exactly clear, there is a trade-off between having more pages with the light binary vs having a smaller light binary.
Using source-map-explorer to get a sense of code size, combined with a survey of existing pages and what features are commonly used could be a good way to prioritize which features to include/exclude.
When using the AMP toolbox optimizer, we should be able to tell when certain parts of the runtime are not necessary for a given page. We could consider making a lightweight runtime with a smaller set of code that handles a large percentage of pages, and a full one including all the features.
One example of feature not often needed for transformed pages is the client-side static layout logic (
applyStaticLayout
) in layout.js along with the corresponding CSS inampshared.css
. Another example is some CSS needed for amp-accordion inampshared.css
.This would need to be included for anything doing client-side rendering (
amp-list
,amp-mustache
,amp-script
), but may be omitted for some number of more simple pages.Some things can also have a lightweight stub implementation in the lightweight version, without breaking the synchronous nature of their heavyweight implementations. For example,
url-replacements-impl.js
,viewer-impl.js
,pull-to-refresh.js
(only needed if in a viewer),font-stylesheet-timeout
(only needed if using a custom font),document-submit
(only needed if amp-form is present).We could potentially create a variety of binaries, but I think to keep things simple, we could create just two variants. The criteria for which features to include/exclude from the light binary are not exactly clear, there is a trade-off between having more pages with the light binary vs having a smaller light binary.
Using source-map-explorer to get a sense of code size, combined with a survey of existing pages and what features are commonly used could be a good way to prioritize which features to include/exclude.