Cách giảm lưu lượng truy cập của trình phân tích xuống 5 lần mà không mất dữ liệu.

Mỗi megabyte lưu lượng truy cập thừa của trình phân tích đều có thể là chi phí cho nhà cung cấp proxy hoặc rủi ro bị giới hạn và bị cấm theo IP. Nếu bạn thu thập giá từ Wildberries, Ozon hoặc theo dõi quảng cáo trên Avito qua hàng trăm địa chỉ proxy, việc tiết kiệm lưu lượng truy cập sẽ ảnh hưởng trực tiếp đến ngân sách của dự án. Trong bài viết này, chúng tôi sẽ trình bày các kỹ thuật cụ thể cho phép giảm khối lượng dữ liệu truyền tải từ 4-5 lần mà vẫn giữ được độ đầy đủ và chính xác của thông tin được trích xuất.

Tại sao lưu lượng truy cập của trình phân tích ảnh hưởng đến ngân sách

Hầu hết các nhà cung cấp proxy tính phí cho proxy cư trú và di động dựa trên khối lượng gigabyte đã truyền, chứ không phải thời gian sử dụng. Nếu trình phân tích của bạn tải trang sản phẩm Wildberries hoàn toàn — với hình ảnh, kịch bản gợi ý, theo dõi phân tích và phông chữ — bạn sẽ phải trả cho 2-3 MB cho mỗi thẻ, trong khi thực tế chỉ cần 15-20 KB văn bản: tên, giá, xếp hạng, tình trạng hàng hóa.

Khi mở rộng đến 50.000-100.000 thẻ mỗi ngày, sự khác biệt giữa "tải tất cả" và "tải chỉ những gì cần thiết" trở thành hàng chục gigabyte lưu lượng truy cập thừa mỗi ngày. Điều này không chỉ là chi phí cho proxy, mà còn là tăng tải cho trang web mục tiêu, làm tăng khả năng bị bảo vệ chống bot và nhận captcha hoặc bị cấm IP tạm thời. Tối ưu hóa lưu lượng truy cập đồng nghĩa với việc tiết kiệm tiền và giảm rủi ro bị chặn.

Còn có một hiệu ứng thứ ba: càng ít dữ liệu được truyền tải trong một yêu cầu, yêu cầu đó càng nhanh được thực hiện. Điều này cho phép tăng cường độ song song — khởi chạy nhiều luồng hơn trên cùng một số proxy mà không vượt quá giới hạn tốc độ mà các trình duyệt chống phát hiện như Dolphin Anty hoặc AdsPower đặt ra khi làm việc với các phiên.

Mẹo 1: Chặn hình ảnh, CSS và phông chữ

Nếu trình phân tích hoạt động qua trình duyệt headless (Playwright, Puppeteer, Selenium) — cách nhanh nhất để giảm lưu lượng truy cập từ 2-3 lần là chặn tải các tài nguyên tĩnh không ảnh hưởng đến dữ liệu trong DOM. Hình ảnh sản phẩm, phông chữ của trang web, video và kiểu CSS chiếm tới 70% trọng lượng trang, nhưng không tham gia vào việc trích xuất văn bản và thuộc tính.

from playwright.sync_api import sync_playwright

def block_heavy_resources(route, request):
    if request.resource_type in ["image", "media", "font", "stylesheet"]:
        route.abort()
    else:
        route.continue_()

with sync_playwright() as p:
    browser = p.chromium.launch(headless=True)
    page = browser.new_page()
    page.route("**/*", block_heavy_resources)
    page.goto("https://example.com/product/123")
    html = page.content()
    browser.close()

Logic tương tự được thực hiện trong Puppeteer qua page.setRequestInterception(true) và trong Selenium qua cấu hình hồ sơ Chrome với tham số profile.managed_default_content_settings.images: 2. Trên thực tế, chỉ cần một cài đặt này có thể cắt giảm từ 50% đến 70% lưu lượng truy cập khi phân tích các thị trường, nơi các trang bị quá tải với nội dung hình ảnh và quảng cáo.

Mẹo 2: Yêu cầu HTTP thay vì trình duyệt đầy đủ

