Core Web Vitals và Độ trễ: Liệu các trang nhanh hơn có nhận được nhiều trích dẫn từ AI hơn không?

Core Web Vitals và Độ trễ: Liệu các trang nhanh hơn có nhận được nhiều trích dẫn từ Trí tuệ nhân tạo hơn không?

Giới thiệu

Một trang web nhanh sẽ dễ sử dụng hơn cho người dùng. Nó cũng có thể dễ dàng hơn cho các công cụ tìm kiếm và hệ thống trí tuệ nhân tạo trong việc tìm nạp, kết xuất và hiểu nội dung.

Nhưng một điểm khác biệt quan trọng thường bị bỏ qua:

Một trang nhanh hơn có thể cải thiện khả năng thu thập dữ liệu và tính khả dụng của nội dung. Điều đó không có nghĩa chỉ riêng tốc độ làm cho một hệ thống trí tuệ nhân tạo trích dẫn trang đó.

Tính đến ngày 2 tháng 8 năm 2026, Google tuyên bố rằng thời gian phản hồi máy chủ ổn định và độ trễ thấp hơn có thể làm tăng khả năng thu thập dữ liệu của một trang web. Google cũng tuyên bố rằng các tính năng tìm kiếm trí tuệ nhân tạo của họ sử dụng cùng một hệ thống tìm kiếm và lập chỉ mục cơ bản như tìm kiếm truyền thống và không yêu cầu đánh dấu hoặc tối ưu hóa tốc độ đặc biệt cho trí tuệ nhân tạo. (developers.google.com)

Bài viết này trình bày một kế hoạch thử nghiệm dựa trên bằng chứng thay vì tuyên bố rằng một thí nghiệm đã hoàn thành đã được chạy. Không có trang web, tập hợp trang, nhật ký máy chủ hoặc tập dữ liệu trích dẫn nào được cung cấp. Mục tiêu là xác định một nghiên cứu có kiểm soát có thể đo lường:

1. Liệu thời gian phản hồi byte đầu tiên thấp hơn có làm tăng tần suất thu thập dữ liệu không.
2. Liệu Largest Contentful Paint thấp hơn có cải thiện khả năng khám phá hoặc lập chỉ mục không.
3. Liệu Cumulative Layout Shift thấp hơn có ảnh hưởng đến việc thu thập dữ liệu hoặc truy xuất trí tuệ nhân tạo không.
4. Liệu những cải thiện về hiệu suất có làm tăng tỷ lệ các trang được các hệ thống tìm kiếm trí tuệ nhân tạo trích dẫn một cách rõ ràng hay không.

Câu trả lời ngắn gọn

Thời gian phản hồi byte đầu tiên thấp hơn có thể cải thiện việc thu thập dữ liệu trong điều kiện phù hợp

Tài liệu thu thập dữ liệu hiện tại của Google cho biết giới hạn khả năng thu thập dữ liệu của họ có thể tăng lên khi một trang web có thời gian phản hồi ổn định hoặc được cải thiện, bao gồm cả thời gian phản hồi byte đầu tiên. Nếu thời gian phản hồi tăng lên, hoặc nếu một trang web trả về quá nhiều lỗi máy chủ hoặc phản hồi giới hạn tốc độ, Google có thể giảm việc thu thập dữ liệu. (developers.google.com)

Tuy nhiên, thời gian phản hồi nhanh hơn không đảm bảo việc thu thập dữ liệu nhiều hơn. Nhu cầu thu thập dữ liệu cũng phụ thuộc vào các yếu tố như:

• Tần suất thay đổi của trang web.
• Mức độ phổ biến của trang web và các trang của nó.
• Nội dung có hữu ích và độc đáo hay không.
• Có bao nhiêu URL trùng lặp hoặc giá trị thấp tồn tại.
• Liệu các URL đã cập nhật có được đưa vào sitemaps hay không.

Điều này có nghĩa là độ trễ thấp hơn sẽ có tác động mạnh nhất đến các trang web lớn, thường xuyên cập nhật hoặc bị giới hạn máy chủ, chứ không nhất thiết là một trang web nhỏ với ít nội dung mới.

Largest Contentful Paint thấp hơn có thể giúp ích một cách gián tiếp

Largest Contentful Paint đo lường thời điểm nội dung chính hiển thị cho người dùng. Google cũng tuyên bố rằng cả thời gian phản hồi máy chủ và thời gian cần thiết để kết xuất các trang và tài nguyên nhúng đều có thể ảnh hưởng đến hiệu quả thu thập dữ liệu. (developers.google.com)

Mối quan hệ có khả năng là gián tiếp:

Độ trễ thấp hơn → phân phối tài nguyên nhanh hơn → kết xuất hoặc tìm nạp hiệu quả hơn → ít lỗi hết thời gian chờ thu thập dữ liệu hoặc tìm nạp không đầy đủ.

Hiệu ứng sẽ mạnh nhất khi nội dung quan trọng phụ thuộc vào:

• JavaScript chậm.
• Hình ảnh lớn.
• Các biểu định kiểu chặn kết xuất.
• Kết xuất phía máy khách (client-side rendering).
• Các tài nguyên nhúng nặng.

