Page speed is a measure of how quickly a web page loads and becomes usable for visitors, encompassing the time from a user initiating a navigation to the point at which the page content is fully loaded, visually rendered, and interactive. Page speed is not a single number but a collection of measurements, different metrics capture different aspects of the loading experience, from how quickly the first content appears to how long until the page responds to user input.

Page speed matters because users are impatient, research consistently shows that page load time directly affects user behaviour. Even small increases in load time, fractions of a second, correlate with higher bounce rates, lower conversion rates, reduced pages per session, and worse user satisfaction scores. Google’s own research has shown that as page load time increases from one second to three seconds the probability of a visitor bouncing increases by 32%. As load time increases from one second to five seconds the probability of bounce increases by 90%.

Page speed is also a direct SEO ranking factor, Google incorporated page speed into its ranking algorithms in 2010 for desktop and in 2018 for mobile. More significantly Google’s Core Web Vitals: a set of specific page experience metrics, became confirmed ranking signals in 2021. Core Web Vitals measure specific aspects of loading performance, interactivity, and visual stability, pages that perform well on these metrics receive a ranking advantage over equivalent pages that perform poorly.

For redirect management page speed is relevant because redirects add latency to the loading process, each redirect hop introduces a full request-response cycle before the destination page begins loading. Understanding page speed and its components helps quantify the performance cost of redirects and motivates minimising redirect chains and serving redirects from edge infrastructure close to users.

Core Web Vitals, the primary page speed metrics

Google’s Core Web Vitals are the most important page speed metrics for SEO, they are direct ranking signals and the standard framework for measuring and communicating page loading experience.

Largest Contentful Paint, LCP: measures the time from when a page begins loading to when the largest content element, typically the hero image, the main heading, or the primary content block, is rendered and visible in the viewport. LCP captures the perceived loading speed of the main content, when users feel the page has loaded rather than when the browser has finished processing all resources.

Google’s LCP thresholds: Good, under 2.5 seconds. Needs Improvement, 2.5 to 4.0 seconds. Poor, over 4.0 seconds.

LCP is heavily influenced by server response time, the time before the browser receives the first byte of HTML. A slow origin server or a redirect chain that adds several hundred milliseconds before the destination page begins loading directly degrades LCP. CDN deployment and edge-based redirect execution reduce server response time, improving LCP by delivering content faster.

Interaction to Next Paint, INP: measures the responsiveness of a page to user interactions, tapping, clicking, keyboard input, throughout the entire page visit. INP replaced First Input Delay, FID, as a Core Web Vital in March 2024. INP captures the worst interaction delay across all interactions during a visit, identifying pages where heavy JavaScript execution or main thread blocking creates sluggish responses to user input.

Google’s INP thresholds: Good, under 200 milliseconds. Needs Improvement, 200 to 500 milliseconds. Poor, over 500 milliseconds.

INP is primarily affected by JavaScript execution, heavy JavaScript frameworks, third-party scripts, and long tasks that block the main thread degrade INP. Redirects have minimal direct effect on INP, it is a post-load interactivity metric rather than a loading speed metric.

Cumulative Layout Shift, CLS: measures the visual stability of a page during loading, how much the page content moves around as resources load. A page where images load and push text down, where ads appear and shift the layout, or where fonts load and change text positions has high CLS, a visually unstable, disorienting loading experience.

Google’s CLS thresholds: Good, under 0.1. Needs Improvement, 0.1 to 0.25. Poor, over 0.25.

CLS is primarily caused by images without declared dimensions, the browser does not know how much space to reserve for the image before it loads, and by late-loading content that inserts above existing content. Redirects do not directly affect CLS, it is a rendering stability metric that depends on page structure and resource loading order.

Additional page speed metrics

Beyond Core Web Vitals several other metrics provide useful page speed insights.

Time to First Byte, TTFB: the time from the browser sending a request to receiving the first byte of the server’s response. TTFB is the most direct measure of server-side performance, it captures network latency, DNS resolution time, TCP connection establishment, TLS handshake time, and server processing time. High TTFB delays everything downstream, LCP cannot be good if TTFB is poor because the browser cannot begin rendering before it receives the HTML.

TTFB is directly affected by redirects, each redirect adds a full TTFB for the redirect response before the destination page’s TTFB begins. A single redirect on a server with 200ms TTFB adds at least 200ms of additional delay before the destination page begins loading. Edge-executed redirects reduce this to tens of milliseconds.

First Contentful Paint, FCP: the time from page load initiation to when the first content element, any text, image, or canvas, is rendered in the viewport. FCP is a user perception metric, it marks when the user first sees that the page is loading. A page with poor FCP feels unresponsive, the browser appears to be doing nothing for an extended period before anything appears.

Total Blocking Time, TBT: the total time during which the main thread is blocked by long tasks, preventing user interaction, between FCP and Time to Interactive. TBT is a lab metric that correlates strongly with INP in field data. High TBT indicates heavy JavaScript execution that blocks the main thread.

Speed Index: a composite metric measuring how quickly content is visually populated in the viewport during loading, calculated from the visual progression of the page as it loads. Speed Index captures the perceived loading speed better than single-point metrics by accounting for the entire visual loading timeline.

Factors affecting page speed

