How Far Below the Fold Does Chrome Start Loading Lazy Images?
Chrome 154 requested lazy images up to about 1,200 pixels below the fold on phone, tablet and desktop, and DevTools throttling did not change that distance.
Performance Lab ▸ 4 min read
We Audited Every Image on This Site: What We Found and Fixed
All 188 image loads were WebP and close to the right size on a phone. On desktop, a stale sizes value and a WordPress quirk sent oversized files; fixing them cut the category archive from 127 to 77 KB.
Performance Lab ▸ 5 min read
A Base64 Image Inside Your CSS: What It Does to First Paint
Embedding a 54 KB photo in the stylesheet delayed the first paint of the whole page from 404 to 788 ms on a throttled phone. The image itself appeared only 85 ms sooner.
Performance Lab ▸ 3 min read
What a Page Cache Did to This Site’s Server Response Time
Enabling the page cache cut our HTML response time from 358 to 420 ms down to about 193 ms, as fast as a static image. Uncached search and API requests did not change.
Performance Lab ▸ 4 min read
Hero Image Bytes vs LCP: About Half a Second per 100 KB on Slow 4G
On a 1.6 Mbit/s phone profile, LCP rose 5.14 ms per kilobyte of hero image, from 2,056 ms at 327 KB to 8,680 ms at 1,614 KB.
Performance Lab ▸ 4 min read
Inline CSS vs an External Stylesheet: First Paint on a Throttled Phone
Inlining our 20 KB stylesheet cut first paint from 600 to 312 ms on a throttled phone profile, but the main image appeared only 24 ms sooner.
Performance Lab ▸ 4 min read
A CLS of 1.0 From Our Own Stylesheet: What We Measured and Fixed
An external stylesheet plus the async AdSense script gave four of our pages a Lighthouse CLS of about 1.0. Inlining the same CSS brought it to 0.005 or less with the ads still loading.
Performance Lab ▸ 5 min read
content-visibility: auto on a 1,000-Card Image Gallery
content-visibility: auto brought first paint and LCP forward by about 23 % and cut layout during load by 42 %, but more than doubled the layout work done while scrolling to the end.
Performance Lab ▸ 3 min read
HTTP/2 vs HTTP/1.1 for a Grid of Thumbnails
Over HTTP/2, grids of 12 to 72 thumbnails finished 13 to 16 % sooner than over HTTP/1.1 on a throttled connection, but the first image arrived up to almost six times later.
Performance Lab ▸ 3 min read
Cache-Control for Images: Repeat Visits With no-store, ETag and immutable
On a throttled connection, a repeat visit to a page of eight photos took 2.68 s with no-store, 0.54 s with no-cache and an ETag, and 0.22 s with a one-year immutable policy.
Performance Lab ▸ 3 min read
Blurred Image Placeholders (LQIP and BlurHash): How Small Can They Be?
A 24-pixel WebP placeholder took a median 160 bytes, less than half a JPEG or AVIF of the same size, while a BlurHash string took only 28 characters.
Performance Lab ▸ 3 min read
Images Without width and height: Layout Shift Measured
Three images without dimensions gave an article a CLS of 0.15 on mobile, above the 0.1 'good' limit. width and height attributes or CSS aspect-ratio brought it to 0.
Performance Lab ▸ 4 min read
Lazy Loading Measured: Bytes Saved and the Cost of a Lazy Hero
Lazy-loading the 12 photos below the fold cut initial image bytes from 1,652 KB to 372 KB and LCP by 39 % on mobile. Lazy-loading the hero too cost 160–244 ms.
Performance Lab ▸ 5 min read
fetchpriority and preload for the LCP Image: When They Help
fetchpriority and preload raised the hero request to High priority in Chrome 155, yet LCP did not change across 224 throttled loads over HTTP/1.1 and HTTP/2. Here is why.
Performance Lab ▸ 5 min read
decoding=”async” Tested: Does It Change LCP or Blocking Time?
With four 2400-pixel AVIF images, decoding=async, sync and auto gave LCP within 16 ms of each other and no long tasks, with a normal and a 4× slower CPU.
Performance Lab ▸ 4 min read
Auditing Every Image Request: What We Found on Our Own Pages
Our own audit found one lossless comparison panel making up 68 % of a guide's weight. Replacing it halved the page from 1,381 KB to 683 KB on a phone.
Performance Lab ▸ 5 min read