Ngiêm cấm sử đụng PROXY và VPS vào mục đích trái pháp luật bạn sẽ phải chịu toàn bộ trách nhiệm trước pháp luật khi sử dụng dịch vụ của chúng tôi tks!
Zyte API browser actions: thao tác, chờ đúng và kiểm DOM

Zyte API browser actions: thao tác, chờ đúng và kiểm DOM

Chuyên viên Kỹ thuật ProxyVN 02-17-2026 Đang tính... phút đọc

Zyte API browser actions là danh sách thao tác mà trình duyệt của Zyte thực hiện trên trang trước khi trả về HTML đã render. Ví dụ là bấm nút xem thêm, cuộn xuống cuối trang, chờ một phần tử xuất hiện. Không có thao tác đúng, HTML trả về chỉ là trạng thái ban đầu của trang. Có thao tác mà không chờ đúng điều kiện, HTML vẫn có thể thiếu nội dung. ProxyVN đọc tài liệu browser của Zyte ngày 03/11/2026, gọi API thật với khóa giả, rồi chạy cùng chuỗi thao tác trên một trang fixture bằng trình duyệt Edge headless cục bộ để thấy DOM thay đổi ra sao. Bài ghi rõ phần nào là Zyte, phần nào là mô phỏng.

Zyte API browser actions: mục tiêu và phạm vi không lặp

Phần này chốt bài toán, đầu ra và giới hạn.

Bài toán

Một trang danh sách sản phẩm chỉ hiện ba mục đầu, phần còn lại tải khi bấm nút Xem thêm. Bảng giá đầy đủ chỉ xuất hiện khi cuộn xuống cuối trang. Gọi Zyte API với browserHtml mà không có thao tác thì chỉ nhận ba mục. Câu hỏi là dùng thao tác nào, chờ điều kiện gì, và làm sao biết thao tác đã chạy đúng.

Đầu ra nghiệm thu

Đầu ra gồm một trang fixture cần tương tác, các chuỗi thao tác dạng JSON theo cú pháp của Zyte. Kèm theo là kết quả chứng minh trạng thái DOM thay đổi: số mục trong danh sách, nội dung ô trạng thái, sự có mặt của bảng giá tải chậm.

Không phải bài Playwright qua proxy

Lab dùng Playwright để chạy trang fixture, nhưng bài không hướng dẫn cấu hình Playwright với proxy. Playwright chỉ đóng vai trình duyệt thay cho Zyte trong môi trường không có tài khoản. Trọng tâm là logic của chuỗi thao tác và điều kiện chờ, áp dụng được cho Zyte.

Không đặt mục tiêu né chặn

Thao tác trình duyệt ở đây dùng để lấy nội dung cần tương tác mới hiện ra trên trang được phép thu thập. Bài không bàn kỹ thuật vượt cơ chế chống bot. Zyte có tài liệu riêng cho chuyện đó, nằm ngoài phạm vi bài.

Giới hạn của lab

Lab không có tài khoản Zyte. Gọi API thật với khóa giả nhận HTTP 401 dạng problem JSON. Chuỗi thao tác được chạy bằng một bộ chạy tự viết trên Playwright 1.64.1 với Edge headless, đọc đúng cú pháp action, selector của Zyte, và mô phỏng giới hạn thời gian theo mô tả tài liệu. Kết quả action trong lab do bộ chạy này tạo, không phải phản hồi của Zyte.

Vì sao cần trình duyệt

Trang trong lab dựng danh sách bằng JavaScript. Một request HTTP thường chỉ nhận mã HTML gốc với thẻ ul rỗng và đoạn script. Không có trình duyệt chạy script, không có mục nào trong danh sách. browserHtml giải quyết phần render, còn actions giải quyết phần nội dung chỉ hiện sau tương tác.

Ai nên đọc

Người dùng Zyte API cho trang cần tương tác và nhận HTML thiếu nội dung. Người đang viết chuỗi thao tác đầu tiên và chưa rõ nên chờ cái gì. Người cần giải thích cho đồng đội vì sao thao tác báo thành công mà dữ liệu vẫn thiếu.

