Chapter 16 — Quiz

Twenty-four self-check questions: sixteen multiple choice, then eight short answer. Answer them before you open the key at the bottom. This quiz tests the three vitals, the field-versus-lab distinction, and — most important — the honest weight of Core Web Vitals as a ranking factor.

Part 1 — Multiple choice

Q1. The three Core Web Vitals are: - A. LCP, TTFB, and CrUX - B. LCP, INP, and CLS - C. Speed, Stability, and SEO - D. Lighthouse, PageSpeed, and Search Console

Q2. Largest Contentful Paint (LCP) measures: - A. The total time until the last byte of the page loads - B. How long until the largest visible content element is painted (the "loading feel") - C. How fast the page responds to a tap - D. How much the layout shifts

Q3. A "good" LCP is: - A. ≤ 100 ms - B. ≤ 0.1 - C. ≤ 2.5 seconds - D. ≤ 4 seconds

Q4. Interaction to Next Paint (INP) measures: - A. Visual stability - B. Server response time - C. Responsiveness — the delay from a user interaction to the next painted frame - D. The size of the largest image

Q5. A "good" INP is: - A. ≤ 200 milliseconds - B. ≤ 2.5 seconds - C. ≤ 0.1 - D. ≤ 500 milliseconds

Q6. Cumulative Layout Shift (CLS) measures: - A. How much visible content moves unexpectedly (visual stability) - B. How many layouts the page uses - C. The time to first byte - D. Cumulative page views

Q7. A "good" CLS is: - A. ≤ 2.5 seconds - B. ≤ 0.1 - C. ≤ 200 ms - D. ≥ 0.25

Q8. In 2024, INP replaced which older metric as a Core Web Vital? - A. Time To First Byte (TTFB) - B. First Contentful Paint (FCP) - C. First Input Delay (FID) - D. Speed Index

Q9. Field data (as used for the Core Web Vitals ranking assessment) comes from: - A. A single synthetic Lighthouse test on a simulated device - B. Real Chrome users on their real devices and networks (CrUX) - C. Your own browser when you visit the page - D. Google's internal servers guessing your speed

Q10. The 0-to-100 performance score in a Lighthouse / PageSpeed Insights report is: - A. Your Core Web Vitals ranking signal - B. A lab score from one synthetic run — useful for diagnosis, not what Google ranks on - C. The percentage of users who had a good experience - D. A Google-issued grade that guarantees a ranking

Q11. For the ranking question, when field data and the lab score disagree, you should believe: - A. The lab score, because it is a single crisp number - B. Whichever is higher - C. The field data, because that is what Google's signal uses - D. Neither; rankings ignore speed entirely

Q12. TTFB (Time To First Byte) matters for LCP because: - A. It is the last segment of LCP - B. It is the opening segment of LCP, so a slow TTFB caps how fast LCP can be - C. It only affects CLS - D. It measures JavaScript execution

Q13. Which fix most directly improves CLS? - A. Adding a CDN - B. Reducing Time To First Byte - C. Setting explicit width/height (or aspect-ratio) and reserving space for late content - D. Deferring JavaScript

Q14. Bad INP is most often caused by: - A. Large images - B. A slow server - C. JavaScript hogging the main thread (heavy or third-party scripts) - D. Missing image dimensions

Q15. Core Web Vitals as a ranking factor is best described as: - A. The single most important ranking factor - B. A confirmed but modest signal — a tiebreaker among comparable results - C. Not a ranking factor at all - D. A guarantee of a top-three position if green

Q16. A page has a slow, "poor" LCP but is the most relevant, highest-quality result for the query. According to Google's stated framing, it will most likely: - A. Be excluded from the results entirely - B. Still rank well — relevance and quality outweigh a poor page experience - C. Rank #1 only if it also fixes CLS - D. Be replaced by a faster but less relevant page

Part 2 — Short answer

Q17. Name the three Core Web Vitals, what each measures in plain terms, and each "good" threshold.

Q18. Explain the difference between field data and lab data, and give the job each is best suited for.

Q19. Why does the chapter argue for fixing speed "for users first, rankings second"? Give the business reason that holds even if rankings never move.

Q20. A caching plugin and a CDN are installed. Which vital do they most help, and which vital(s) do they not meaningfully help — and why?