Chỉ riêng điểm số Largest Contentful Paint nhanh không có khả năng là một tín hiệu trích dẫn trí tuệ nhân tạo trực tiếp.

Cumulative Layout Shift thấp hơn có thể ít có ảnh hưởng trực tiếp đến việc thu thập dữ liệu

Cumulative Layout Shift đo lường sự di chuyển không mong muốn của nội dung hiển thị. Đây chủ yếu là một chỉ số trải nghiệm người dùng. Các nguyên nhân phổ biến bao gồm hình ảnh không có kích thước, quảng cáo được chèn động, nội dung nhúng và phông chữ web. (web.dev)

Trình thu thập dữ liệu không trải nghiệm sự thay đổi bố cục theo cùng một cách mà một khách truy cập con người trải nghiệm. Do đó, một mối quan hệ trực tiếp giữa Cumulative Layout Shift thấp hơn và việc thu thập dữ liệu nhiều hơn là không có khả năng xảy ra.

Có thể có một mối quan hệ gián tiếp khi sự thay đổi bố cục cao được gây ra bởi:

• Nội dung được chèn muộn bởi JavaScript.
• Văn bản quan trọng bị ẩn cho đến khi các tập lệnh chạy.
• Hình ảnh hoặc nội dung nhúng làm chậm quá trình xây dựng trang.
• Các mẫu không ổn định tạo ra nội dung khác nhau trong các lần tìm nạp khác nhau.

Trong những trường hợp đó, vấn đề thực sự không phải là điểm số thay đổi bố cục. Vấn đề thực sự là trang có thể khó xử lý hoặc có thể hiển thị nội dung quan trọng quá muộn.

Các trang nhanh hơn không tự động được trích dẫn thường xuyên hơn

Google cho biết các trang xuất hiện trong các tính năng trí tuệ nhân tạo trước tiên phải được lập chỉ mục và đủ điều kiện xuất hiện trong kết quả tìm kiếm thông thường với một đoạn trích. Google cũng cho biết không có yêu cầu kỹ thuật bổ sung hoặc tối ưu hóa trí tuệ nhân tạo đặc biệt nào cho các tổng quan trí tuệ nhân tạo và chế độ trí tuệ nhân tạo của họ. (developers.google.com)

OpenAI cũng tuyên bố rằng thứ hạng tìm kiếm của ChatGPT phụ thuộc vào nhiều yếu tố và việc cho phép trình thu thập dữ liệu tìm kiếm của họ, OAI-SearchBot, là quan trọng để được đưa vào. Họ không nêu rằng Core Web Vitals thấp hơn trực tiếp làm tăng khả năng trích dẫn. (help.openai.com)

Điều này gợi ý một mô hình bốn giai đoạn:

1. Khám phá — Hệ thống có biết URL tồn tại không?
2. Tìm nạp và xử lý — Hệ thống có thể truy xuất và hiểu trang không?
3. Lập chỉ mục và truy xuất — Trang có được chọn cho một truy vấn cụ thể không?
4. Chọn trích dẫn — Trang có được hiển thị như một nguồn rõ ràng trong câu trả lời không?

Tốc độ trang có thể ảnh hưởng đến hai giai đoạn đầu tiên. Nó không được thiết lập như một nguyên nhân trực tiếp của giai đoạn thứ tư.

Nghiên cứu gần đây cũng cho thấy các hệ thống trí tuệ nhân tạo có thể đọc nhiều trang liên quan nhưng chỉ trích dẫn một số trong số đó. Nói cách khác, việc truy xuất và trích dẫn là những sự kiện riêng biệt. (cambridge.org)

Những gì nên được kiểm tra?

Nghiên cứu nên kiểm tra hai câu hỏi khác nhau thay vì coi “khả năng hiển thị của trí tuệ nhân tạo” là một chỉ số duy nhất.

Câu hỏi 1: Hiệu suất có ảnh hưởng đến việc thu thập dữ liệu không?

Kết quả chính:

• Thời gian từ khi xuất bản đến yêu cầu thu thập dữ liệu đầu tiên.
• Số lượng yêu cầu thu thập dữ liệu mỗi trang mỗi ngày.
• Thời gian giữa các lần thu thập lại thành công.
• Số lượng trang được thu thập dữ liệu trên mỗi 1.000 trang đã xuất bản.
• Tỷ lệ tìm nạp thành công.
• Tỷ lệ lỗi máy chủ và phản hồi giới hạn tốc độ.
• Thời gian từ khi xuất bản đến khi lập chỉ mục.

Câu hỏi 2: Hiệu suất có ảnh hưởng đến việc chọn trích dẫn không?

Kết quả chính:

• Tỷ lệ phần trăm các truy vấn đã thử nghiệm tạo ra một trích dẫn rõ ràng.
• Tỷ lệ trích dẫn trên mỗi trang đủ điều kiện.
• Tỷ lệ trích dẫn trong một truy vấn.
• Tỷ lệ phần trăm các trang được truy xuất trở thành trích dẫn rõ ràng.
• Sự bền vững của trích dẫn theo thời gian.
• Tỷ lệ trích dẫn theo hệ thống trí tuệ nhân tạo.