Dùng browser actions của Zyte API trên trang fixture để lấy trạng thái sau thao tác với Zyte API browser actions

Phần này tóm tắt tài liệu chính thức.

browserHtml

Theo trang Browser automation trong tài liệu Zyte, browserHtml là HTML biểu diễn DOM của trang sau khi render trong trình duyệt. Đặt trường browserHtml bằng true trong request để nhận nó. Tài liệu ghi chuỗi này giới hạn 10 MB, dài hơn bị cắt. Iframe mặc định rỗng, muốn nhúng nội dung iframe phải bật includeIframes.

Trường actions

Trong request trình duyệt, trường actions là danh sách thao tác thực hiện trước khi tạo đầu ra. Ví dụ trong tài liệu dùng một thao tác scrollBottom trên trang cuộn vô hạn rồi đếm số trích dẫn trong browserHtml.

Selector

Thao tác tương tác với phần tử có khóa selector. selector.value là truy vấn, selector.type là ngôn ngữ truy vấn, hỗ trợ css và xpath. Tài liệu ghi selector không tương tác được với iframe hay shadow DOM, chỉ thao tác evaluate, browser script và CDP làm được.

Thao tác chờ

Tài liệu liệt kê bốn thao tác chờ: waitForSelector, waitForRequest, waitForResponse, waitForTimeout. Tài liệu khuyên nên nghĩ tới waitForSelector trước tiên. Mặc định nó chờ phần tử khớp và hiển thị. Có thể đổi selector.state thành attached để chờ phần tử tồn tại bất kể hiển thị, hoặc hidden để chờ phần tử ẩn.

Giới hạn thời gian

Tài liệu ghi có thể dùng bao nhiêu thao tác tùy ý, nhưng tổng thời gian thực thi trình duyệt giới hạn 60 giây. Nếu thao tác còn chạy khi hết giờ, thao tác đang chạy bị ngắt, các thao tác sau không chạy, và bạn nhận đầu ra như trang đang hiển thị lúc đó. Phản hồi có khóa action chứa elapsedTime, error và status để gỡ lỗi. Cần lâu hơn thì dùng CDP với ttl tối đa 3600 giây.

Thứ tự thao tác là thứ tự thực thi

Các thao tác trong danh sách chạy tuần tự từ trên xuống. Không có rẽ nhánh, không có vòng lặp trong cú pháp actions cơ bản. Muốn bấm Xem thêm ba lần, phải viết ba cặp click và chờ. Muốn logic phức tạp hơn, tài liệu chỉ tới browser script hoặc CDP.

Gọi thật với khóa giả

Lab gửi POST tới api.zyte.com/v1/extract với Basic Auth bằng khóa giả, thân có url, browserHtml và một thao tác scrollBottom. Phản hồi là HTTP 401, Content-Type application/problem+json, với type /auth/key-not-found, title Authentication Key Not Found. Lỗi xác thực có cấu trúc chuẩn, dễ đọc bằng mã.

Chọn browserHtml và action type đúng nhu cầu fixture của Zyte API browser actions

Phần này mô tả trang fixture và chọn thao tác.

Trang fixture

Trang fixture

Trang fixture

Máy chủ cục bộ ở cổng 9421 phục vụ một trang có danh sách ba gói proxy, một nút Xem thêm, một ô trạng thái và một khoảng trống cao 3000 điểm ảnh. Bấm nút thì ô trạng thái đổi thành đang tải, sau 800 mili giây thêm ba mục và ô trạng thái thành đã tải 6. Cuộn tới cuối trang thì sau 500 mili giây xuất hiện đoạn bảng giá đầy đủ có class lazy.

Vì sao dùng fixture thay vì trang thật

Trang thật thay đổi theo thời gian, có quảng cáo, có biểu ngữ, có thời gian tải khác nhau mỗi lần. Fixture cho kết quả lặp lại được: cùng chuỗi thao tác luôn ra cùng DOM. Nhờ vậy, khác biệt giữa các ca chỉ đến từ chuỗi thao tác, không từ trang.

