Khi trao đổi với một lập trình viên của khách hàng về giới hạn thời gian render, tôi được nghe rằng Google sẽ ngừng render trang sau 5 giây. Đây là con số tôi từng gặp nhiều lần, nhưng tôi biết rõ điều đó không đúng.

Thank you for reading this post, don't forget to subscribe!

Tuy vậy, tôi hiểu con số này đến từ đâu và nghĩ nó đáng để giải thích, vì những bài kiểm tra bạn có thể đã thực hiện để chứng minh giới hạn này rất dễ bị sai lệch do cách xử lý thời gian kỳ lạ của Web Rendering Service.

Sơ lược về cách Google render trang

Khi Google thu thập dữ liệu một trang, Googlebot lấy trang ban đầu rồi chuyển HTML cho Web Rendering Service (WRS), thực chất là một phiên bản headless Chrome.

Mọi tài nguyên bổ sung cần thiết để render trang, như file CSS và JS, sẽ được hạ tầng thu thập dữ liệu tải về, đưa qua đường ống thu thập và chuyển lại cho trình duyệt headless Chrome để render.

Cách tải tài nguyên khác biệt này có lẽ là một trong những điểm khác lớn nhất giữa cách Google render trang và cách trình duyệt thông thường hoạt động. Trong trình duyệt thường, chính trình duyệt sẽ tải tài nguyên.

Nhưng có một điểm khác nữa là thời gian.

Tìm hiểu thêm: Để biết thêm về cách Google render trang, tôi khuyên bạn đọc hướng dẫn JavaScript SEO basics từ Google Search Central.

Kiểm tra giới hạn render 5 giây

Vậy hãy kiểm tra thử. Tôi tạo một trang đơn giản trì hoãn một khoảng thời gian ngẫu nhiên từ 3 đến 6 giây trước khi trả nội dung. Trang này có tại https://testing.tamethebots.com/timer.html.

Trang thực hiện vài phép đo thời gian khác nhau. Đầu tiên là một vòng lặp setInterval đếm lên mỗi giây và cập nhật trang với số giây cùng dấu thời gian.

<script> // chúng tôi cập nhật thẻ title mỗi giây let seconds = 0; setInterval(() => { seconds++; const now = new Date(); const timeString = now.toLocaleTimeString(); if (seconds === 1) { document.getElementById('first-time').innerHTML = \`Lần đầu tiên bộ đếm được cập nhật: ${now.toISOString()}\`; } document.title = \`WRS Timer - ${seconds}s - ${timeString} - \{TametheBots\} Testing Site\`; // chúng tôi cập nhật thẻ h2 có id testing-time mỗi giây document.getElementById('testing-time').innerHTML = \`Thời gian kiểm tra trong WRS - ${seconds}s - ${timeString}\`; }, 1000); </script>

Đo lường thứ hai thực hiện vài yêu cầu fetch đến một tập lệnh PHP, tập lệnh này sẽ trì hoãn ngẫu nhiên từ 3 đến 6 giây trước khi trả nội dung và thu thập thông tin thời gian:

Các yêu cầu fetch là POST để tránh vấn đề cache.

Hãy chạy thử qua công cụ URL Inspection và xem điều gì xảy ra.

Nhìn vào ảnh chụp màn hình, bạn có thể thấy vòng lặp setInterval() chạy được 5 giây và cập nhật thẻ title. Thời gian hiển thị, 10:59:37 AM, theo PST (luôn theo giờ Mountain View, tức UTC-7). Ảnh chụp thứ hai cho thấy thời điểm chạy thử là 18:59:33, theo giờ địa phương của tôi ở Anh, BST (UTC+1). Vậy bài kiểm tra chạy trong 5 giây; theo giờ UTC, bài kiểm tra chạy từ 17:59:33 đến 17:59:37, tức 5 giây.

Vậy, kết luận hợp lý sẽ là WRS có giới hạn render 5 giây, đúng không?

Bẻ cong thời gian theo ý muốn

Không hẳn. WRS xử lý thời gian theo cách riêng của nó. Thay vì dùng đồng hồ phần cứng như máy tính hay máy chủ của bạn, WRS dùng một đồng hồ ảo mà họ có thể điều khiển. Điều này có nghĩa là họ có thể tăng tốc, làm chậm, thậm chí tạm dừng thời gian cho phiên bản headless Chrome nếu muốn.

