AukodeAukode
Web performance facts that change how you build
Optimization

Web performance facts that change how you build

A 100ms delay cuts conversions by 7%. Most images are still JPEG. The average site loads 22 third-party scripts. The data on performance is more specific than most people realize.

web performancelcpimagesthird partygzip

A 100ms Delay in Page Load Reduces Conversions by 7%

This number comes from a study Amazon ran internally in 2006. They found that every 100 milliseconds of additional page load time correlated with a 1% reduction in revenue. Google published similar findings in 2017, showing that a 1 second delay in mobile load time can reduce conversions by up to 20%.

These figures get quoted a lot but the mechanism behind them is worth understanding. Users do not consciously think 'this page is slow.' What actually happens is that slow pages increase cognitive friction. The brain perceives a wait as a failure signal. Users lose confidence in the site before they have even read a word.

A stopwatch closeup on a dark background representing milliseconds in web performance
Every 100ms counts: slow pages cause users to lose trust before reading a single word

Most of the Web's Images Are Still Not in WebP

WebP was released by Google in 2010. It produces files roughly 25 to 35% smaller than JPEG at equivalent quality. Browser support reached 96% of global users by 2021. Despite all of this, HTTP Archive data from 2024 shows that JPEG is still the most commonly served image format on the web, accounting for over 40% of all image requests.

AVIF, the format that beats WebP on compression, has been supported by Chrome since 2020 and Firefox since 2021. Safari added support in 2023. Adoption in production is still minimal.

The gap between 'supported' and 'actually used' in web development is enormous.

The Largest Contentful Paint Element Is Almost Always Predictable

If you have never run a Lighthouse audit on your own site, you might not know what element is your LCP. But it follows a pattern so consistent it is almost a rule: on marketing sites and landing pages, the LCP element is the hero image roughly 80% of the time. On content sites and blogs, it is usually the main heading or article body text.

This matters because LCP improvement is rarely about fixing many things. It is about finding one element and loading it faster. The single most effective change for most sites is adding fetchpriority="high" to the hero image tag. That tells the browser's preload scanner to treat that resource as the most important thing on the page.

Speed performance dashboard on a monitor screen with colorful charts in a dark office
Lighthouse and Core Web Vitals dashboards reveal the single element responsible for LCP

Third-Party Scripts Are the Silent Killer

The average website loads around 22 third-party scripts according to HTTP Archive. Analytics, chat widgets, A/B testing tools, ad pixels, heatmap recorders, customer support scripts. Each one adds to Total Blocking Time, delays interactivity, and often runs network requests to domains you have no control over.

A single poorly implemented third-party script can add 2 to 4 seconds to your Time to Interactive. The irony is that most of these tools are meant to improve business outcomes, but they measurably harm the user experience that drives those outcomes.

Gzip Has Been Available Since 1993

HTTP compression using gzip has been part of the web since 1993 and built into virtually every web server for decades. Despite this, audits regularly find production sites serving uncompressed HTML, CSS, and JavaScript. Enabling gzip or Brotli compression is typically a one-line server config change that reduces text asset sizes by 70 to 90%.

Brotli, released by Google in 2013 and now supported by all major browsers, compresses roughly 15 to 20% better than gzip. Most CDNs serve Brotli automatically when clients advertise support via the Accept-Encoding header.

Service Workers Make Websites Work Offline

Service workers are JavaScript files that run in the background, separate from the main browser thread. They can intercept network requests and serve responses from a local cache, which means a properly configured web app can work with no internet connection at all.

Google Maps, Twitter, and Pinterest all use service workers. The Twitter web app was rebuilt as a Progressive Web App using service workers in 2017 and saw a 65% increase in pages per session and a 75% decrease in tweets sent that failed. These are real production numbers from an engineering post-mortem, not a benchmark.

A smartphone showing a map application with cached offline data
Service workers power offline-first apps: Google Maps and Twitter PWA both rely on them


Sources

  • Amazon 100ms study: Greg Linden, Marissa Mayer at Web 2.0 (2006), referenced in Amazon internal presentations - glinden.blogspot.com
  • Google mobile delay study: Deloitte / Google, Milliseconds make millions (2017) - deloitte.com
  • Image format distribution: HTTP Archive, State of Images 2024 - httparchive.org
  • Third-party script count: HTTP Archive, Third Parties report - httparchive.org
  • Gzip history: IETF RFC 1952, GZIP file format specification - tools.ietf.org
  • Twitter PWA case study: Addy Osmani, A Pinterest Progressive Web App Performance Case Study and Twitter Lite Engineering post (2017) developers.google.com

Work with me

Want to build something like this?

I build, optimise, and ship for teams who need it done right. Free project scoping, full code ownership.

Stay in the loop

Want the latest posts straight to your inbox?

DH

Hawari

Lead Engineer

Lead Engineer specializing in high-performance web architecture, automation, and AI integration. Writes to share battle-tested patterns. Read more →