Ba loại nội dung

Trang có ba loại nội dung: có sẵn khi tải, xuất hiện sau khi bấm, xuất hiện sau khi cuộn. Mỗi loại cần thao tác khác nhau. Đây là cấu trúc phổ biến của trang thương mại điện tử hiện nay.

Thao tác click

click tìm phần tử theo selector và bấm. Với nút Xem thêm, selector là css với giá trị #more. click chỉ bấm, không chờ kết quả của việc bấm.

Nút có thể bị che

Trong trang thật, nút Xem thêm có thể bị che bởi biểu ngữ cookie hay cửa sổ quảng cáo. click vào phần tử bị che có thể thất bại hoặc bấm nhầm vào lớp che. Trang fixture không có lớp che. Với trang thật, chuỗi thao tác thường phải đóng biểu ngữ trước khi bấm nút chính.

Thao tác scrollBottom

scrollBottom cuộn xuống cuối trang. Không cần selector. Trang có nội dung tải khi cuộn sẽ bắt đầu tải sau thao tác này, nhưng cũng như click, scrollBottom không chờ nội dung tải xong.

Bộ chạy thao tác

def run(page, actions, budget=60.0):
    t0 = time.time(); results = []
    for a in actions:
        left = budget - (time.time() - t0)
        if left <= 0:
            results.append({"action": a["action"], "status": "skipped"}); continue
        # click, waitForSelector, scrollBottom, waitForTimeout
        ...
        results.append({"action": a["action"], "status": st,
                        "elapsedTime": round(time.time() - s, 2), **err})
    return results

Bộ chạy đọc từng thao tác theo cú pháp Zyte, thực hiện bằng Playwright, ghi status, elapsedTime và error giống các trường tài liệu mô tả. Ngân sách thời gian mặc định 60 giây.

Đếm DOM sau thao tác

Sau chuỗi thao tác, bộ chạy lấy HTML của trang, tương ứng browserHtml. Lab đếm số phần tử li class goi, đọc nội dung ô trạng thái, kiểm có phần tử class lazy không. Ba con số này là bằng chứng DOM đã thay đổi.

Kiểm theo phần tử, không theo chuỗi

Lần chạy đầu, kiểm bảng giá bằng cách tìm chuỗi Bang gia day du trong HTML luôn ra đúng, kể cả khi chưa cuộn. Lý do: chuỗi đó có sẵn trong mã JavaScript của trang. Lab sửa thành kiểm thuộc tính class lazy của phần tử. Đây là lỗi dễ mắc khi kiểm browserHtml: HTML chứa cả mã script, không chỉ nội dung hiển thị.

Đặt selector cùng điều kiện chờ sau thao tác trong Zyte API browser actions

Phần này chạy các chuỗi thao tác và đọc DOM.

Ca 1: không thao tác

HTML có 3 gói, ô trạng thái đã tải 3, không có bảng giá. Đây là mốc so sánh.

Ca 2: click, không chờ

Chuỗi chỉ có click vào #more. click báo success sau 0,15 giây. HTML có 3 gói, ô trạng thái là đang tải. Thao tác chạy đúng, nút đã được bấm, nhưng HTML được chụp trước khi ba mục mới xuất hiện.

Kết quả action nói success, dữ liệu thì thiếu. Đây là hiểu lầm hay gặp nhất: success của click chỉ nghĩa là bấm được, không nghĩa là trang đã cập nhật.

Ca 3: click rồi chờ mục thứ sáu

Chuỗi có click, rồi waitForSelector với css #list li:nth-child(6). waitForSelector thành công sau 0,83 giây, khớp với 800 mili giây trang cần để thêm mục. HTML có 6 gói, ô trạng thái đã tải 6.

Điều kiện chờ ở đây là chính thứ mình cần: mục thứ sáu tồn tại. Khi nó xuất hiện, dữ liệu đã đủ.

Ca 4: chờ phần tử đã có sẵn

