[Story localization] Lazy load locale strings on stories

[mszylkowski]

Summary

21 language bundles are currently bundled in amp-story-1.0.js, and contribute towards 8.7kB of the bundle size (about 16% as of Jan 10, probably around 20% after other performance improvements). Larger payloads contribute towards delays in rendering as other assets (like images) are throttled, as well as the more critical logic in amp-story.js and v0.js that should run ASAP.

We want to load only the document language bundle without having to download the other 20 unused localization bundles. We can serve the localization strings from the AMP CDN as JSON files (where we can automatically compute fallbacks) and fetch the appropriate bundle after amp-story.js is loaded.

Benefits:

• More locales: Support 80 languages (translations we have) instead of 20 (what we bundle now).
• Better LCP: Decrease bundle size significantly for amp-story (55.4kB -> 46.8kB), improving LCP.
  • New strings added/translated would increase bundle size considerably.
• No CLS changes: No text from amp-story is displayed on the initial view.
• Fast loading: Compressed locale JSONs can be as small as 0.6kB, and can be inlined in the doc (or preloaded / preconnected since they are served through the AMP CDN).

Currently the uses of the localization bundles are synchronous to the component build stages, but we would need to asynchronously use these resources so we don't block the rendering until the language bundle is downloaded [draft].

Most of the localized strings are used for:

• Aria-label: When async loading the aria-labels for a doc, the labels will arrive before Talkback reaches the buttons given the speed of downloading the JSON. Talkback first reads the title of the doc, which gives a lot of time for the labels to arrive.
• State updates: Can be delayed in the rendering (eg: "video failed to play", "browser is unsupported") because they are not time sensitive and will not cause LCP when added to the page, or UX is broken.
• Extensions: Page attachments (+shopping), interactive components, share menus, amp-consent are not the main content and rarely LCP candidates on the first page. Most of the time they load hidden or on inactive pages, so lazy-loading these strings should not impact UX.

We can work to load the localization strings as efficiently as possible for each serving type:

• Origin: Make the preload tag valid AMP, and always preconnect to the AMP CDN.
• AMP Optimizer: Inline the language bundle similarly to the pre-rendered CSS on origin, marked with the RTV (we could also just preload + preconnect).
• AMP Cache Transformer: Inline the JSON and prevent the request (we could also just preload).

FAQ

1) Does this prevent us from having strings displayed from the beginning of the story?

It doesn't, given how fast the translations get downloaded. This is generally faster than the Poppins font lazy-loaded by amp-story-interactive or amp-story-shopping (which has a size of 8kB per font-weight, compared to 0.6kB for the translations). This results in CLS of 0 for all tests I made with decent speeds, and potentially in the order of 10^-4 CLS on other cases, due to how little the UI would shift (which can be reduced to 0 with good styling). This is unless we want to show a huge string in the middle of the screen initially, in which case the delay between amp-story.js and the translations load could increase LCP just a bit, but the CLS would be the same from adding a large text when amp-story loads, or when the translations load. We could get rid of most of this CLS with SSR or good styles (CLS would only happen if adding the text shifts other things, so leaving the space empty would prevent any CLS).

2) Do we need to signal screen readers the system layer's aria labels are not loaded (before they load)

Screen readers first read the title of the document when a page is accessed, and this alone would give enough time for the translations to load in +99% of cases before the screen reader even has time to reach any buttons.

3) Can we lazy-load the strings of amp-story-auto-ads as well?

Yes, we can either include it on the main locale bundles or have a separate set of bundles. This is not a priority for now though.

Notifications

/cc @ampproject/wg-approvers @ampproject/wg-stories

[gmajoulet]

I very strongly support this.

Key points for me:

• 20% bundle size improvement
• Support for 50+ new languages
• There are ways we can have the 0.6kB JSON loaded very early on so it has practically 0 impact on the rest of the code

[newmuis]

I think this is definitely worth considering, and am happy about the "better LCP" and "more locales" points. I want to see if we can refine the idea further to address a few points:

• We should call out, as a top-level tradeoff, that this makes it so that we would never be able to have a string that is used in a story's initial render. The "No CLS changes" point addresses this, but it's looking only at the current state, not considering future state.
• We should discuss what behaviors this has when used with a screen reader on a slow connection, and determine whether there is anything that could be done to make that better. I don't think this is likely to make it substantially worse (we already have to wait for the JavaScript bundle to load anyway), but I wonder if we can make it clearer to screen reader users what the state of the document is until the strings have been loaded.

[mszylkowski]

The plan is:

1. Use inlined strings if available. On amp-cache the strings for the given version will be inlined. If the version matches the RTV, use the strings inlined and don't install the 20 languages. #37836
2. Add an experiment called "story-remote-locales" (to start testing the implementation) that fetches the localization strings instead of using the ones bundled with amp-story. This will make early usages of the strings fail because they are currently calling the translations synchronously (which is fine because we'll fix that next). #37843
   • If a language doesn't exist, the cache will make the right fallback.
   • Locally it will fetch from localhost; and on deployed stories from the CDN.
3. Make all translations fill the strings async: amp-story, system-layer, unsupported browser, 360, interactives, shopping, consent, hint, info-dialog, pagination-buttons, forms, page-attachment, share-menu. #37303
   • Could be done in multiple PRs to make them easier to review.
   • Check any significant changes to the CLS (not expected to happen).
   • Will need to refactor localization service with changes explained below:
     • Register multiple bundles at the same time so we don't need to check every pending string when ergistering every language and bundle.
     • Add a helper that will localize a template async
4. Clean up synchronous localization code (which will be unused by then).

[mszylkowski]

Update: This was implemented to completion in amp-story, we have an experiment that we need to roll out for the launch, and then clean up the code

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.