Những kết quả này phải được tách biệt theo nhà cung cấp. Một tổng quan AI của Google, kết quả tìm kiếm ChatGPT, câu trả lời Microsoft Copilot, câu trả lời Perplexity và phản hồi tìm kiếm Claude có thể sử dụng các chỉ mục, trình thu thập dữ liệu, hệ thống xếp hạng và lịch làm mới khác nhau.

Thiết kế thí nghiệm

1. Xây dựng một tập hợp trang được kiểm soát

Sử dụng một tập hợp trang đủ lớn để tạo ra dữ liệu thu thập và trích dẫn có ý nghĩa.

Một thiết kế ban đầu thực tế sẽ bao gồm:

• 240 đến 800 trang.
• Ít nhất 20 trang trên mỗi mẫu trang.
• Ba đến năm danh mục nội dung.
• Sự kết hợp giữa các trang evergreen và các trang được cập nhật thường xuyên.
• Số lượng trang bằng nhau trong mỗi nhóm xử lý.

Mỗi trang nên có:

• Cấu trúc HTML tương tự.
• Độ dài nội dung tương tự.
• Cùng một hệ thống xuất bản.
• Cùng một mẫu liên kết nội bộ.
• Cùng một quy tắc chính tắc.
• Cùng một cách xử lý sitemap.
• Cùng một quyền robots.txt.
• Một chủ đề độc đáo, hữu ích.

Không tạo hàng trăm trang mỏng hoặc gần trùng lặp chỉ cho thí nghiệm. Hướng dẫn của Google cảnh báo rằng các URL trùng lặp và giá trị thấp có thể lãng phí tài nguyên thu thập dữ liệu và giảm hiệu quả của một trang web. (developers.google.com)

Thiết kế cặp phù hợp rất hữu ích. Ví dụ, ghép các trang có sự tương tự về:

• Độ dài nội dung.
• Nhu cầu về chủ đề.
• Tần suất cập nhật.
• Số lượng liên kết nội bộ.
• Số lượng liên kết ngoài.
• Lưu lượng truy cập lịch sử.
• Vị trí xếp hạng tìm kiếm.

Sau đó đặt một trang từ mỗi cặp vào nhóm kiểm soát và trang còn lại vào nhóm xử lý.

2. Sử dụng thiết kế xử lý giai thừa

Các xử lý hiệu suất chính nên được kiểm tra độc lập và cùng nhau.

Điều này tạo ra một thí nghiệm có kiểm soát cho ba tối ưu hóa được yêu cầu:

• HTTP/3.
• Lưu trữ cạnh của mạng phân phối nội dung.
• Nén hình ảnh.

Xử lý độ ổn định bố cục là cần thiết vì ba tối ưu hóa đầu tiên không đáng tin cậy trong việc tách biệt Cumulative Layout Shift. Nén hình ảnh có thể làm giảm Largest Contentful Paint mà không làm thay đổi độ ổn định bố cục chút nào.

Tại sao HTTP/3 cần phép đo riêng

HTTP/3 sử dụng giao thức truyền tải QUIC và cung cấp các luồng độc lập, có thể tránh được tình trạng chặn đầu dòng ở cấp độ truyền tải được tìm thấy trong HTTP/2 qua TCP. Lợi ích của nó phụ thuộc vào việc máy khách hoặc trình thu thập dữ liệu có thực sự thương lượng HTTP/3 hay không. (rfc-editor.org)

Do đó, hãy ghi lại giao thức đã thương lượng cho mỗi yêu cầu:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Đừng cho rằng việc bật HTTP/3 có nghĩa là mọi trình thu thập dữ liệu đều sử dụng nó. Nếu Googlebot, OAI-SearchBot hoặc một trình thu thập dữ liệu khác tiếp tục sử dụng HTTP/2, HTTP/3 không thể ảnh hưởng đến các yêu cầu của trình thu thập dữ liệu đó.

Tại sao việc lưu trữ cạnh nên được kiểm tra cẩn thận

Mạng phân phối nội dung (CDN) có thể giảm thời gian phản hồi byte đầu tiên bằng cách phục vụ nội dung gần hơn với người yêu cầu. Nó cũng có thể giảm số lượng yêu cầu đến máy chủ gốc. (web.dev)

Kiểm tra ít nhất ba trạng thái bộ nhớ đệm:

1. Bộ nhớ đệm lạnh — Cạnh phải liên hệ với nguồn gốc.
2. Bộ nhớ đệm ấm — Cạnh phục vụ trang mà không liên hệ với nguồn gốc.
3. Bộ nhớ đệm được xác thực lại — Cạnh hoặc trình thu thập dữ liệu sử dụng giá trị ETag hoặc Last-Modified và nhận phản hồi 304 Not Modified.

Google đặc biệt khuyến nghị việc lưu trữ HTTP hiệu quả và hỗ trợ việc sử dụng các phản hồi 304 Not Modified để giảm xử lý và băng thông không cần thiết. (developers.google.com)

Không cho phép bộ nhớ đệm phục vụ nội dung cũ hoặc không chính xác cho trình thu thập dữ liệu. Ghi lại:

