Common Interaction Readiness mistakes that still ship

I keep a short list of interaction mistakes that survive content review. None of them are exotic. They come from treating a quiet desktop load on office Wi-Fi like a responsiveness review. Thin pages with beautiful hero copy still fail when the CTA ignores the first input.

SlaySlop's Interaction readiness check "Reviews browser signals related to responsive interaction." The mistakes below fight that observation point.

Outcome if you catch these early

You get tickets that name pages and suspect scripts instead of "make it snappier somehow." Editors and SEO folks should still care: a stalled shell can leave crawlers and answer engines with less meaningful rendered content than the static HTML promised. Different audience, same unfinished feel.

Boundaries

Read-only public scan. Permission required. Not a pentest. Interaction readiness sits under Performance next to LCP and CLS. Closing an interaction finding does not invent a good LCP. SlaySlop does not edit the target. Only scan hosts you are authorized to assess.

Mistake 1: shipping before hydration finishes mattering

Marketing teams approve the design in a tool where buttons always respond. On the live host the React or Vue shell mounts late, and the first taps hit a non-interactive layer. The copy was ready. The interaction was not.

Mistake 2: third-party tags on the critical path

Tag managers, chat widgets, and "just one more pixel" scripts still monopolize the main thread after paint. The hero looked fine. The visitor could not click through. I have cleaned too many thin landing pages where the SEO meta was perfect and the CTA was blocked by a vendor script.

Mistake 3: local Lighthouse as production proof

A green lab run on a quiet laptop is useful. It is not the same as SlaySlop's live public check. Site compare language notes Lighthouse as a lab snapshot while SlaySlop keeps checking a live URL over time. Fix your strings. Use both tools; substitute neither.

Mistake 4: homepage-only confidence

Campaign landings with embeds often stall more than /. If your handoff script only opens the homepage, you shipped a glance.

# Permissioned: confirm which templates you are about to discuss
for path in "/" "/pricing" "/blog/example-post"; do
  printf '%s => ' "$path"
  curl -sI "https://www.example.com$path" | awk 'NR==1{print}'
done

Mistake 5: collapsing every Performance weirdness into one ticket

Interaction readiness, LCP, CLS, and viewport configuration are different sensors. Mixing them into "perf weirdness" wastes a week. Product language attaches evidence to findings. Borrow that packaging.

Mistake 6: fixing by deleting the banner from staging only

Temporary "remove the chat widget for launch day" notes expire in silence unless a rescan exists. Production reintroduces the stall while "following the docs."

Mistake 7: trusting warm-cache demos

The war-room laptop already had fonts, JS, and consent state cached. Clients open a cold phone session. Measure the cold path you claim to ship.

Interaction mistake watchlist
late_hydration: yes|no
third_party_on_critical_path: yes|no
local_only_lighthouse: yes|no
templates_covered: home|landing|pricing|mixed
cold_load_checked: yes|no
owner:

Happy path that avoids the list

1. Enumerate public templates in the SOW.
2. Run a permissioned SlaySlop scan.
3. Open Interaction readiness evidence on the cited pages.
4. Check LCP and CLS on the same pass.
5. Name owners and rescan dates before portal access goes out.

Editorial checklist for the Performance section

Before I accept a Performance handoff paragraph, I want three concrete nouns: the URL, the interaction path, and the sibling status for Failed requests. Vague adjectives like "snappy" and "buttery" do not survive client questionnaires. Scannable structure does.

If someone pastes Interaction readiness findings into a Failed requests ticket because both appear after a browser session, push back. A failed font request is a network failure. A sticky tap with clean network is an interaction-signal problem. Mixing them produces PRs that change the wrong layer.

I also refuse to treat silence on / after a fix as proof about /signup. Rescan the routes that mattered.

Mistake 8: renaming the ticket instead of fixing the cause

Renaming a ticket from "Interaction readiness" to "Polish UI" does not change the live session. Neither does marking it done because someone "optimized images" without a cold-load reproduce step. Require a before/after note with the cited URL and the behavior that returned.

Documentation culture is part of the bug

Sometimes the theme is fine and the runbook is wrong. The runbook says "inject the chat widget immediately for engagement." A tired engineer applies the runbook to every template. The mistake shipped as documentation culture. Fix the runbook in the same change window when you defer the widget. Otherwise the next launch reintroduces the stall while "following the docs."

Process that survives launch week looks like a checklist you can hand to someone who was not on the build. Not like a hero engineer who remembers which pixel was sketchy.

What I refuse to invent in tickets

Unpublished interaction thresholds. Device lab lists the product did not publish. Claims that a quiet homepage proves signup is responsive. Stick to browser signals related to responsive interaction on the scanned public pages. That sentence is enough for a clean ticket.

Related next step

Bring the SlaySlop evidence to the awkward call that starts with "but PageSpeed said green." Soft product mention only when it helps: ranked findings with page evidence beat a hallway memory of "felt fine."