Should I merge it now? Yes.
No blocking findings in the reviewed commit.
I would merge 3645b6d5ee. The old template's layout bindings match the new input map, five public pages produce the same server-rendered content as the base, and both main and generated white-label builds pass.
What changes
Zero components are deleted. The PR removes 53 eager component imports and their repeated template branches from MarketingPageFullPreviewComponent. A new registry loads those same components through dynamic imports. The header stays statically imported, so its projected user menu keeps the existing template structure.
The 345 deleted lines mainly belong to imports and repeated markup. This is different from PR 10845's unused-component deletion. The layout files and their styles stay in the application.
Here, visible means isVisible !== false. All enabled sections load together, including sections below the fold. Scrolling does not trigger the imports.
Code review
Every old layout has a destination
I checked all 54 old switch cases against the new registry. There are 53 dynamic loaders and one static header. Each loader resolves to the expected exported component and selector.
The input audit compared 53 layouts across eight combinations of CMS mode, desktop or mobile preview, and logo synchronization. All 424 comparisons match the old template bindings, including branding inputs and special layout flags.
Server rendering waits for the imports
The loader registers work with Angular PendingTasks and releases it in a finally block. That keeps server rendering from completing before the layout imports settle. After loading, markForCheck updates this OnPush component.
A generation counter discards results from an older request or a destroyed preview. Changes to CMS mode, viewport, logo synchronization and branding rebuild the input objects. The header and welcome-video template remain static.
One failure-handling improvement remains
The imports use Promise.all. If one required chunk fails, the component does not publish any results from that batch, and there is no local error message or retry. PendingTasks still gets released.
I would add a retry or fallback in a follow-up. I did not reproduce a layout-import failure in the successful page checks, and this is not a blocker for this change.
Source: loader and input registry and loading lifecycle.
What the bundle reduction means
| Entry | Base bytes | PR bytes |
|---|---|---|
| Initial JavaScript | 7,130,945 | 7,137,146 |
| Marketing | 1,226,596 | 32,779 |
| Comparison | 1,227,334 | 33,522 |
| Home | 2,791,937 | 1,761,229 |
| Pro marketing | 2,054,629 | 862,509 |
These are uncompressed JavaScript bytes from fresh QA builds. Route rows include their static imports beyond the initial JavaScript. They exclude subsequent dynamic imports, and they overlap with one another.
The 32,779-byte marketing entry is not the whole page download. Each page still fetches the layouts it uses. The saving comes from avoiding the other layouts. Initial JavaScript grows by 6,201 bytes.
In the athletes browser check, all 14 expected layout elements rendered. The requested JavaScript excluded the chunks containing the newsletter, pro-hero and portfolio-album-detail layouts. That confirms the split affects actual requests, not just build labels.
Checks and limits
| Check | Result |
|---|---|
| TopFans QA client and server builds, base and head | Pass. 42 warning groups each. |
| Generated ajwhite QA client and server build | Pass. 42 warning groups. |
| Angular compilation | Pass. |
| Changed TypeScript lint and git whitespace check | Pass. |
| Registry and input parity | 54 layout IDs covered; 424 input comparisons pass. |
| SSR comparison against base | Five routes return HTTP 200 with matching title, description, text and layout counts. |
| Browser rendering | Home, athletes and TopFan vs Patreon render their expected layouts. |
The SSR routes were /, /athletes, /music-artists, /topfan-vs-patreon and /creators-home. Their layout counts were 9, 14, 15, 9 and 6 respectively. Builds used a 10 GB heap with full prerendering disabled; the five SSR checks ran against the built servers.
I did not run the complete prerender route list or interact with every layout in the editor picker. Signed-in header menus, welcome-video interactions and white-label browser flows still need their usual smoke tests. The white-label check here is a generated build.
The browser session included external image failures and one service-worker 504 that cleared on retry. The successful page checks do not establish an error-free console or production performance.