The 8 tech ideas that made the web move quicker are broadband, web caching, content delivery networks (CDNs), data compression, AJAX, JavaScript engines, HTTP/2 with HTTP/3, and cloud plus edge computing. Each idea removed one specific delay between a server and a screen, taking the web from minute-long dial-up loads at 56 Kbps to pages that render in under 2.5 seconds.
These tech ideas that made the web move quicker sit on four layers of every page load. Broadband and 5G mobile networks raise bandwidth on the physical layer, while HTTP/2, HTTP/3, and the QUIC protocol cut handshake delays on the transport layer. Compression, caching, and CDNs shrink or shorten every byte that travels, and JavaScript engines such as V8 turn the arriving code into a working page.
The benefits show up in three places: faster page loading for visitors, lower bandwidth costs for site owners, and better Core Web Vitals scores for search visibility. Developers apply the same web performance optimization methods today in online stores, SaaS dashboards, streaming platforms, and AI applications that answer users in milliseconds.
This guide explains how each idea works, when it arrived, which bottleneck it removed, and how the technologies work together in one page load. The final sections cover the new web technologies, from speculation rules to WebGPU, that carry the same work into 2026.
What Are the 8 Tech Ideas That Made the Web Move Quicker?
There are 8 tech ideas that made the web move quicker, and each one targets a different source of delay, from thin connections to slow code inside the browser. The table follows the path a request takes, starting with the cable outside a building and ending with the script engine inside the browser.
| # | Tech idea | Arrived | Delay it removed | Key entities |
|---|---|---|---|---|
| 1 | Broadband internet | Late 1990s onward | Low bandwidth | DSL, fiber optic internet, 5G |
| 2 | Web caching | HTTP/1.1, 1997 | Repeat downloads | Browser, server, and edge caching |
| 3 | Content delivery networks (CDNs) | 1998 | Physical distance | Akamai, Cloudflare, Fastly |
| 4 | Data compression | 1990s to 2024 | Oversized files | Gzip, Brotli, Zstandard, WebP, AVIF |
| 5 | AJAX | Named in 2005 | Full page reloads | XMLHttpRequest, Fetch API, JSON |
| 6 | JavaScript engines | V8, 2008 | Slow script execution | V8, JIT compilation, WebAssembly |
| 7 | HTTP/2 and HTTP/3 | 2015 and 2022 | Connection queues and handshakes | SPDY, QUIC, UDP, TLS 1.3 |
| 8 | Cloud and edge computing | 2006 onward | Overloaded single servers | AWS, Google Cloud, edge functions |
Why Was the Early Web So Slow?
The early web was slow for 4 stacked reasons: thin dial-up bandwidth, single-location servers, uncompressed files, and browsers that ran scripts slowly. A modem built on the V.90 standard topped out at 56 kilobits per second (Kbps), and real connections in the 1990s often ran closer to 40-50 Kbps.
At 56 Kbps, a 1 megabyte (MB) page needs about 143 seconds to download, while the same page on a 100 megabits per second (Mbps) line arrives in roughly 0.08 seconds. The HTTP Archive Web Almanac reports that the median desktop page now weighs more than 2 MB, a size dial-up users would have waited over five minutes to receive.
- Bandwidth stayed below 0.06 Mbps, and a dial-up session tied up the home phone line.
- Distance added delay, as one origin server answered every visitor wherever the visitor lived.
- File size stayed large, since servers sent HTML, images, and scripts without compression.
- Processing stalled interactive pages, as early browsers interpreted JavaScript line by line. Every idea in this list removed at least one of these four bottlenecks, which explains why web speed improved in steps across three decades rather than in a single jump.
1. Broadband Internet Replaced Slow Dial-Up
Broadband internet made the web quicker by replacing 56 Kbps dial-up with always-on connections that now reach 1 gigabit per second (Gbps) and beyond. Broadband replaced slow dial-up first through Digital Subscriber Line (DSL) and cable service, which offered 256 Kbps to several Mbps in the early 2000s without blocking the phone line.
Fiber optic internet followed, sending data as pulses of light through glass strands instead of electrical signals through copper. Symmetrical 1 Gbps home plans are now common in many cities, and some providers sell 2-10 Gbps tiers to homes and offices.
Official benchmarks moved with the technology, as the Federal Communications Commission (FCC) raised its fixed broadband benchmark to 100/20 Mbps in March 2024. The previous benchmark, set in 2015, stood at only 25 Mbps download and 3 Mbps upload.
Bandwidth vs Latency: Why a Faster Line Is Not the Whole Story
Bandwidth measures how much data a connection carries per second, while latency measures how long one round trip takes between a browser and a server. Broadband solved the bandwidth problem for most users, yet a page with 70 requests still waits on dozens of round trips. Latency therefore became the next target for CDNs, HTTP/3, and edge computing.
How Did Mobile Networks Extend Broadband Speed to Phones?
Mobile networks carried the broadband leap to phones, moving from 2G data in the late 1990s to 5G connections that exceed 1 Gbps in good coverage. The table lists typical real-world figures for each generation, not lab peaks.
| Generation | Era | Typical real-world speed | Typical latency |
|---|---|---|---|
| 2G (GPRS, EDGE) | Late 1990s to 2000s | 0.05-0.2 Mbps | 300-1,000 ms |
| 3G | 2000s | 1-7 Mbps | 100-500 ms |
| 4G LTE | 2010s | 10-50 Mbps | 30-60 ms |
| 5G | 2020s | 100 Mbps to 1+ Gbps | 10-30 ms |
The International Telecommunication Union (ITU) set a peak download target of 20 Gbps for 5G under its IMT-2020 requirements. Faster mobile networks matter most in markets such as Bangladesh, where most people reach the web through a phone rather than a fixed line.
2. Web Caching Stopped Repeat Downloads
Web caching made the web quicker by storing copies of files closer to the user, so a browser, server, or CDN can reuse them instead of fetching them again. HTTP/1.1, published by the Internet Engineering Task Force (IETF) in 1997, introduced the Cache-Control header that still tells browsers how long a file stays fresh.
The current caching rules live in the IETF’s RFC 9111, published in 2022. There are 3 main types of web caching, and each one saves a different trip:
- Browser caching saves CSS, JavaScript, fonts, and images on the device, so a return visit skips those downloads.
- Server caching stores ready-made page responses or database results, so the server avoids rebuilding the same page for every visitor.
- Edge caching keeps copies on CDN servers near the visitor, so even a first-time visitor gets a short round trip.
Validation headers such as ETag and Last-Modified let a browser ask whether a file changed, and a 304 Not Modified reply costs a few hundred bytes instead of the full file. Wrong cache rules cause the opposite problem, where a stale price or a private account page reaches the wrong person, so checkout and account pages usually carry no-store or private directives.
Service workers added a programmable cache inside the browser, which lets progressive web apps (PWAs) open instantly on repeat visits and keep working offline. Teams that want a cache filled before traffic arrives send a warmup cache request, which loads key pages into the cache ahead of a launch or a deployment.
3. Content Delivery Networks Brought Content Closer to Users
A content delivery network (CDN) made the web quicker by copying website files to edge servers in many cities, so each visitor downloads from the nearest one. Akamai launched the first large commercial CDN in 1998 to absorb traffic spikes that crashed single servers. Cloudflare (2010) and Fastly (2011) later brought CDN services within reach of small sites.
Distance sets a hard floor on latency, since light inside fiber optic cable travels at roughly 200,000 km per second (about 124,000 miles per second). A round trip between New York and Dhaka, Bangladesh, covers about 25,200 km (15,700 miles), so it can never finish in less than about 125 milliseconds (ms).
A visitor in New Jersey reaching the same New York server waits only a few milliseconds, which shows that distance decides how fast the first bytes arrive. Content delivery networks (CDNs) close that distance gap in 4 ways:
- Edge servers cache static files such as images, CSS, and JavaScript near visitors.
- Anycast routing sends each DNS lookup and request to the closest point of presence.
- TLS termination at the edge completes the secure handshake close to the visitor.
- Load balancing spreads traffic spikes across many machines instead of one origin. A CDN does not fix every delay on its own, since personalized pages, slow database queries, and heavy scripts still depend on the origin. The next ideas on this list target those remaining delays inside files, browsers, and protocols.
4. Data Compression Shrank Every Byte on the Wire
Data compression made the web quicker by shrinking text and images before transfer, so fewer bytes cross the network and pages finish loading sooner. Gzip, built on the DEFLATE algorithm and described in RFC 1952 in 1996, became the default text compression for web servers.
Google released Brotli in 2015, and the IETF published it as RFC 7932 in 2016. Brotli compresses HTML, CSS, and JavaScript roughly 15-25% smaller than gzip at similar decoding speed, and Zstandard (zstd), developed at Meta, joined Chrome as a content encoding in 2024.
Minification removes whitespace and comments from code before compression runs, and the two steps together often cut a JavaScript bundle by 70% or more.
Modern Image Formats: WebP and AVIF
Images make up the largest share of page weight on most sites, so image compression delivers the biggest byte savings. WebP, released by Google in 2010, produces files about 25-34% smaller than JPEG at equal quality. AVIF, finalized in 2019 by the Alliance for Open Media, usually compresses further than WebP.
| Format | Year | Best for | Typical saving |
|---|---|---|---|
| Gzip | 1992 | HTML, CSS, JavaScript | 60-80% vs uncompressed text |
| Brotli | 2015 | HTML, CSS, JavaScript | 15-25% smaller than gzip |
| Zstandard | 2016 | Text, fast server compression | Close to Brotli, faster to compress |
| WebP | 2010 | Photos and graphics | 25-34% smaller than JPEG |
| AVIF | 2019 | Photos and hero images | Often around 50% smaller than JPEG |
5. AJAX Let Web Pages Update Without Reloading
AJAX made the web quicker by letting a page fetch new data in the background and update one part of the screen without reloading the whole page. Asynchronous JavaScript and XML (AJAX) got its name from Jesse James Garrett in February 2005, yet its core tool, the XMLHttpRequest object, first shipped in Internet Explorer 5 in 1999.
Gmail (2004) and Google Maps (2005) showed what the approach could do, and AJAX became the engine behind Web 2.0 sites that behaved like desktop software. Modern code uses the Fetch API and JSON instead of XML, and frameworks such as React and Next.js build single-page applications on the same asynchronous idea. AJAX-style background requests now handle 4 everyday tasks on most websites:
- Search boxes suggest results while the user types.
- Shopping carts update the item count without leaving the product page.
- Dashboards refresh one chart instead of redrawing every panel.
- Chat windows receive new messages through background requests or WebSockets. The approach has one trap, as dozens of small requests or a heavy script bundle can slow a page as much as a full reload once did. Asynchronous loading works best when it is paired with compression, caching, and lean code.
6. Faster JavaScript Engines Turned Browsers Into App Platforms
Faster JavaScript engines made the web quicker by compiling scripts into machine code while they run, which turned slow, interpreted pages into responsive web applications. Google released the V8 engine with Chrome in September 2008, and V8 used just-in-time (JIT) compilation instead of reading JavaScript line by line.
Mozilla’s SpiderMonkey and Apple’s JavaScriptCore adopted similar JIT designs, and benchmark scores across browsers climbed many times over within a few years. V8 later moved outside the browser as the runtime inside Node.js, so the same engine now runs server code as well as page scripts.
Rendering engines improved in parallel with script engines, as Blink, WebKit, and Gecko began using the graphics processing unit (GPU) to paint and composite page layers. GPU compositing keeps scrolling and animation smooth even on mid-range phones.
How Does WebAssembly Push Browser Speed Further?
WebAssembly (WASM) pushes browser speed further by running compiled code at near-native speed inside the browser. Code written in C++, Rust, or Go compiles to WASM, which shipped in all major browsers in 2017 and became a World Wide Web Consortium (W3C) Recommendation in December 2019.
WASM handles heavy work such as video editing, 3D rendering, and image processing, while JavaScript and TypeScript keep handling the user interface. Design tools, CAD software, and photo editors that once required a desktop install now run in a browser tab for this reason.
7. HTTP/2 and HTTP/3 Rewired Browser-to-Server Communication
HTTP/2 and HTTP/3 made the web quicker by sending many files over one connection at once and by cutting the handshakes needed before data starts to flow. Hypertext Transfer Protocol version 1.1 (HTTP/1.1) handled one request at a time per connection, so browsers opened about 6 parallel connections per host and still queued the rest.
Developers worked around that limit with image sprites, file concatenation, and domain sharding, and every workaround added build complexity without fixing the protocol itself.
What Did HTTP/2 Change?
Google’s experimental SPDY protocol (2009) proved that multiplexing worked, and the IETF standardized HTTP/2 as RFC 7540 in 2015, later revised as RFC 9113. HTTP/2 introduced 3 core upgrades: multiplexing many requests over one TCP connection, HPACK header compression, and stream prioritization.
Server push was part of the original standard, but Chrome removed it in 2022 after real-world gains proved small. Preload hints and 103 Early Hints took over the job of starting critical downloads early.
How Do HTTP/3 and QUIC Go Further?
HTTP/3 runs on QUIC, a transport protocol built on the User Datagram Protocol (UDP) instead of the Transmission Control Protocol (TCP). QUIC, published as RFC 9000 in 2021, builds encryption into the transport handshake and keeps each stream independent, so one lost packet no longer stalls every file on the connection.
Transport Layer Security version 1.3 (TLS 1.3), published as RFC 8446 in 2018, cut the secure handshake from two round trips to one. HTTP/3 itself became RFC 9114 in June 2022, and the table shows how the round trips add up before the first request leaves the browser.
| Connection setup | Round trips before the request | Typical protocol |
|---|---|---|
| TCP + TLS 1.2 | 3 | HTTP/1.1 or HTTP/2 on older servers |
| TCP + TLS 1.3 | 2 | HTTP/2 on modern servers |
| QUIC, new connection | 1 | HTTP/3 |
| QUIC, resumed connection | 0 (0-RTT) | HTTP/3 for returning visitors |
On a 125 ms link between New York and Dhaka, dropping from 3 round trips to 1 saves about 250 ms before the page starts to arrive. Connection migration lets a QUIC session survive a switch from Wi-Fi to 5G, which matters on mobile networks where devices change IP addresses mid-visit.
8. Cloud Computing and Edge Computing Spread the Load
Cloud computing and edge computing made the web quicker by spreading websites across many servers that scale with demand and by running code at locations close to each user. Amazon Web Services (AWS) launched S3 storage and EC2 servers in 2006, and Google Cloud and Microsoft Azure followed with the same rent-on-demand model.
A site no longer lived on one machine that crashed during a traffic spike. Auto-scaling groups add servers within minutes, load balancers spread requests across them, and Docker containers with Kubernetes orchestration made that scaling repeatable across clouds.
What Is Edge Computing and How Does It Cut Latency?
Edge computing cuts latency by moving application logic from a central data center to CDN locations near users, so personalization, redirects, and A/B tests run within milliseconds of the visitor. Edge function platforms such as Lambda@Edge and Cloudflare Workers appeared in the late 2010s, and they now handle image resizing, bot filtering, and small AI inference tasks.
Edge code still pays the full distance cost when it needs data from one central database, so teams pair edge functions with replicated data or edge caching. The same budgeting logic applies to AI products, and our guide to a sub-250ms inference latency budget shows how teams split those milliseconds across network, model, and response.
How Do These Technologies Work Together in One Page Load?
These technologies work together as one chain, and a single page load in 2026 touches all 8 ideas in about 1-2 seconds:
- DNS resolution returns the nearest CDN address through Anycast routing, often straight from a resolver cache.
- QUIC opens an encrypted HTTP/3 connection in one round trip, or zero round trips for a returning visitor.
- An edge server answers from its cache or runs an edge function, so the request rarely travels to the origin.
- Brotli or zstd compressed HTML arrives over a broadband or 5G link, and the browser starts parsing it at once.
- The browser follows the critical rendering path, loading render-blocking CSS first and deferring non-critical JavaScript.
- Cached files from the previous visit skip the network, while WebP and AVIF images fill the visible area.
- V8 compiles the page scripts, and Fetch requests pull live data without another full reload.
Critical rendering path optimization ties the chain together, since the browser cannot paint until it builds the Document Object Model (DOM) and the CSS Object Model (CSSOM). Inlining above-the-fold CSS, adding defer or async to scripts, and preloading the hero image let the largest visible element appear sooner.
The same layered approach sits behind an application acceleration manager, which bundles caching, compression, and connection tuning into one appliance or service for business applications.
How Do Core Web Vitals Measure Whether the Web Got Quicker?
Core Web Vitals measure web speed through 3 user-centered metrics: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. Google announced the metrics in May 2020 and added them to search ranking signals through the page experience update in 2021.
INP replaced First Input Delay (FID) on March 12, 2024, and Google scores each metric at the 75th percentile of real visits. The thresholds below come straight from the official Google Search Central.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Time until the largest visible element renders | 2.5 s or less | 2.5-4.0 s | Over 4.0 s |
| INP | Delay between a click, tap, or key press and the next paint | 200 ms or less | 200-500 ms | Over 500 ms |
| CLS | Unexpected movement of page elements | 0.1 or less | 0.1-0.25 | Over 0.25 |
Core Web Vitals do not speed up a page on their own, as the metrics act as a scoreboard that shows which of the 8 ideas a site still needs. Good scores support search engine optimization (SEO) and user experience (UX), while relevance still decides most rankings.
Which Web Page Design Technologies Keep Pages Fast Today?
The web page design technologies that keep pages fast today are responsive images, native lazy loading, resource hints, modern font loading, code splitting, and CSS containment. These latest web design technologies work inside HTML and CSS, so a designer can apply them without changing servers or protocols.
- Responsive images with srcset and sizes let a phone download a 450-pixel file instead of a 1,600-pixel desktop file.
- Native lazy loading through loading=“lazy”, supported in Chrome since 2019, delays offscreen images and iframes until the user scrolls near them.
- Resource hints such as preconnect, dns-prefetch, and preload start DNS lookups, handshakes, or critical downloads early.
- Font loading with WOFF2 files and font-display: swap shows text immediately instead of hiding it while a custom font downloads.
- Code splitting and tree shaking ship only the JavaScript a page needs, which cuts parse time on slower devices.
- CSS containment through the content-visibility property skips rendering work for sections far below the fold. MDN Web Docs documents the loading and srcset attributes for every major browser. One rule matters more than the rest: never lazy-load the image that becomes the LCP element, since delaying it pushes the main loading score past 2.5 seconds.
What New Web Technologies Are Shaping Future Web Speed?
The new web technologies shaping future web speed are speculation rules, 103 Early Hints, Zstandard compression, WebGPU for web AI, and WebAssembly outside the browser. These new technologies in web development share one goal with the original 8 ideas, which is removing the next delay between a request and a usable page. Any new technology in web development earns adoption only when it cuts a delay that users can feel.
Speculation Rules and Instant Navigation
The Speculation Rules API lets a page tell Chrome which links to prefetch or fully prerender, so the next page appears almost instantly when the user clicks. The back/forward cache (bfcache) completes the picture by restoring a previous page from memory instead of reloading it.
103 Early Hints
The 103 Early Hints status code lets a server or CDN send preload and preconnect hints while the origin is still building the HTML. Chrome added support in version 103 in 2022, which turned server think time into useful download time.
Web AI and WebGPU
Web AI runs machine learning models directly in the browser, and WebGPU, shipped in Chrome 113 in 2023, gives those models access to the graphics card for fast parallel math. On-device inference removes the network round trip entirely, which makes live translation, AI visual search, and text suggestions feel instant.
Teams that want these features inside their own products can start with our explainer on how AI works or plan a build through generative AI development.
Next Big Things on the Internet
The next big things on the internet for speed include HTTP/3 becoming the default protocol, AI-driven prefetching that predicts the next click, and edge AI that runs models inside CDN locations. These web tech trends sit alongside the latest innovations in web platforms, such as WebAssembly running on servers and edge runtimes.
Quantum networking sits further out among future web technologies, and our report on the latest breakthroughs in quantum computing explains where that research stands today.
Web 2.0 Technologies List: Where Speed Met Interaction
The Web 2.0 technologies list centers on 6 tools that made sites interactive and fast at the same time: AJAX, JSON, RSS feeds, public APIs, CSS layouts, and JavaScript libraries. Web 2.0 technologies examples include Gmail’s background inbox updates, Google Maps’ draggable tiles, Flickr’s photo tagging, and Wikipedia’s shared editing, all launched between 2001 and 2005.
Web 2.0 design solution development moved the browser from a document viewer to an application platform. That shift created the demand for the faster JavaScript engines, wider CDN coverage, and HTTP/2 multiplexing that followed later in the decade.
How Can a Business Apply These Speed Ideas in 2026?
A business applies these speed ideas by measuring first, fixing the largest bottleneck, and measuring again. The six steps below follow that order and fit most company websites and web apps.
- Run PageSpeed Insights on the homepage, a key landing page, and the sign-up or checkout flow, then note the field data for LCP, INP, and CLS.
- Confirm that the host or CDN serves HTTP/3, Brotli or zstd compression, and long cache lifetimes for static files.
- Convert hero and product images to WebP or AVIF, add srcset, and lazy-load only offscreen images.
- Remove or defer third-party scripts that block the main thread, such as unused chat widgets and duplicate analytics tags.
- Move personalization and redirects to edge functions where the logic does not need a central database.
- Re-test after each change against a fixed baseline, a habit covered in our guide to software testing basics, and compare field data over the next 28 days. For AI-heavy products, speed work extends to model serving, data pipelines, and inference latency. SoftBrixAI handles that layer through AI software development, MLOps, and AI data engineering, and SaaS teams often begin with an AI consulting session to find which bottleneck to fix first.
FAQs About the Tech Ideas That Made the Web Move Quicker
What is the most important tech idea that made the web move quicker?
Broadband internet is the most important single idea, since every later improvement, from CDNs to video streaming, depends on connections far faster than 56 Kbps dial-up. Latency fixes such as CDNs and HTTP/3 delivered the largest gains once broadband became common.
Does a CDN make every website faster?
No, a CDN does not make every website faster. A CDN speeds up cacheable files for distant visitors, but it cannot fix slow database queries, heavy JavaScript, or oversized images that the origin still sends.
Is HTTP/3 faster than HTTP/2?
Yes, HTTP/3 is usually faster than HTTP/2 on mobile networks and lossy connections, since QUIC sets up in fewer round trips and stops one lost packet from blocking every stream. On a stable wired connection, the gap shrinks to a few milliseconds.
What are the cutting-edge web technologies in 2026?
The cutting-edge web technologies in 2026 are HTTP/3, the Speculation Rules API, WebGPU, WebAssembly, edge functions, and Zstandard compression. Teams tracking cutting-edge web tech usually adopt HTTP/3 and speculation rules first, as both need no change to page content.
Which new website technology speeds up a site the most?
Modern image formats speed up most sites the most, since images make up the largest share of page weight. Switching JPEG and PNG files to WebP or AVIF often cuts total page weight by a third without visible quality loss. That switch is the new web tech change with the quickest payoff for most sites.
Can AI make websites load faster?
Yes, AI can make websites load faster by predicting the next page for prefetching, choosing image quality per device, and flagging scripts that block the main thread. Every AI suggestion still needs a before-and-after check in Core Web Vitals field data.
What is the difference between bandwidth and latency?
Bandwidth is the amount of data a connection moves per second, measured in Mbps or Gbps, while latency is the delay of one round trip, measured in milliseconds. Broadband raised bandwidth, and CDNs, HTTP/3, and edge computing lowered latency.
Final Thoughts
The 8 tech ideas that made the web move quicker each removed a specific delay. Broadband replaced slow dial-up, web caching ended repeat downloads, content delivery networks (CDNs) brought content closer to users, and data compression with WebP and AVIF shrank every file.
AJAX ended full page reloads, V8 and other JavaScript engines sped up code, HTTP/2 and HTTP/3 cut connection handshakes, and cloud computing with edge computing spread the load worldwide. Core Web Vitals now measure the result, while new web technologies such as speculation rules, WebGPU, and WebAssembly continue the same work.
Sites that measure, fix the biggest bottleneck, and measure again turn these ideas into faster page loading for every visitor. To apply the same thinking to an AI product or a high-traffic web app, contact the SoftBrixAI team for a performance-first plan.
References
- IETF RFC 9111: HTTP Caching
- IETF RFC 9113: HTTP/2
- IETF RFC 9114: HTTP/3
- IETF RFC 9000: QUIC
- IETF RFC 8446: TLS 1.3
- IETF RFC 7932: Brotli Compressed Data Format
- IETF RFC 1952: GZIP File Format
- W3C WebAssembly Core Specification
- FCC Broadband Progress Reports
- ITU IMT-2020 (5G) Requirements
- HTTP Archive Web Almanac: Page Weight
- Google Search Central: Core Web Vitals
- MDN Web Docs: The img element