• Lỗi hoặc thành công của bộ nhớ đệm.
• Tuổi của bộ nhớ đệm.
• Vị trí cạnh.
• Thời gian phản hồi nguồn gốc.
• Phiên bản nội dung.
• Mã trạng thái.
• Tiêu đề xác thực.

Tại sao nén ảnh nên gắn liền với Largest Contentful Paint

WebP và AVIF thường cung cấp khả năng nén tốt hơn các định dạng hình ảnh cũ hơn. Hình ảnh nhỏ hơn có thể giảm thời gian truyền tải và có thể cải thiện Largest Contentful Paint khi hình ảnh là yếu tố Largest Contentful Paint. (web.dev)

Bài kiểm tra nên sử dụng:

• Cùng kích thước hình ảnh.
• Cùng mục tiêu chất lượng hình ảnh.
• Hình ảnh srcset thích ứng.
• Một định dạng hiện đại với một phương án dự phòng phù hợp.
• Các giá trị width và height rõ ràng.
• Không tải chậm cho hình ảnh Largest Contentful Paint.
• Một URL hình ảnh hiển thị trong HTML ban đầu.

Chỉ riêng nén hình ảnh có thể không cải thiện Largest Contentful Paint nếu sự chậm trễ thực sự đến từ JavaScript hoặc việc phát hiện tài nguyên muộn. Hướng dẫn hiệu suất của Google lưu ý rằng việc giảm thời gian tải xuống hình ảnh có thể đơn giản là chuyển sự chậm trễ sang một phần khác của trang nếu yếu tố Largest Contentful Paint được tiết lộ muộn. (web.dev)

3. Chạy thử nghiệm đủ lâu

Một thử nghiệm ngắn có thể bỏ lỡ các tác động của việc lên lịch thu thập dữ liệu và làm mới chỉ mục.

Một thiết kế thực tế là:

• Hai tuần đo lường cơ sở.
• Sáu đến mười hai tuần đo lường xử lý.
• Một giai đoạn đảo ngược hoặc chéo cuối cùng nếu có thể.

Đối với một thử nghiệm chéo, hãy chuyển đổi các xử lý giữa các nhóm trang phù hợp. Nếu hiệu ứng hiệu suất biến mất khi loại bỏ xử lý, kết quả sẽ mạnh hơn so với so sánh đơn giản trước và sau.

Dữ liệu trường Core Web Vitals nên được đánh giá trong một khoảng thời gian thích hợp. Báo cáo Trải nghiệm người dùng Chrome sử dụng tổng hợp 28 ngày luân phiên, vì vậy nó không được thiết kế để hiển thị những thay đổi tức thì sau khi triển khai. (developer.chrome.com)

4. Đo lường toàn bộ quần thể crawler

Không coi tất cả lưu lượng truy cập tự động là một nhóm.

Tối thiểu, hãy tách biệt:

Các trình thu thập dữ liệu tìm kiếm

• Googlebot.
• Bingbot.

Các trình thu thập dữ liệu tìm kiếm trí tuệ nhân tạo

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

Các trình tìm nạp do người dùng yêu cầu

• Perplexity-User.
• Claude-User.
• Các trình tìm nạp người dùng ChatGPT nếu có thể nhận dạng.

Các trình thu thập dữ liệu đào tạo

• GPTBot.
• ClaudeBot.
• Các điều khiển Google-Extended.

Các trình thu thập dữ liệu đào tạo không nên được sử dụng làm đại diện cho các trích dẫn tìm kiếm trí tuệ nhân tạo. Anthropic, OpenAI và Google phân biệt giữa các trình thu thập dữ liệu được sử dụng để đào tạo, tìm kiếm hoặc truy xuất theo yêu cầu của người dùng. Google cũng tuyên bố rằng Google-Extended không ảnh hưởng đến việc đưa vào hoặc xếp hạng trong Google Tìm kiếm. (help.openai.com)

Perplexity cũng tương tự phân biệt giữa PerplexityBot, hỗ trợ lập chỉ mục tìm kiếm và Perplexity-User, có thể truy xuất một trang để phản hồi yêu cầu của người dùng. (docs.perplexity.ai)

Xác minh danh tính trình thu thập dữ liệu bằng cách sử dụng các dải IP đã xuất bản hoặc DNS ngược nơi nhà cung cấp hỗ trợ. Chuỗi user-agent có thể bị sao chép bởi các trình thu thập dữ liệu không liên quan. Google đặc biệt cảnh báo rằng chuỗi user-agent của Googlebot có thể bị giả mạo. (developers.google.com)

Các chỉ số cần thu thập

Các chỉ số hiệu suất

Thu thập cả dữ liệu phòng thí nghiệm và dữ liệu người dùng thực:

• Thời gian phản hồi byte đầu tiên.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Tổng trọng lượng trang.
• Kích thước HTML ban đầu.
• Kích thước truyền tải hình ảnh.
• Số lượng yêu cầu.
• Thời gian dành cho việc xử lý máy chủ.
• Thời gian chờ đợi tài nguyên Largest Contentful Paint.
• Giao thức HTTP.
• Trạng thái bộ nhớ đệm.