Nhiều người sử dụng Selenium hoặc Playwright ở những nơi không cần thiết. Nếu trang không yêu cầu thực thi JavaScript để hiển thị dữ liệu (điều này có thể dễ dàng kiểm tra bằng cách mở "Xem mã trang" thay vì DevTools), thì việc lấy HTML trực tiếp qua các thư viện requests hoặc httpx trong Python là lợi ích hơn nhiều. Một yêu cầu như vậy chỉ nặng kilobyte, không phải megabyte, vì không kéo theo việc kết xuất của động cơ trình duyệt, các cuộc gọi mạng cho các trình theo dõi và các tài nguyên thứ yếu.

import httpx

headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)",
    "Accept-Encoding": "gzip, br",
    "Accept": "text/html,application/xhtml+xml"
}

proxies = {"http://": "http://user:pass@proxy_host:port",
           "https://": "http://user:pass@proxy_host:port"}

with httpx.Client(headers=headers, proxies=proxies, http2=True) as client:
    response = client.get("https://example.com/catalog/item/456")
    print(len(response.content), "byte đã nhận")

Việc chuyển từ mô phỏng trình duyệt sang yêu cầu HTTP trực tiếp ở những nơi mà trang web trả về HTML đã sẵn sàng mà không cần kết xuất phía khách hàng, giảm lưu lượng truy cập từ 3-8 lần. Chỉ cần lưu ý rằng các yêu cầu như vậy dễ bị phân biệt với người dùng thực, vì vậy đối với các trang web có bảo vệ chống bot nghiêm ngặt, nên kết hợp phương pháp này với các proxy cư trú chất lượng, cung cấp IP từ các nhà cung cấp thực tế và giảm khả năng bị chặn yêu cầu.

Mẹo 3: Phân tích qua API JSON ẩn

Hầu hết các thị trường hiện đại — bao gồm Wildberries, Ozon và Yandex.Market — tạo ra các thẻ sản phẩm và danh sách thông qua các API JSON nội bộ mà frontend gọi. Bạn có thể tìm thấy các điểm cuối này qua tab Network trong DevTools, lọc các yêu cầu theo loại XHR/Fetch. Thông thường, một yêu cầu như vậy trả về JSON từ 5-30 KB với dữ liệu sạch: id sản phẩm, giá, giảm giá, tồn kho, xếp hạng — không có một byte HTML nào hoặc CSS.

Sự khác biệt về khối lượng dữ liệu truyền tải giữa một trang HTML đầy đủ và việc truy cập trực tiếp vào API JSON có thể đạt tới 10-15 lần. Một lợi ích bổ sung — JSON dễ dàng hơn để phân tích bằng chương trình: không cần các bộ chọn XPath, chỉ cần truy cập đến trường cần thiết theo khóa từ điển. Nhược điểm — các điểm cuối như vậy thường yêu cầu tiêu đề đặc biệt, token phiên hoặc các tham số chữ ký yêu cầu, cần phải được trích xuất trước từ trang chính hoặc ứng dụng di động.

Lời khuyên cho các thực hành

Trước khi xây dựng trình phân tích xung quanh API ẩn, hãy kiểm tra phiên bản di động của trang web hoặc ứng dụng qua bộ chặn proxy (Charles Proxy, Fiddler) — các API di động thường trả về JSON gọn gàng và ổn định hơn so với phiên bản desktop của trang web.

Mẹo 4: Nén Gzip và Brotli

Ngay cả khi bạn buộc phải lấy HTML đầy đủ, việc kích hoạt nén đúng cách có thể giảm kích thước truyền tải từ 60-80%. Nhiều trình phân tích tự viết không gửi tiêu đề Accept-Encoding: gzip, br, do đó máy chủ trả về phản hồi không được nén. Các thư viện requests và httpx tự động giải nén Gzip và Brotli — chỉ cần chỉ định rõ ràng hỗ trợ nén trong tiêu đề yêu cầu.

Brotli trung bình nén HTML văn bản mạnh hơn Gzip từ 15-20%, nhưng không phải tất cả các máy chủ đều hỗ trợ thuật toán này — nên yêu cầu cả hai tùy chọn và cho phép máy chủ chọn cái tối ưu. Đối với API JSON, hiệu ứng từ việc nén còn rõ ràng hơn: các khóa từ điển lặp lại ("price", "name", "rating") nén gần như hoàn hảo, giảm trọng lượng phản hồi xuống nhiều lần.

