WebP Done Properly: The Image Pipeline Behind a Real Rebuild | APX Digital

WebP done properly: the image pipeline behind BLOC's rebuild (real weights, before and after)

An architecture site is mostly images, so image weight decides how it loads. Get the images wrong and you either ship blurry renders or a 12 MB homepage, and architects notice the blur before the client notices the wait. Here is the actual pipeline we ran for the BLOC Architecture rebuild, with every byte measured from real files rather than a stock claim.

What "before" looked like

The source library arrived as camera/screenshot output with no consideration for the web at all. Real examples, measured from the build folder on 3 September 2026:

• unnamed.jpg: 187,685 bytes at 940×576 px. That's 200 bytes per pixel-equivalent for a JPEG; a hero image at this weight loads on desktop and stalls on a phone on bad signal.
• The "before" page captures themselves: four PNGs, 776 KB to 4.5 MB. A PNG of a photographic screenshot is the classic mistake; lossless compression of photos is terrible.
• One PDF materials schedule measured 666,119 bytes. Fine as a download; a disaster if someone tries to preview it as an image.

The site's own history proves why discipline matters: an earlier code snapshot (1,250 lines of index.html, dated 27 August 2026 in the project folder) referenced zero WebP files and six plain `` tags. The version deployed later that week moved everything to converted WebP with dimensioned delivery, a one-week lesson in "ship, look, fix".

The conversion pass: what the numbers actually did

Every webp in the pipeline was re-measured with stat and `sips` on 3 September 2026:

Google's own WebP compression study puts lossy WebP at 25% to 34% smaller than JPEG at equivalent SSIM; our measured conversions beat the headline because the originals were badly-encoded JPEGs. Source: developers.google.com/speed/webp/docs/webp_study, accessed 3 September 2026.

The honest asterisks sit in the project-plan images. The three materials-schedule WebPs (Shelly Lane 568,862 B, Land at Yew Tree Lane 419,894 B, Ulverley Crescent 330,570 B, all 3308×2339) are drawings, not photos: dense line work at high resolution. They were converted, not resized, because a homeowner zooms a floor plan to check a bedroom size. A 568 KB plan image is a deliberate trade; a 568 KB hero would not be. The batch of general imagery lands between 144,606 and 301,026 bytes at 1280 px wide; that is the ceiling we treat as acceptable for a single art-directed image, and the hero at 195,878 bytes sits inside it.

Second asterisk: the hero is the one file we left alone. The deployed Img hero large.webp (195,878 bytes, 940 px wide) is the same file we measured from the source batch; it inherited the 940×576 dimensions of the original JPEG instead of getting a 1280 px pass like the rest of the library. At 940 px it's fine on a phone and slightly soft on a wide desktop. It's next on the list, and we'd rather say so here than pretend the pipeline is uniform.

Delivery sizes, not just format

WebP is half the job; the other half is not sending 1280 px to a 390 px phone. The live production bundle (fetched from blocarc.co.uk with curl on 3 September 2026, 512,885 bytes) does three measurable things:

1. Responsive candidates. srcSet appears five times in the bundle (plus two lowercase `srcset` occurrences in raw markup), so images ship at a size matched to the viewport rather than one oversized file everywhere.
2. Lazy loading by default. Seven explicit loading:"lazy" declarations versus a single `loading:"eager"` (the above-the-fold hero), so nothing below the viewport competes with the first paint.
3. Dimensioned media. Content images are declared with explicit width/`height` pairs in the bundle (measured examples: 1993×538, 1280×908, 940×576), which reserves layout space so text doesn't jump as photos arrive; the cheapest CLS insurance available.

We are not going to print a Lighthouse score; we didn't run one this week and a score from a folder of files is fiction. The claim is narrower and true: every WebP in the conversion pass (67,746 to 148,898 bytes) is lighter than the single source JPEG that came in (187,685 bytes) while carrying roughly double the pixels, and the site serves those bytes responsively instead of all at once. For an image-led practice site, that's the entire game, and when the site moves to a bigger scheme library, the same pipeline is exactly what a bespoke build maintains. If you want to see how it looked end-to-end, the before/after case study is here.

The checklist we actually run

• [ ] Screenshot/asset intake: reject photographic PNGs, convert at ingest, never at ship time
• [ ] Encode lossy WebP at the delivery size you actually need; re-measure, don't assume
• [ ] Drawings and line-work get conversion but no resize, since zoom is the use case
• [ ] Hero gets eager loading; everything else lazy
• [ ] width/`height` on every image; `srcSet` for any image that appears at two-plus sizes
• [ ] Log byte weights per asset; anything over ~300 KB for non-drawing imagery goes back through the pass

Your site is 60% to 90% images by weight. APX bakes this pipeline into every build tier; see the website service or email Info@apxdigital.io · 07753 226214.