A Core Web Vitals & site speed breakdown

Will adding Whatmore slow down my store?

Short answer: No. Whatmore is engineered to stay off your store's critical render path. For a visitor who lands on your page and never scrolls to the widget, the total Whatmore footprint is a 41 KB bootstrap, about the size of a single product thumbnail, that does three small things and nothing else: reads your widget configuration from Shopify Metafields, reserves the widget's exact space so the page never shifts, and waits for the widget to scroll into view. No UI is rendered, no framework is loaded, and nothing blocks your theme from painting.

With the latest widget architecture, the carousel itself is plain JavaScript with no React or UI library behind it. When it scrolls into view it loads just 22 KB, and the video player loads only when a visitor taps a video.

Every claim in this article is backed by real Google CrUX field data from live Whatmore merchants, and we run our own Core Web Vitals checks against a live storefront every 30 minutes. Full per-merchant breakdowns are at the bottom.

Instead of loading everything upfront, Whatmore splits its code into three stages that fire only when needed. This is the single most important reason Whatmore doesn't impact performance.

The math for a typical visitor:

For context, a single optimised hero image is typically 150 to 300 KB. Even a visitor who watches a streamed video downloads less Whatmore code than that, spread across triggered stages rather than dumped onto first paint.

One note on placement: a stories bar or banner at the very top of your homepage is already in view when the page loads, so its surface stage and thumbnails load immediately rather than waiting for a scroll. That's by design, and it still stays off the critical render path.

Whatmore is designed to contribute zero to each Core Web Vital on initial page load. Here's the per-metric breakdown:

The Whatmore widget is designed to stay out of LCP. It mounts only when it enters the viewport, so a widget below the fold never competes with your hero image or above-the-fold content, and LCP is determined by your theme. If you place a banner or stories bar at the very top of a page, it loads with the page like any other above-the-fold element, sized and reserved in advance.

Widget JavaScript is deferred until the widget enters the viewport, so it adds nothing to the page's interaction cost until a visitor uses it. Event listeners are scoped to the widget container and don't touch global page responsiveness. Since the latest release the carousel is plain JavaScript with no framework, so even those interactions are light.

The widget container's dimensions are pre-reserved via CSS before any content loads. A shimmer skeleton placeholder appears immediately at the final dimensions, so when the carousel renders, nothing on the page moves.

The 41 KB bootstrap renders nothing on load. It reserves the widget's space and waits, so it cannot affect when your page first paints content. FCP is driven entirely by your theme's assets.

TTFB is a pure server-side metric (hosting, CDN, Shopify infrastructure). Whatmore has no bearing on it.

Whatmore stores your widget configuration in Shopify Metafields, so it ships with your storefront HTML instead of waiting on an API round trip. The moment the page loads, the bootstrap reads that configuration and draws a shimmer skeleton in the widget's exact place, matched to your chosen layout and to the number of videos it will show.

Visitors never see a blank rectangle or a spinner. When the widget scrolls into view, the carousel renders underneath and the shimmer fades out over it, so the transition

reads as a native component settling in rather than something loading. If the widget can't load for any reason, the placeholder is removed and its space released, so a failure never leaves a gap.

The same idea carries into playback. When a visitor taps a video, a poster frame fills the screen instantly and the player loads behind it, so there is no blank frame between the tap and the video starting.

When a visitor plays a video, Whatmore streams it with Adaptive Bitrate (ABR) over HLS. The player picks the right quality in real time from the visitor's connection and device, and keeps adjusting as conditions change.

Below is Google CrUX field data (75th percentile, latest 28-day window) from live merchants running Whatmore. Six merchants across different categories, from a few thousand to hundreds of thousands of monthly sessions. Every one runs Whatmore carousels on the homepage; the numbers below are what their shoppers actually experienced over the last 28 days.

Open any of the stores above and you'll see the Whatmore widget live. To check the raw CrUX data, run them through Google's PageSpeed Insights:

PageSpeed Insights pulls the same Google CrUX field data quoted here. Numbers may differ slightly from the table because CrUX updates on a rolling 28-day window, but the verdict on each store stays the same.

The benchmarks above are from other Whatmore merchants. If you'd like Core Web Vitals data for your store instead, the team can pull it on demand.

During your 14-day trial (available on Scale plan and above), our team generates PageSpeed Insights reports for your domain at any point you ask — before installation, after installation, and at any point in between if you want to track the delta. The numbers come from the same Google CrUX field data cited throughout this article, but pulled against your traffic, your customers, your theme.

Reach out to your Whatmore contact to get started. Thank you.