标签：#webperf

The average person does not wake up choosing between "website" and "no website." They choose between opening an app, asking ChatGPT, tapping a map result, or typing a URL. Websites are still relevant when those paths need a place to land: confirm a business is real, compare two options side by side, pay for something, book a slot, or read instructions that outlive a chat thread. They become irrelevant when the destination is slow, broken, or empty, because the next tap is always available. That shift is what agencies miss when the brief says "we need a website" as if presence alone still wins. In 2026 a site is less often where people first find you and more often where they check you are real, pay, or book after they found you somewhere else. Your job is not only to exist on the open web. It is to be the destination that still earns the click when someone is ready to act. What does "still relevant" mean after apps and AI answers? Relevance is not traffic volume. Pew Research analysis of tens of thousands of Google searches in 2025 found users clicked a traditional result on only about 8% of queries that showed an AI Overview, versus about 15% without one. Casual browsing traffic is thinner. The visits that remain often carry sharper intent: someone already heard a name and wants proof, or they are ready to buy and need a form that works on mobile. Google's Search team has argued the same restraint in public: websites are not obsolete, but they are not mandatory for every goal ( Search Off the Record ). Whether you need one depends on audience, control, and what you are trying to deliver. For many businesses the answer is still yes, because apps and social profiles do not replace a site you control when AI systems and search features need structured facts to cite. The relevance question therefore splits in two. Is the open web still where machines and sceptical humans go to verify claims? Yes, for most categories. Is every marketing site still the main place people

I run a search engine that publishes in twelve languages from one static site on Cloudflare Pages. Last week I audited its machine-readable layer — the part crawlers and answer engines read rather than humans — and found four problems. None of them threw an error. None appeared in logs. Every page rendered perfectly. That is the whole point of this post: the multilingual layer fails in a register where nothing tells you. 1. The homepage was serving the wrong language to everyone abroad The site's primary market speaks Hebrew, so / is Hebrew and /en/ , /ar/ , /de/ and nine others sit alongside it. A middleware rule redirected visitors from one specific region to their language. Everyone else — including every English speaker on earth — landed on Hebrew. My first instinct was to fix it with a broader geo-redirect: detect English-speaking countries, send them to /en/ . This would have been a bad idea, and it is worth saying why. Googlebot crawls predominantly from US IPs. A geo-redirect on / that keys off country would take the crawler off the Hebrew homepage and onto the English one almost every time it visited. You do not want your primary-market homepage to become the page the crawler can never reach. The correct tool is hreflang , and it is what search engines built for exactly this. Checking the page, the tags were already there and already right: <link rel= "alternate" hreflang= "he" href= "https://example.com/" > <link rel= "alternate" hreflang= "en" href= "https://example.com/en/" > <link rel= "alternate" hreflang= "ar" href= "https://example.com/ar/" > <!-- …ten more… --> <link rel= "alternate" hreflang= "x-default" href= "https://example.com/en/" > Two things make this work, and both are easy to get wrong: The set must be reciprocal. Every page in the group lists every other page including itself . If /en/ does not point back at / , search engines are entitled to ignore the whole cluster. x-default is not "the default language" — it is the fallback for users

Lighthouse kept warning me about inefficient cache lifetimes, even though I had already added caching for my static files. The missing piece was Nuxt Image and its generated /_ipx URLs . In this post, I’ll share the simple caching setup I use for Nuxt build files, public assets, and optimized images without risking stale content after deployment. The basic rule is simple: Cache files aggressively when changing the file also changes its URL. Be more careful when the same URL can serve different content later. You have probably seen the same Lighthouse warning I have: Use efficient cache lifetimes. Browser caching for static files is usually straightforward. You add a Cache-Control header, choose a reasonable lifetime, and the browser avoids downloading the same files again on every visit. However, in a Nuxt application, not every static-looking file should use the same caching policy. Nuxt build files are automatically versioned. Files inside public/ usually are not. Nuxt Image also creates transformed image URLs under /_ipx , which need their own cache rule. In this post, I’ll go through the setup I use, including the Nuxt Image rule that was missing during my latest Lighthouse audit. The simple caching rule The most important question is not whether a file is an image, font, or JavaScript file. The important question is: Will the URL change when the file changes? When the answer is yes, you can safely cache the file for a very long time. When the answer is no, you should use a shorter cache lifetime. Otherwise, visitors may continue seeing an old version after you deploy an update. What the cache directives mean Here are the main directives used in this setup: public allows browsers and shared caches such as CDNs to store the response. max-age controls how long the browser considers the file fresh. s-maxage controls how long shared caches such as Cloudflare consider it fresh. immutable tells the browser that the file is not expected to change while that URL exists.