Google khuyến nghị mục tiêu thời gian phản hồi byte đầu tiên khoảng 800 mili giây hoặc ít hơn, nhưng bản thân thời gian phản hồi byte đầu tiên không phải là Core Web Vital. (web.dev)

Các ngưỡng "tốt" hiện tại của Core Web Vitals ở phân vị thứ 75 là:

• Largest Contentful Paint: 2,5 giây hoặc ít hơn.
• Cumulative Layout Shift: 0,1 hoặc ít hơn.
• Interaction to Next Paint: 200 mili giây hoặc ít hơn. (web.dev)

Các chỉ số thu thập dữ liệu

Đối với mỗi yêu cầu trình thu thập dữ liệu đã được xác minh, hãy ghi lại:

text timestamp url user_agent verified_bot source_ip http_protocol status_code response_time time_to_first_byte bytes_sent cache_status edge_location etag last_modified referrer

Tính toán:

text crawl_requests_per_url_day successful_fetch_rate 5xx_rate 429_rate median_recrawl_interval p75_recrawl_interval publication_to_first_fetch publication_to_first_index

Các chỉ số trích dẫn trí tuệ nhân tạo

Sử dụng một tập hợp các truy vấn cố định trên mỗi nền tảng. Tập hợp truy vấn nên bao gồm:

• Các câu hỏi thực tế trực tiếp.
• Các câu hỏi so sánh.
• Các câu hỏi "tốt nhất" hoặc khuyến nghị.
• Các câu hỏi nhạy cảm với sự mới mẻ.
• Các câu hỏi mà trang được thử nghiệm là câu trả lời mạnh nhất.
• Các câu hỏi mà trang được thử nghiệm có liên quan nhưng không nổi trội.

Đối với mỗi truy vấn, hãy ghi lại:

text engine model or experience timestamp location device query pages shown as sources page citation order whether the tested page was cited whether the tested page was retrieved but not cited answer text hash

Lặp lại các truy vấn vì câu trả lời của trí tuệ nhân tạo có thể thay đổi. Sử dụng một lịch trình cố định, chẳng hạn như ba lần mỗi tuần, và ghi lại những thay đổi trong công cụ hoặc mô hình.

Công cụ Quản trị trang web Bing của Microsoft hiện cung cấp báo cáo Hiệu suất Trí tuệ nhân tạo hiển thị các trang được trích dẫn, các truy vấn làm nền tảng và xu hướng trích dẫn trên các trải nghiệm trí tuệ nhân tạo được hỗ trợ của Microsoft. Microsoft cảnh báo rằng dữ liệu được tổng hợp, lấy mẫu và mang tính quan sát; nó không thể chứng minh rằng một thay đổi trang cụ thể đã gây ra thay đổi trích dẫn. (bing.com)

Google cũng bắt đầu triển khai các báo cáo hiệu suất trí tuệ nhân tạo tạo sinh chuyên dụng trong Search Console vào tháng 6 năm 2026. Các báo cáo này ban đầu chỉ có sẵn cho một số trang web nhất định, vì vậy quyền truy cập có thể khác nhau. (developers.google.com)

Phân tích thống kê

Tần suất thu thập dữ liệu

Sử dụng mô hình đếm hiệu ứng hỗn hợp, chẳng hạn như mô hình nhị thức âm:

text crawl_count ~ treatment + time_to_first_byte + page_age + update_frequency + sitemap_status + internal_links + server_errors + (1 | page) + (1 | crawler)

Các hiệu ứng trang và trình thu thập dữ liệu quan trọng vì một số trang tự nhiên nhận được nhiều sự chú ý hơn các trang khác, và các trình thu thập dữ liệu khác nhau có lịch trình khác nhau.

Khám phá và lập chỉ mục

Sử dụng phân tích sống sót cho:

• Thời gian từ khi xuất bản đến lần tìm nạp đầu tiên.
• Thời gian từ khi xuất bản đến lần lập chỉ mục đầu tiên.
• Thời gian từ khi cập nhật đến khi thu thập lại.

Kết quả chính không đơn giản là liệu một trang có cuối cùng được thu thập dữ liệu hay không. Mà là liệu xử lý có làm giảm thời gian cần thiết để trang được tìm thấy và xử lý hay không.

Chọn trích dẫn trí tuệ nhân tạo

Sử dụng mô hình logistic phân cấp:

text citation_present ~ treatment + time_to_first_byte + largest_contentful_paint + cumulative_layout_shift + indexed_status + search_visibility + content_freshness + page_authority + (1 | query) + (1 | engine) + (1 | page)

Chạy hai mô hình riêng biệt:

1. Mô hình truy xuất — Trang có được truy xuất hoặc hiển thị dưới dạng ứng cử viên không?
2. Mô hình trích dẫn — Nếu được truy xuất, trang có được trích dẫn rõ ràng không?

Sự phân biệt này là cần thiết. Một cải thiện hiệu suất làm tăng khả năng thu thập dữ liệu nhưng không làm tăng khả năng truy xuất thì không phải là hiệu ứng trích dẫn trí tuệ nhân tạo. Một cải thiện hiệu suất làm tăng khả năng truy xuất nhưng không làm tăng trích dẫn cho thấy trang đang được xem xét nhưng bị loại trong quá trình chọn nguồn.