Q21. What does it mean that CrUX reports at the "75th percentile," and why does Google weight it toward your slower users rather than your median?

Q22. State the myth this chapter is required to bust, and give two distinct reasons it is false.

Q23. A low-traffic location page shows "insufficient field data" in PageSpeed Insights. What does that mean, and why is it a limitation you must handle honestly?

Q24. Give the honest, evidence-tiered answer to "Does Core Web Vitals affect rankings?" — naming what is confirmed by Google and what the important caveat is.

Answer key (try every question first) **Part 1 — Multiple choice** 1. **B** — LCP, INP, CLS. 2. **B** — Time until the largest visible content element is painted; the loading feel. 3. **C** — ≤ 2.5 seconds. 4. **C** — Responsiveness: the delay from an interaction to the next painted frame. 5. **A** — ≤ 200 milliseconds. 6. **A** — How much visible content moves unexpectedly; visual stability. 7. **B** — ≤ 0.1. 8. **C** — First Input Delay (FID). INP watches all interactions and the full latency, not just the first delay. 9. **B** — Real Chrome users (the Chrome User Experience Report, CrUX). 10. **B** — A lab score from one synthetic run; for diagnosis, not the ranking signal. 11. **C** — The field data; that is what Google's signal uses. 12. **B** — TTFB is the opening segment of LCP, so it caps how fast LCP can be. 13. **C** — Explicit dimensions and reserving space for late-loading content. 14. **C** — JavaScript hogging the main thread (often heavy or third-party scripts). 15. **B** — A confirmed but modest signal; a tiebreaker among comparable results. 16. **B** — It will still rank well; relevance and quality outweigh a poor page experience (Google's stated framing). **Part 2 — Short answer** 17. **LCP (Largest Contentful Paint)** — time until the largest visible element is painted; good ≤ 2.5 s. **INP (Interaction to Next Paint)** — delay from an interaction to the next painted frame (responsiveness); good ≤ 200 ms. **CLS (Cumulative Layout Shift)** — how much content shifts unexpectedly (visual stability); good ≤ 0.1. 18. **Field data** is measured from real users on their real devices/networks (CrUX) — the truth about your audience, and the basis of the ranking signal. **Lab data** is one synthetic, repeatable test on a simulated device (Lighthouse) — best for *diagnosing what to change*. Use field data to judge whether real users are okay; use lab data to find the specific fix. 19. Because a slow page loses real customers *now* — higher bounce, fewer conversions, less revenue — and that loss is direct and often larger than any ranking effect. Even if rankings never move, fixing speed stops the leak of visitors who give up before they see or use your content. 20. They most help **LCP** (via faster server response/TTFB and asset delivery). They do **not** meaningfully help **CLS** (layout shift is about reserving space, not delivery speed) or **INP** (responsiveness is about JavaScript executing on the user's device, which edge-caching doesn't change). Match the fix to the vital. 21. It means 75% of your real visits met that value or better (and 25% were worse) — so "your LCP is 3.1 s" describes the experience at the slower end, not the middle. Google weights toward slower users because it cares whether *most* people had a good experience, not whether your fastest quarter did. 22. Myth: **"A perfect 100 PageSpeed score ranks you #1."** Any two of: the 100 is a *lab* score, not the *field* data Google ranks on; Core Web Vitals is a *tiebreaker*, not a dominant factor, and cannot outrank a more relevant competitor; ranking is a *relative contest*, not a checklist, so no score *entitles* you to #1; getting from good to perfect buys ~nothing for ranking (aim for the threshold). 23. It means the page doesn't have enough real Chrome traffic for CrUX to report a reliable field result, so the tools fall back to site-wide (origin) data or show only a lab test. You must handle it honestly: "insufficient data" is *not* a pass, and often it signals the deeper problem that the page has too few visitors to even measure — a visibility/content problem, not a speed one. 24. **Confirmed by Google:** yes — Core Web Vitals / page experience is a documented ranking signal (launched via the Page Experience update). **The caveat (also from Google):** it is a *tiebreaker among comparable results*, based on *field* data, and it does not override relevance and quality — Google will still rank the most relevant result even with a poorer page experience. No specific position-gain number exists; anyone quoting one is inventing it.