I'll tell you what your site really feels like to load

Flash was discontinued in December 2020 and is blocked by all modern browsers. Flash content is invisible to users and search engines, creating dead spots on the page. Google cannot index Flash content and considers its presence a significant mobile usability failure.

Google uses mobile-first indexing, meaning the mobile version of your page is what gets indexed and ranked. Without a viewport meta tag, Google considers the page non-mobile-friendly, which can significantly hurt rankings in mobile search results. Mobile traffic now exceeds 60% of all web traffic in most industries.

CLS is one of the three Core Web Vitals and a Google ranking signal. Content that jumps as images, ads, or fonts load causes mis-taps (e.g. hitting the wrong button) and a jarring experience. Google demotes pages that shift unexpectedly.

INP replaced First Input Delay as a Core Web Vital in 2024 and is a Google ranking signal. A high INP means the interface feels laggy and unresponsive, which frustrates users and reduces conversions — it reflects the experience of your actual visitors, not a synthetic test.

LCP is one of the three Core Web Vitals and a confirmed Google ranking signal. It marks the moment a visitor perceives the page as loaded. A slow LCP makes the page feel broken and sharply increases bounce rate, especially on mobile connections where most traffic now originates.

The two headers contradict each other, and the contradiction is silent: the page looks cached, the CDN is configured, and every request still pays full origin latency. It is a common cause of site-wide slow first-byte readings that no amount of server optimisation will fix, because the server was never the problem.

The performance score is the single headline number Google's own tooling reports for a page. A low score signals a slow experience that hurts Core Web Vitals rankings and conversion rates — faster pages consistently convert better and rank higher.

Page speed is a confirmed Google ranking factor, and TTFB is the foundational component. A slow server delays everything downstream: rendering, interactivity, and Largest Contentful Paint (a Core Web Vital). Google's crawler has a limited time budget per site — slow pages consume more of it, reducing the number of pages that can be crawled per session.

A fixed-width viewport forces all devices to render the page at a specific width, ignoring the actual screen size. Mobile devices will either show a tiny, unreadable version or require horizontal scrolling. Google's mobile-first indexing penalizes pages that are not mobile-friendly, and a fixed-width viewport is a definitive failure.

Horizontal scrolling on mobile is one of the most common mobile usability failures flagged by Google's Mobile-Friendly Test and Google Search Console. Pages with this issue are considered non-mobile-friendly, which directly impacts rankings in mobile search results under Google's page experience system.

Horizontal scrolling is a top mobile usability failure that Google actively penalizes in mobile search rankings. Pages requiring horizontal scrolling are classified as not mobile-friendly, significantly reducing their visibility in mobile search results, which represents the majority of all searches.

TTFB directly impacts all subsequent loading metrics. A slow TTFB means the browser cannot begin parsing HTML, discovering resources, or rendering content until the server responds. Google uses server response time as a ranking signal, and users perceive sites with high TTFB as sluggish.

Each HTTP request incurs overhead from DNS lookup, TCP connection, TLS handshake, and server processing. While HTTP/2 multiplexing helps, excessive requests still compete for bandwidth and processing time. Browser connection limits can cause request queuing, delaying critical resources.

LCP is one of the three Core Web Vitals and a Google ranking signal. In this band the page passes for some visitors and fails for others, so the assessment can tip either way with a slow network or a busy origin.

TBT correlates strongly with a poor real-user INP, so it is an early warning that heavy JavaScript is freezing the page while it loads. During that window, taps and clicks are silently ignored, which users experience as the page being stuck.

The Largest Contentful Paint (LCP) element is often a hero image. Without fetchpriority='high', the browser may deprioritize the LCP image in favor of other resources discovered earlier in the HTML. Setting fetch priority ensures the most visually important image loads first.

Proper caching prevents browsers from re-downloading unchanged resources, dramatically improving repeat visit performance. Without Cache-Control headers, browsers use heuristic caching which is unpredictable. Google PageSpeed Insights specifically checks for efficient cache policies on static resources.