The Slack thread started with a screenshot of a green GitHub Actions run. By the third reply someone had pasted a Lighthouse JSON artefact, a link to a Chrome release note, and a question nobody wanted to own: "Which client repository still pins Lighthouse 10?" That is the week Lighthouse CI stopped being a merge gate and became a second job. The pipeline still passed and the portfolio still needed evidence, but the difference was who paid in hours: the developer shipping a feature, or the one person who inherited every lighthouserc file across client repositories. When does Lighthouse CI maintenance outgrow a CI/CD pipeline? Lighthouse CI earns its place early. You wire assertions on a preview URL, block a CLS regression, and the team trusts the red build. The cost is front-loaded configuration, not ongoing calendar time. The shift happens when success creates obligations a CI/CD pipeline was never designed to carry: Every new client repository needs a copied workflow, pinned Chrome, and preview URL rules that match their host. Assertions need tuning after flaky LCP on cold runners, so thresholds loosen until they barely catch real regressions. Account managers ask for client-ready reports, and the only export is a CI/CD artefact someone must turn into slides. Production URLs outside the two preview paths regress while the job stays green. At that point you are not "running Lighthouse CI in a pipeline." You are operating a small internal product: version pins, runner hygiene, assertion policy, and reporting glue. For a single product team that can be fine. For an agency portfolio it competes with billable delivery. How do you know Lighthouse CI in CI/CD became an unpaid side role? We treat these as signals to shrink CI/CD scope or add a managed monitoring layer, not as moral failure. Teams hit them around five to fifteen client sites, sometimes sooner when preview hosts differ wildly. Flaky Lighthouse CI runs on GitHub Actions Engineers merge after the third "Re-ru

I spent an evening opening other companies' product configurators — 3D and parametric tools on manufacturers' sites — looking for things that were genuinely broken. Twenty-seven of them. The findings were real. But the part worth writing down is that four separate times in one evening, my tooling told me an application was broken when it was fine. Every one of those four passed automated checks that looked rigorous. What caught them was a screenshot. If you write scripts that judge pages you don't own — uptime checks, competitor teardowns, scraping health, QA of an embedded widget — you will hit these. Here is the full list of signals that lied to me, and the one control that never has. The four false positives All four produced the same symptom: no <canvas> on the page, and an almost empty innerText . That looks damning when the page is literally titled "Configurator". It is also what three completely healthy situations look like: The tool starts on a click. An orange button launches it. My script measured an unopened door and reported an empty room. Four automated passes — raw HTTP with a browser UA, my own browser, two runs from a clean profile, a control on the same domain — all four confidently examined a page that hadn't started yet. The entire UI lives inside the canvas. One hall configurator draws its menus, its undo/redo and its PDF export in WebGL. Empty DOM text is correct there, not a defect. The tool is behind a login. I was measuring a sign-in page. Fifty-four characters of text and one button reading "Anmelden". The page is a landing page about the configurator, not the configurator. No network-level or DOM-level check distinguishes these from an actual failure. A screenshot distinguishes all four instantly. So the first rule I now follow, before any measurement at all: Take the screenshot first. Look at the picture. What you cannot see in the image, you do not measure. It costs one second and it is the highest-yield step in the whole process. The cor