Chờ vô dụng

Chờ vô dụng

Chuỗi có click, rồi waitForSelector với css #list li. waitForSelector thành công sau 0,01 giây. HTML có 3 gói, ô trạng thái đang tải.

Điều kiện chờ khớp ngay với ba mục có sẵn, nên chờ kết thúc tức thì. Nó không chờ gì cả. Cả hai thao tác báo success, dữ liệu vẫn thiếu như ca 2.

Chờ theo nội dung ô trạng thái

Một lựa chọn khác là chờ ô trạng thái có chữ đã tải 6. Với css, khó chọn phần tử theo nội dung văn bản. Với xpath, có thể viết điều kiện contains trên text. Lab chọn chờ mục thứ sáu vì đó chính là dữ liệu cần lấy, không phụ thuộc vào cách trang viết chữ trạng thái.

Chờ phần tử biến mất

Một số trang hiện biểu tượng đang tải rồi ẩn đi khi xong. waitForSelector với state hidden chờ biểu tượng đó ẩn. Cách này hữu ích khi không biết trước bao nhiêu mục sẽ xuất hiện. Trang fixture không có biểu tượng đang tải nên lab không thử.

Chọn điều kiện chờ

Điều kiện chờ phải là thứ chỉ xuất hiện sau khi thao tác có tác dụng. Ở đây là mục thứ sáu, hoặc ô trạng thái có chữ đã tải 6. Một điều kiện đã đúng từ trước khi thao tác là điều kiện vô dụng. Khi viết chuỗi, nên hỏi: phần tử này có tồn tại trước khi bấm không? Nếu có, chọn phần tử khác.

Ca 5: cuộn rồi chờ bảng giá

Chuỗi có scrollBottom, rồi waitForSelector với css .lazy. Chờ thành công sau 0,85 giây. HTML có phần tử class lazy. Số gói vẫn là 3, vì không ai bấm nút.

Mỗi loại nội dung cần thao tác riêng. Muốn cả sáu gói lẫn bảng giá, chuỗi phải có cả click, chờ mục thứ sáu, cuộn, chờ bảng giá.

Bảng kết quả các ca

Bảng: Bảng kết quả các ca

Ca

Chuỗi thao tác

Gói

Trạng thái

Bảng giá

1

không

3

đã tải 3

không

2

click

3

đang tải

không

3

click, chờ li thứ 6

6

đã tải 6

không

4

click, chờ li bất kỳ

3

đang tải

không

5

scrollBottom, chờ .lazy

3

đã tải 3

có

6

click sai, click đúng, chờ li[6] xpath

6

đã tải 6

không

7

chờ 3 giây với ngân sách 2 giây, rồi click

3

đã tải 3

không

Thực hiện action và kiểm DOM trước/sau với Zyte API browser actions

Phần này xem lỗi selector và chuỗi thao tác bị gián đoạn.

Ca 6: selector sai

Chuỗi có click vào #xem-them, một id không tồn tại, rồi click vào #more, rồi waitForSelector với xpath //li[6]. click đầu báo error sau 3,01 giây với thông điệp timeout. click sau và chờ thành công. HTML có 6 gói.

Bộ chạy trong lab đi tiếp sau thao tác lỗi. Tài liệu Zyte trên trang browser không nói rõ một thao tác lỗi có dừng cả chuỗi không, chỉ nói về trường hợp hết giờ. Lab không khẳng định hành vi của Zyte ở điểm này.

Thao tác lỗi tốn thời gian

click vào selector không tồn tại mất 3 giây chờ trước khi báo lỗi, đúng bằng timeout mà bộ chạy đặt cho click. Trên Zyte, thời gian này tính vào ngân sách 60 giây. Một chuỗi có vài selector sai có thể tiêu hết ngân sách trước khi tới thao tác cần thiết.

Thời gian chờ của từng thao tác

Bộ chạy trong lab đặt timeout 3 giây cho click và 5 giây cho waitForSelector. Zyte có thể có giá trị mặc định riêng, tài liệu trang browser không nêu con số. Điều rõ ràng theo tài liệu là tổng thời gian của chuỗi không vượt 60 giây.

