Image hosting origins on Wix sites

Sites with cross-origin images image hosting origin have a good LCP most often: 92%, against 92% of all Wix sites. Sites with inline data-URI images image origin have it least often, at 89%.

Cross-origin images is the most used: 100.0% of Wix sites.

Across the four LCP sub-parts in Chrome's field data, the largest gap between cross-origin images and inline data-URI images sits in time to first byte (TTFB): 343 ms median for cross-origin images against 375 ms for inline data-URI images. Overall median field LCP is 1.2s for cross-origin images (TTFB 343 ms, load delay 478 ms, load duration 259 ms, render delay 137 ms) versus 1.3s for inline data-URI images.

React sets the image hosting origin to cross-origin images on 100% of its sites, and 92% of React sites have a good LCP, against 92% of all sites.

FrameworkImage hosting origin on its sitesGood LCP

Wix sites with image hosting origin 5,619 sitesCross-origin / external CDN 100%Inline data: URI images 36%92%

React 5,618 sitesCross-origin / external CDN 100%Inline data: URI images 36%92%

Cross-origin / external CDN Inline data: URI images Same-origin (self-hosted)

Does the framework explain the image hosting origin difference?

Almost every site with cross-origin images image hosting origin is a React site, and almost every React site has cross-origin images image hosting origin, so the data can't tell cross-origin images image hosting origin and React apart.

Why base64 inline data-URI images bloat HTML and delay LCP

Serving images from the same origin (2.5% of sites, 142) reuses the primary HTTP/2 or HTTP/3 connection (77% good LCP, 1.3s median). Cross-origin images (100.0%, 92% good LCP) include both dedicated media CDNs and external third-party pixels. Inlining images as base64 data: URIs (36.2% of sites, 2,032) inflates HTML/CSS byte size by ~33% and blocks the parser, dropping good LCP to 89% (1.2s median).