When a store or a large site is slow, the reflex is to install a speed app. It rarely works, because the problem is almost never something an app can reach. Core Web Vitals are decided by how the site is built: its templates, its code, its images, its scripts. On a transactional site, that speed moves two things at once, rankings and conversion rate, which is why it is worth fixing properly rather than patching. And fixing it properly means the template, not the plugin store.

The Three Metrics, Plainly

Core Web Vitals are three measurements of real user experience. Largest Contentful Paint is how quickly the main content appears. Interaction to Next Paint is how quickly the page responds when someone taps or clicks. Cumulative Layout Shift is how much the page jumps around as it loads. Google uses all three as signals, and users feel all three directly, a slow, janky page loses rankings and sales in the same motion.

On a marketplace with a progressive web app front end, none of these could be fixed with an add-on. They were addressed in the code and the templates: how images were sized and loaded, how much JavaScript shipped and when, how space was reserved so the layout did not lurch. That is the pattern everywhere. The levers that actually move Core Web Vitals live in the build, which is why an app bolted on top so rarely helps.

Why Apps Rarely Fix It

Fixing It at the Root

None of this is a quick toggle, and that is the point. Speed that lasts is built into the site, not sprinkled on top. On a transactional site the return is unusually direct, because the same work that lifts your Core Web Vitals also lifts the conversion rate the business runs on, which makes it some of the best-paid technical work there is.

Which Vital to Fix First

You rarely fix all three Core Web Vitals at once, so the order matters. Start with field data, the real-world measurements from actual visitors, rather than a single lab score, because the lab can flag problems users never feel and miss ones they do. Whichever metric is failing for the most real users, on the templates that carry the most traffic and revenue, is where the work begins. On most transactional sites that turns out to be Largest Contentful Paint, because heavy images and slow server responses on key templates hit the metric that gates the first impression.

From there, sequence by leverage. A fix in a shared template, a header, a product layout, a collection grid, corrects every page that uses it, so template-level fixes almost always outrank one-off page tweaks. Interaction to Next Paint usually comes next, since it is driven by the JavaScript and third-party scripts that accumulate over time and are worth auditing regardless. Cumulative Layout Shift is often the cheapest to fix, reserving space for images, ads, and fonts, and makes a good early win. The principle throughout is the same: measure what real users feel, fix it in the template, and start where the most traffic meets the worst score.