Core Web Vitals are built around three metrics, each measuring a different kind of user-perceived slowness. Largest Contentful Paint (LCP) measures how long it takes for the largest visible element, usually an image or a block of text, to render; the 2026 "good" threshold is under 2.5 seconds. Interaction to Next Paint (INP) measures how responsive the page feels when a visitor actually interacts with it, clicking an "add to cart" button or opening a filter, with a threshold under 200 milliseconds. Cumulative Layout Shift (CLS) measures how much visible content jumps around unexpectedly as a page keeps loading, scored under 0.1 to pass. Google folds all three into the ranking signals it uses, and Chrome's real-user data (CrUX) is what most sites get judged against, not a synthetic lab test.
A typical WooCommerce product page is structurally exposed on two of these three metrics more than most page types. The LCP element on a product sheet is very often the main product photo itself: if that image is oversized, in a slow format, or waiting on other resources before it can even start downloading, the whole LCP score for that page moves with it. CLS follows a similar pattern for a different reason: a product gallery, thumbnail strip, or category grid where images load without their final dimensions reserved in advance pushes surrounding text and buttons around as each photo finishes loading, which is exactly what CLS penalizes. Both problems trace back to the same root cause, images that are larger or slower to decode than they need to be, and to layouts that don't reserve space for them ahead of time.
INP sits in a different category. It's driven mostly by JavaScript execution time, event handler cost, and main-thread blocking, things like a heavy cart-drawer script or a slow filter widget, not by how images are served. An image-heavy catalog can still have excellent INP if its interactive elements are lean, and a text-light page can have poor INP if its scripts are heavy. It's worth knowing the threshold exists and where it comes from, but treating image optimization as an INP fix would be solving the wrong problem.
Where image handling does move the needle directly is LCP, and indirectly through faster overall page weight, CLS: serving each image already resized to its actual display dimensions, in a modern format the visitor's browser supports, from a cache instead of generating it on the fly, addresses the mechanical cause of a slow LCP element rather than working around its symptoms. That's the layer ImagePipe operates at inside a WordPress/WooCommerce store, without touching the JavaScript side of INP at all.