At a glance
- Start from field data by template and device, then audit the failing templates.
- Test logged out and logged in, and each market variant you serve.
- Record lab settings with every result so runs can be compared.
- Treat the checklist as a review aid; it does not replace field data.
Before you start
- Pull field data for each template on mobile from Search Console or your own monitoring, and note which metric fails.
- Choose one representative URL per failing template and variant (market, language, login state).
- Set up the lab: Chrome DevTools or Lighthouse with the standard mobile throttling, which simulates 150 ms latency, 1.6 Mbps download and a 4x CPU slowdown. Record the browser version and date.
Loading (LCP)
| Check | Pass when |
|---|---|
| The LCP element is identified per template on mobile | Named in the audit notes |
| The LCP image is in the HTML, not created by script | Found in the page source |
| The LCP image is not lazy-loaded | No loading="lazy" on it |
| fetchpriority="high" on the LCP image only, or one other | One or two images at most |
| Banner served at mobile size in a modern format | File width close to display width |
| No redirect chain before the lobby | One request to the final URL |
Responsiveness (INP)
| Check | Pass when |
|---|---|
| Tap category tabs, filters and search during and after load | Visual response in the next frame |
| Long tasks during load | Few, and none from code the first view does not need |
| Filter, cashier, game launcher code split from the main bundle | Loaded on use |
| Chat loads behind a facade | Chat code requested only after a tap |
| Non-essential tags fire after load | Not in the critical path |
Stability (CLS)
| Check | Pass when |
|---|---|
| Every image and video has width and height | No unsized media in the source |
| Consent, app prompts and promo strips overlay or are reserved | No content pushed down after first paint |
| Widgets and frames have reserved height | No shift when they load |
| Scroll the lobby for 10 seconds | No shifts outside user input |
| Fonts swap without reflow | Fallback metrics matched, or font-display optional |
Delivery and weight
| Check | Pass when |
|---|---|
| Total transfer size within your budget | Under the agreed limit in the calculator |
| Versioned static files cached for a long time | Long max-age, ideally immutable |
| Text compressed | HTML, CSS, JS served compressed |
| Page eligible for the back/forward cache | DevTools bfcache test passes |
Accessibility checks that affect performance work
- Auto-rotating carousels and previews have a pause control (WCAG 2.2, 2.2.2).
- Animations respect
prefers-reduced-motion. - Tap targets meet WCAG 2.2's minimum target size criterion.
More in accessibility and performance.
Reporting
For each failing check, record the template, variant, lab settings, date and a trace or screenshot. Mark lab results as lab results. Re-check field data after the 28-day window before calling a fix confirmed. The measurement protocol lists the fields to record.
Questions
Do I need a real phone if I use throttling?
It helps. Throttling is consistent, but a real mid-range phone shows touch behavior, heat and memory limits that simulation does not.
Which templates come first?
Those with the most mobile traffic and a failing field metric, usually the lobby and popular game pages.
Can I download this checklist?
Print the page, or copy the tables into your own tracker. The calculator's CSV export covers the budget part.
Sources
- GoogleChrome, Lighthouse throttling documentation, no date shown.
- web.dev, Optimize Largest Contentful Paint, last updated March 31, 2025.
- web.dev, Optimize Interaction to Next Paint, last updated September 2, 2025.
- web.dev, Optimize Cumulative Layout Shift, last updated February 7, 2025.
- web.dev, Back/forward cache, last updated October 16, 2026.
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2, W3C Recommendation, October 5, 2023.