I compressed 100 photos through 3 formats. Here's the actual data. A 2MB JPEG photo. Convert it to WebP — now it's 480KB. Convert it to AVIF — now it's 310KB. Same visual quality. Three different file sizes. I've spent the last 2 weeks building an image compression tool, so I've seen thousands of these comparisons. Here's what the numbers actually say, and what it means for your website. The Setup I took 50 real-world photos and 50 screenshots/design assets — not synthetic test images, but actual files people would upload: Photos : vacation shots (JPEG, 2-8MB), product photos, portrait selfies Graphics : PNG screenshots (1-4MB), logos, UI mockups, illustrations Source sizes : 500KB to 12MB, average ~3.2MB Each image was compressed through JPEG (quality 85%), WebP (quality 80%), and AVIF (quality 65%) — settings that produce visually identical results on a 2x retina display. The Numbers Format Avg Compressed Size Reduction vs Original Reduction vs JPEG Browser Support Original 3.2 MB — — 100% JPEG (q85) 820 KB 74.4% — 100% WebP (q80) 480 KB 85.0% 41.5% smaller than JPEG 96.8% AVIF (q65) 310 KB 90.3% 62.2% smaller than JPEG 93.1% The headline : WebP halves your JPEG size. AVIF halves WebP again. Photo Results (JPEG source, 50 images) For photographs — the most common use case — here's what happened: Format Avg Size Best Case Worst Case JPEG q85 820 KB 180 KB 3.1 MB WebP q80 480 KB 95 KB 1.8 MB AVIF q65 310 KB 60 KB 1.2 MB What this means : On an average product page with 6 photos: JPEG: 6 × 820KB = 4.9 MB WebP: 6 × 480KB = 2.9 MB (saves 2 MB) AVIF: 6 × 310KB = 1.9 MB (saves 3 MB) On a 4G connection (10 Mbps), that's the difference between 4 seconds and 1.5 seconds to load all images. On a product page, that's the difference between a bounce and a sale. Screenshot/Graphics Results (PNG source, 50 images) PNGs are a different story. Lossy WebP and AVIF can crush PNGs — but only if you're OK losing pixel-perfect accuracy. Format Avg Size Notes Original PNG 1.4 MB Lossles

If you build anything on top of hosted AI APIs, latency isn't a detail you get to ignore — it's a feature. A sluggish time-to-first-token is the difference between an assistant that feels alive and one that feels broken. Yet when I went looking for an honest answer to a simple question — how fast is provider X from where my users actually are? — I couldn't find one. The numbers people quote tend to come from a single machine in a single region (usually somewhere in the US), from vendor-reported status pages, or from a benchmark that got run once and never refreshed. There was no independent, measured , regional view. So I built one: LLM Latency Tracker , a provider-neutral tracker of latency and uptime for AI inference APIs. How it works The core idea is boring on purpose: actually measure, don't scrape. A small Python prober — standard library only, no API key needed for the edge probes — opens real connections to each provider's endpoint and times every phase of the handshake: DNS resolution → TCP connect → TLS negotiation → time-to-first-byte (TTFB) . That's the edge view: how long the network path itself takes before a single byte comes back. Separately, where possible, it measures inference time-to-first-token (TTFT) — the thing your users actually feel, i.e. how long after you hit "send" the model starts streaming. Those two numbers answer different questions, and keeping them apart matters. Edge latency is about the network and the front door; TTFT is about the model and the queue behind it. The probes run from four regions — Europe (Germany), US Central, Asia (Tokyo), and South America (São Paulo) — because "fast" is meaningless without "from where." Results land in a SQLite time-series; a static-site generator turns that into the pages you see, hosted on Cloudflare Pages, and the whole thing is self-updating on a schedule. There's no always-on backend to rot or page me at 3am. It currently covers ~45 providers — the usual Western labs (OpenAI, Anthropic, Go

After spending 2 years building an image compression tool, here's my no-nonsense format guide. ## The Rule | If it's... | Use... | |---|---| | Logo, icon, screenshot | PNG | | Photo, everyday image | WebP | | Smallest possible file | AVIF | | Maximum compatibility | JPEG | ## Why? PNG — Lossless. Keeps text and sharp edges crisp. Supports transparency. But files are large for photos. JPEG — Works literally everywhere since 1992. Good compression for photos. No transparency support. At 80-85% quality, the visual difference from 100% is invisible but the file is half the size. WebP — The sweet spot. 25-35% smaller than JPEG with same quality. Supports both lossy and lossless. Supports transparency. Every modern browser supports it now (97%+ global coverage). For most websites, this is the right answer. AVIF — The next-gen format. 50% smaller than JPEG, 30% smaller than WebP. Supports HDR, 12-bit color, and both lossy/lossless. The catch: not supported on older devices (iOS 15 and below). Use it with a <picture> fallback. ## Real Numbers I ran the same photo through all four formats at comparable quality: JPEG (90%): 842 KB PNG: 3,241 KB WebP (90%): 547 KB AVIF (90%): 382 KB WebP cut the JPEG size by 35%. AVIF cut it by 55%. ## What I Recommend I built CompressFast ( https://compressfast.site ) — a free browser-based image compressor that handles all these formats. No uploads, no servers, everything runs locally.

