UserWay's Hidden Tax: 8 ms Load Time, 753 ms First-Click Freeze
UserWay Accessibility Widget is marketed as a lightweight tool for WCAG compliance. StackConflict lab measurements reveal a different story: 753 ms of main-thread blocking fires the moment a user first taps or clicks — directly harming Google's INP Core Web Vital.
What We Measured
StackConflict's clean-room lab runs each app in isolation on a real Shopify storefront shell. For post-interaction measurements, a synthetic click event fires after page load and we record V8 CPU execution time and long-task data.
| Phase | V8 CPU | Long Tasks | Blocked (ms) |
|---|---|---|---|
| Page load (no interaction) | 8 ms | 0 | 0 ms |
| First click / tap | 822 ms | 3 | 753 ms |
| With Booster Page Speed | 63 ms | — | ~50 ms |
Why This Happens: The Defer Illusion
UserWay ships a tiny JavaScript stub (~160 KB) at page load. This stub loads almost instantly — producing the low 8 ms CPU figure that performance dashboards display. What performance dashboards don't show: the stub waits, then fires a full lazy-load sequence the moment a user first interacts with the page.
Payload breakdown at first interaction (516 KB deferred)
- remediation.js 13.7 KB
- widget_app_lazy.js 36 KB
- app-DRLQsKtn.js 144 KB
- combined.js ← main offender 322.6 KB
The combined.js file alone is 322.6 KB — larger than
most full-featured e-commerce apps. It executes synchronously on the main thread when the
user first taps a button, scrolls, or interacts with any element on the page.
Why This Matters: INP Is a Google Ranking Signal
Since March 2024, Google's Core Web Vitals report includes Interaction to Next Paint (INP) — a measure of how quickly a page responds to user input. INP directly influences search rankings.
Google's thresholds:
| INP | Rating |
|---|---|
| ≤ 200 ms | Good |
| 200–500 ms | Needs Improvement |
| > 500 ms | Poor |
UserWay's first-click cost of 822 ms falls squarely in the Poor category — 4× over the "Needs Improvement" threshold. Every accessibility-enabled page on your store delivers a Poor INP to every visitor who first taps or clicks.
Does a Speed Optimizer Help?
StackConflict also measured UserWay paired with Booster Page Speed using the v2 OSI (Optimized Stack Impact) methodology — which includes a post-interaction phase.
| Config | Load CPU | First-Click CPU | INP rating |
|---|---|---|---|
| UserWay alone | 8 ms | 822 ms | Poor |
| UserWay + Booster Page Speed | 3 ms | 63 ms | Good |
With Booster Page Speed, the first-click cost drops from 822 ms to 63 ms — a 13× improvement. This is because Booster rewrites how JavaScript loads on the page, preventing UserWay's deferred bundle from executing synchronously on click.
This is one of the clearest demonstrations of how a speed optimizer can fix INP problems introduced by third-party apps — not just page-load speed.
What Should Merchants Do?
If you have UserWay installed and your Google Search Console shows a Poor INP score:
- Pair it with a speed optimizer. Lab data shows Booster Page Speed reduces UserWay's first-click impact from 822 ms to 63 ms. View Booster Page Speed →
- Monitor INP in Google Search Console. Check your Core Web Vitals report specifically for INP — not just LCP and CLS.
- Consider lazy-loading the widget itself. UserWay can be configured to load only on demand rather than on every page load.
- Evaluate alternatives. Some accessibility overlays have lower interaction costs. Compare them at StackConflict →
About This Measurement
This finding was produced by StackConflict's post-interaction lab methodology
(run_solo_interaction.py). The app runs in a clean Shopify storefront shell
without any other scripts. A synthetic click event fires after the page is fully loaded and
idle. V8 CPU execution time and Chromium long-task data are recorded for the 3-second window
after the click.
Read the full methodology → · View UserWay's full performance profile →
Check Your Own Stack
See how your installed apps interact — and whether a speed optimizer would help your INP.