Mục lục bài viết
Nhiều người làm AEO tập trung hoàn toàn vào structured data và content mà bỏ qua một yếu tố nền tảng: tốc độ trang. AI search không chỉ đọc nội dung — nó cũng đánh giá trang web có đáng tin hay không dựa trên các tín hiệu chất lượng kỹ thuật.
Core Web Vitals là gì?
Google đo chất lượng trải nghiệm người dùng qua 3 chỉ số:
| Chỉ số | Đo gì | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Thời gian tải xong phần tử lớn nhất trong viewport | Dưới 2.5s | 2.5s–4s | Trên 4s |
| INP (Interaction to Next Paint) | Độ trễ khi người dùng tương tác | Dưới 200ms | 200–500ms | Trên 500ms |
| CLS (Cumulative Layout Shift) | Mức độ layout bị dịch chuyển | Dưới 0.1 | 0.1–0.25 | Trên 0.25 |
INP thay thế FID từ tháng 3/2024. Nếu bạn vẫn đang track FID — hãy chuyển sang INP.
Mối liên hệ CWV và AEO
Cơ chế 1: Trust signal
Google xây dựng "Page Quality Score" dựa trên nhiều tín hiệu, bao gồm CWV. Trang có CWV tốt → người dùng ở lại lâu hơn → Google tin rằng trang này hữu ích → AI Overviews ưu tiên trích dẫn.
Cơ chế 2: Crawl budget
Googlebot phân bổ thời gian crawl cho mỗi domain. Trang chậm → Googlebot chờ lâu hơn → crawl ít trang hơn trong cùng thời gian → AI biết ít hơn về nội dung mới của bạn.
Cơ chế 3: Content accessibility
Nếu LCP trên 4 giây, một phần nội dung quan trọng (như bảng, FAQ, schema JSON-LD) có thể chưa render xong khi Googlebot snapshot. AI có thể đọc trang mà không thấy phần nội dung quan trọng nhất.
Benchmark CWV theo ngành (Việt Nam 2026)
| Ngành | LCP trung bình | Tỷ lệ đạt Good | Cơ hội AEO |
|---|---|---|---|
| Tin tức/Báo | 1.8–2.2s | 65% | Trung bình (nhiều đối thủ cũng tốt) |
| E-commerce | 2.8–3.5s | 35% | Cao (nhiều shop chậm) |
| B2B / SaaS | 2.0–2.8s | 55% | Trung bình |
| Y tế / Sức khỏe | 2.5–3.8s | 40% | Cao |
| Bất động sản | 3.0–4.5s | 25% | Rất cao (trang nặng ảnh) |
| Nhà hàng / Local | 2.2–3.0s | 50% | Trung bình |
Nếu bạn đang ở ngành có tỷ lệ đạt Good thấp — đây là cơ hội cạnh tranh lớn.
Nguyên nhân LCP chậm và cách fix
LCP bị ảnh hưởng bởi những yếu tố này (theo thứ tự tác động):
1. Time to First Byte (TTFB) chậm
Server phản hồi chậm kéo dài mọi thứ. Target TTFB: dưới 600ms.
Fix:
- Enable caching cho static pages (Next.js:
revalidate, ISR) - Dùng CDN (Vercel Edge Network tự động với Next.js)
- Optimize database queries nếu dùng dynamic rendering
2. Ảnh hero không được ưu tiên
// Sai — Next.js lazy load mặc định
<Image src="/hero.jpg" width={1200} height={600} alt="Hero" />
// Đúng — hero image phải priority
<Image src="/hero.jpg" width={1200} height={600} alt="Hero" priority />
3. Render-blocking resources
<!-- Sai — Google Fonts chặn render -->
<link href="https://fonts.googleapis.com/css2?family=..." rel="stylesheet">
<!-- Đúng — preconnect + async load -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
<link rel="stylesheet" href="..." media="print" onload="this.media='all'">
4. Ảnh chưa được tối ưu
- Dùng WebP hoặc AVIF thay PNG/JPG
- Next.js Image component tự động convert nếu cấu hình đúng
- Compress ảnh trước khi upload: target dưới 200KB cho hero image
CLS: Những thứ gây layout shift
CLS 0 là lý tưởng nhưng gần như không thể với trang có quảng cáo. Mục tiêu: dưới 0.1.
Ảnh không có dimensions:
// Gây CLS — không có dimensions
<img src="/product.jpg" />
// Fix — khai báo width và height
<img src="/product.jpg" width="400" height="300" />
// Hoặc dùng Next.js Image (tự handle CLS)
<Image src="/product.jpg" width={400} height={300} alt="..." />
Font loading CLS:
/* Tránh FOUT (Flash of Unstyled Text) gây CLS */
@font-face {
font-family: 'MyFont';
src: url('/fonts/myfont.woff2') format('woff2');
font-display: optional;
}
INP: Tương tác phản hồi chậm
INP thường bị ảnh hưởng bởi JavaScript nặng chạy trên main thread:
| Nguyên nhân | Giải pháp |
|---|---|
| Long tasks trên main thread | Code splitting, Web Workers cho heavy computation |
| Event handlers chậm | Debounce input, optimize state updates |
| Third-party scripts | Load async, defer, hoặc dùng Partytown |
| React re-renders không cần thiết | useMemo, useCallback, React.memo đúng chỗ |
CWV và AEO: Checklist kỹ thuật
- LCP dưới 2.5 giây trên mobile (đo bằng PageSpeed Insights)
- INP dưới 200ms
- CLS dưới 0.1
- TTFB dưới 600ms (Server/Edge response time)
- Ảnh hero/above-fold dùng
prioritytrong Next.js Image - Mọi ảnh có khai báo
widthvàheight - Không có render-blocking resources trong
<head> - Google Search Console — 0 URLs trong "Poor" bucket
- WebP hoặc AVIF cho ảnh lớn
- Lazy load cho ảnh below-fold, không lazy load cho above-fold
Thực tế: CWV bao nhiêu là "đủ tốt" cho AEO?
| CWV Status | AEO Impact |
|---|---|
| Tất cả Good | Loại trừ CWV khỏi rủi ro — AI xem xét nội dung bình thường |
| 1-2 chỉ số Needs Improvement | Ít ảnh hưởng trực tiếp, nhưng cần theo dõi |
| Bất kỳ chỉ số Poor | Rủi ro — có thể bị deprioritize trong AI source selection |
| LCP trên 4s | Red flag — nhiều AI systems filter out trang này |
Điều thực tế cần nhớ: CWV là điều kiện cần, không đủ cho AEO. Tốc độ tốt mà nội dung kém — vẫn không được trích dẫn. Nhưng nội dung tốt mà tốc độ tệ — có thể không bao giờ được AI đọc đủ để trích dẫn.
Đầu tư vào CWV là đầu tư vào nền tảng. Một lần làm đúng, hưởng lợi mọi thứ xây lên trên.
Câu hỏi thường gặp
Core Web Vitals ảnh hưởng đến AEO như thế nào?
3 cơ chế chính: (1) Threshold lọc — Google AI Overviews lọc nguồn có CWV kém trước khi xem xét nội dung. Nếu LCP trên 4 giây, trang có thể bị loại khỏi pool nguồn trích dẫn ngay cả khi nội dung tốt. (2) Trust signal — tốc độ chậm = trải nghiệm tệ = Google tin tưởng ít hơn vào trang đó như một nguồn đáng tin cậy. (3) Crawl priority — Googlebot ưu tiên crawl trang nhanh, trang chậm bị crawl ít hơn → AI biết ít hơn về nội dung của bạn.
Ngưỡng Core Web Vitals nào cần đạt được để tốt cho AEO?
Mục tiêu là Good cho tất cả 3 chỉ số: LCP dưới 2.5 giây (tải xong phần tử lớn nhất), INP dưới 200ms (độ trễ tương tác), CLS dưới 0.1 (độ dịch chuyển layout). Với AEO, mục tiêu thực tế: LCP dưới 3 giây là an toàn, dưới 2.5 giây là tốt. INP và CLS thường dễ đạt hơn nếu không có JavaScript nặng và ads layout shift.
LCP, INP, CLS — chỉ số nào quan trọng nhất với AEO?
LCP quan trọng nhất cho AEO. Lý do: LCP đo thời gian người dùng thấy nội dung chính — nếu chậm, người dùng rời trang ngay, Google ghi nhận bounce rate cao, trust signal giảm. CLS quan trọng thứ hai vì layout shift làm nội dung bị che, người dùng click sai, trải nghiệm tệ. INP quan trọng cho SEO nhưng ít ảnh hưởng AEO trực tiếp vì AI không tương tác với trang như người dùng.
Trang dùng nhiều JavaScript có thể đạt CWV tốt không?
Có — nhưng cần tối ưu chủ động. Next.js App Router giúp nhiều: Server Components giảm JS bundle, Streaming SSR cải thiện LCP, Image component tự optimize. Cần thêm: lazy load các component không cần thiết ngay lập tức, code splitting cho heavy widgets, dynamic import cho chart/editor. Framework không tự giải quyết mọi thứ — cần đo và tối ưu cụ thể.
Đo Core Web Vitals ở đâu là chính xác nhất?
Field data (dữ liệu thực) quan trọng hơn lab data. Nguồn chính xác nhất: (1) Google Search Console — mục Core Web Vitals, dữ liệu CrUX thực từ người dùng Chrome; (2) PageSpeed Insights — kết hợp lab data (Lighthouse) và field data (CrUX) cho URL cụ thể; (3) Chrome DevTools Lighthouse — lab only, hữu ích để debug nhưng không phản ánh dữ liệu thực. Lab data và field data thường khác nhau 20-50%.
AEO Saigon
Agency Answer Engine Optimization tại TP. Hồ Chí Minh — giúp website doanh nghiệp được AI trích dẫn. Về AEO Saigon →
Muốn website của bạn được AI trích dẫn như vậy?
Audit miễn phí