A PageSpeed Insights run flags a high Time to First Byte. The ticket lands on the theme backlog. Hosting gets upgraded. A CDN is added. The next lab run still shows a slow first byte on the same priority URL. In our experience the miss is often earlier in the path: DNS, TLS, HTTP version, connection reuse, edge routing, or cache policy. Theme and plugin work still matter, but they sit after the network and delivery stack has done its job. If first byte is already late, paint and interactivity inherit that delay. What follows walks that request in order for teams who need to reduce TTFB before another theme rewrite. We stay on the network and delivery layers. For WordPress cases where code on the stack beats a bigger hosting plan, see Why Your WordPress Site Is Slow (It Is Not Always Hosting) . For LCP levers once first byte is under control, see A Quick Way to Fix LCP: Four Changes That Cut Time to Paint . What TTFB includes when you measure first byte in lab tools Time to First Byte (TTFB) measures how long the browser waits from the start of the navigation request until the first byte of the response arrives. In PageSpeed Insights and Lighthouse, it appears as a diagnostic timing. In WebPageTest and similar waterfall tools, you can split the same wait into DNS, TCP connect, TLS, and waiting (server or edge processing). That split is what makes network work actionable for delivery teams. TTFB is not a Core Web Vital , but it feeds Largest Contentful Paint and overall load feel. A page that spends 800 ms waiting for first byte has already used a large share of a mobile LCP budget before the hero image or heading can paint. Field data from Chrome UX Report may show Time to First Byte as a supporting metric. Lab tools remain the fastest way to prove a DNS or CDN change after a release, because you control the URL, location, and cache state of the run. When you read TTFB in a report, ask which hop dominated. Resolver delay looks different from a cold TLS handshake. A c

I built Luxury Hotel Offers , a fully static site with 3,400+ listings that generates 4,400 HTML pages at build time. No SSR, no database at runtime. Here are the four hardest scaling problems I hit. 1. Googlebot's 2 MB HTML Limit With 3,400 hotels on one listing page, the naive approach (render all cards in HTML) produced a 9 MB page. Googlebot truncates at 2 MB and ignores the rest. The fix: cap the initial HTML at 400 cards. The remaining 2,500+ cards are generated as a separate HTML fragment file at a predictable URL ( /data/cards/{slug}-remaining/ ). A "Load More" button injects 48 cards at a time from the fragment. The first search or filter interaction loads the entire fragment so all cards are available for client-side filtering. This keeps every page under 2 MB for crawlers while giving users access to everything. 2. Content-Aware Lastmod with Cascading A site with 4,400 pages can't update every lastmod on every build. Search engines treat that as spam, and IndexNow has rate implications. Instead, the build hashes each hotel's SEO-relevant fields and compares against a persisted store. Only pages with actual content changes get their lastmod bumped. The interesting part is cascading: when a hotel in Paris changes, the Paris city page, France country page, and Europe region page all get their dates updated too, since their content changed (they list that hotel). Changed URLs feed into IndexNow so only genuinely modified pages get pushed to search engines. 3. DOM Filtering Breaks on Mobile at Scale The site started with pure DOM filtering: every card has data-* attributes for region, country, brand, and perks. JavaScript reads attributes and toggles visibility. Zero network requests, instant results. Great on desktop. On a mid-range phone with 2,500+ cards in the DOM, filtering took 2-3 seconds per interaction. textContent traversal across 20-40 nodes per card means ~60,000 DOM visits per keystroke. Layout thrashing with 10,000+ nodes made every show/hide cyc

Hello Dev Community! 👋 It is officially Day 127 of my software engineering marathon! Today, I leveled up my asynchronous data pipeline in React.js by tackling a critical production-grade performance problem: avoiding memory leaks and managing component unmounting states using the useEffect Cleanup function alongside the native browser AbortController API ! ⚛️🛡️⚡ Additionally, I integrated a fully responsive async loading engine to drastically improve our overall User Experience (UX). 🛠️ Deconstructing the Day 127 Network Boundary Control As shown inside my refactored workspace code layout across "Screenshot (283)_2.png" and "Screenshot (284)_2.png" , the side-effect layer is now safe from ghost background executions: 1. Ingesting the Abort Signal API Inside the lifecycle layer, before initiating the endpoint call, I instantiated an active execution cancellation anchor on Lines 12-13 inside PostContainer.jsx : javascript const controller = new AbortController(); const signal = controller.signal;

