Page Speed Optimization Checklist

Page speed optimization is the systematic process of improving the time it takes for a web page to load, render, and become fully interactive for a user. It matters because modern internet users demand instantaneous access to information, and search engines like Google heavily penalize slow-loading websites by burying them in search results. By mastering the techniques outlined in this comprehensive checklist, practitioners can dramatically reduce bounce rates, increase conversion metrics, and engineer digital experiences that feel frictionless and instantaneous.

What It Is and Why It Matters

Page speed optimization represents the intersection of server-side engineering, frontend web development, and network architecture, all focused on a single goal: delivering digital content to a user's screen as rapidly as possible. At its core, it is the discipline of minimizing the payload size of a website, optimizing the delivery route of that payload, and structuring the code so the browser can paint the pixels on the screen without hesitation. This is not merely a technical vanity metric; it is a fundamental pillar of user experience and digital business viability. When a user clicks a link, a psychological stopwatch begins ticking. If the page does not provide visual feedback within a critical threshold—typically under 1.0 second—the user's attention wanes, and cognitive friction builds.

The business implications of page speed are staggering and mathematically proven. In 2006, Amazon conducted a landmark study revealing that every 100 milliseconds of latency cost them 1% in total sales revenue. Similarly, Walmart discovered that for every 1-second improvement in page load time, conversions increased by 2%. When a page takes longer than 3 seconds to load, 53% of mobile users will abandon the site entirely. This phenomenon is known as the "bounce rate," and it scales exponentially with load time. Furthermore, page speed is a direct ranking factor in search engine algorithms. Google operates on a finite "crawl budget" and prefers sites that load efficiently. A slow site not only bleeds existing customers but also prevents new customers from ever discovering the business through organic search.

Understanding page speed requires recognizing that "speed" is not a single, monolithic metric. It is a perceived experience. A page might take 10 seconds to fully download all background assets, but if the text and primary image appear in 800 milliseconds, the user perceives the page as fast. Therefore, page speed optimization is largely about prioritizing the critical rendering path—ensuring the most important elements load first while deferring non-essential scripts, trackers, and off-screen images until after the user has engaged with the content. It is a continuous balancing act between adding rich functionality to a website and maintaining a lean, aerodynamic codebase.

History and Origin of Web Performance

The discipline of web performance optimization was born out of necessity during the dial-up internet era of the 1990s. In 1995, the average internet connection speed was 28.8 kilobits per second (Kbps), meaning a single 100-kilobyte image took nearly 30 seconds to download. During this period, optimization consisted almost entirely of aggressive image compression and writing minimal HTML. The modern era of page speed optimization, however, truly began in 2007 with the publication of "High Performance Web Sites" by Steve Souders, who was the Chief Performance Yahoo at the time. Souders formulated 14 rules for faster-loading websites, introducing concepts like utilizing Content Delivery Networks (CDNs), putting stylesheets at the top of the document, and putting scripts at the bottom. He also created YSlow, an open-source browser extension that graded web pages against these rules, effectively giving developers their first performance checklist.

In 2008, Patrick Meenan created WebPagetest, a tool that allowed developers to test their websites from real browsers on consumer-grade network conditions. This tool introduced the "waterfall chart" to the masses, visually mapping exactly how and when every asset on a page loaded. This visualization revolutionized the industry by proving that the backend (server response time) accounted for only 10% to 20% of the end-user response time. The other 80% to 90% of the delay occurred on the frontend, as the browser struggled to download, parse, and execute images, stylesheets, and JavaScript.

The paradigm shifted permanently in April 2010 when Google officially announced that site speed would be used as a signal in their web search ranking algorithms. This transformed page speed from a developer's hobby into a mandatory marketing requirement. In July 2018, Google rolled out the "Speed Update," making mobile page speed a ranking factor for mobile searches, reflecting the global shift toward smartphone browsing. Finally, in May 2020, Google introduced the "Core Web Vitals," a standardized set of three specific metrics designed to measure the real-world user experience of loading performance, interactivity, and visual stability. This established a universal, quantifiable benchmark that the entire web development industry operates against today.

How It Works — Step by Step

To optimize page speed, one must deeply understand the Critical Rendering Path—the exact sequence of steps the browser takes from the moment a user hits "Enter" to the moment pixels appear on the screen. The process begins with DNS Resolution. The browser asks a Domain Name System server to translate a human-readable URL (like example.com) into a machine-readable IP address (like 192.0.2.1). Next, the browser establishes a connection with the server using a TCP Handshake (Transmission Control Protocol), and if the site is secure, it performs a TLS Negotiation (Transport Layer Security) to encrypt the connection. Only after these network round-trips can the browser send the actual HTTP Request for the HTML document.

