Review widgets and page speed
The short answer
A third-party widget affects page speed mainly through Cumulative Layout Shift and, if loaded badly, through blocking the main thread. A widget that loads after content and reserves its space does very little damage.
The widget is usually not the heaviest thing on the page, and checking before assuming saves a lot of time.
Which metric it touches
CLS is the one to watch: a widget that appears after the page has painted pushes everything below it down, and that shift is measured. Reserving the space in advance largely solves it.
LCP is affected only if the widget is the largest element above the fold, which is unusual. INP is affected if the script blocks the main thread while the user is trying to interact — which is about how it loads, not how big it is.
What most people get wrong
Blaming the visible new thing. A page with an unoptimised hero image, four tracking scripts and a chat widget will have poor vitals regardless, and the reviews block is simply the most recent change. Measure with and without rather than assuming.
The second is using synthetic scores alone. Lab tools are useful for diagnosis; field data in Search Console is what actually counts.
What to check
Run the page in PageSpeed Insights before and after. Look at the waterfall to see when the widget requests fire relative to your content. If it loads before your own images, that is a configuration problem worth fixing.
What ours does
Loads after page content rather than blocking rendering. If you are seeing layout shift, reserving the container height fixes most of it.