Mẹo 5: Yêu cầu có điều kiện và bộ nhớ đệm

Nếu bạn theo dõi giá của cùng một sản phẩm nhiều lần trong ngày, phần lớn các thẻ giữa các lần kiểm tra không thay đổi. Sử dụng các tiêu đề If-Modified-Since và If-None-Match với giá trị ETag nhận được khi yêu cầu đầu tiên. Nếu nội dung không thay đổi, máy chủ trả về trạng thái 304 Not Modified gần như không có nội dung phản hồi — tiết kiệm lưu lượng truy cập lên đến 95% trên các trang không thay đổi.

import httpx

etag_store = {}

def fetch_with_cache(url, client):
    headers = {}
    if url in etag_store:
        headers["If-None-Match"] = etag_store[url]
    resp = client.get(url, headers=headers)
    if resp.status_code == 304:
        return None  # dữ liệu không thay đổi
    etag_store[url] = resp.headers.get("ETag", "")
    return resp.content

Không phải tất cả các trang web đều hỗ trợ ETag một cách chính xác, nhưng đối với những trang hỗ trợ, mẹo này trở thành cách hiệu quả nhất để giảm lưu lượng truy cập khi theo dõi thường xuyên — bạn thực tế chỉ trả tiền cho những thay đổi thực tế của dữ liệu, chứ không phải cho việc tải lại nội dung không thay đổi.

Mẹo 6: Phân tích chọn lọc các trường cần thiết

Đôi khi việc giảm lưu lượng truy cập từ phía máy chủ là không thể — trang web trả về toàn bộ trang mà không phụ thuộc vào yêu cầu. Trong trường hợp này, tối ưu hóa diễn ra ở giai đoạn xử lý: đừng tải lại trang chỉ để trích xuất thêm một trường. Thiết kế các bộ chọn XPath hoặc CSS sao cho trong một lần duyệt DOM có thể trích xuất ngay tất cả các thuộc tính cần thiết — giá, tên, mã sản phẩm, tình trạng hàng hóa, xếp hạng — thay vì thực hiện các yêu cầu lặp lại đến cùng một URL với các trình phân tích khác nhau cho các nhiệm vụ khác nhau.

Cũng hữu ích khi giới hạn độ sâu duyệt của các trang lồng nhau. Nếu để theo dõi giá chỉ cần dữ liệu từ trang danh mục (danh sách sản phẩm), đừng chuyển đến thẻ của từng sản phẩm riêng lẻ — điều này tạo ra lưu lượng trùng lặp, thường không cung cấp thông tin mới, ngoại trừ mô tả và đánh giá, không ảnh hưởng đến giá và tình trạng hàng hóa.

Mẹo 7: Tối ưu hóa mẫu duyệt

Xóa trùng lặp URL — một mẹo cơ bản nhưng thường bị bỏ qua. Các danh mục của thị trường tạo ra nhiều liên kết với nội dung giống nhau nhưng có các tham số sắp xếp khác nhau, nhãn UTM hoặc ID phiên. Chuẩn hóa URL trước khi đưa vào hàng đợi (xóa các tham số theo dõi, sắp xếp các tham số truy vấn) loại bỏ 10-30% các yêu cầu dư thừa khi duyệt các danh mục lớn.

Ưu tiên duyệt theo tần suất thay đổi dữ liệu cũng tiết kiệm lưu lượng truy cập: các sản phẩm có nhu cầu cao và giá biến động nên được kiểm tra mỗi giờ, trong khi các mặt hàng hiếm — một lần mỗi ngày. Lịch trình thích ứng như vậy thay vì duyệt đều tất cả các thẻ với tần suất giống nhau giảm tổng khối lượng yêu cầu từ 2-4 lần mà không mất đi tính chính xác của dữ liệu quan trọng.

Cách kết hợp với chiến lược proxy