Performance optimization has always been one of the hardest parts of web development. You run...

Most on-page audits catch the obvious stuff: a missing title here, a duplicate meta description there. The thing that quietly costs you rich results is structured data that exists but is invalid, and most flat-list crawlers either skip it or bury it. Here is why it happens and how to catch it. The problem, concretely You add FAQ schema to a product page to win that expandable rich result in Google. You paste a JSON-LD block into the head, ship it, and move on. Six weeks later the rich result never showed up, and nobody knows why. The usual culprits are small and silent: A @type that does not match the content (FAQPage with no mainEntity ). A required property missing ( acceptedAnswer without text ). A trailing comma or a stray character that makes the JSON parse fail entirely. Schema that contradicts what is actually on the page, which Google can flag as spammy and ignore. None of these throw a visible error. The page renders fine. The schema is just dead weight, and a standard "issues" crawl that only counts titles and headings walks right past it. How to catch it First, validate the JSON itself. A block that does not parse is invisible to search engines. Even a quick local check surfaces the dumb-but-fatal errors: // Pull every JSON-LD block and check it parses + has a @type const blocks = [... document . querySelectorAll ( ' script[type="application/ld+json"] ' )]; blocks . forEach (( b , i ) => { try { const data = JSON . parse ( b . textContent ); if ( ! data [ " @type " ]) console . warn ( `Block ${ i } : missing @type` ); } catch ( e ) { console . error ( `Block ${ i } : invalid JSON ->` , e . message ); } }); If that logs an error, the schema was never going to work, no matter how perfect the markup looked. Second, check required properties for the specific type you are using. FAQPage needs mainEntity with Question items, each carrying an acceptedAnswer . Article needs headline , author , and datePublished . Validating "it parsed" is not the same as "it is c

