Technical SEO — what Google actually has to crawl, render and index
How crawl budget, robots, sitemap, JS rendering, indexing, canonical and Core Web Vitals fit together — the full arc for production sites.
in Technisches SEO
Ladezeit-Optimierung, Tools und Techniken jenseits der reinen Core-Web-Vitals-Metriken.
Server-side compression methods that shrink text resources like HTML, CSS and JavaScript before transmission — Brotli usually delivers better ratios than Gzip today.
A distributed server network that delivers static — and increasingly dynamic — content from the geographically nearest edge server to the user.
The critical rendering path is the sequence the browser runs to turn HTML/CSS/JS into pixels parsing, render tree, layout, paint. Optimizing it shortens first paint and LCP.
CrUX is Google's public field-data dataset of real performance values from Chrome users (opt-in). It's the source of Core Web Vitals scoring in Search Console and PageSpeed Insights — not synthetic.
FCP measures when the browser renders the first visible DOM element (text, image, SVG). "Good" at ≤ 1.8 s. The earliest signal that the page is responding — not a Core Web Vital, but an important PageSpeed metric.
Field data are real performance values from actual users (CrUX, RUM). Lab data are synthetic measurements under controlled conditions (Lighthouse, WebPageTest). Google ranks by field data — lab data only hints at trends.
Modern versions of the HTTP protocol that deliver parallel requests over a single connection (HTTP/2) or via the faster QUIC transport (HTTP/3).
Using modern image formats (WebP, AVIF) plus appropriate sizes and compression to dramatically shrink image payloads without visible quality loss.
Lazy loading is a technique where images, iframes, or JavaScript modules load only when actually needed — usually when scrolled into the viewport.
Lighthouse is Google's open-source audit tool that synthetically measures a page's performance, accessibility, best practices, and SEO in a controlled environment.
PageSpeed Insights is Google's free web tool that combines Lighthouse lab scores with CrUX field data from real Chrome users and outputs concrete optimization suggestions.
Resource hints in the HTML head that tell the browser to fetch resources earlier, set up connections in advance, or accelerate DNS lookups.
Render-blocking resources are CSS and JavaScript files the browser must load and parse before it can render. They delay FCP and LCP — minimize them with async/defer, inline critical CSS, and remove unused CSS.
TTFB measures the time from request start to the first byte received. It sums DNS, TCP, TLS, and server processing. Rule of thumb — good < 200 ms, problematic > 600 ms; directly affects LCP and FCP.
How crawl budget, robots, sitemap, JS rendering, indexing, canonical and Core Web Vitals fit together — the full arc for production sites.
What INP measures, why it replaced FID in March 2024, the 200 ms threshold, and the levers against long JavaScript tasks on the main thread.
LCP measures when the largest visible element loads. Why TTFB and render-blocking resources hold the image back — and which levers actually move it.
Why the same page shows different numbers in Lighthouse and Search Console — and why only field data counts for rankings.
What CLS measures, why under 0.1 is the target, and which levers — image dimensions, font-display, placeholders — reliably remove layout jumps.
How TTFB fires the starting gun for LCP and how the browser turns bytes into pixels via the critical rendering path — plus the levers that matter.