A large DOM tree directly impacts Interaction to Next Paint (INP), a Core Web Vital. Every time the browser needs to recalculate styles, perform layout, or repaint, it must process all DOM nodes. Pages with over 1,500 elements see noticeably slower interactions, and Lighthouse flags DOMs over 1,500 nodes as problematic.

Third-party resources are outside your control and often add significant payload, blocking time, and unpredictable latency. Studies show that third-party scripts account for 57% of JavaScript execution time on average. They can also introduce security vulnerabilities, privacy concerns, and single points of failure.

Images typically account for 50-75% of a page's total weight. Oversized images directly impact Largest Contentful Paint (LCP), a Core Web Vital and ranking factor. On mobile connections, a single 2 MB image can add several seconds to load time. Google Image Search also favours properly optimized images.

Missing image dimensions are the leading cause of Cumulative Layout Shift (CLS), a Core Web Vital and ranking factor. When an image loads without pre-defined dimensions, the page content jumps to accommodate it, creating a frustrating user experience. Poor CLS scores directly affect search rankings.

The performance score is the headline number Google's own tooling reports for a page. A middling score usually means one or two heavy assets or scripts rather than a broken page — cheap to fix, and each point moves both the Core Web Vitals assessment and conversion.

Separate mobile URLs (m. subdomains) split link equity between desktop and mobile versions, require duplicate content management, and can cause redirect errors. Google strongly recommends responsive design over separate mobile URLs. Mobile redirects also add latency for mobile users.

Page weight directly affects load time, which impacts Core Web Vitals (particularly Largest Contentful Paint), user engagement, and bounce rates. Google has indicated a strong preference for fast-loading pages, and mobile-first indexing makes size particularly important since mobile connections are typically slower. Studies show that 53% of mobile users abandon pages that take more than 3 seconds to load.

Render-blocking resources directly impact First Contentful Paint (FCP) and Largest Contentful Paint (LCP), both Core Web Vitals metrics. Users see a blank screen until all blocking resources load, increasing perceived load time and bounce rates. Google explicitly measures render-blocking impact in its page experience assessment.

Synchronous scripts halt HTML parsing while the browser downloads and executes them. This delays the discovery and loading of subsequent resources, increases Time to Interactive, and can significantly slow First Contentful Paint. Scripts that block parsing are one of the most impactful performance bottlenecks.

Uncompressed text resources unnecessarily increase page load time and bandwidth consumption. Compression is one of the easiest and most impactful performance optimizations available. Google PageSpeed Insights flags missing compression as a high-priority issue, and it directly affects Core Web Vitals scores.

Multiple CSS files multiply HTTP requests and increase the total blocking time before the page can render. Each stylesheet must be downloaded and parsed before the browser can display content, directly impacting First Contentful Paint and Largest Contentful Paint Core Web Vitals.

Each external script requires a DNS lookup, TCP connection, and HTTP request. With HTTP/1.1, browsers limit parallel connections, causing scripts to queue. Even with HTTP/2, excessive scripts increase total download size and parsing time. JavaScript is the most expensive resource type in terms of processing time per byte.

Small text forces mobile users to pinch-to-zoom to read content, creating a poor experience. Google's mobile-friendly assessment specifically checks for legible font sizes, and pages with too-small text may be classified as not mobile-friendly, hurting mobile search rankings.

Stylesheets in the body block rendering of subsequent content and can cause visible layout shifts as styles are applied incrementally. Browsers must re-calculate styles and re-layout the page when late-loaded CSS arrives, degrading both performance and user experience.

Fixed-width tables do not adapt to narrow mobile screens, forcing horizontal scrolling or content overflow. This is a frequent cause of mobile-unfriendly assessments by Google. Tables with data are especially problematic because they cannot simply be reflowed like text content.

Small or crowded tap targets cause accidental taps, frustrating mobile users and increasing bounce rates. Google's mobile usability report in Search Console flags this issue, and it is part of the overall page experience assessment that affects mobile rankings. The minimum recommended tap target size is 48x48 CSS pixels with at least 8 pixels of spacing.

Disabling pinch-to-zoom prevents users with low vision from enlarging text and content to a readable size. This is a WCAG 2.1 Level AA violation (Success Criterion 1.4.4) and is flagged by Lighthouse as an accessibility issue. Google considers accessibility as part of overall page quality assessment.

