Optimizing a Cannabis Site's Core Web Vitals

Three metrics, three numbers

Largest Contentful Paint (LCP) times how long the biggest visible element takes to render; on a dispensary site that is usually the hero image or the first row of menu products. Good is 2.5 seconds or less. Interaction to Next Paint (INP) measures the gap between a tap and the next visual update, passes at 200 milliseconds or under, and replaced the older First Input Delay metric in March 2024. Cumulative Layout Shift (CLS) scores how much the page jumps while loading; 0.1 or below passes. A page passes when 75% of real visits hit the target, not when your laptop does.

Lab tests diagnose, field data decides

Lighthouse loads your page once on a simulated device and connection. That number finds problems; it settles nothing. Google's systems grade field data from the Chrome User Experience Report (CrUX), a rolling 28-day sample of what real visitors experienced. PageSpeed Insights puts both on one screen, field data up top and the Lighthouse audit below. When they disagree, believe the field number and use the lab report to figure out why.

LCP: get the biggest thing painted sooner

Compress the hero image and convert it to WebP or AVIF. Add a preload hint so the browser fetches it before discovering it in the layout. Never lazy-load anything above the fold. Then look at server response, where caching or a CDN buys back the first few hundred milliseconds every visit spends waiting. If your menu renders through a third-party embed, the grid cannot paint until that JavaScript loads and runs, which caps how fast the page can ever feel.

INP: cut the script tax

Dispensary sites accumulate JavaScript fast: an age gate, a chat widget, a loyalty pop-up, a menu embed, two analytics tags. Each runs on the main thread, and long main-thread tasks are what push INP past 200ms, because the browser cannot respond to a tap while a script holds the thread. Defer what can wait. Load chat on first scroll instead of page load. Delete tags nobody looks at. The Performance panel in Chrome DevTools will show you exactly which scripts own the longest tasks.

CLS: stop the layout from jumping

Layout shift has boring causes and boring fixes. Images without width and height attributes make text reflow when they arrive, so set explicit dimensions on every one. Promo bars injected above content after load shove everything down; reserve their space in advance. Run age verification as an overlay sitting on top of the page rather than an element pushed into it. Of the three metrics, CLS is usually the cheapest to pass.

A worked example

A client's flower category page reported LCP at 4.1 seconds in CrUX, with INP failing on mobile. The Lighthouse audit pointed at two culprits: a 1.2MB hero PNG and a chat widget running long tasks at load. We converted the hero to a 90KB WebP with a preload hint, moved the chat script to load on first interaction, and added width and height attributes to every product thumbnail, which took lab CLS from 0.18 to under 0.05. The next 28-day CrUX window came back green on all three metrics. No replatform, no redesign — three template edits.

Frequently asked questions

How much do Core Web Vitals affect rankings?

They are a real but modest signal, closer to a tiebreaker between comparable pages than a shortcut past better content. The stronger argument is commercial: a menu that loads in two seconds keeps shoppers a five-second menu sends back to Google.

Lighthouse gives me 95 but the field data fails. Which is right?

The field data. Lighthouse simulates one visit on one synthetic device, while CrUX aggregates 28 days of real visits, including cheap phones on slow connections. Google grades the field number; treat the lab score as a diagnostic.

Why does PageSpeed Insights show no field data for my page?

The page gets too little Chrome traffic to build a CrUX sample. Check the origin-level data that covers your whole site instead, and hold the page to the lab thresholds as a stand-in until real-user numbers exist.