Làm sao biết 5 giây không phải là giới hạn? Bạn có nhớ các lệnh gọi API ở trên không? Chúng bị trì hoãn về phía máy chủ trong khoảng 3 đến 6 giây. Vậy tổng thời gian cho cả hai lệnh gọi API có thể nằm trong khoảng 6 đến 12 giây, dài hơn nhiều so với giới hạn 5 giây nổi tiếng kia.

Vậy mà WRS vẫn render trang và trả về nội dung thành công, điều không thể xảy ra nếu thực sự có giới hạn 5 giây.

Nhưng mốc thời gian trong kết quả nghĩa là gì?

Chúng ta thấy lệnh gọi API đầu tiên được trả về sau 5 giây, còn lệnh gọi API thứ hai được trả về sau 4 giây.

Thế nhưng, tổng thời gian báo cáo chỉ là 0,02 giây? Sao điều đó có thể xảy ra?

Bạn còn nhớ WRS dùng đồng hồ ảo không? Nó đóng băng thời gian trong lúc chờ các yêu cầu. Vậy nên 0,02 giây không phải thời gian thực tế cho các yêu cầu, mà là thời gian WRS xử lý yêu cầu và chèn kết quả vào DOM.

Điều đó được xác nhận bởi mốc Start time và End time, được tính theo UTC.

Đó là với công cụ kiểm tra, còn lập chỉ mục thực tế thì sao?

Kết quả vẫn tương tự. Trang này đã được Google lập chỉ mục, và dùng công cụ URL Inspection, chúng ta có thể thấy trang được render và lập chỉ mục đúng, với hành vi giống hệt bài kiểm tra trực tiếp.

Có một điểm khác nhỏ: khi lập chỉ mục, thời gian luôn bắt đầu từ nửa đêm UTC, dù trang được lập chỉ mục lúc 10:57:42 GMT:

Dấu thời gian cho lệnh gọi API thứ nhất và thứ hai đều là 00:00:00, tức nửa đêm UTC, và tổng thời gian là 0,02 giây, giống với bài kiểm tra trực tiếp. (Từ sau khi lập chỉ mục, tôi đã đổi định dạng dấu thời gian sang có mili giây, nên dấu thời gian trong bài kiểm tra trực tiếp và trang đã lập chỉ mục có định dạng khác nhau.)

Vậy, quá trình render kết thúc khi nào?

Chắc chắn phải có một thời điểm nào đó Google quyết định render đã hoàn tất và trang sẵn sàng để lập chỉ mục. Đây không phải giới hạn thời gian cứng, mà dựa trên việc quan sát Event Loop để xác định khi nào trang ở trạng thái rảnh và không cần render thêm nữa.

Video này của Martin Splitt, chuyên gia tư vấn tìm kiếm của Google, giải thích hành vi Event Loop này và rất đáng để xem (video được cài sẵn điểm bắt đầu phù hợp, nhưng tôi khuyên bạn nên xem toàn bộ nếu có thời gian):

Nhưng chắc chắn vẫn có một giới hạn chứ?

WRS dĩ nhiên có giới hạn, nó không thể render mãi mãi. Hãy tưởng tượng một trang có vòng lặp vô hạn, hoặc một trang liên tục tải thêm dữ liệu, Event Loop sẽ không bao giờ rảnh và trang sẽ không bao giờ render xong.

Để mô phỏng điều này, tôi tạo một trang liên tục tải dữ liệu từ máy chủ và không bao giờ dừng. Mỗi lần gọi đều trì hoãn phía máy chủ 3 giây. Trang này có tại https://testing.tamethebots.com/longrun-timer.html.

Kết quả kiểm tra cho thấy điểm cắt, trong trường hợp này, khá dao động, nhưng các công cụ kiểm tra trực tiếp chủ yếu cắt sau 16 – 18 lần gọi, tức 48 – 54 giây.

Việc lập chỉ mục thực tế của trang này cho thấy trang vẫn được lập chỉ mục, nhưng chỉ có 10 lần gọi, tức 30 giây.

Nhưng một lần nữa, con số này có vẻ khá dao động, và dĩ nhiên, không người dùng thực tế nào chờ 30 giây để trang tải, nên đây không phải tình huống ngoài đời thực.

Sự kiên nhẫn của WRS không phải là vô hạn, nhưng nó lớn hơn 5 giây, và lớn hơn rất nhiều so với sự kiên nhẫn của người dùng trung bình.

Đọc thêm

Tôi rất khuyên bạn đọc bài viết xuất sắc của Tony McCreath với những hiểu biết rất thú vị về cách WRS xử lý thời gian và nhiều thứ khác: Tony’s Theory of Googlebot Relativity.

Bài viết được biên dịch và tổng hợp từ bài gốc.