Image fetchpriority hints on Wix sites

Sites with fetchpriority="high" image fetchpriority hints have a good LCP most often: 92%, against 92% of all Wix sites. Sites with default auto priority fetchpriority hints have it least often, at 92%.

Fetchpriority="high" is the most used: 99.4% of Wix sites.

Across the four LCP sub-parts in Chrome's field data, the largest gap between fetchpriority="high" and default auto priority sits in time to first byte (TTFB): 343 ms median for fetchpriority="high" against 360 ms for default auto priority. Overall median field LCP is 1.2s for fetchpriority="high" (TTFB 343 ms, load delay 478 ms, load duration 259 ms, render delay 138 ms) versus 1.2s for default auto priority.

React sets the image fetchpriority hints to fetchpriority="high" on 99% of its sites, and 92% of React sites have a good LCP, against 92% of all sites.

FrameworkImage fetchpriority hints on its sitesGood LCP

Wix sites with image fetchpriority hints 5,599 sitesfetchpriority="high" 99%Default priority (auto / unset) 95%92%

React 5,598 sitesfetchpriority="high" 99%Default priority (auto / unset) 95%92%

fetchpriority="high" Default priority (auto / unset) fetchpriority="low"

Does the framework explain the image fetchpriority hints difference?

Almost every site with fetchpriority="high" image fetchpriority hints is a React site, and almost every React site has fetchpriority="high" image fetchpriority hints, so the data can't tell fetchpriority="high" image fetchpriority hints and React apart.

How fetchpriority="high" and fetchpriority="low" reorder image fetches

In Chromium, <img> requests start at Low priority until layout determines which images sit inside the viewport. Setting fetchpriority="high" (99.4% of sites) elevates the request to High priority during HTML parsing, while setting fetchpriority="low" (0.5% of sites, 100% good LCP) keeps offscreen carousel or thumbnail images from competing with critical resources.