TL;DR — If your backend already uses OpenTelemetry, you can send traces and logs to Sentry by changing a few environment variables. No SDK swap, no instrumentation rewrite. Point your OTLP exporter at Sentry’s endpoint, add the Sentry SDK on the frontend for browser context, and you get one connected trace from click to backend span. You already instrumented the backend with OpenTelemetry. Your services emit spans. Your teams know the OTel APIs. Maybe you already run a Collector. So when you start evaluating Sentry, the obvious question is: Do you need to replace your OpenTelemetry setup with the Sentry SDK? No. The practical answer is usually: keep OpenTelemetry where it already works, add the Sentry SDK where it gives you more application context, and send OpenTelemetry Protocol (OTLP) events to Sentry. For a web app, that often means using the Sentry SDK on the frontend for browser tracing, errors, logs , Session Replay , and source maps, while keeping OpenTelemetry on the backend for existing service instrumentation. One scope note: OTLP can carry traces, logs, and metrics. At this moment, Sentry’s OTLP ingest supports logs and traces, not metrics. We’re considering adding support for them in the future. The important part is separating two decisions that often get lumped together: How traces stay connected across frontend and backend. How backend OTLP events are exported to Sentry. Once you separate those, the architecture gets a lot easier to reason about. Sentry vs OpenTelemetry is the wrong question The first decision is trace linking. If a user clicks a button in your React app and that click triggers a backend request, the frontend and backend need to agree on the same distributed trace context. In this example, the Sentry frontend SDK sends W3C traceparent headers (configurable through the propagateTraceparent option), and the OpenTelemetry backend continues the trace. That linking is handled by the frontend SDK configuration: Sentry . init ({ integration

I run Convertify , a free image converter built on Rust and libvips. Last week I decided to stop guessing about format performance and actually measure it. I took 50 real images (26 PNGs, 24 iPhone HEIC photos), ran 17 conversions through the production pipeline, and recorded every file size and encode time. Some results confirmed what everyone says. Others did not. The three results that surprised me 1. Converting HEIC to JPG makes files 14% bigger , not smaller. This one hurt. "Convert iPhone photos to JPG" is probably the most common advice on the internet. But HEIC wraps the HEVC codec, which compresses roughly 2x better than JPEG. Going from a better codec to a worse one means the file grows. Every time. If you actually want smaller iPhone photos: HEIC to WebP saves 43%, HEIC to AVIF saves 57%. 2. AVIF encodes 7x slower than WebP for 10% more compression. AVIF Q63: 55 KB, 1.30s per image. WebP Q80: 61 KB, 0.19s per image. That is a 10% size difference for a 7x speed penalty. For a single hero image, nobody cares. For a batch pipeline processing thousands of product photos, that is the difference between 3 minutes and 21 minutes. 3. PNG at 600 DPI is smaller than PNG at 300 DPI when rasterizing PDFs. This was the weirdest one. I was benchmarking PDF-to-image and noticed PNG output shrank from 2,221 KB at 300 DPI to 1,660 KB at 600 DPI. I spent an hour convinced I had a bug. Turns out it is a real property of PNG encoding. Higher DPI renders smoother gradients between adjacent pixels, and PNG's prediction filters (Paeth, sub, up) compress smooth gradients dramatically better than the sharp edges you get at lower resolutions. Not a bug. Just PNG being PNG. The quick reference table Conversion Size change Speed JPG to WebP Q80 -64% 0.19s JPG to AVIF Q63 -68% 1.30s PNG to WebP Q80 -92% 0.21s PNG to JPG Q85 -86% 0.07s HEIC to JPG Q85 +14% 1.90s HEIC to WebP Q80 -43% 5.64s HEIC to AVIF Q63 -57% 14.52s WebP to JPG Q85 +60% 0.09s AVIF to JPG Q85 +80% 0.15s What I actual

In web development, every millisecond on the critical path matters. Typography is part of your visual identity, yet a single self-hosted family can add hundreds of kilobytes before the browser paints the hero line clients actually see. That cost often shows up as slower First Contentful Paint (FCP) and a worse Largest Contentful Paint (LCP) when the LCP element is a headline set in a custom face. Font subsetting is the practical fix: ship only the characters (glyphs) each page or component needs instead of entire typefaces built for every language and symbol you will never render. What font subsetting is A typical desktop font file contains thousands of glyphs: Latin extended, Cyrillic, ligatures, numerals, punctuation, and symbols you may never use on a marketing site. When you @font-face that file or pull it from a CDN, the browser still has to download and parse the whole package unless you split it. Subsetting creates a smaller font file that includes a defined subset of Unicode code points. Examples: A display font used only on one H1 might need fewer than 40 characters. A Latin-only blog body font does not need CJK tables on every article. UI labels in English can omit unused weights and scripts. The browser downloads less data, spends less time decoding, and can apply the face sooner. You keep the look; you drop the dead weight. When font subsetting improves web font performance and LCP Subsetting pays off fastest in these cases: Situation Why subsetting helps Display or hero typography Few unique characters, high visual impact, often on the LCP text node Single-language sites Remove unused scripts and diacritic ranges you do not publish Icon or logo fonts misused as full fonts Replace with SVG where possible; subset if you must keep a font icon set Multiple weights loaded globally Subset per weight, or load weights only on routes that need them It is lower priority when you already use a system font stack for body copy and only load one small variable font w

An account manager forwarded us a Search Console screenshot at 4:47 p.m. on a Friday. LCP on the homepage had been in the red for eleven days. Engineering had not been in the thread because nobody was assigned to watch the numbers until a sponsor noticed. That is reactive performance monitoring in practice: fast tools, slow humans, and a calendar that only opens when someone else raises the alarm. Proactive monitoring is the opposite shape. Scheduled lab tests run whether or not anyone remembered to open PageSpeed Insights. Performance budgets turn history into rules. Alerts fire when those rules break, with enough context to triage and enough restraint that people still read them. The word “smart” in product copy usually means the second part: alerts that match how teams actually work, not a louder siren. This post is for agency leads who already automate some tests but still learn about regressions from client inboxes. We walk through what reactive looks like, what proactive requires, and how to wire alerts so they change behaviour instead of training everyone to mute the integration. What reactive performance monitoring looks like on agency teams Reactive does not mean “no tools.” Most agencies we speak with have PageSpeed Insights bookmarks, a monthly spreadsheet, and a standing item on the retainer review slide. Reactive means the signal arrives after the business event you wanted to prevent. Common patterns: Spot checks after deploy. Someone runs PSI on staging, ships, and assumes production matches until a complaint arrives. Quarterly or monthly report pulls. CrUX and Lighthouse exports go into a deck. Useful for storytelling; too slow to catch a plugin update that moved INP on Tuesday. Client-led discovery. The sponsor pastes a screenshot, asks “is this new?”, and the team scrambles to reproduce on a laptop that may not match the lab conditions you use in production monitoring. Alerting without policy. Webhooks fire on every metric twitch. By week three the