Selector xpath

Ca 6 dùng xpath //li[6] để chờ. Kết quả giống css nth-child ở ca 3. Hai ngôn ngữ đều được hỗ trợ. Chọn ngôn ngữ nào là thói quen, miễn khai báo đúng selector.type.

Ca 7: hết ngân sách thời gian

Hết ngân sách thời gian

Hết ngân sách thời gian

Lab thu nhỏ ngân sách từ 60 giây xuống 2 giây để thử nhanh. Chuỗi có waitForTimeout 3 giây rồi click. waitForTimeout bị ngắt sau 2,01 giây với status interrupted. click bị bỏ qua với status skipped. HTML có 3 gói như ban đầu.

Bộ chạy làm đúng mô tả của tài liệu: thao tác đang chạy bị ngắt, thao tác sau không chạy, đầu ra là trạng thái lúc đó. Con số 2 giây là của lab, giới hạn thật của Zyte là 60 giây.

Ngân sách thu nhỏ có đại diện không

Thu nhỏ từ 60 giây xuống 2 giây chỉ đổi con số, không đổi logic: thao tác vượt ngân sách bị ngắt, thao tác sau bị bỏ. Bộ chạy lab cài đúng logic tài liệu mô tả. Chưa kiểm được độ chính xác của mốc 60 giây trên Zyte thật.

Đầu ra khi hết giờ

Khi hết giờ, Zyte vẫn trả browserHtml như trang đang hiển thị. Không có lỗi HTTP. Nếu mã chỉ kiểm mã trạng thái, nó sẽ coi kết quả là thành công. Phải đọc khóa action trong phản hồi để biết thao tác nào chưa chạy.

waitForTimeout là lựa chọn cuối

Chờ cố định vài giây có vẻ đơn giản, nhưng trang nhanh thì phí thời gian, trang chậm thì chờ không đủ. Ca 3 cho thấy waitForSelector kết thúc ngay khi nội dung xuất hiện, sau 0,83 giây. Chờ cố định 3 giây sẽ phí hơn 2 giây mỗi request, và vẫn có thể không đủ nếu trang chậm hơn thường lệ.

Đọc action result, timeout và giới hạn số action theo bản API của Zyte API browser actions

Phần này rút ra cách đọc kết quả thao tác.

Ba trường cần đọc

Theo tài liệu, khóa action trong phản hồi có elapsedTime, error và status. Lab dùng đúng ba trường này trong bộ chạy. Đọc status để biết thao tác nào thành công, error để biết lý do, elapsedTime để biết thao tác nào tốn thời gian.

Success không phải là đủ

Ca 2 và ca 4 có mọi thao tác success mà dữ liệu thiếu. Kết quả thao tác chỉ nói về thao tác, không nói về dữ liệu. Sau khi đọc kết quả thao tác, vẫn phải kiểm DOM: đếm phần tử cần có, so với kỳ vọng.

Lỗi selector và lỗi trang

Thao tác lỗi vì không tìm thấy phần tử có thể do selector sai, hoặc do trang chưa tải xong phần tử đó. Hai nguyên nhân cần cách sửa khác nhau. Đặt một waitForSelector trước click giúp tách hai trường hợp: nếu chờ lỗi, phần tử không xuất hiện; nếu chờ đạt mà click lỗi, vấn đề nằm ở thao tác.

Kiểm DOM trong mã gọi

Mã gọi Zyte nên có một hàm kiểm browserHtml cho từng loại trang: số mục tối thiểu, phần tử bắt buộc. Kết quả không đạt thì ghi lại cùng kết quả thao tác, để biết lỗi ở thao tác, ở điều kiện chờ, hay ở trang.

Không giới hạn số thao tác, chỉ giới hạn thời gian

