Kết xuất phía khách hàng so với phía máy chủ

Trình duyệt tác nhân Scrapeless chạy các phiên duyệt web có thể thực thi JavaScript và hiển thị nội dung trang kết quả để trích xuất.

Nội dung trang trở thành HTML ở đâu?

Kết xuất phía máy khách so với phía máy chủ mô tả nơi nội dung ứng dụng được chuyển thành cấu trúc HTML hoặc DOM mà người dùng nhìn thấy. Kết xuất phía máy chủ tạo HTML của trang trên máy chủ cho mỗi yêu cầu. Kết xuất phía máy khách sử dụng JavaScript trong trình duyệt để xây dựng hoặc cập nhật trang sau khi các tài nguyên được tải về.

Trình duyệt vẫn thực hiện phân tích cú pháp, dàn trang và vẽ trong cả hai trường hợp. Mô hình phân tích HTML giải thích cách một phản hồi trở thành cây tài liệu. Nói rằng máy chủ kết xuất HTML không có nghĩa là máy chủ vẽ pixel trực tiếp lên màn hình của người dùng.

Các ứng dụng thực tế thường kết hợp nhiều cách tiếp cận. Tiêu đề sản phẩm có thể được gửi dưới dạng HTML do máy chủ tạo, trong khi trạng thái còn hàng được cập nhật sau một yêu cầu từ phía client và bảng đánh giá chỉ được tải khi được mở. Phân loại toàn bộ miền là SSR hoặc CSR có thể che khuất hành vi của trường cụ thể mà bạn cần.

Tính sẵn sàng của HTML và khả năng tương tác

Tính sẵn sàng về nội dung và tính sẵn sàng cho tương tác là hai mốc riêng biệt. HTML do máy chủ trả về có thể giúp một bài viết có thể đọc được trước khi mã ứng dụng liên quan tải xong. Một nút hiển thị trong HTML đó có thể vẫn cần các bộ xử lý sự kiện JavaScript trước khi nó thực hiện được hành động như dự định.

Hydration là quá trình trong đó một ứng dụng phía client gắn hành vi của nó vào phần markup được tạo từ phía server. Tùy thuộc vào ứng dụng, việc này có thể bao gồm thực thi đáng kể hoặc kích hoạt có chọn lọc các component. Đừng cho rằng chỉ cần thấy văn bản là đủ để khẳng định một form hoặc điều khiển điều hướng đã sẵn sàng.

Đối với việc render phía client, nội dung cần thiết có thể phụ thuộc vào các yêu cầu dữ liệu bổ sung và các cập nhật trạng thái. Sự kiện tải tài liệu có thể xảy ra trước khi một danh sách cụ thể được điền dữ liệu, trong khi các phân tích nền có thể tiếp tục lâu sau khi danh sách đã có thể sử dụng. Mức độ sẵn sàng nên theo sát nội dung hoặc tương tác mà bạn cần, chứ không phải một độ trễ chung được sao chép giữa các trang không liên quan.

The Mô hình Navigation Timing phân biệt các mốc điều hướng. Những mốc thời gian đó giúp chẩn đoán việc phân phối và vòng đời tài liệu, nhưng một vị từ cụ thể cho tác vụ vẫn cần xác nhận rằng các trường hoặc điều khiển liên quan có hiện diện.

Hiệu Suất Phụ Thuộc Nhiều Hơn Chỉ Nhãn Kết Xuất

Kiến trúc render phân bổ công việc giữa máy chủ và trình duyệt; nó không thiết lập một kẻ chiến thắng về hiệu năng mang tính phổ quát. Render phía máy chủ có thể làm cho nội dung sẵn có trong phản hồi ban đầu, nhưng việc tính toán ở backend và truy cập dữ liệu có thể làm chậm phản hồi đó. Render phía client có thể hỗ trợ các tương tác phong phú trong khi làm tăng lượng script và công việc thực thi cần thiết trước khi nội dung hữu ích xuất hiện.

