Nội dung đã nằm trong HTML chưa, trước khi chọn SSR

From TaiNguyenSeo · 1:21

Show by TNSPODTOP1

Nghe ai đó nói SSR tốt cho SEO là chuyện rất dễ gặp. Nhưng đổi kiến trúc website chỉ vì một câu như vậy thì dễ tốn công vô ích. Việc cần làm trước là xem nội dung chính có nằm sẵn trong HTML phản hồi hay phải chờ JavaScript dựng lên. Tập này đi qua cách tự kiểm điều đó, những chỗ SSR vẫn có thể chậm, và cách chọn kiểu dựng theo từng loại trang. Kiểm trước, chọn sau. SSR là cách máy chủ dựng HTML trước khi gửi về trình duyệt. Lấy ví dụ một trang sản phẩm giả định. Trình duyệt gửi yêu cầu, máy chủ lấy dữ liệu, rồi trả về HTML đã có tên và mô tả sản phẩm. Với CSR, nội dung được dựng bằng JavaScript phía trình duyệt. Phản hồi ban đầu có thể chỉ có một điểm gắn ứng dụng và một đường dẫn tới tệp mã. Đây chỉ là minh họa kỹ thuật. Không phải website nào dùng React cũng trả về HTML thiếu nội dung. Cách kiểm thì khá đơn giản. Mở Chrome DevTools, chọn Network rồi tải lại trang. Chọn yêu cầu tài liệu chính, sau đó tìm tên sản phẩm trong phần Response. Thấy tên thì nội dung đã có trong phản hồi. Tiếp theo, đối chiếu với tab Elements, nơi thể hiện DOM, tức cấu trúc trang mà trình duyệt đang dùng sau mọi thay đổi. Có chữ trong Elements chưa chứng minh chữ đó nằm trong phản hồi. Ngược lại, HTML có sẵn cũng chưa chứng minh nó được dựng riêng cho từng yêu cầu. Đưa phép đối chiếu này vào checklist. Làm vậy đỡ tốn công khi trao đổi với lập trình viên. Tiếp theo là hydration. Giao diện hiện ra chưa có nghĩa thao tác đã hoạt động. Trình duyệt nhận HTML dựng sẵn rồi chạy JavaScript để gắn hành vi tương tác vào giao diện đó. Nút thêm vào giỏ có thể đã hiện, nhưng phần xử lý cú bấm vẫn chưa sẵn sàng. Nhìn được chưa đủ. Nó giống quầy hàng đã bật đèn nhưng máy tính tiền còn đang khởi động. Vì vậy hãy thử đúng thao tác người dùng cần, như mở bộ lọc, đổi lựa chọn hoặc thêm sản phẩm. Không phải trang SSR nào cũng cần hydration. Trang chỉ trình bày nội dung có thể không cần lớp này. JavaScript vẫn có thể làm trang SSR chậm. HTML dựng sẵn không xóa công việc của JavaScript. Trình duyệt còn phải tải mã phục vụ tương tác. Mã tải xong vẫn cần được phân tích và thực thi, có thể khiến luồng chính bận. Rồi đến hydration, lúc giao diện được nối với trạng thái ứng dụng. Nếu nội dung máy chủ và trình duyệt không khớp, có thể phát sinh cảnh báo hoặc buộc dựng lại giao diện. Phải đo mới biết. Nên tìm tác vụ đang giữ trình duyệt bận trước khi đề nghị chuyển kiến trúc. Còn một hiểu lầm nữa. Nơi dựng HTML không quyết định nơi chạy toàn bộ ứng dụng. Khi mở trực tiếp một địa chỉ, máy chủ có thể trả HTML đầy đủ. Sau đó ứng dụng xử lý chuyển trang phía trình duyệt mà không tải lại toàn bộ tài liệu. Biểu mẫu cũng cần xem riêng. Trình duyệt có thể kiểm tra ô nhập, còn máy chủ xác thực quyền và lưu dữ liệu. Câu hỏi hữu ích vẫn là HTML được dựng lúc nào, ở đâu, và chuyện gì xảy ra sau đó. Vậy SSR giúp SEO trong điều kiện nào. Google Search Central mô tả việc xử lý JavaScript qua các giai đoạn thu thập dữ liệu, kết xuất và lập chỉ mục trong tài liệu JavaScript SEO. Nội dung có sẵn trong HTML giảm sự phụ thuộc vào việc chạy JavaScript để đọc phần đó. Nhưng vẫn phải kiểm thêm mấy thứ. Nội dung chính có trong phản hồi và đúng với trang đang mở. Liên kết nội bộ dùng đường dẫn truy cập được, không chỉ dựa vào thao tác giao diện. Trang trả trạng thái phù hợp. Chỉ dẫn lập chỉ mục không loại trang khỏi kết quả. Đừng gom mọi lỗi vào JavaScript. Muốn xem kỹ từng điều kiện, đọc phần giải thích server side rendering theo từng điều kiện. Về tình huống chuyển sang SSR, điểm đáng giữ là mối liên hệ giữa trở ngại đọc nội dung và cách sửa, không phải nhãn công nghệ. Không suy rộng nhé. Nếu vừa chuyển SSR vừa sửa liên kết và chỉ dẫn lập chỉ mục, đừng quy hết kết quả cho SSR. Kết quả ở website này không bảo đảm lặp lại ở website khác. Thứ cần bàn giao là bằng chứng nội dung đã xuất hiện trong phản hồi. Phần đo cũng nên tách riêng. TTFB là thời gian chờ byte phản hồi đầu tiên, xem ở Network, mục Timing. LCP là lúc phần nội dung lớn nhất trong vùng nhìn xuất hiện. INP phản ánh độ trễ khi tương tác. Lighthouse kiểm bằng mô phỏng, nên cần đối chiếu với trải nghiệm thực tế. Đừng gộp chung nhé. Máy chủ trả lời sớm chưa nói được nút bấm phản hồi ra sao. Giữ cùng trang, dữ liệu, thiết bị và điều kiện mạng giữa các lần kiểm. Tách lượt có bộ nhớ đệm và lượt chưa có. Chưa có phép đối chiếu cùng điều kiện thì đừng chốt mức cải thiện. Cuối cùng là chọn theo loại trang. Bài kiến thức ít đổi hợp với tạo trang tĩnh, làm mới bản lưu khi xuất bản thay đổi. Danh mục cần cập nhật thì cân nhắc SSR hoặc trang tĩnh có cơ chế làm mới phù hợp. Khu vực tài khoản có thể dùng CSR hoặc SSR, nhưng phải tách nội dung riêng, tránh dùng chung bản lưu giữa người dùng. Đừng đổi cả website. Chỉ một nhóm trang cần sửa thì sửa nhóm đó. Nội dung đầy đủ cùng mẫu ghi kết quả đo có trên website của Tài Nguyên SEO. Bài gốc: https://tainguyenseo.com/server-side-rendering/ CÔNG TY TNHH TÀI NGUYÊN SEO Địa chỉ: BT T14-11, The Manhattan, KĐT Vinhomes Grand Park, Đường Nguyễn Xiển, Phường Long Bình, TP. Hồ Chí Minh Mã số…

More episodes of TaiNguyenSeo

More episodes

PodSearch is a free, independent podcast search engine. Read about PodSearch, the privacy policy or contact us.