Tài liệu ghi không giới hạn số thao tác, chỉ giới hạn tổng thời gian 60 giây. Chuỗi dài vẫn được nếu mỗi thao tác nhanh. Với trang cần bấm Xem thêm nhiều lần, có thể lặp cặp click và chờ nhiều lần trong một chuỗi, miễn tổng thời gian dưới giới hạn.

Khi 60 giây không đủ

Tài liệu chỉ ra CDP cho phép phiên dài tới 3600 giây theo ttl. Lab không thử CDP. Với phần lớn trang danh sách, 60 giây là đủ nếu điều kiện chờ chọn đúng. Nếu không đủ, trước khi chuyển sang CDP, nên xem có thao tác nào đang chờ vô ích không.

Lưu request cùng kết quả

Mỗi lần gọi, nên lưu request JSON, khóa action trong phản hồi và kết quả kiểm DOM cùng một chỗ. Khi trang đích đổi giao diện và chuỗi thao tác bắt đầu lỗi, ba thứ này cho biết thao tác nào gãy trước. Không có chúng, chỉ biết dữ liệu thiếu mà không biết vì sao.

Trang đổi giao diện

Selector gắn chặt với cấu trúc trang. Khi trang đổi id hay class, click báo lỗi không tìm thấy phần tử, và mọi thao tác sau có thể vô nghĩa. Nên ưu tiên selector ổn định như id có ý nghĩa hoặc thuộc tính data, tránh selector dựa vào vị trí như div thứ ba trong body.

Ghi elapsedTime để tối ưu

elapsedTime của từng thao tác cho biết thời gian đi đâu. Ca 6 cho thấy một click lỗi tốn 3 giây, gấp nhiều lần các thao tác còn lại. Thống kê elapsedTime qua nhiều request giúp tìm thao tác chậm và selector hay lỗi.

Đầu ra nghiệm thu: fixture cần tương tác, request action và output chứng minh trạng thái DOM của Zyte API browser actions

Phần cuối gom kết quả thành bộ bàn giao.

Bộ bàn giao

Bộ bàn giao gồm tệp lab.py với trang fixture, máy chủ cục bộ, bộ chạy thao tác và bảy ca; tệp out.txt với kết quả; phản hồi 401 thật từ Zyte. Người nhận chạy lại lab.py với Playwright và Edge, phải thấy bảng kết quả như trên.

Request mẫu cho Zyte

{"url": "https://shop.example.vn/danh-sach",
 "browserHtml": true,
 "actions": [
  {"action": "click", "selector": {"type": "css", "value": "#more"}},
  {"action": "waitForSelector", "selector": {"type": "css", "value": "#list li:nth-child(6)"}},
  {"action": "scrollBottom"},
  {"action": "waitForSelector", "selector": {"type": "css", "value": ".lazy"}}]}

Request này gộp ca 3 và ca 5. Lab chưa gửi nó tới Zyte vì không có khóa.

Tiêu chí đạt

Chuỗi thao tác đưa DOM tới trạng thái có đủ sáu gói và bảng giá. Mỗi thao tác chờ dùng điều kiện chỉ đúng sau khi thao tác trước có tác dụng. Kết quả thao tác được đọc cùng với kiểm DOM. Ca hết giờ được nhận ra qua status của thao tác.

Khi nào cần proxy với Zyte API browser actions

Zyte tự lo phần trình duyệt và mạng khi tải trang. Người dùng API không cấu hình proxy cho thao tác. Proxy chỉ liên quan khi máy gọi API nằm sau proxy công ty.

Khi nhóm tự chạy trình duyệt trên máy mình cho trang được phép thu thập, có lúc cần IP tại Việt Nam để trang hiển thị đúng nội dung trong nước. Khi đó anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN. Proxy không sửa điều kiện chờ sai và không làm nút Xem thêm tự bấm. Vai trò hợp lệ của proxy được phân tích ở bài Web Scraping proxy là gì.

Proxy và thao tác trình duyệt

Một số người nghĩ đổi IP sẽ làm nội dung tải chậm hiện ra nhanh hơn. Không đúng. Nội dung sau tương tác phụ thuộc vào JavaScript của trang và điều kiện chờ, không phụ thuộc vào IP. Proxy chỉ ảnh hưởng tới việc trang có được tải hay không và hiển thị phiên bản vùng nào.