Việc giảm lưu lượng truy cập ảnh hưởng trực tiếp đến việc lựa chọn loại proxy. Nếu bạn phân tích một khối lượng lớn các trang từ các yêu cầu HTTP trực tiếp mà không có bảo vệ chống bot phức tạp, chỉ cần các proxy trung tâm dữ liệu nhanh và rẻ — chúng cung cấp tốc độ truyền tải cao với chi phí thấp cho mỗi gigabyte, điều này rất quan trọng khi phân tích quy mô hàng ngàn thẻ mỗi ngày.

Đối với các trang web có bảo vệ chống bot nghiêm ngặt, nơi việc mô phỏng hành vi của người dùng thực là quan trọng, tốt hơn nên sử dụng proxy cư trú — kết hợp chúng với các mẹo chặn tài nguyên thừa, bạn sẽ có được cả lưu lượng thấp và mức độ tin cậy cao của trang web đối với yêu cầu. Nếu việc phân tích diễn ra qua các phiên bản di động của API thị trường, nơi dữ liệu gọn gàng hơn và hệ thống chống bot hướng đến các dải IP di động, bạn nên xem xét các proxy di động để giảm thêm rủi ro bị chặn.

Sự kết hợp giữa "lưu lượng tối thiểu trên mỗi yêu cầu" + "loại proxy phù hợp với nhiệm vụ" cho phép đồng thời giảm chi phí cho cơ sở hạ tầng và tăng tốc độ thu thập dữ liệu mà không mất đi độ tin cậy.

Bảng so sánh các mẹo

Mẹo	Giảm lưu lượng	Độ khó triển khai
Chặn hình ảnh/CSS/phông chữ	50-70%	Thấp
Yêu cầu HTTP thay vì trình duyệt	3-8 lần	Trung bình
API JSON ẩn	10-15 lần	Cao
Nén Gzip/Brotli	60-80%	Thấp
Yêu cầu có điều kiện (ETag)	lên đến 95% trên các trang không thay đổi	Trung bình
Xóa trùng lặp URL và ưu tiên	2-4 lần	Trung bình

Danh sách kiểm tra triển khai

Kiểm tra xem trang mục tiêu có yêu cầu kết xuất JavaScript hay không, hoặc có thể lấy HTML trực tiếp qua httpx/requests
Cấu hình chặn hình ảnh/media/phông chữ/stylesheet trong trình duyệt headless, nếu trình duyệt vẫn cần thiết
Tìm các API JSON nội bộ qua DevTools → Network → XHR/Fetch
Thêm tiêu đề Accept-Encoding: gzip, br vào tất cả các yêu cầu
Thực hiện lưu trữ ETag/Last-Modified cho các yêu cầu có điều kiện trên các URL lặp lại
Chuẩn hóa và xóa trùng lặp hàng đợi URL trước khi duyệt
Cấu hình tần suất duyệt thích ứng theo tầm quan trọng và tính biến động của dữ liệu
Lựa chọn loại proxy phù hợp với hồ sơ lưu lượng cuối cùng — trung tâm dữ liệu, cư trú hoặc di động

Kết luận

Giảm lưu lượng truy cập của trình phân tích xuống 5 lần là một mục tiêu thực tế nếu áp dụng các mẹo một cách tuần tự: loại bỏ các tài nguyên thừa, chuyển sang yêu cầu HTTP trực tiếp hoặc API JSON ở những nơi có thể, kích hoạt nén, sử dụng yêu cầu có điều kiện cho dữ liệu không thay đổi và tối ưu hóa chính mẫu duyệt. Mỗi bước này đều mang lại hiệu ứng đo lường được, và tổng hợp chúng lại sẽ thay đổi hoàn toàn kinh tế của dự án thu thập dữ liệu từ các thị trường và các trang web khác.

Sau khi tối ưu hóa lưu lượng truy cập, điều quan trọng là chọn đúng cơ sở hạ tầng proxy cho hồ sơ tải mới. Để thu thập nhanh chóng và rẻ các khối lượng dữ liệu lớn, các proxy trung tâm dữ liệu là lựa chọn phù hợp, trong khi đối với các trang web có bảo vệ chống bot nghiêm ngặt — proxy cư trú với các địa chỉ IP thực tế từ các nhà cung cấp trong nước, giúp giảm rủi ro bị chặn ngay cả khi phân tích cường độ cao.