Once the server processes the request and sends the first byte of data back (measured as Time to First Byte, or TTFB), the browser begins parsing the HTML. The browser reads the HTML top-to-bottom and constructs the Document Object Model (DOM). When the parser encounters a link to a CSS file, it must pause, request the file, download it, and construct the CSS Object Model (CSSOM). CSS is "render-blocking" because the browser cannot paint the page until it knows how the elements should be styled. If the parser encounters a synchronous JavaScript <script> tag, it must halt parsing the HTML entirely, download the script, and execute it using the browser's JavaScript engine (like Chrome's V8), because JavaScript has the power to alter both the DOM and the CSSOM.

After the DOM and CSSOM are fully constructed, the browser combines them into a Render Tree. The Render Tree contains only the nodes required to render the page (excluding elements with display: none). Next comes the Layout phase, where the browser calculates the exact geometry—the size and position—of every element on the screen based on the viewport size. Finally, the browser executes the Paint phase, filling in the pixels, and the Composite phase, drawing different layers (like a fixed header or an overlapping modal) in the correct order. Page speed optimization involves systematically identifying bottlenecks in this specific pathway and eliminating them.

The Performance Budget Formula and Worked Example

Professionals use mathematical models known as "Performance Budgets" to dictate exactly how many assets a page can contain while still meeting speed goals. The foundational formula calculates the theoretical load time based on page size, network bandwidth, and network latency (Round Trip Time, or RTT).

The Formula

Estimated Load Time (in seconds) = (Total Page Weight in Kilobits / Network Bandwidth in Kilobits per second) + (Number of Critical Requests × RTT Latency in seconds)

Variables Defined:

• Total Page Weight in Kilobits: The total size of all assets transferred over the network. (Note: 1 Kilobyte [KB] = 8 Kilobits [Kb]).
• Network Bandwidth (Kbps): The maximum rate of data transfer across the user's connection.
• Number of Critical Requests: The total number of sequential network round-trips required to fetch blocking resources (HTML, CSS, synchronous JS).
• RTT Latency: The time it takes for a signal to travel from the user to the server and back.

Worked Example

Suppose a development team wants to know if their new landing page will load in under 2.5 seconds for a user on a standard 3G mobile connection.

• Total Page Weight: The page is 1.5 Megabytes (MB). First, convert to Kilobytes: 1.5 MB = 1,500 KB. Next, convert to Kilobits: 1,500 KB × 8 = 12,000 Kb.
• Network Bandwidth: A standard 3G connection provides roughly 1.6 Megabits per second (Mbps). Convert to Kilobits per second: 1.6 Mbps × 1,000 = 1,600 Kbps.
• Number of Critical Requests: The page requires 4 sequential round trips (1 for HTML, 1 for CSS, 1 for JS, 1 for the hero image).
• RTT Latency: 3G networks typically have an RTT of 0.15 seconds (150 milliseconds).

Step 1: Calculate the pure download time. Download Time = 12,000 Kb / 1,600 Kbps Download Time = 7.5 seconds.

Step 2: Calculate the latency time. Latency Time = 4 requests × 0.15 seconds Latency Time = 0.6 seconds.

Step 3: Calculate the Total Estimated Load Time. Total Estimated Load Time = 7.5 seconds + 0.6 seconds = 8.1 seconds.

Conclusion: The estimated load time is 8.1 seconds, which massively fails the 2.5-second goal. To fix this, the team must either reduce the page weight to roughly 350 KB, decrease the number of critical requests, or accept that the page will fail Core Web Vitals on 3G connections.

Key Concepts and Terminology

To navigate a page speed optimization checklist, one must master the specific vocabulary used by performance engineers and search engines. The most critical terms belong to Google's Core Web Vitals, a subset of performance metrics that quantify the user experience. Largest Contentful Paint (LCP) measures loading performance. It marks the exact millisecond when the largest text block or image element becomes visible within the viewport. A fast LCP reassures the user that the page is useful. Cumulative Layout Shift (CLS) measures visual stability. It calculates the sum of all unexpected layout shifts that occur during the entire lifespan of the page. If a user goes to click a button, but a late-loading ad pushes the button down causing them to click the wrong thing, the CLS score spikes. Interaction to Next Paint (INP) measures responsiveness. Introduced in 2024 to replace First Input Delay (FID), INP observes the latency of all click, tap, and keyboard interactions throughout the user's visit, reporting the longest delay between a user action and the browser painting the visual update.