Khóa API và Basic Auth

Zyte nhận khóa qua Basic Auth, khóa là tên người dùng, mật khẩu để trống. Khóa nằm trong header Authorization dạng base64, ai đọc được header là đọc được khóa. Nếu gọi qua proxy công ty có soi TLS, cần cân nhắc. Cách viết chuỗi proxy cho thư viện HTTP được giải thích trong bài định dạng proxy.

Chi phí của thao tác

Request có trình duyệt thường đắt hơn request HTTP thường ở hầu hết dịch vụ. Thao tác chờ dài làm request chạy lâu, có thể ảnh hưởng chi phí tùy cách tính của nhà cung cấp. Lab không kiểm bảng giá Zyte. Chọn điều kiện chờ chính xác vừa giúp dữ liệu đủ, vừa giúp request ngắn.

Những gì lab chưa thử

Lab chưa gửi request có thao tác tới Zyte thật, chưa thấy khóa action thật trong phản hồi, chưa biết Zyte xử lý thao tác lỗi giữa chuỗi thế nào. Lab chưa thử waitForRequest, waitForResponse, evaluate, browser script hay CDP. Lab chưa thử includeIframes hay shadow DOM. Bộ chạy trong lab mô phỏng cú pháp, không thay được phép thử trên Zyte.

Checklist Zyte API browser actions

Checklist

Checklist

  • browserHtml bằng true cho trang cần render.
  • Mỗi loại nội dung một cặp thao tác và chờ.
  • Điều kiện chờ chỉ đúng sau khi thao tác có tác dụng.
  • Ưu tiên waitForSelector, hạn chế waitForTimeout.
  • Kiểm selector trước, selector sai tốn thời gian.
  • Đọc status, error, elapsedTime của từng thao tác.
  • Kiểm DOM sau thao tác, không tin success.
  • Nhớ giới hạn 60 giây cho cả chuỗi.

Câu hỏi thường gặp về Zyte API browser actions

Vì sao click thành công mà HTML không đổi?

Vì click không chờ kết quả. Lab thấy ô trạng thái còn đang tải khi HTML được chụp. Cần thêm waitForSelector sau click.

Chờ phần tử nào sau khi bấm Xem thêm?

Phần tử chỉ xuất hiện sau khi bấm, như mục thứ sáu. Chờ phần tử có sẵn thì kết thúc ngay, lab gọi đó là chờ vô dụng.

Zyte giới hạn bao nhiêu thao tác?

Tài liệu ghi không giới hạn số thao tác, chỉ giới hạn tổng thời gian trình duyệt 60 giây.

Hết 60 giây thì sao?

Theo tài liệu, thao tác đang chạy bị ngắt, thao tác sau không chạy, bạn nhận HTML như lúc đó. Lab mô phỏng với ngân sách 2 giây và thấy đúng hành vi này.

Khóa sai thì API trả gì?

Lab gọi thật nhận HTTP 401 dạng application/problem+json với title Authentication Key Not Found.

Dùng Zyte có cần proxy không?

Không. Zyte tự lo phần mạng. Chỉ cần khi mạng công ty bắt buộc.

Zyte API browser actions và những điều cần nhớ

Zyte API browser actions đưa trang tới đúng trạng thái trước khi lấy HTML, nhưng chỉ khi mỗi thao tác đi kèm điều kiện chờ đúng. Lab trên trang fixture cho thấy click không chờ thì dữ liệu thiếu, chờ phần tử có sẵn cũng thiếu, chờ mục thứ sáu thì đủ. Khi hết ngân sách thời gian thì thao tác sau bị bỏ mà không có lỗi HTTP. Đọc kết quả thao tác rồi kiểm DOM, đừng tin chữ success. Cần IP tĩnh khi tự chạy trình duyệt bên cạnh Zyte API browser actions, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.

TIN TỨC LIÊN QUAN