· Tác giả: Trường — Founder Webchốt
Liên quan: Bài này nằm trong cụm chuyển WordPress sang Next.js. Xem thêm vì sao web WordPress khó lên AI Overview và thiết kế web lên Google AI Overview.
Khi Google AI Overview xuất hiện ở đầu trang kết quả, một câu hỏi thực tế nổi lên: website của bạn có được AI đọc đầy đủ không? Và khi AI trích dẫn nguồn và người dùng click vào, trang đó mở ngay hay chờ 4 giây?
Tốc độ web ảnh hưởng đến AI Overview qua hai mắt xích thường bị tách rời nhưng thực ra liên kết: crawl budget (trang chậm hoặc render JS phía client bị crawler đọc ít hơn, bỏ qua nội dung) và giữ chân sau click (người dùng từ AI Overview có intent cao, trang mở chậm là mất cơ hội chuyển đổi đó). Bài này đi sâu vào cả hai, với kỹ thuật thực tế từ kinh nghiệm dựng web Next.js — không phải lý thuyết chép từ docs.
Trong bài này
- Ba chỉ số Core Web Vitals và vai trò với AI Overview
- Crawl budget và liên kết ít được nói tới với AI crawler
- Vấn đề render JavaScript: nội dung ẩn sau JS là trang rỗng với crawler
- Ảnh — nguồn gây LCP kém lớn nhất và kỹ thuật xử lý
- JavaScript bundle nhỏ: tại sao ~87KB quan trọng
- Font tối ưu: tránh FOUT và CLS
- SSR vs SSG: chọn đúng cho từng loại trang
- Trước và sau: đo thực tế trên hai nền tảng
- Tự kiểm tốc độ website của bạn
- Sai lầm phổ biến khi tối ưu tốc độ
- Câu hỏi thường gặp
Ba chỉ số Core Web Vitals và vai trò với AI Overview
Google công bố ba chỉ số Core Web Vitals (CWV) để đo trải nghiệm người dùng thực tế — không phải tốc độ lab thuần. Mỗi chỉ số đo một khía cạnh khác nhau của trải nghiệm tải trang:
Vai trò của ba chỉ số này với AI Overview: Google chưa xác nhận CWV là yếu tố xếp hạng trực tiếp trong AI Overview. Tuy nhiên có hai mắt xích gián tiếp quan trọng. Thứ nhất, trang nhanh với HTML server-rendered giúp crawler thu thập nội dung đầy đủ hơn (ảnh hưởng chất lượng index). Thứ hai, khi AI trích dẫn và người dùng click, LCP kém dẫn đến bounce ngay lập tức — tín hiệu tiêu cực theo thời gian. Cả hai đều chỉ về một hướng: trang nhanh có lợi hơn về dài hạn, dù cơ chế không phải trực tiếp.
Crawl budget và liên kết ít được nói tới với AI crawler
Crawl budget là khái niệm Googlebot phân bổ tài nguyên có hạn theo domain khi thu thập nội dung. Trang load nhanh, trả về HTML ngay từ server được crawl nhiều hơn trong cùng một khoảng thời gian. Trang chậm hoặc cần thêm thời gian để JavaScript hydrate có thể bị thu thập ít hơn, dẫn đến nội dung không được index đủ để trích dẫn.
Liên quan AI Overview: bộ máy tổng hợp câu trả lời AI cần đọc nội dung đã được index đủ và rõ ràng. Nếu crawler chỉ đọc được header trang nhưng bỏ qua nội dung chính vì nó nằm sau JavaScript — nội dung đó không tồn tại trong mắt AI. Đây là lý do thiết kế kỹ thuật quan trọng hơn người ta nghĩ khi bàn về AI Overview.
Cách kiểm tra: vào Google Search Console, chọn URL Inspection cho một trang, xem phần "Rendered HTML" so với "Raw HTML". Nếu Raw HTML trống hoặc thiếu nội dung chính — đó là dấu hiệu nội dung ẩn sau JS, cần chuyển sang server rendering.
Vấn đề render JavaScript: nội dung ẩn sau JS là trang rỗng với crawler
Với Next.js App Router, mặc định mọi component là Server Component: HTML được render trên server, trả về ngay từ response đầu tiên. Crawler đọc được toàn bộ text, heading, FAQ ngay mà không cần đợi JS hydrate. Đây là lợi thế lớn so với Single Page Application (SPA) thuần JavaScript — loại mà phần lớn trang dùng React/Vue không có SSR.
Một nguyên tắc đơn giản nhưng quan trọng: nếu bạn tắt JavaScript trên trình duyệt mà trang trống trơn, crawler cũng đang nhìn thấy trang trống đó. Kiểm tra dễ: mở Chrome DevTools, tab Settings, tìm "Disable JavaScript", reload trang. Nội dung phần quan trọng có hiện không?
Ảnh — nguồn gây LCP kém lớn nhất và kỹ thuật xử lý
Phần lớn trang có LCP kém không phải do code JavaScript mà do ảnh: ảnh hero quá lớn, sai định dạng, không có thuộc tính width và height (gây CLS khi load), hoặc không được preload. Ảnh hero thường là phần tử lớn nhất trên trang (Largest Contentful Element) — nên nó thường chính là LCP element.
Thao tác cụ thể mình làm khi bàn giao: ảnh hero (above the fold) luôn dùng thuộc tính priority trong next/image — Next.js tự inject preload link vào <head>, trình duyệt tải ảnh đó ngay với độ ưu tiên cao nhất. Ảnh dưới fold dùng lazy mặc định. Định dạng nguồn: JPEG/PNG gốc, Next.js tự convert sang WebP khi serve và tự resize theo viewport. Kết quả: LCP ảnh hero thường dưới 1 giây trên kết nối 4G ổn định — số mình thực đo trên môi trường staging, không phải ước tính.
JavaScript bundle nhỏ: tại sao ~87KB quan trọng
Với trang thông tin (landing, blog, trang dịch vụ), JavaScript phía client cần cho interactivity nhỏ: menu mobile, accordion FAQ, form. Webchốt giữ client bundle ở khoảng 87KB cho các trang loại này. Để so sánh: nhiều site WordPress với plugin phổ biến có thể lên 500KB - 1MB chỉ riêng JavaScript.
Tại sao bundle nhỏ quan trọng: trình duyệt cần parse và thực thi JS trước khi trang trở nên interactive. JS nhiều hơn = INP cao hơn = người dùng bấm nút bị trễ phản hồi. Với trang bán hàng, bấm "Thêm vào giỏ" mà phải chờ 500ms là trải nghiệm tồi có thể dẫn đến abandon.
Cách đạt được bundle nhỏ với Next.js App Router: chỉ đánh dấu "use client" cho component thực sự cần state hoặc event handler. Phần còn lại là Server Component — không gửi một byte JS nào về client. Mình thường có tỷ lệ khoảng 90% Server Component và 10% Client Component cho trang thông tin — menu mobile và accordion FAQ là hai việc cần client, còn lại đều có thể server.
Font tối ưu: tránh FOUT và CLS
Font Google Fonts khi load bằng thẻ <link> truyền thống có thể gây FOUT (Flash of Unstyled Text) — chữ hiện ra với font fallback rồi nhảy sang font thật, tạo CLS. Hai vấn đề từ đây: trải nghiệm trang nhảy chữ khó chịu, và điểm CLS tăng lên.
Với Next.js, giải pháp là next/font/google: font được tải qua host của chính trang (tránh thêm DNS lookup tới fonts.googleapis.com), tự inject font-display: swap hoặc optional và subset chỉ ký tự cần dùng (tiếng Việt Latin Extended). Kết quả: CLS từ font gần 0, không có request ngoài vào Google CDN.
SSR vs SSG: chọn đúng cho từng loại trang
Next.js hỗ trợ hai kỹ thuật render quan trọng ảnh hưởng trực tiếp đến tốc độ và crawlability:
- SSR (Server-Side Rendering): trang render mỗi khi có request, luôn có dữ liệu mới nhất. Phù hợp với trang có dữ liệu thay đổi theo người dùng hoặc theo thời gian thực.
- SSG (Static Site Generation): trang render lúc build, phục vụ từ CDN edge. Thời gian phản hồi gần 0, không tốn server computation. Phù hợp với trang thông tin ổn định: landing dịch vụ, bài blog, trang sản phẩm không thay đổi liên tục.
- ISR (Incremental Static Regeneration): kết hợp — trang được cache như SSG nhưng tự động rebuild sau interval nhất định. Phù hợp với bài viết cần cập nhật định kỳ mà không cần real-time.
Trang dịch vụ và bài blog của webchot.com đều dùng SSG — phục vụ từ CDN edge, thời gian phản hồi gần như tức thì. Bạn đang đọc trang này và nó mở nhanh chính vì lý do đó. Với trang ERP có dữ liệu khách hàng real-time — đó là SSR, route riêng.
Trước và sau: đo thực tế trên hai nền tảng
Đây là ví dụ minh hoạ về sự khác biệt tốc độ giữa hai cách triển khai — không phải số liệu từ một dự án cụ thể, nhưng phản ánh đúng khoảng cách điển hình:
Số LCP của Webchốt là thực đo trên môi trường staging với next/image, CDN và bundle tối ưu. Số WordPress là điển hình minh hoạ — con số thực tế khác nhau tùy hosting, cấu hình, số plugin.
Tự kiểm tốc độ website của bạn
Bốn bước tự kiểm miễn phí, không cần công cụ trả phí:
- PageSpeed Insights (pagespeed.web.dev). Dán URL trang, chọn preset Mobile (không phải Desktop — người dùng thực tế chủ yếu trên mobile). Xem LCP (dưới 2.5 giây = tốt), CLS (dưới 0.1 = tốt), INP (dưới 200ms = tốt). Màu đỏ ở LCP là dấu hiệu cần xử lý ảnh hoặc đổi nền tảng.
- Xem mã nguồn (Ctrl+U). Tìm một câu nội dung chính của trang trong HTML raw. Thấy = nội dung server-rendered, crawler đọc được. Không thấy = nội dung ẩn sau JS, cần chuyển sang SSR/SSG.
- Tắt JavaScript, reload trang. Trong Chrome DevTools (F12) → Settings → Disable JavaScript → reload. Nội dung quan trọng có hiện không? Nếu không — vấn đề nghiêm trọng với cả SEO và AI crawler.
- Rich Results Test. Dán URL, xem phần "Rendered HTML" so với "Raw HTML". Nếu khác nhiều — JavaScript đang thay đổi đáng kể DOM sau khi load, crawler có thể đọc phiên bản khác với người dùng.
Sai lầm phổ biến khi tối ưu tốc độ
Câu hỏi thường gặp
LCP bao nhiêu là đủ để AI crawler đọc được nội dung?
Không có ngưỡng chính thức riêng cho AI crawler. Nguyên tắc quan trọng hơn ngưỡng số là: nội dung phải có sẵn trong HTML server-rendered, không đợi JavaScript. Google công bố LCP tốt là dưới 2,5 giây. Webchốt đặt mục tiêu dưới 1 giây — không phải vì AI yêu cầu, mà vì người dùng sau click AI có intent cao và không có thời gian chờ.
Tại sao nội dung chôn trong JavaScript là vấn đề lớn với AI crawler?
Googlebot và AI crawler có crawl budget giới hạn. Trang render JS client cần vài giây để hydrate trước khi nội dung hiện. Crawler có thể đọc DOM rỗng và bỏ qua nội dung chính. Với Next.js App Router, mặc định mọi trang là Server Component — HTML server-rendered sẵn, crawler đọc ngay.
Ba chỉ số Core Web Vitals là gì và cái nào quan trọng nhất?
LCP (Largest Contentful Paint, dưới 2,5s tốt), INP (Interaction to Next Paint, dưới 200ms tốt), CLS (Cumulative Layout Shift, dưới 0,1 tốt). Với AI crawler, LCP quan trọng nhất vì ảnh hưởng trực tiếp đến crawl. Với người dùng sau click AI, cả ba đều quan trọng.
Ảnh tối ưu ảnh hưởng thế nào đến LCP?
Ảnh hero thường là LCP element. Ảnh chưa tối ưu (JPEG lớn, không preload, không có width/height) là nguyên nhân số một gây LCP kém. Giải pháp: WebP/AVIF, preload ảnh hero với priority/fetchpriority="high", khai báo width+height tránh CLS, lazy load ảnh below fold.
Webchốt đạt LCP dưới 1 giây bằng cách nào?
Bốn kỹ thuật: Next.js App Router Server Components mặc định (HTML sẵn); next/image tự resize và WebP, thuộc tính priority cho ảnh hero; next/font tự host, tránh DNS lookup ngoài; giữ client bundle ~87KB bằng cách chỉ dùng use client khi cần state. Không có magic — kiến trúc đúng từ đầu.
WordPress có thể đạt Core Web Vitals tốt không?
Được, nhưng cần nhiều công hơn: plugin cache, CDN, tắt plugin thừa, tối ưu ảnh thủ công. Rào cản chính là page builder sinh HTML rối và nhiều plugin mỗi cái thêm CSS/JS riêng. Với Next.js, các tối ưu tích hợp sẵn ở framework, ít điểm thất bại hơn và bền hơn theo thời gian.
Webchốt làm gì ở mảng này
Webchốt dựng web Next.js với mục tiêu LCP dưới 1 giây và bundle ~87KB được cài sẵn vào kiến trúc từ ngày đầu — không phải tối ưu sau. Server Component mặc định, ảnh tối ưu qua next/image, font tự host qua next/font, SSG cho trang thông tin. Bạn nhận trang có Core Web Vitals tốt mà không cần tự cài plugin hay chỉnh server. Xem dịch vụ chuyển WordPress sang Next.js nếu trang hiện tại đang gặp LCP kém, và dịch vụ thiết kế web doanh nghiệp nếu bắt đầu mới.
Liên Hệ Webchốt
Muốn biết LCP và Core Web Vitals trang hiện tại của bạn đang ở mức nào, và cần làm gì trước để cải thiện? Mình chạy audit PageSpeed miễn phí và tư vấn lộ trình cụ thể — hoặc build mới trên Next.js với LCP dưới 1 giây ngay từ đầu:
- 0905 151 701
- Zalo
- hi@webchot.com
- STK 0905151701 — NGUYEN VAN TRUONG
- 262/1/93 Phan Anh, Phường Phú Thạnh, TP.HCM
Xem thêm dịch vụ · blog · công cụ. Cam kết: demo 48h, bảo hành 12 tháng, hoàn 100% trong 7 ngày, source code 100% cho khách.
Reference: web.dev/vitals, developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics, nextjs.org/docs/app/building-your-application/rendering/server-components, pagespeed.web.dev