Beyond the Core Web Vitals, several foundational metrics map to the browser rendering pathway. Time to First Byte (TTFB) is a server-side metric measuring the time from the user's request to the arrival of the first byte of data. It isolates server processing time and network latency from frontend rendering. First Contentful Paint (FCP) marks the time when the browser renders the first piece of DOM content, whether that is text, an image, or an SVG. It is the first moment the user sees anything other than a blank white screen. Time to Interactive (TTI) measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly (meaning the main JavaScript thread is idle).

Technical terminology regarding asset delivery is equally important. Minification is the process of removing all unnecessary characters from source code (like whitespace, line breaks, and comments) without changing its functionality, thereby reducing file size. Compression refers to algorithms like Gzip or Brotli applied at the server level to shrink text-based files (HTML, CSS, JS) before sending them over the network. Lazy Loading is a technique where non-critical resources (usually images or iframes below the user's immediate screen) are not downloaded until the user scrolls down near them. Render-Blocking Resources are static files, typically synchronous CSS and JavaScript, that prevent the browser from painting the page until they are fully downloaded and parsed.

Types, Variations, and Methods

Page speed optimization is not a single task but a multi-disciplinary effort divided into three distinct categories: Server/Network Optimization, Asset Optimization, and Rendering Optimization. Each category attacks a different phase of the critical rendering path.

Server and Network Optimization focuses on the physical delivery of bytes. The most impactful method here is utilizing a Content Delivery Network (CDN) like Cloudflare or Fastly. A CDN is a globally distributed network of proxy servers. Instead of a user in Tokyo requesting a website hosted on a single server in New York (incurring massive geographic latency), the CDN serves a cached version of the site from a node physically located in Tokyo, reducing network round-trip times from 200 milliseconds to 15 milliseconds. Another critical network method is upgrading to modern transfer protocols like HTTP/2 or HTTP/3. Older HTTP/1.1 protocols could only download a few files simultaneously per domain, causing a bottleneck known as head-of-line blocking. HTTP/2 introduced multiplexing, allowing dozens of files to be downloaded concurrently over a single TCP connection, while HTTP/3 utilizes the QUIC protocol over UDP to virtually eliminate connection latency even on unstable mobile networks.

Asset Optimization focuses on reducing the sheer volume of data transferred. For images, this means moving away from legacy formats like JPEG and PNG to modern, highly compressed formats like WebP and AVIF, which offer identical visual quality at file sizes 30% to 50% smaller. It also involves serving responsive images—using the HTML <picture> element or srcset attribute to send a small 400-pixel wide image to a mobile phone, while reserving the 2000-pixel wide image for 4K desktop monitors. For code assets, this involves aggressive minification and compression, as well as "Tree Shaking"—a process used in modern JavaScript bundlers (like Webpack or Vite) to automatically detect and remove dead, unused code from libraries before shipping them to the user.

Rendering Optimization focuses on manipulating the browser's prioritization queue. This includes implementing Critical CSS, where the exact CSS required to style the "above-the-fold" content is calculated and injected directly into the HTML <head>, while the rest of the stylesheet is loaded asynchronously. It also involves aggressively managing JavaScript execution by using the defer or async attributes on <script> tags. The defer attribute tells the browser to download the script in the background without pausing HTML parsing, and to only execute the script after the DOM is fully built. These methods ensure that heavy logic does not prevent the user from seeing the visual content.

Real-World Examples and Applications

To understand the tangible impact of these optimizations, consider the real-world scenario of a mid-sized e-commerce retailer generating $10 million in annual revenue. Their product pages were suffering from a sluggish Largest Contentful Paint (LCP) of 4.8 seconds on mobile devices. The primary culprit was a massive 1.2-megabyte unoptimized PNG hero image of the product, coupled with a render-blocking JavaScript file from a third-party review widget. By converting the product image to the WebP format, reducing its dimensions to match the mobile viewport, and adding a <link rel="preload" as="image"> tag to the document head, they forced the browser to fetch the image immediately. Furthermore, they added the defer attribute to the review widget script. These two changes dropped the page weight by 900 kilobytes and eliminated the render-blocking thread. The LCP plummeted from 4.8 seconds to 1.9 seconds. Consequently, the retailer saw their mobile bounce rate drop from 68% to 42%, and their conversion rate increased by 1.5%, yielding an additional $150,000 in annualized revenue from entirely existing traffic.

Another common application occurs in the digital publishing industry. A major news website was failing the Cumulative Layout Shift (CLS) metric with a disastrous score of 0.65. Users were complaining that while reading an article, the text would suddenly jump down the screen, causing them to lose their place. A performance audit revealed the issue: the site was injecting programmatic display advertisements into the middle of the article text. Because the ad server took 1.5 seconds to return the ad creative, the browser initially rendered the page with no space for the ad. When the ad finally loaded, it violently pushed the paragraphs downward. The optimization team solved this by implementing "aspect ratio boxes"—reserving the exact pixel dimensions (e.g., min-height: 250px; width: 300px;) in the CSS for the ad slots before the ad even loaded. The CLS score instantly dropped to 0.02. User session duration increased by 40%, and page views per session rose, directly increasing the publisher's ad impression revenue.

Common Mistakes and Misconceptions

The most pervasive misconception in page speed optimization is confusing "Lab Data" with "Field Data." Beginners frequently run their website through Google Lighthouse on their high-end MacBook Pro connected to gigabit fiber internet, score a 98/100, and declare the site optimized. This is Lab Data—a simulated test run in a controlled environment. However, Google's search algorithms do not care about Lab Data; they rank sites based on Field Data, specifically the Chrome User Experience Report (CrUX). CrUX aggregates the actual load times experienced by real users in the real world, many of whom are using 4-year-old Android devices on spotty 3G cellular connections. A site can score 100 in Lighthouse and still fail Core Web Vitals in the field. Professionals optimize for the 75th percentile of their actual user base, not for the simulation.

Another critical mistake is the overuse of third-party plugins in Content Management Systems like WordPress. Novices assume that installing five different "speed optimization" plugins will stack their benefits. In reality, these plugins often conflict, double-minify files resulting in broken code, and add their own heavy PHP processing overhead to the server, ultimately increasing the Time to First Byte (TTFB). The correct approach is to use a single, comprehensive caching and optimization solution and to manually audit the site's architecture.

Developers also frequently misunderstand the difference between the async and defer attributes for JavaScript. A common mistake is slapping async on every script tag to prevent render-blocking. However, async scripts execute the exact millisecond they finish downloading, pausing the HTML parser whenever that happens. If multiple async scripts have dependencies on each other (e.g., a plugin relying on jQuery), they will execute in random order based on download speed, causing fatal console errors and broken functionality. defer is almost always the correct choice for non-critical scripts, as it guarantees scripts will execute in the exact order they appear in the document, but only after the HTML is completely parsed.

Best Practices and Expert Strategies

The definitive checklist for expert page speed optimization requires a methodical, top-down approach to the web stack. First, configure the server to serve assets with aggressive caching headers. Static assets like logos, fonts, and CSS files rarely change, so experts set the Cache-Control header to public, max-age=31536000, immutable. This instructs the user's browser to store the file locally for exactly one year, meaning repeat page views require zero network requests for those assets. Simultaneously, ensure the server is configured to use Brotli compression, which compresses text-based files 15% to 20% smaller than the older Gzip standard.

For image optimization, experts do not rely solely on automated compression. They implement a strict responsive imagery strategy using the HTML srcset attribute, providing the browser with 4 to 5 different resolutions of the same image (e.g., 400w, 800w, 1200w, 1600w). The browser intelligently downloads only the smallest file necessary to fill the user's specific screen. Furthermore, every image below the initial viewport must include the loading="lazy" attribute, a native HTML feature that defers the network request until the user scrolls within a set distance of the image. For the critical hero image above the fold, experts explicitly set fetchpriority="high" to command the browser to move that specific image to the top of the download queue.

Font optimization is another expert battleground. Custom web fonts can easily weigh 200KB and block text rendering, causing a phenomenon known as FOIT (Flash of Invisible Text), where the user stares at blank space until the font downloads. The best practice is to use the CSS descriptor font-display: swap;. This forces the browser to immediately render the text using a system fallback font (like Arial or Times New Roman), and then seamlessly "swap" to the custom font once it finishes downloading. Additionally, experts subset their fonts—removing Cyrillic, Greek, and other unused character glyphs from the font file if the site is only published in English, reducing the font file size by up to 80%.

Edge Cases, Limitations, and Pitfalls

While the standard checklist works for traditional multi-page websites, it breaks down significantly when applied to Single Page Applications (SPAs) built with frameworks like React, Angular, or Vue. In an SPA, the initial HTML document is essentially empty. The server sends a massive bundle of JavaScript, and the browser must download, parse, and execute that entire bundle before it can generate the HTML and render the page. This architecture inherently causes a terrible First Contentful Paint (FCP) and a massive Time to Interactive (TTI). Traditional optimization techniques like Critical CSS are ineffective here. The required strategy shifts to Server-Side Rendering (SSR) or Static Site Generation (SSG) using meta-frameworks like Next.js or Nuxt, which pre-calculate the HTML on the server before sending it to the client.

Another major limitation involves third-party ad networks and tracking pixels. A publisher might perfectly optimize their core codebase, achieving a 1.0-second load time, only to have a programmatic ad network inject 4 megabytes of unoptimized video ads and 15 different tracking scripts into the page. The site owner has zero control over the servers hosting these third-party scripts. The pitfall here is allowing these scripts to execute on the main thread. The mitigation strategy involves using technologies like Partytown, a library that relocates resource-intensive third-party scripts into a Web Worker. This executes the tracking logic on a separate background thread, completely freeing up the main thread to handle user interactions and keeping the Interaction to Next Paint (INP) score low.

Finally, practitioners must be wary of the "optimization trap"—spending dozens of engineering hours to shave 50 milliseconds off a load time that is already under 2 seconds. The relationship between page speed and conversion rate is logarithmic, not linear. Moving a load time from 8 seconds to 4 seconds will yield massive business results. Moving it from 1.5 seconds to 1.4 seconds will cost thousands of dollars in developer salaries and yield statistically zero change in user behavior. Performance budgets must be balanced against feature development and business constraints.

Industry Standards and Benchmarks

The undisputed authority on page speed benchmarks is Google, and their specific thresholds dictate the industry standard. To achieve a "Good" rating in the Core Web Vitals assessment—which is required to receive the ranking boost in Google Search—a page must meet three exact criteria at the 75th percentile of actual user page loads over a rolling 28-day period.

First, the Largest Contentful Paint (LCP) must occur in 2.5 seconds or less. If the LCP is between 2.5 and 4.0 seconds, it is marked "Needs Improvement," and anything over 4.0 seconds is classified as "Poor." Second, the Cumulative Layout Shift (CLS) score must be 0.1 or less. A score between 0.1 and 0.25 needs improvement, and above 0.25 is poor. Third, the Interaction to Next Paint (INP) must be 200 milliseconds or less. An INP between 200 and 500 milliseconds needs improvement, and over 500 milliseconds is poor. Meeting these three specific thresholds is the primary objective of any modern page speed optimization campaign.

For simulated lab testing, Google's Lighthouse auditing tool (currently on version 10) uses a weighted scoring system to generate a final performance score out of 100. As of Lighthouse v10, the score is weighted as follows: Largest Contentful Paint accounts for 25% of the score. Total Blocking Time (TBT)—a lab proxy for INP—accounts for 30%. Cumulative Layout Shift accounts for 25%. First Contentful Paint accounts for 10%, and the Speed Index (how quickly the contents of a page are visually populated) accounts for the final 10%. A score of 90 to 100 is considered excellent, 50 to 89 is moderate, and 0 to 49 is failing. Professionals use these exact weights to prioritize their optimization efforts; fixing a layout shift issue (25% weight) will yield a much higher score increase than tweaking the First Contentful Paint (10% weight).

Comparisons with Alternatives

When faced with a fundamentally slow website, businesses generally have three paths: systematic optimization (the checklist approach), a complete replatforming to Headless/Jamstack architecture, or adopting restrictive frameworks like Accelerated Mobile Pages (AMP).

Systematic Optimization vs. Complete Replatforming: Optimization involves taking an existing monolithic architecture—like a legacy WordPress or Magento site—and applying the checklist techniques (caching, minification, image compression) to patch the performance holes. The primary advantage is cost and time; optimization can be executed in weeks without disrupting the underlying business logic. However, the limitation is that monolithic systems have a performance ceiling dictated by their database queries and server rendering times. Replatforming to a Jamstack architecture (JavaScript, APIs, and Markup) involves decoupling the frontend from the backend. The frontend is pre-built into static HTML files during a build process and served globally via a CDN, while dynamic functionality is handled via APIs. Jamstack sites are astronomically faster by default because there is no database to query when a user requests a page. The downside is that replatforming requires rebuilding the entire website from scratch, costing tens or hundreds of thousands of dollars and requiring a highly specialized engineering team.

Systematic Optimization vs. Accelerated Mobile Pages (AMP): AMP was introduced by Google in 2015 as an open-source HTML framework designed to guarantee near-instant load times on mobile devices. AMP achieves this by strictly enforcing performance rules: all CSS must be inline and under 75KB, custom JavaScript is heavily restricted or banned entirely, and the pages are cached and served directly from Google's own servers. The advantage of AMP is guaranteed speed and, historically, preferential placement in Google's Top Stories carousel. However, the trade-offs are severe. AMP requires maintaining a separate, stripped-down codebase alongside the main website. It strips away brand identity, restricts complex interactive features, and keeps the user on a Google-hosted URL rather than the brand's actual domain. Because of these restrictions, and because systematic optimization of standard HTML has advanced so significantly, the industry has largely abandoned AMP. Standard page speed optimization is universally preferred over AMP today because it delivers excellent performance without sacrificing developer control or user experience.

Frequently Asked Questions

What is the difference between Lab Data and Field Data, and which one matters more? Lab Data is generated by running a simulated test in a controlled environment with predefined device and network settings, such as running a Google Lighthouse report in your Chrome browser. It is incredibly useful for debugging specific issues during development because the results are reproducible. Field Data, specifically from the Chrome User Experience Report (CrUX), is the aggregated historical data of real users loading your website on their actual devices across the globe. Field Data is what matters most. Google's search algorithm exclusively uses Field Data to determine if your site passes the Core Web Vitals assessment and deserves a ranking boost.

Do I need a 100/100 Google Lighthouse score to rank well in search engines? No, a perfect 100/100 Lighthouse score is not required, nor is it always practically achievable for complex, feature-rich websites. Lighthouse is a lab tool, and its score is merely a diagnostic indicator of best practices. Google Search does not see or use your Lighthouse score. Search engines evaluate the three Core Web Vitals (LCP, CLS, INP) based on real user data. As long as your website meets the "Good" thresholds for those three specific metrics at the 75th percentile of your user base, you receive the full SEO benefit, regardless of whether your lab score is an 85 or a 100.

How do third-party scripts like Google Analytics or Facebook Pixel affect page speed? Third-party scripts severely impact page speed by consuming the browser's main thread. When a browser encounters a tracking script, it must download the JavaScript file, parse it, compile it, and execute it. Because JavaScript is single-threaded, the browser cannot respond to user inputs (like scrolling or clicking a button) while this execution is happening, leading to high Interaction to Next Paint (INP) times. Furthermore, these scripts often download additional secondary scripts, creating a waterfall of network requests. To mitigate this, third-party scripts should always be loaded asynchronously or deferred, and ideally managed through a tag manager that prevents them from firing until after the primary visual content has rendered.

What is the difference between Gzip and Brotli compression? Both Gzip and Brotli are algorithms used by web servers to compress text-based files (HTML, CSS, JavaScript) before sending them over the network to the user's browser, which then decompresses them. Gzip is the older, universally supported standard developed in the 1990s. Brotli is a modern compression algorithm developed by Google in 2015 specifically optimized for web assets. Brotli uses a pre-defined dictionary of common HTML and JavaScript keywords, allowing it to compress files 15% to 20% smaller than Gzip at the same processing speed. Modern best practice dictates configuring your server to serve Brotli to modern browsers, while keeping Gzip as a fallback for legacy browsers.

Why does my page load fast visually, but I can't click anything for several seconds? This frustrating phenomenon occurs when a page suffers from a poor Time to Interactive (TTI) or high Total Blocking Time (TBT). It happens because the visual assets (HTML and CSS) have successfully downloaded and rendered, but the browser is still downloading and executing a massive payload of JavaScript in the background. Because the browser's main thread is locked up processing the JavaScript, it cannot register or respond to your click events. The solution is to reduce the amount of JavaScript sent to the browser through code-splitting, removing unused code, and breaking up long-running JavaScript tasks into smaller chunks so the main thread has moments to breathe and respond to user input.

Is upgrading my web hosting the easiest way to improve page speed? Upgrading web hosting—such as moving from a cheap $5/month shared server to a dedicated Virtual Private Server (VPS)—will primarily improve your Time to First Byte (TTFB). If your current server takes 1.5 seconds just to process a database query and respond to the initial request, upgrading your hosting will provide a massive, immediate speed boost. However, server response time usually accounts for only 10% to 20% of the total page load time. If your slow speed is caused by 5 megabytes of unoptimized images and render-blocking CSS, upgrading your server hardware will not fix the problem. Hosting upgrades must be paired with frontend asset optimization.