Skip to content

Engineering

Cumulative Layout Shift: what to verify before client handoff

Before handoff, verify visual stability during page load on the templates clients actually open—and keep LCP and Lighthouse performance as separate Performance rows, not substitutes.

· by Sam Ortega

Cumulative Layout Shift: what to verify before client handoff

Handoff decks show a polished screenshot. Clients later open the live URL on a phone and watch the CTA jump under their thumb. That discovery happens on a call you wanted to keep short. Process that survives launch week should have caught the shift.

SlaySlop's Cumulative Layout Shift check "Checks for visual instability during page load." Before portal access goes out, that sentence is the Performance bar I use for the CLS row.

Outcome you want at handoff

On the public templates in scope, load-time layout instability is either absent or owned with a dated fix. You can show evidence tied to a page. LCP still has its own status. The client can repeat the scope without inventing a full field RUM program they did not buy.

Boundaries to state on the call

Read-only public scan. Permission required. Not a pentest and not a stress test of someone else's CDN. SlaySlop does not patch the theme for you. A quiet CLS row is not a full Performance sign-off.

Keep siblings visible:

  • Largest Contentful Paint: reviews the loading signal for the primary page content
  • Lighthouse performance: runs browser-based performance checks on key pages
  • Interaction readiness: reviews browser signals related to responsive interaction
  • Viewport configuration: checks mobile viewport setup and zoom-safe behavior

Uptime being green only means the site responded. It does not mean the hero stopped shoving the headline.

Happy path checklist before you send the portal

List the public templates in the SOW: home, key landings, product or article templates with embeds. Scan with permission. Open any CLS finding on the cited page before the call. Prefer a first-visit mindset when you spot-check—banners and fonts often misbehave before cache warmth.

text
Handoff — CLS
[ ] Permission confirmed for each host
[ ] Key templates listed (home/landing/article)
[ ] SlaySlop CLS row reviewed with page evidence
[ ] Image/embed dimensions reserved where relevant
[ ] Late banners/consent UI space planned
[ ] LCP sibling noted
[ ] Owner named for any open CLS finding
[ ] Rescan date after the fix

Loading diagram.

What to verify on the live public surface

Agencies get burned by verifying the design file instead of the rendered page. Web fonts, cookie banners, async embeds, and ads are not in Figma the way they are in a real browser. Product language stresses a real browser crawl so runtime and layout behavior can be measured. Borrow that standard for handoff spot-checks.

bash
# Permissioned: confirm the handoff host responds before the call
curl -sI "https://www.example.com/" | sed -n '1,20p'

If the finding cites a landing page, open that landing page—not only the homepage you memorized. Write the ticket with the public URL and the suspect node class (hero, banner, embed), not "make it not jump."

Pitfalls that embarrass you on a call

Calling the domain stable because / looked fine on desktop Ethernet. Equating a local Lighthouse green with a clean CLS row on the live host. Collapsing LCP and CLS into one "perf" ticket so nobody owns either fix. Promising "Core Web Vitals forever" when the published definition is visual instability during page load on the scanned pages.

Another miss: scanning only the brochure host while the campaign microsite with the heavy embed lives elsewhere. Put every host from the SOW in the packet.

How to talk about residual risk without drama

Say what was observed during load. Say what was not in scope: authenticated apps, infinite-scroll sessions, third-party domains you are not authorized to tune. Clients respect a narrow true claim. They punish a vague absolute.

If a finding remains, name the owner and the rescan date in the portal notes. Soft-pedaling an open Performance row is how launch week turns into "the button moved again" chat threads.

After the call

Schedule the first rescan. Promo banners and "temporary" embeds return quietly. Availability monitoring will not catch a shift; it only records whether the public site responded. Keep quality scans on a cadence the client understands.

When staff rotates, the checklist above is the artifact that saves you. Tribal knowledge about "that one font file" does not.

Content structure for the portal note

I treat Performance handoff notes like client checklists: scannable, concrete, no filler adjectives. A useful note has the templates, the CLS status, the LCP sibling, and a rescan date. A useless note says "optimized" three times.

When marketing and campaign hosts differ, put both URLs in the calendar invite. People verify what is in front of them. Give them the right front. If the SOW promised a portal, expand the Performance evidence once on the call so the client sees the shape before they self-serve.

Related next step

Read the Cumulative Layout Shift row beside LCP on a permissioned SlaySlop scan, then decide whether the gap is reserved space, late UI, or both. Soft links: Cumulative Layout Shift and Performance and accessibility.