“Zero fetch” sounds great in a performance chart. It needs context.
Proofi has two rendering paths. The dashboard preview loads widget data on the server and places it safely into the preview document. The browser already has the testimonials when the widget starts, so the preview does not need a second request.
The public embed works differently. It loads the static widget script, then requests the current testimonial data from the Proofi API.
That request is intentional.
Why the public embed fetches data
Inlining every testimonial into the installation snippet would remove a request, but it would create a worse editing workflow. Each change would require a new snippet and another update to the customer’s website.
With the current model, the script URL stays stable and the API returns the latest published content. Proofi caches that response, so repeat traffic does not always require a fresh database query.
There is another practical benefit. Multiple widgets on a page can share the same browser-cached script while requesting their own content.
What we can claim
The embed has a small compiled runtime and one content request. It does not load a web font, analytics package, or iframe. Its styles live in Shadow DOM, which reduces the amount of defensive CSS and keeps host-page rules from triggering unexpected layout work inside the widget.
We do not claim zero milliseconds or a guaranteed Lighthouse score. Those numbers depend on the page that contains the widget. A slow host page remains slow, and a widget inserted above the fold without reserved space can still contribute to layout shift.
What we measure instead
Useful checks are less dramatic:
- the size of the shipped script
- the number of network requests
- whether narrow containers overflow
- whether the widget moves unrelated page content
- how quickly cached and uncached payloads render
Those checks are repeatable. They also tell us what to fix next.