# ✅ Checklist Tối Ưu Core Web Vitals 2026
> **Mục tiêu:** LCP < 2.5s · CLS < 0.1 · INP < 200ms
> Cập nhật theo tiêu chuẩn Google Search 2026 — kiểm tra định kỳ mỗi sprint hoặc trước mỗi lần release.
---
## 📋 Hướng Dẫn Sử Dụng
- ☐ = Chưa thực hiện
- ✅ = Đã hoàn thành
- ⚠️ = Cần xem xét lại
- Ưu tiên thực hiện theo thứ tự từ trên xuống trong mỗi phần
- Gắn nhãn **[CRITICAL]** = ảnh hưởng trực tiếp đến ranking Google
---
## PHẦN 1 — 🖼️ LCP Optimization (Largest Contentful Paint)
> **Ngưỡng đạt:** LCP ≤ 2.5 giây (đo tại P75 của field data)
> LCP là yếu tố xếp hạng quan trọng nhất trong Core Web Vitals. Đây thường là ảnh hero, banner đầu trang hoặc khối text lớn nhất.
---
- [ ] **[CRITICAL] Xác định đúng phần tử LCP trên từng loại trang**
> *Tại sao:* Mỗi template trang (homepage, product, blog) có LCP element khác nhau. Dùng DevTools → Performance tab hoặc WebPageTest để xác định chính xác. Tối ưu sai phần tử = lãng phí toàn bộ công sức.
- [ ] **[CRITICAL] Thêm `fetchpriority="high"` vào thẻ ``**
> *Tại sao:* Khi không có kích thước, trình duyệt không biết trước ảnh chiếm bao nhiêu không gian, dẫn đến toàn bộ layout bên dưới bị đẩy xuống khi ảnh load xong. Chỉ hai thuộc tính này giải quyết 60–70% lỗi CLS phổ biến.
```html
` với AVIF → WebP → JPEG fallback để tối ưu cho mọi trình duyệt.
```html
```
- [ ] **[CRITICAL] Implement `srcset` và `sizes` cho tất cả ảnh responsive**
> *Tại sao:* Phục vụ ảnh 1920px cho màn hình mobile 375px là lãng phí 5–10x băng thông. `srcset` cho phép trình duyệt chọn kích thước phù hợp nhất dựa trên device pixel ratio và viewport. Giảm trung bình 60–70% dung lượng ảnh trên mobile.
```html
```
- [ ] **[CRITICAL] Thêm `` cho LCP image trong ``**
> *Tại sao:* Browser discovery thông thường phải đợi HTML parse xong mới biết cần tải ảnh. Preload giúp trình duyệt khởi động tải ảnh ngay từ byte HTML đầu tiên, giảm đáng kể thời gian chờ.
```html
```
- [ ] **Loại bỏ `loading="lazy"` khỏi ảnh LCP**
> *Tại sao:* `loading="lazy"` trì hoãn tải ảnh cho đến khi người dùng cuộn đến gần. Áp dụng nhầm cho ảnh LCP (thường nằm above-the-fold) là nguyên nhân phổ biến nhất khiến LCP thất bại — chỉ dùng lazy cho ảnh below-the-fold.
- [ ] **Đảm bảo server trả về LCP resource trong vòng 600ms (TTFB ≤ 800ms)**
> *Tại sao:* Google phân tách LCP thành 4 giai đoạn; TTFB cao ảnh hưởng toàn bộ pipeline. Nếu server chậm, mọi tối ưu frontend đều vô nghĩa. Dùng caching, CDN edge, và server-side rendering để cải thiện.
- [ ] **Inline critical CSS liên quan đến LCP element vào ``**
> *Tại sao:* Nếu CSS của phần tử LCP nằm trong file external stylesheet, trình duyệt phải chờ download + parse CSS mới render được. Inline CSS block rendering (~200–400 bytes cho LCP element) loại bỏ round-trip này.
- [ ] **Giảm chuỗi redirect trước khi tải LCP resource về 0 hoặc tối đa 1**
> *Tại sao:* Mỗi redirect thêm 100–300ms latency do phải thiết lập connection mới. Chuỗi redirect `http → https → www → non-www` có thể ngốn 600ms+ trước khi tải bất cứ thứ gì.
- [ ] **Sử dụng `rel="preconnect"` cho các origin chứa LCP resource (CDN, font server)**
> *Tại sao:* Kết nối đến third-party domain (DNS lookup + TCP + TLS) tốn 150–300ms. Preconnect thực hiện handshake này sớm khi trình duyệt còn đang parse HTML, tiết kiệm toàn bộ thời gian đó khi resource thực sự cần tải.
```html
```
---
## PHẦN 2 — 📐 CLS Prevention (Cumulative Layout Shift)
> **Ngưỡng đạt:** CLS ≤ 0.1 (tổng điểm dịch chuyển layout trong suốt vòng đời trang)
> CLS ảnh hưởng trực tiếp đến trải nghiệm người dùng — nút bấm nhảy chỗ, text dịch chuyển khi đang đọc. Google phạt nặng các trang có CLS cao trong mobile index.
---
- [ ] **[CRITICAL] Khai báo `width` và `height` cho tất cả thẻ `