Image fetchpriority hints on Wix sites

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

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): 404 ms median for fetchpriority="high" against 406 ms for default auto priority. Overall median field LCP is 1.1s for fetchpriority="high" (TTFB 404 ms, load delay 446 ms, load duration 109 ms, render delay 150 ms) versus 1.1s for default auto priority.

React sets the image fetchpriority hints to fetchpriority="high" on 99% of its sites, and 94% of React sites have a good LCP, against 94% 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%94%

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

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, 92% good LCP) keeps offscreen carousel or thumbnail images from competing with critical resources.