Paweł Pokrywka's wroclove.rb 2024 talk explaining how he brought Largest Contentful Paint on planujewesele.pl below 350 ms (real number even lower; rounded up to avoid disbelief). Covers: why LCP matters (Google SEO ranking boost below 2.5 s, conversion-rate impact), a live demo of a cached Google search result loading in ~140 ms on throttled 3G, reverse-engineering the HTML to reveal that Google does NOT use naive `<link rel=prefetch>` (privacy leakage of user IPs via referer, lack of control over prefetched bytes), history of AMP (2015, simplified HTML framework, mobile-only, ugly google.com URLs, trust issues), the 2018 invention of Signed Exchanges (sxg) as a draft standard supported by Chromium browsers, Cloudflare, an nginx module, and Fastly. Walks through how SXG works end-to-end (Googlebot requests with Accept: signed-exchange, server returns a signed package, Google stores it in the opaque SXG cache, browser prefetches from web-pkg-c.com, and decoded SXG is served on click). Basic implementation: one-click toggle in a $20/month Cloudflare subscription. Full implementation requires decoupling request from response: Cache-Control: public with max-age between 120s and 7 days (speaker uses 24 h; Googlebot keeps it fresh), no server-side personalization, no server-side cookies (session cookie moved to a dedicated endpoint, avatar/username to client-side, CSRF moved client-side, HSTS header removed). 'First impression optimization' assumes anonymous visitor to avoid hitting auth endpoints — useful for crawler budget. Sub-resource prefetching uses the Link HTTP header with SHA hashes per URL; Cloudflare's Automatic Signed Exchanges (ASX) generates these, but Rails' built-in Link header for early hints takes precedence and had to be stripped for SXG responses via a Cloudflare Worker. Sub-resources have strict rules: Cache-Control (1 year ideal), no cookies, no HSTS, must share the main domain (a Cloudflare Worker rewrites CDN URLs), max ~20 resources, all-or-nothing prefetching (one failure discards all — for privacy). CORS-looking errors usually mask cache misses in the underdocumented Google SXG cache; Cloudflare even returns different responses to Googlebot vs curl. Debugging tools: Chrome DevTools (enable/disable cache carefully), an SXG prefetch simulator page, the SXG Validator browser extension (unstable, false negatives), curl (but disable Cloudflare Bot Fight Mode first), the Requestly browser header-modifying extension, Google Search Console's URL inspection. Measurement: naive before/after is swamped by seasonal bias and low signal-to-noise; Cloudflare injects a `window.isSXG` flag but SXG traffic is biased (users saw the site high in SERPs). Best approach: compare SXG-with-working-sub-resources to SXG-with-broken-prefetch using a Canary sub-resource detected via JavaScript (a future 'poisonous' sub-resource will always fail for A/B). Q&A: does SXG break on its own due to Google changes? Speaker only started tracking error rate while preparing this talk, so doesn't yet know.