Web Push Notifications + Site Performance — When They Help and Hurt Ecommerce Conversions

Web push notifications return regularly to the ecommerce roadmap because the headline number is irresistible: open rates of 5–15%, click-through of 1–5%, and conversion attribution of 0.5–2% incremental revenue on the channel. For a $5M ecommerce store, that's $25K–$100K/year of attributed revenue from a $20–$200/month tool.

The hidden cost is more subtle: service worker overhead on every page load, opt-in prompt UX friction on first visits, browser update churn (Safari's web push support shipped/restricted across years), and the conversion attribution accuracy question. By 2026, the net-positive vs. net-negative decision is more nuanced than vendor pitches suggest.

This article documents the real performance cost, the implementation patterns that minimize harm, and the audit framework to measure your store's specific net value before or after implementation.

How Web Push Works Technically

Web push requires three components: a service worker registered by your site, a push subscription stored by the browser, and a notification service that sends push messages (Firebase Cloud Messaging, Apple Push Notification Service, or vendor-managed). The flow:

1. User visits site for the first time.
2. JavaScript on the site registers a service worker — a background script with limited persistent execution rights.
3. Service worker requests notification permission via browser API (typically delayed by a custom soft prompt UI).
4. User accepts. Browser generates a push subscription endpoint URL.
5. Site stores the subscription endpoint via vendor API.
6. Later, vendor sends push messages to the subscription endpoint. Service worker wakes, fetches notification content, displays system notification.
7. User clicks notification. Browser opens URL (typically product page or campaign landing page).

Performance overhead applies at steps 2 and 3, then again at every page load while the service worker is active.

The Four Categories of Performance Cost

1. Service worker registration weight. The service worker JavaScript bundle adds 20–100KB to your initial JS payload. Vendor SDKs (OneSignal, PushOwl, Pushwoosh) ship 60–200KB. The first-visit cost is the full bundle download + parse + execute, typically 100–300ms on mobile.

2. Service worker active overhead. Once installed, the service worker intercepts every fetch request from the page. Even a passive service worker adds 5–15ms per request for the message-passing roundtrip between the page and the service worker context. For a page with 50 requests, that's 250–750ms of cumulative overhead per page load.

The fix: ensure the service worker doesn't actually intercept anything it doesn't need to. The default vendor service worker often intercepts every fetch by default. A well-configured push-only service worker should intercept only the push and notificationclick events.

3. Opt-in prompt UX cost. Custom soft prompts (asking permission via in-page UI before triggering the browser's native prompt) cost layout shift and user attention. The browser native prompt itself blocks the page until dismissed; many users dismiss with "Block" instead of "Not now", permanently disabling push for that domain.

For Chrome's Quiet Notification UI policy (active since 2020), sites that show prompts to users who reflexively dismiss them get their prompt downgraded to a silent bell icon. Effectively, sites with poor opt-in UX get their push channel auto-disabled by Chrome.

4. Browser update churn. Safari supports web push as of iOS 16.4 (March 2023), but with restrictions: requires user to add the site to home screen as a Web App. Most iOS users never add ecommerce sites to home screen, so Safari push subscription rate is typically <2% of Safari traffic. For a US store with 50% Safari/iOS traffic, the effective addressable audience for web push is ~50% of total visitors — significantly smaller than vendor pitches suggest.

The Conversion Attribution Math

Vendor dashboards typically report "attributed revenue" as: any session that begins with a push click, multiplied by AOV, summed over time. This over-attributes for two reasons:

1. Existing customers click push as a navigation shortcut. A user already planning to return clicks the push notification as a convenient link. The conversion would have happened regardless. This is "non-incremental attribution" and typically accounts for 40–70% of vendor-reported revenue.

2. Last-click bias. Push gets credit for conversions that involved multiple touchpoints (email, paid, organic search). True incremental contribution is smaller than last-click attribution suggests.

To estimate true incremental revenue: run a holdout test. Randomly exclude 10% of your subscribed audience from receiving push for 30 days. Compare revenue per subscriber across the test and control. The diff is incremental. Vendors hate this test because it typically reduces attributed revenue by 50–80%.

The Net-Value Decision Framework

True incremental push revenue minus performance cost minus opt-in UX cost = net value. The performance cost translates to organic search impact (CWV regression affects ranking) and conversion rate impact on the broader site (slower pages convert worse). Concretely:

Estimated annual cost: 200ms TTI regression x ~1% conversion rate impact per 100ms x annual revenue. For a $5M store: ~$100K/year of conversion loss from a 200ms TTI regression (figures based on published ecommerce CWV studies; your store-specific elasticity may differ).

Estimated annual gain: True incremental push revenue, measured via holdout test. For a typical Shopify store, ~$25K–$100K/year.

For stores where the performance cost exceeds the push gain, the net value is negative. This is most common for: stores with weak push opt-in UX (low subscription rate), stores already at the CWV ranking threshold (any regression has outsized organic traffic impact), and stores with strong email/SMS programs (where push adds little incremental reach over existing channels).

Implementation Patterns That Minimize Harm

1. Delayed service worker registration. Don't register the service worker on first page load. Wait until after first contentful paint, after user interaction, or after the user has been on the site for 10+ seconds (signaling intent to engage). Reduces first-visit performance cost.

2. Lightweight service worker. Many vendor service workers include analytics tracking, A/B test SDK loaders, and other features unrelated to push. Audit and trim to a push-only implementation. Net savings: 20–80KB JS, 5–15ms per request overhead.

3. Soft prompt before native prompt. Show a custom in-page prompt asking for push opt-in (with clear value proposition) before triggering the native browser prompt. Sites with this pattern see 2–5x higher opt-in rates and avoid Chrome's Quiet Notification penalty.

4. Avoid opt-in prompts on first visit. Wait until the user has engaged with the site — viewed multiple products, added to cart, returned for a second session. Opt-in conversion is dramatically higher post-engagement.

5. Respect browser autoblock policies. Don't re-prompt users who dismissed. Don't show prompts on every page load. Don't trigger prompts on page load (always require user action). Sites that respect these patterns retain native prompt eligibility.

6. Send relevant, low-frequency notifications. Push fatigue causes unsubscribes and "Block" reactions. Two notifications per week max for most ecommerce contexts; one for niche/premium brands. Personalize content (back-in-stock for previously viewed products, price drops on wishlist items) — generic broadcast push has 2–5x lower CTR than personalized.

Vendor Comparison for 2026

OneSignal: Largest player, generous free tier (up to 10K subscribers), full-featured. Service worker bundle 150–200KB. Comprehensive segmentation. Best for stores with engineering capacity for tuning.

PushOwl: Shopify-native, simpler UX, $19–$99/mo. Service worker bundle 80–120KB. Lighter touch but fewer features. Best for non-technical Shopify stores.

Pushwoosh: Enterprise focus, multi-channel (push + in-app + email orchestration). Service worker bundle 100–180KB. Best for large stores with omnichannel needs.

Firebase Cloud Messaging (direct): Free, custom implementation required. Service worker bundle minimal if implemented properly (20–40KB). Best for engineering-led implementations with full control.

Pusher Beams: Developer-friendly API, pay-per-message pricing. Custom implementation. Best for stores with engineering teams and high-volume notification needs.

The Audit Framework

Step 1: Measure current performance baseline. WebPageTest median of 5 runs without service worker (incognito or fresh browser session). Capture TTI, LCP, INP, total JS weight.

Step 2: Measure with service worker active. WebPageTest from a logged-in browser with the service worker installed. Capture same metrics. Diff is the per-page overhead.

Step 3: Measure opt-in rate and subscription growth. Vendor dashboard or analytics: what % of unique visitors are opting in? Healthy: 2–5% for ecommerce. Below 1% indicates the opt-in UX needs work.

Step 4: Run a 30-day holdout test for attribution. Randomly exclude 10% of subscribers from push for 30 days. Compare revenue per subscriber across test and control. The diff is incremental.

Step 5: Calculate net value. Incremental annual revenue minus annual conversion loss from performance regression. If net positive by >20%, keep and optimize. If net negative, consider removal or implementation overhaul.

What StoreVitals Detects

Our crawler audits service worker behavior and surfaces:

• Service worker presence and bundle size
• Service worker scope and fetch interception scope
• Push notification vendor identification (OneSignal, PushOwl, Pushwoosh signatures)
• Opt-in prompt timing and pattern (load-triggered vs. interaction-triggered)
• Performance overhead estimate from service worker presence
• Notification permission API call audit

Run a free scan and check the "Performance" pillar. If you see "Heavy service worker" or "Service worker bundle: large", the implementation likely needs trimming. For stores running web push, our Premium $79 audit includes a full push notification cost/benefit analysis with the holdout test framework and implementation optimization recommendations.