font-display: block hides text for up to 3 seconds while the web font downloads. On slow connections, users see a blank page with no readable content, directly harming usability and Core Web Vitals (LCP). Using font-display: swap shows a fallback font immediately.

Deeply nested DOM trees increase the complexity of CSS selector matching and layout calculations. Each additional nesting level multiplies the work the browser must do during rendering. This directly impacts page responsiveness and Core Web Vitals scores, particularly Interaction to Next Paint.

Without srcset, a 1200px wide image is downloaded on a 375px wide mobile screen, wasting bandwidth and slowing load times. Responsive images with srcset allow the browser to choose the most appropriate size, reducing data usage by 40-70% on mobile devices while maintaining visual quality.

WebP images are 25-35% smaller than equivalent JPEG images, and AVIF offers even greater savings. Since images typically account for the majority of page weight, converting to modern formats can dramatically reduce load times. Google PageSpeed Insights specifically flags images that could benefit from modern formats.

The apple-touch-icon provides a branded icon when users bookmark your site on iOS devices. Without it, iOS generates a low-quality screenshot thumbnail that looks unprofessional. A proper touch icon improves brand recognition and increases the likelihood of repeat visits from home screen bookmarks.

Loading all images immediately increases initial page weight and competes with critical resources for bandwidth. Lazy loading defers off-screen images until the user scrolls near them, reducing initial load time and data usage. This improves LCP by freeing bandwidth for above-the-fold content.

Unminified CSS files are larger than necessary, increasing download time and delaying rendering. Since CSS is render-blocking by default, every kilobyte of unnecessary whitespace and comments directly delays when users see content. This is especially impactful on mobile connections.

Without ETags, browsers cannot efficiently validate whether cached resources have changed. They must either re-download the full resource or rely solely on Cache-Control expiration. ETags enable 304 Not Modified responses that confirm cache validity with minimal bandwidth, improving performance for returning visitors.

Inline CSS cannot be cached separately by the browser, so it is re-downloaded with every page load. Large amounts of inline CSS increase the HTML document size, slowing the initial response and Time to First Byte. It also makes the HTML harder to parse and increases rendering time.

Inline JavaScript cannot be cached by the browser and must be parsed and executed every time the page loads. Large inline scripts block HTML parsing, delay rendering, and increase Time to Interactive. They also cannot be deferred or loaded asynchronously like external scripts.

JavaScript is the most expensive resource type per byte because it must be downloaded, parsed, compiled, and executed. Unminified JavaScript wastes bandwidth and increases parsing time. This directly impacts Time to Interactive and Interaction to Next Paint Core Web Vitals.

Without preloading, the browser discovers critical resources late in the parsing process, delaying their download. Fonts discovered through CSS @font-face rules, hero images referenced in CSS, and key scripts imported by other scripts all benefit from preloading. This directly impacts LCP and visual stability.

Each new origin connection requires DNS resolution, TCP handshake, and TLS negotiation, adding 100-300ms of latency. Preconnect hints allow the browser to perform these steps in advance, reducing the time to fetch critical third-party resources like fonts, CDN assets, and analytics scripts.

Without initial-scale=1, some mobile browsers may not correctly establish the initial zoom level, potentially causing layout issues. Setting it explicitly ensures the page renders at 1:1 scale on all devices, which is the foundation of responsive design.

The default browser behavior for web fonts is to hide text until the font loads, which can result in invisible text for several seconds on slow connections. This directly impacts Largest Contentful Paint if the LCP element uses a web font. Lighthouse flags missing font-display as a performance issue.

A real visitor arriving at a scaled-to-zero instance pays this cost once, and search engine crawlers hit cold instances disproportionately because they arrive at quiet times. It is worth knowing about — but it is not the problem 'optimise your server' describes, and acting on that advice would cost money without changing anything.

Browser-native app install banners are more effective and less intrusive than custom app download interstitials. Google penalizes pages that show intrusive interstitials (including app install pop-ups), so using the native banner API is the recommended approach for promoting your app.