| name | cro-performance-as-conversion |
| description | CRO lens — is slowness (LCP/CLS/INP) the thing suppressing conversion? Surveyed by the Analyst. |
| license | Apache-2.0 |
| metadata | {"version":"1.1.0"} |
Performance as Conversion
Lens question: Is the block losing conversions to speed — slow LCP, layout
shift, sluggish interaction — rather than to clarity or trust?
Signal of the gap (DOM/RUM):
- DOM: oversized hero images, render-blocking work in the eager phase, layout that
shifts after paint, heavy decorate-time JS, work that belongs in the lazy/delayed
phases running eagerly (EDS three-phase loading).
- RUM: poor LCP/CLS/INP p75 against the block manifest's guardrails
(
blocks/<block>/<block>.manifest.json); bounce that rises with load time.
If LCP/CLS are already healthy, this lens is the wrong one — do not pick it
just because it's measurable.
Variant kind it implies: CSS-only (smaller assets, reserve space to kill
CLS) or JS (defer/trim decorate work, push non-critical work to lazy/delayed).
Note: this overlaps the platform's own performance budget — EDS targets a PSI score
of 100 (aem.live "keeping it 100") — only pick it when speed is genuinely the
binding constraint.
Related Skills
- testing-blocks: browser validation that proves the variant doesn't regress LCP/CLS at mobile/tablet/desktop viewports.
- docs-search: search aem.live (e.g. keeping-it-100) for platform performance guidance.