Những phát hiện dự kiến

Đây là các giả thuyết làm việc, không phải kết quả thử nghiệm đã được khẳng định.

Giả thuyết 1: Time to first byte sẽ có tác động rõ ràng nhất đến việc thu thập dữ liệu

Mong đợi một mối quan hệ tích cực giữa thời gian phản hồi byte đầu tiên thấp hơn và khả năng thu thập dữ liệu khi:

• Trang web có nhiều trang.
• Các trang thay đổi thường xuyên.
• Máy chủ gốc chậm hoặc quá tải.
• Trang web trả về các phản hồi 5xx hoặc 429.
• Trình thu thập dữ liệu dành thời gian đáng kể để chờ phản hồi.

Mong đợi ít tác động có thể đo lường được trên một trang web nhỏ với nhu cầu thu thập dữ liệu thấp.

Giả thuyết 2: Largest Contentful Paint sẽ quan trọng thông qua kết xuất và phân phối tài nguyên

Mong đợi Largest Contentful Paint thấp hơn sẽ hữu ích khi:

• Trang phụ thuộc vào kết xuất trình duyệt.
• Nội dung quan trọng nằm sau JavaScript.
• Hình ảnh hoặc biểu định kiểu lớn được yêu cầu để lập chỉ mục.
• Trình thu thập dữ liệu tìm nạp nhiều tài nguyên trang.
• Xử lý chậm hơn tạo ra lỗi hết thời gian chờ hoặc kết xuất không đầy đủ.

Mong đợi một mối quan hệ yếu khi văn bản quan trọng của trang đã có trong HTML ban đầu.

Giả thuyết 3: Cumulative Layout Shift sẽ có ít ảnh hưởng trực tiếp

Mong đợi không có mối quan hệ trực tiếp có ý nghĩa giữa Cumulative Layout Shift và tần suất thu thập dữ liệu hoặc tỷ lệ trích dẫn sau khi kiểm soát cấu trúc trang và hành vi JavaScript.

Nếu Cumulative Layout Shift dường như dự đoán các trích dẫn, hãy điều tra xem nó có đang đóng vai trò là đại diện cho:

• Kết xuất phía máy khách.
• Chèn nội dung muộn.
• Quảng cáo không ổn định.
• Văn bản bị ẩn hoặc trì hoãn.
• HTML được cấu trúc kém.

Giả thuyết 4: Chỉ riêng tốc độ sẽ không tạo ra nhiều trích dẫn trí tuệ nhân tạo hơn

Các yếu tố dự đoán mạnh nhất về việc chọn trích dẫn có khả năng vẫn là:

• Mức độ liên quan đến truy vấn.
• Chất lượng nội dung.
• Câu trả lời rõ ràng.
• Sự mới mẻ.
• Quyền hạn và sự tin cậy.
• Điều kiện đủ để lập chỉ mục tìm kiếm.
• Hạng truy xuất.
• Liệu trang có trực tiếp hỗ trợ tuyên bố đang được đưa ra hay không.

Hướng dẫn của Google nhấn mạnh nội dung hữu ích, đáng tin cậy, lấy con người làm trung tâm và cho biết các tính năng tìm kiếm trí tuệ nhân tạo dựa trên các hệ thống tìm kiếm và lập chỉ mục hiện có. (developers.google.com)

Ngân sách hiệu suất được điều chỉnh cho việc truy xuất trí tuệ nhân tạo

Sau đây là ngân sách hoạt động được đề xuất. Đây không phải là công thức xếp hạng trí tuệ nhân tạo đã xuất bản.

Tài liệu hiện tại của Google cho biết Googlebot tìm nạp 2 megabyte đầu tiên của một tệp được hỗ trợ và tìm nạp các tập lệnh và biểu định kiểu bên ngoài một cách riêng biệt. Nó cũng khuyến nghị đặt siêu dữ liệu và dữ liệu có cấu trúc quan trọng sớm trong HTML. (developers.google.com)

Khuyến nghị triển khai

HTTP/3

Sử dụng HTTP/3 khi nó được nhà cung cấp dịch vụ lưu trữ và mạng phân phối nội dung (CDN) hỗ trợ.

Đo lường:

• Tỷ lệ thương lượng HTTP/3.
• Tỷ lệ dự phòng HTTP/2.
• Thời gian thiết lập kết nối.
• Thời gian phản hồi byte đầu tiên.
• Hiệu suất theo khu vực địa lý.
• Hiệu suất theo trình thu thập dữ liệu.

Không coi HTTP/3 là một tối ưu hóa tìm kiếm hoặc trí tuệ nhân tạo được đảm bảo. Đó là một cải tiến truyền tải chỉ có thể giúp các máy khách sử dụng nó.

Lưu trữ cạnh của Mạng phân phối nội dung

Đối với các trang công khai, không cá nhân hóa:

• Đặt các quy tắc Cache-Control rõ ràng.
• Sử dụng bộ nhớ đệm có thời gian tồn tại dài cho các tài sản tĩnh có phiên bản.
• Sử dụng bộ nhớ đệm ngắn nhưng hữu ích cho HTML được cập nhật thường xuyên.
• Tránh phân mảnh bộ nhớ đệm từ các tham số truy vấn không cần thiết.
• Giữ lại các URL chính tắc.
• Hỗ trợ ETag và Last-Modified.
• Kiểm tra trạng thái bộ nhớ đệm lạnh, ấm và đã được xác thực lại.
• Xác nhận rằng các yêu cầu của trình thu thập dữ liệu nhận được cùng nội dung quan trọng như các yêu cầu của con người.

Mạng phân phối nội dung nên giảm độ trễ mà không tạo ra các phiên bản trang cũ, không nhất quán hoặc dành riêng cho bot.

Nén hình ảnh

Đối với hình ảnh:

• Sử dụng AVIF hoặc WebP khi chất lượng hình ảnh chấp nhận được.
• Cung cấp kích thước hình ảnh thích ứng.
• Không phục vụ hình ảnh kích thước máy tính để bàn cho màn hình di động nhỏ.
• Không tải chậm hình ảnh Largest Contentful Paint.
• Bao gồm kích thước hình ảnh.
• Đặt hình ảnh Largest Contentful Paint trong HTML ban đầu.
• Chỉ sử dụng fetchpriority="high" khi thích hợp.
• Giữ các giải thích quan trọng bằng văn bản thay vì chỉ nhúng chúng vào hình ảnh.

Nén hình ảnh có giá trị nhất khi hình ảnh là yếu tố Largest Contentful Paint. Nó sẽ không khắc phục một trang mà sự chậm trễ chính đến từ kết xuất máy chủ hoặc thực thi JavaScript. (web.dev)

Độ ổn định bố cục

Để giảm Cumulative Layout Shift:

• Đặt các thuộc tính chiều rộng và chiều cao trên hình ảnh.
• Dành không gian cho quảng cáo.
• Dành không gian cho video nhúng và nội dung xã hội.
• Tránh chèn biểu ngữ phía trên văn bản hiện có.
• Sử dụng các chiến lược tải phông chữ ổn định.
• Tránh thay thế các khối lớn nội dung được kết xuất từ máy chủ sau khi tải trang.

Những thay đổi này cải thiện trải nghiệm người dùng ngay cả khi chúng không có tác động đáng kể đến việc thu thập dữ liệu hoặc trích dẫn. (web.dev)

Công cụ và Giám sát

Công cụ hiệu suất

Sử dụng:

• Báo cáo Trải nghiệm Người dùng Chrome cho Core Web Vitals của người dùng thực.
• Giao diện lập trình ứng dụng (API) của Báo cáo Trải nghiệm Người dùng Chrome để thu thập dữ liệu trường tự động.
• PageSpeed Insights cho các cuộc kiểm tra phòng thí nghiệm và dữ liệu trường.
• Lighthouse cho các thử nghiệm phòng thí nghiệm có thể lặp lại.
• Lighthouse Continuous Integration cho ngân sách hiệu suất yêu cầu kéo (pull-request).
• WebPageTest cho các thử nghiệm đa vị trí, trạng thái bộ nhớ đệm và so sánh giao thức.
• Chrome DevTools để gỡ lỗi Largest Contentful Paint và thay đổi bố cục.
• Thư viện JavaScript web-vitals để giám sát người dùng thực.

API Báo cáo Trải nghiệm Người dùng Chrome cung cấp dữ liệu trường tổng hợp cấp trang và cấp nguồn gốc, bao gồm Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint và thời gian phản hồi byte đầu tiên thử nghiệm. (developer.chrome.com)

Lighthouse Continuous Integration có thể chạy kiểm tra hiệu suất trên mỗi lần thay đổi mã và làm lỗi bản dựng khi vượt quá ngân sách. (github.com)

Giám sát trình thu thập dữ liệu

Sử dụng nhật ký máy chủ, nhật ký cạnh và một tập hợp nhỏ các thăm dò tổng hợp.

Ví dụ thăm dò:

bash curl --http3 -sS -o /dev/null -D - \ -w 'status=%{http_code}
http_version=%{http_version}
namelookup=%{time_namelookup}
connect=%{time_connect}
starttransfer=%{time_starttransfer}
total=%{time_total}
size=%{size_download}
' \ -A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \ https://example.com/page

Chạy cùng một thử nghiệm với:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Một user-agent trình duyệt thông thường.

Bài kiểm tra nên xác minh:

• Mã trạng thái.
• Quyền robots.
• Tiêu đề phản hồi.
• Nội dung HTML.
• Phiên bản HTTP.
• Trạng thái bộ nhớ đệm.
• Thời gian phản hồi.
• Liệu văn bản quan trọng có xuất hiện mà không cần JavaScript không.

Giám sát tìm kiếm và lập chỉ mục

Sử dụng:

• Thống kê thu thập dữ liệu của Google Search Console.
• Báo cáo lập chỉ mục trang của Google Search Console.
• Kiểm tra URL của Google Search Console.
• Dữ liệu sitemap của Google Search Console.
• Báo cáo trí tuệ nhân tạo tạo sinh của Google Search Console khi có sẵn.
• Yêu cầu thu thập dữ liệu và các trang được lập chỉ mục của Bing Webmaster Tools.
• Hiệu suất trí tuệ nhân tạo của Bing Webmaster Tools.
• Kiểm tra sitemap và lastmod hàng ngày.

API Search Console có thể truy xuất dữ liệu hiệu suất theo trang, truy vấn, ngày, thiết bị và giao diện tìm kiếm, tuân theo các giới hạn dữ liệu của nó. (developers.google.com)

Giám sát trích dẫn

Tạo một bảng điều khiển trích dẫn chứa 50 đến 200 truy vấn ổn định cho mỗi chủ đề. Chạy bảng điều khiển theo một lịch trình cố định và ghi lại:

• Liệu nền tảng có tìm kiếm không.
• Nguồn nào đã xuất hiện.
• Liệu URL đã thử nghiệm có được trích dẫn không.
• Thứ tự trích dẫn.
• Ngày và giờ trả lời.
• Liệu trang có thay đổi không.
• Liệu mô hình hoặc trải nghiệm tìm kiếm có thay đổi không.

Không so sánh số lượng trích dẫn từ các hệ thống khác nhau như thể chúng tương đương nhau. Microsoft tuyên bố rằng hoạt động trích dẫn không phải là điểm xếp hạng, điểm thẩm quyền, số đo lưu lượng truy cập hoặc điểm chất lượng. (bing.com)

Quy tắc cảnh báo

Tạo cảnh báo cho:

• Thời gian phản hồi byte đầu tiên tăng hơn 25 phần trăm.
• Largest Contentful Paint vượt quá 2,5 giây ở phân vị thứ 75.
• Cumulative Layout Shift vượt quá 0,1.
• Sự gia tăng bền vững trong phản hồi 5xx hoặc 429.
• Tỷ lệ thành công của trình thu thập dữ liệu giảm.
• Thay đổi robots.txt.
• Lỗi sitemap.
• Số lượng trang được lập chỉ mục giảm đột ngột.
• Số lượng trích dẫn trí tuệ nhân tạo giảm đột ngột trên một số nền tảng.
• Thay đổi trong khối lượng trích dẫn chỉ ảnh hưởng đến một nền tảng.

Sự sụt giảm trích dẫn ảnh hưởng đến một nền tảng có thể do thay đổi mô hình, chỉ mục, truy vấn hoặc sản phẩm chứ không phải do vấn đề hiệu suất trang. Microsoft đặc biệt cảnh báo rằng xu hướng trích dẫn mang tính quan sát và có thể thay đổi do cập nhật nội dung, nhu cầu người dùng và thay đổi hệ thống hoặc mô hình. (bing.com)

Kết luận cuối cùng

Kết luận hợp lý nhất là:

Các trang nhanh hơn có thể cải thiện hiệu quả thu thập dữ liệu, đặc biệt khi độ trễ máy chủ, kích thước tài nguyên, lỗi hoặc chậm trễ kết xuất là các yếu tố hạn chế. Nhưng hiện tại không có bằng chứng mạnh mẽ nào cho thấy Core Web Vitals thấp hơn trực tiếp khiến các hệ thống trí tuệ nhân tạo chọn một trang làm trích dẫn.

Chuỗi nguyên nhân dự kiến là:

text Độ trễ thấp hơn → dung lượng máy chủ tốt hơn → ít lỗi hoặc tìm nạp bị trì hoãn hơn → khám phá và xử lý nhanh hơn → cơ hội được lập chỉ mục và truy xuất được cải thiện → có thể tăng trích dẫn

Bước cuối cùng vẫn chưa chắc chắn vì việc chọn trích dẫn phụ thuộc vào mức độ liên quan, chất lượng, sự mới mẻ, thẩm quyền, ý định truy vấn, thứ hạng truy xuất và hành vi của từng hệ thống trí tuệ nhân tạo.

Đối với hầu hết các trang web, chiến lược hiệu suất đúng đắn do đó không phải là “tối ưu hóa cho các trích dẫn trí tuệ nhân tạo” một cách riêng biệt. Đó là:

1. Giữ nội dung quan trọng có sẵn trong HTML ban đầu.
2. Giữ thời gian phản hồi byte đầu tiên ổn định.
3. Sử dụng bộ nhớ đệm cạnh cho nội dung công khai.
4. Nén và ưu tiên hình ảnh quan trọng.
5. Ngăn chặn sự thay đổi bố cục.
6. Trả về mã trạng thái đáng tin cậy.
7. Giữ sitemaps và liên kết nội bộ cập nhật.
8. Cho phép các trình thu thập dữ liệu tìm kiếm chính xác.
9. Đo lường việc thu thập dữ liệu, lập chỉ mục, truy xuất và trích dẫn như các giai đoạn riêng biệt.

Cách tiếp cận đó tạo ra một trang web nhanh hơn cho người dùng, một trang web khỏe mạnh hơn cho các trình thu thập dữ liệu tìm kiếm và một nền tảng có thể kiểm chứng để hiểu khả năng hiển thị của trí tuệ nhân tạo.