Đo lường những gì quan trọng đối với người dùng hoặc người tiêu dùng. Đối với người đọc, việc hiển thị nội dung có ý nghĩa có thể quan trọng hơn việc mọi tiện ích tùy chọn đều đang hoạt động. Đối với một tác vụ tự động hóa, trạng thái sẵn sàng thực hiện một tương tác được cho phép có thể là mốc cần thiết. Một con số thời gian tải trang duy nhất không thể đại diện cho cả hai kết quả này.

Bộ nhớ đệm làm thay đổi phép so sánh. Các quy tắc bộ nhớ đệm HTTP áp dụng cho phản hồi dựa trên ngữ nghĩa và các header của chúng. Một trang được tạo động có thể được lưu vào bộ nhớ đệm, và một phản hồi cá nhân hóa do máy chủ render có thể cần các hạn chế. Các tài nguyên tĩnh được dùng bởi một ứng dụng render phía client cũng có thể được lưu vào bộ nhớ đệm mà không làm cho dữ liệu trực tiếp của nó trở nên tĩnh.

So sánh toàn bộ khối lượng công việc trong các điều kiện đại diện. Bao gồm thời gian phản hồi của máy chủ, tài nguyên được truyền, quá trình thực thi của trình duyệt, việc hoàn tất dữ liệu cần thiết và tương tác thành công khi áp dụng. Tránh khẳng định rằng CSR luôn chậm hơn hoặc SSR luôn rẻ hơn mà không đo chính ứng dụng phải chạy.

Trình thu thập và bộ trích xuất nhận được gì

Một bộ trích xuất HTTP thuần nhận các byte phản hồi thay vì DOM cuối cùng của trình duyệt. Nếu một trường mong muốn chỉ xuất hiện sau khi JavaScript thay đổi tài liệu, thì phân tích cú pháp phản hồi gốc không thể tiết lộ trạng thái về sau đó. Chỉ thay đổi selector không giải quyết được việc thiếu nội dung nguồn.

Bắt đầu với câu hỏi hẹp nhất: trường đó có nằm trong phản hồi không? So sánh tài liệu nhận được với công cụ kiểm tra của trình duyệt cho cùng URL và ngữ cảnh. Kiểm tra chuyển hướng, ngôn ngữ, trạng thái đồng ý và yêu cầu quyền trước khi quy kết sự khác biệt cho việc render bằng JavaScript.

Khi nội dung có trong phản hồi, việc phân tích có thể tránh được chi phí của một phiên trình duyệt. Khi nội dung phụ thuộc vào thực thi hoặc tương tác, trình duyệt có thể cung cấp trạng thái cần thiết. Phần so sánh trích xuất bằng bộ phân tích cú pháp và trình duyệt giải thích lựa chọn đó trong một quy trình JavaScript.

Scrapeless Agent Browser cung cấp một lớp thực thi trình duyệt được quản lý. Quy trình của bạn vẫn phải chọn thời điểm kiểm tra trang, xác định các trường nó chấp nhận và phân biệt nội dung vắng mặt với một lần render chưa đạt đến trạng thái yêu cầu.

SEO và Khả năng Khám phá Cần Các Kiểm Tra Riêng

Chiến lược render ảnh hưởng đến mức độ dễ dàng mà một trình thu thập có thể lấy nội dung, nhưng việc lập chỉ mục cũng phụ thuộc vào các URL có thể khám phá, quy tắc truy cập, tín hiệu canonical và quá trình xử lý của công cụ tìm kiếm. HTML từ máy chủ không đảm bảo được lập chỉ mục, và việc sử dụng JavaScript không tự động làm cho một trang trở nên vô hình với công cụ tìm kiếm.

Giữ cho nội dung chính và các liên kết có thể kiểm tra được. Một ứng dụng có thể phục vụ HTML dễ đọc nhưng lại chỉ cho phép truy cập các điểm đến quan trọng thông qua một tương tác. Ngược lại, một trang ban đầu thưa thớt có thể chứa các liên kết và dữ liệu có thể khám phá mà một trình thu thập có khả năng render sẽ xử lý về sau.