Page speed is affected by dozens of factors spanning server infrastructure, network conditions, page design, and resource loading strategies.

Server response time: the origin server’s ability to generate and begin transmitting responses quickly. Slow database queries, inefficient application code, resource-intensive server-side operations, and overloaded servers all increase server response time, directly degrading TTFB and all downstream metrics. Application-level caching, Redis, Memcached, reduces database query frequency. CDN caching eliminates origin requests for cached content.

CDN and edge network deployment: serving content from edge locations near users reduces the network distance data must travel, decreasing propagation delay and TTFB. A page served from a CDN edge node 20ms away has dramatically lower TTFB than the same page served from an origin 200ms away. CDN deployment is one of the highest-impact page speed improvements for globally distributed audiences.

Image optimisation: images are typically the largest contributors to page weight and loading time. Serving appropriately sized images, not larger than the display requires, using modern formats, WebP, AVIF, that compress better than JPEG and PNG, and implementing lazy loading, deferring offscreen images, significantly reduces bandwidth consumption and improves LCP.

JavaScript execution: JavaScript is the primary source of main thread blocking that degrades INP and TBT. Large JavaScript bundles, inefficient JavaScript execution, and third-party scripts that execute synchronously block the main thread and delay user interaction responsiveness. Code splitting, delivering only the JavaScript needed for the current page, and deferred loading, executing non-critical JavaScript after the page is interactive, reduce JavaScript’s performance impact.

HTTP/2 and HTTP/3: multiplexed connections allow multiple resources to load simultaneously over a single connection, eliminating the connection overhead of HTTP/1.1’s sequential request handling. HTTP/3’s QUIC transport further reduces connection establishment overhead and eliminates head-of-line blocking, particularly beneficial on mobile connections with variable quality.

HTTP caching: browser and CDN caching of static resources eliminates network requests for cached assets on repeat visits. A returning visitor whose browser has cached CSS, JavaScript, fonts, and images loads only the HTML and any changed resources, dramatically faster than a first visit that loads everything from the network.

Resource loading priorities: the order in which the browser loads resources affects perceived performance. Critical resources, CSS needed for above-the-fold rendering, fonts used in the main content, should load as early as possible. Non-critical resources, below-the-fold images, analytics scripts, social media widgets, should be deferred or lazy-loaded to avoid competing with critical resources for bandwidth and processing time.

Page speed and redirects

Redirects add latency to page loading, the precise impact depends on the number of redirect hops, the geographic distance to the redirect infrastructure, and the connection characteristics.

The redirect latency tax: each redirect adds a complete request-response cycle before the destination page begins loading. This cycle includes:

DNS resolution, or reuse of cached DNS. TCP connection establishment, or reuse of existing connection. TLS handshake, or session resumption. Request transmission. Server processing, redirect rule evaluation. Response transmission, the small redirect response.

For a cross-origin redirect with a new connection this cycle adds 200-500ms on typical broadband connections and 500ms-1.5 seconds on mobile connections with high latency. Connection reuse for same-origin redirects reduces this to 10-50ms, primarily server processing time. Edge-executed redirects reduce the server processing component by executing from infrastructure near the user.

Redirect chains: each additional redirect in a chain multiplies the latency cost. A three-hop chain adds three times the single-hop latency, potentially 600ms-1.5 seconds for cross-origin chains on broadband. Minimising redirect chains, collapsing multi-hop chains to direct single-hop redirects, is the primary redirect-specific page speed optimisation.

LCP degradation from redirects: LCP is measured from navigation start. Redirect latency directly extends the time before the destination page begins loading, every millisecond of redirect latency is a millisecond added to LCP. A page that would achieve 1.8 second LCP without redirects achieves 2.2 second LCP with a single 400ms cross-origin redirect, the difference between a good and needs-improvement score.

Edge-served redirects: redirect management platforms built on edge network infrastructure reduce redirect latency by executing redirect rules at edge nodes near users. A user in Tokyo receiving a redirect from a Tokyo edge node experiences 15-25ms redirect latency rather than 300-400ms from a US-based origin. Edge redirect execution minimises the LCP impact of necessary redirects.

Measuring page speed

Several tools measure page speed, each with different perspectives and appropriate use cases.

Google PageSpeed Insights: Google’s primary page speed analysis tool. Analyses both field data, real user performance data from Google’s Chrome User Experience Report, and lab data, simulated measurements from Lighthouse. Provides Core Web Vitals assessments and specific optimisation recommendations. Field data is particularly valuable, it reflects real user experiences rather than simulated conditions.

Lighthouse: Google’s open-source automated page quality tool, integrated into Chrome DevTools and PageSpeed Insights. Provides detailed performance analysis including individual metric scores, performance opportunities, specific improvements with estimated impact, and diagnostics. Lighthouse runs in controlled lab conditions, results represent a consistent benchmark rather than real user performance.

WebPageTest: advanced performance testing tool providing detailed waterfall charts showing the loading sequence of every resource. WebPageTest enables testing from multiple geographic locations, multiple connection types, and multiple browsers, providing detailed analysis of where loading time is spent and what optimisations would have the greatest impact.

Chrome DevTools Network panel: browser-level performance analysis showing individual resource loading times, request headers, response headers, and timing breakdowns, useful for debugging specific performance issues including redirect chains visible in the network waterfall.