Xem lại những gì trình thu thập mục tiêu thực sự quan sát bằng cách dùng công cụ kiểm tra của nền tảng khi có thể. Giữ mã trạng thái và thông tin canonical nhất quán với trạng thái trang. Một giao diện lỗi được render bên trong một phản hồi HTTP thành công có thể gây nhầm lẫn cho cả chẩn đoán tìm kiếm và các pipeline trích xuất.

Chọn Kiến trúc hoặc Tuyến Trích xuất Theo Từng Tác Vụ

Chọn phân phối render phía máy chủ khi HTML ban đầu có ý nghĩa hỗ trợ nhu cầu nội dung và tương tác của sản phẩm. Chọn render phía client khi trạng thái và tương tác phía trình duyệt biện minh cho quá trình thực thi cần thiết. Một thiết kế lai có thể dùng HTML từ máy chủ cho trang cốt lõi và hành vi phía client cho các tính năng cần đến nó.

Đối với trích xuất, hãy viết một bảng kiểm kê trường thay vì một quy tắc cho toàn bộ domain. Ghi lại nơi mỗi trường trở nên sẵn có, trạng thái cần thiết để quan sát nó và liệu tương tác có cần thiết hay không. Một trang có thể chủ yếu được render phía máy chủ trong khi trường giá trị nhất của nó được tải phía client.

1. Kiểm tra phản hồi ban đầu để tìm các trường cần thiết.
2. So sánh DOM trong trình duyệt theo đúng ngôn ngữ và khu vực dự định.
3. Xác định sự kiện hoặc trạng thái làm cho nội dung đang thiếu xuất hiện.
4. Chọn phân tích cú pháp hoặc thực thi trình duyệt cho tập trường đó.
5. Xác nhận bản ghi cuối cùng và lưu lại ngữ cảnh quan sát.

Cân đối việc dùng trình duyệt với tỷ lệ tác vụ thực sự cần đến nó. So sánh giá của Scrapeless với lượng công việc phiên đã quan sát thay vì giả định mọi trang đều cần cùng một tuyến. Giữ lại bản ghi lỗi khi nội dung không thể truy cập được thay vì âm thầm thay thế bằng một trang khác.

Một bàn giao thực tế cũng nên mô tả trạng thái dự phòng mà bên tiêu thụ có thể chấp nhận. Nếu phần thân bài viết sẵn có nhưng một tiện ích trực tiếp thì không, một bản lưu trữ văn bản vẫn có thể được coi là đầy đủ trong khi bản ghi giám sát sản phẩm thì không. Xác định các kết quả đó trước khi triển khai để một trang render chưa hoàn chỉnh không trở thành một bản ghi dữ liệu có vẻ như thành công nhưng gây hiểu lầm.

Một Trường Kiểm Kê Có Thể Băng Qua Các Ranh Giới Render

Một trang sản phẩm có thể cung cấp tiêu đề và mô tả trong HTML từ máy chủ trong khi tải tình trạng còn hàng sau khi khách truy cập chọn một cửa hàng. Một bản lưu trữ văn bản có thể chấp nhận hai trường đầu tiên mà không cần tương tác, nhưng một báo cáo tồn kho theo cửa hàng lại cần trạng thái về sau đó. Gắn nhãn toàn bộ trang là SSR không trả lời được liệu trường tồn kho có thể quan sát được hay không.

Viết điều kiện chọn cửa hàng và tình trạng còn hàng vào yêu cầu thu thập. Giữ lại cửa hàng đã chọn cùng với giá trị để bên tiêu thụ không hiểu một kết quả địa phương thành tồn kho toàn quốc. Một phiên trình duyệt là hợp lý vì phụ thuộc vào trạng thái của trường đó, trong khi các loại trang khác có thể giữ tuyến phân tích phản hồi đơn giản hơn.

Kết luận

Render phía client so với phía máy chủ quyết định nơi nội dung được lắp ráp và các bước thực thi nào phơi bày nó. Kiểm tra riêng HTML ban đầu, quá trình hydration và trạng thái DOM về sau. Chọn tuyến trích xuất có thể quan sát các trường cần thiết, rồi xác minh tính đầy đủ trong các điều kiện thực tế của tác vụ.