Mọi bài viết so sánh “Scrapy vs. Selenium” trên internet gần như đều xoay quanh một ý quen thuộc: Scrapy nhanh hơn, Selenium xử lý được JavaScript, chọn bên nào thì phải chấp nhận điểm yếu của bên đó. Cách nói này nhìn chung không sai, nhưng những lời khẳng định kiểu “mỗi phút quét được bao nhiêu trang” thì chẳng đáng tin nếu đem áp cho mọi trường hợp. Thông lượng thực tế còn phụ thuộc vào website đích, mạng, mức độ chạy song song, vòng đời trình duyệt, cơ chế chờ và cả các biện pháp chống bot.
Bài viết này so sánh kiến trúc và các đánh đổi vận hành thật sự tác động đến dự án từ đầu đến cuối. Ngoài ra, bài còn đi vào những phần mà đa số bài so sánh khác bỏ qua: browser automation làm thay đổi mô hình tài nguyên ra sao, vì sao chỉ render có chọn lọc đôi khi lại tốt hơn crawl hoàn toàn bằng trình duyệt, và khi nào một API trích xuất được quản lý sẵn sẽ phù hợp hơn cả hai framework.
Kết luận nhanh: Scrapy vs. Selenium năm 2026
Nếu cần nói ngắn gọn: Scrapy thắng về tốc độ, khả năng mở rộng và hiệu quả tài nguyên đối với bất kỳ nội dung nào được render ở phía server. Selenium thắng khi bạn cần một trình duyệt thật để làm đúng những việc của trình duyệt thật — bấm, nhập, chờ modal bật lên. Cả hai đều không mạnh sẵn trước các cơ chế chống bot hiện đại, và Playwright đã âm thầm thay thế phần lớn các trường hợp mà trước đây người ta hay tìm đến Selenium.
Đây là ma trận quyết định mà tôi thực sự dùng:
| Tình huống của bạn | Nên chọn |
|---|---|
| Trang tĩnh hoặc render từ server, khối lượng lớn | Scrapy |
| SPA nặng JavaScript, có đăng nhập, click, luồng nhiều bước | Selenium hoặc Playwright |
| Website hỗn hợp — phần lớn tĩnh, một số khu vực chỉ có JS | Mô hình lai Scrapy-Playwright |
| URL đã biết, chỉ cần dữ liệu có cấu trúc, ít phải bảo trì | API trích xuất bằng AI (Thunderbit và các công cụ tương tự) |
Tính đến giữa năm 2026, Scrapy 2.17.0 đã ra mắt, Selenium 4 vẫn tiếp tục mở rộng hỗ trợ WebDriver BiDi, và scrapy-playwright cung cấp một cách làm được duy trì tốt để đưa các request Scrapy được chọn lọc qua trình duyệt. Hãy nhớ kỹ ma trận này — phần còn lại của bài viết sẽ giải thích vì sao nó hợp lý.
Scrapy và Selenium là gì, và vì sao giới lập trình vẫn tranh luận về chúng
So sánh Scrapy với Selenium hơi giống so sánh xe tải với ô tô con. Cả hai đều chở thứ gì đó từ A đến B, nhưng một bên sinh ra để vận chuyển khối lượng lớn thật hiệu quả, còn bên kia được thiết kế để có người lái thật sự tương tác với đường đi. Cuộc tranh luận này vẫn kéo dài vì cả hai công cụ đều có thể crawl dữ liệu — chỉ là chúng được xây cho những mục đích khác nhau, và khá nhiều đội ngũ đã chọn nhầm rồi mới nhận ra.
Scrapy: Bộ máy crawl bất đồng bộ
Scrapy là một framework thuần Python được xây trên mô hình I/O hướng sự kiện, không chặn của Twisted. Nó không phải trình duyệt — trước giờ cũng chưa từng là trình duyệt — mà chỉ gửi request HTTP và phân tích HTML trả về. Đó là toàn bộ “bí kíp”. Vì không phải chờ trình duyệt render, Scrapy có thể gửi hàng chục request cùng lúc mà không bị nghẽn.
Ngay khi cài đặt, Scrapy đã có spider, item pipeline, bộ xuất feed, middleware retry và giới hạn tốc độ. Đây không phải kiểu framework “muốn gì thì tự xây hết” — rất nhiều vấn đề của môi trường production đã được giải quyết sẵn. Tài liệu kiến trúc của Scrapy tách Engine, Scheduler, Downloader và Item Pipeline thành các thành phần riêng có thể thay thế, và đó chính là lý do framework này bền bỉ đến vậy: bạn có thể gắn thêm chức năng mà không phải viết lại lõi.
Điểm yếu của nó rất rõ: không có trình duyệt thì không có JavaScript. Nếu dữ liệu của bạn được tải bằng fetch phía client sau khi trang render xong, Scrapy sẽ không thấy gì cả. Nó chỉ đọc HTML ban đầu, hết.
Selenium: Trình duyệt bạn có thể lập trình
Selenium điều khiển các trình duyệt thật — Chrome, Firefox, Edge — thông qua giao thức W3C WebDriver, một chuẩn chung giúp Selenium không phụ thuộc ngôn ngữ hay trình duyệt, chứ không chỉ là một mẹo dành riêng cho Chrome. Nó render JavaScript, thực thi các lời gọi AJAX, và có thể click, cuộn, nhập đúng như người dùng thật.
Điều đó khiến Selenium trở thành lựa chọn đúng cho mọi thứ phụ thuộc vào tương tác: đăng nhập nhiều bước, wizard, cuộn vô hạn, menu thả xuống kích hoạt API. Nhưng đổi lại, mỗi phiên trình duyệt như vậy khá “nặng”. Hướng dẫn sizing của Selenium Grid chính Selenium thường khuyến nghị khoảng 1 GB RAM cho mỗi phiên trình duyệt chỉ để lên kế hoạch — chưa kể CPU còn phải gánh phần render trang.
Có một chi tiết rất dễ gây nhầm: trang tải xong không có nghĩa là giao diện đã sẵn sàng. Tài liệu của Selenium còn cảnh báo không nên trộn implicit wait với explicit wait vì thời gian chờ sẽ trở nên khó đoán rất nhanh. Nếu script Selenium của bạn hay lỗi ngẫu nhiên, đây thường là nguyên nhân.
Scrapy vs. Selenium: Hiệu năng mà không bịa số liệu chung chung
Một benchmark đáng tin phải công bố trang đích, trạng thái cache, điều kiện mạng, mức độ đồng thời, chiến lược tái sử dụng trình duyệt, điều kiện wait và toàn bộ mã nguồn. Nếu thiếu bối cảnh đó, con số “bao nhiêu trang mỗi phút” chỉ là marketing chứ không phải bằng chứng. Dù vậy, so sánh kiến trúc vẫn rất hữu ích:
| Đặc điểm workload | Scrapy | Selenium | Scrapy-Playwright |
|---|---|---|---|
| HTML render từ server | Đường đi HTTP trực tiếp | Đường đi trình duyệt đầy đủ | Dùng đường đi trực tiếp của Scrapy |
| Nội dung render bằng JavaScript | Cần thêm renderer | Thực thi native trong trình duyệt | Render chọn lọc bằng trình duyệt |
| Mô hình đồng thời | Bộ lập lịch request bất đồng bộ | Phiên trình duyệt do code của bạn hoặc Grid quản lý | Scheduler của Scrapy + browser context |
| Hồ sơ tài nguyên | Không tốn overhead render trình duyệt | Tốn CPU và bộ nhớ cho trình duyệt | Chỉ tốn chi phí trình duyệt cho request được gắn cờ |
| Chỉ số đo tốt nhất | Số item/phút ở mức lỗi an toàn | Số luồng hoàn tất/phút ở mức lỗi an toàn | Đo riêng thông lượng request tĩnh và request render |
Mức concurrent request mặc định của Scrapy chỉ là giới hạn trên, không phải cam kết thông lượng. Tốc độ thực tế bị chi phối bởi độ trễ mạng, giới hạn theo domain, throttling, retry, kích thước response, khối lượng parse và tốc độ request mà website chấp nhận. Selenium có thể tái sử dụng một phiên trình duyệt, nên nó không mặc định là “mỗi trang một trình duyệt mới”, nhưng mỗi phiên đang hoạt động vẫn phải render và chạy đầy đủ môi trường trình duyệt.
Mô hình lai hấp dẫn vì nó giữ các request thông thường trên đường HTTP của Scrapy và chỉ đẩy những trang cần render qua trình duyệt. Cách này thường giảm tải trình duyệt, nhưng không tự động nhanh hơn: hãy đo riêng đường tĩnh và đường render, tính cả tỷ lệ lỗi và retry, rồi chỉnh concurrency sao cho vừa an toàn với website đích vừa phù hợp với bộ nhớ hiện có.
Những khác biệt cốt lõi quyết định lựa chọn của bạn
Tốc độ không phải biến số duy nhất. Khi đưa hệ thống vào production, một loạt yếu tố thực tế cũng quan trọng không kém.
JavaScript rendering và nội dung động
Bản thân Scrapy không nhìn thấy bất kỳ thứ gì được render ở phía client. Selenium thì thấy hết vì nó là trình duyệt thật. Giải pháp trung gian — Scrapy-Splash (cũ hơn, có thể script bằng Lua) và scrapy-playwright (hiện đại hơn, nên dùng) — cho phép bạn render JS có chọn lọc ngay trong luồng crawl của Scrapy thay vì bắt mọi request đều phải đi qua trình duyệt đầy đủ. Nếu 80–90% trang đích là HTML tĩnh và chỉ vài trang cần JS, render chọn lọc là kiến trúc rất rõ ràng. Render toàn bộ qua trình duyệt chỉ vì một số trang cần đến nó là phí tài nguyên.
Khả năng mở rộng và concurrency
Mở rộng Scrapy từ 1.000 trang lên 1.000.000 trang chủ yếu là bài toán hạ tầng — tăng request đồng thời, có thể chia tải qua nhiều worker bằng Redis. Mở rộng Selenium thì đồng nghĩa với việc thêm trình duyệt theo tỷ lệ tuyến tính, kéo theo RAM và CPU tăng tuyến tính, tức là bạn đang quản lý cả một “browser farm” với Selenium Grid và xử lý khôi phục khi crash. Không phải Selenium không scale được — mà là scale nó giống một dự án hạ tầng, chứ không phải đổi vài dòng config là xong.
Pipeline dữ liệu và xuất dữ liệu
Item pipeline của Scrapy xử lý validation, khử trùng lặp và xuất ra JSON, CSV hoặc database như một tính năng có sẵn. Selenium không có sẵn những thứ đó — bạn phải tự viết toàn bộ logic serialize và lưu trữ từ đầu. Nếu chất lượng dữ liệu và tích hợp downstream quan trọng với bạn (và nên là như vậy), Scrapy cho bạn một lợi thế rất đáng kể ngay từ đầu.
Bảo trì và độ tin cậy lâu dài
Một xu hướng tôi thường thấy: spider Scrapy thường sống lâu hơn vì kiến trúc dựa trên middleware giúp hệ thống có cấu trúc hơn. Script Selenium thì dễ vỡ hơn — cập nhật trình duyệt làm hỏng driver, vấn đề timing khiến test chập chờn, và chỉ cần DOM đổi là phải sửa selector. Tôi từng thấy người trong cộng đồng nói thẳng rằng scraper dùng Selenium “có vẻ không phải lựa chọn tốt nhất cho thứ mà chúng tôi sẽ bán cho khách hàng”, và thật lòng mà nói thì cảm giác đó hoàn toàn đúng nếu dự án cần sống nhiều tháng mà không bị đụng chạm quá nhiều.
Thực tế chống bot: Mỗi công cụ trụ được đến đâu trước các lớp phòng thủ năm 2026
Đây là phần mà các bài so sánh khác thường lướt qua, nhưng lại là phần quyết định scraper của bạn có chạy được hay không. Cả Scrapy lẫn Selenium đều không được xây với hạ tầng chống bot hiện đại trong đầu, và giả vờ ngược lại chỉ khiến bạn gặp bất ngờ tệ khi lên production.
| Lớp phòng thủ | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Render JS | ❌ Cần middleware | ✅ | ✅ | ✅ Có sẵn |
| TLS fingerprint | ⚠️ Có thể bị phát hiện | ⚠️ Có thể bị phát hiện | ⚠️ Tốt hơn, nhưng chưa giải quyết triệt để | ✅ Được xử lý |
| Giải CAPTCHA | ❌ Thủ công | ❌ Thủ công | ❌ Thủ công | ✅ Có sẵn |
| Xoay vòng rate limit | ⚠️ Tự làm bằng proxy | ⚠️ Tự làm bằng proxy | ⚠️ Tự làm bằng proxy | ✅ Được quản lý sẵn |
Scrapy dễ bị lỗi với kiểm tra browser fingerprint ngay từ đầu vì thực ra nó không phải trình duyệt — nó chỉ là HTTP client, và không ít nhà cung cấp chống bot sẽ gắn cờ lưu lượng không giống như đến từ trình duyệt thật. Selenium vượt qua các kiểm tra JS cơ bản vì nó đúng là trình duyệt thật, nhưng vẫn có thể bị phát hiện qua những tín hiệu như navigator.webdriver, một cờ chuẩn cho biết phiên đang được tự động hóa. Các bản vá như undetected-chromedriver cố che giấu điều này, nhưng thực chất chỉ là chơi trò đuổi bắt với các nhà cung cấp phát hiện bot, những người liên tục cập nhật chữ ký của họ.
Cuộc đua stealth (và vì sao tự làm rất mong manh)
Sự thật khó chịu về các bản vá chống phát hiện là: chúng là một guồng bảo trì chứ không phải giải pháp. undetected-chromedriver và playwright-stealth hoạt động cho đến khi Cloudflare Turnstile hoặc DataDome tung ra một bản cập nhật bắt được kỹ thuật mà chúng đang dùng. Rồi bạn lại phải vá tiếp. Tôi đã thấy các đội ngũ dành nhiều thời gian kỹ thuật để giữ lớp stealth sống sót hơn cả thời gian họ bỏ ra để xây scraper thật sự.
Giới hạn tốc độ cũng đáng nói riêng. Khi server trả về 429 Too Many Requests, header Retry-After chỉ là một gợi ý chứ không phải mệnh lệnh — nhiều website không gửi header này, và một số còn throttle bạn bằng tín hiệu khác hoàn toàn. AutoThrottle của Scrapy giúp điều chỉnh độ trễ dựa trên độ trễ quan sát được, nhưng đó là phản ứng sau khi vấn đề đã xuất hiện, không phải phòng ngừa.
Đây là lúc một API trích xuất được quản lý sẵn phát huy giá trị — phần xử lý chống bot trở thành việc của bên khác, không phải của bạn. Tôi sẽ nói kỹ hơn ở phần sau.
Yếu tố Playwright: Vì sao “Scrapy vs. Selenium” không còn là toàn bộ câu chuyện
Đặt vấn đề chỉ là cuộc tranh luận giữa hai công cụ đã bỏ lỡ điều thực sự xảy ra trong cộng đồng scraping vài năm gần đây. Các diễn đàn đầy rẫy những câu kiểu “tôi chuyển từ Selenium sang Playwright và rất hài lòng” — vậy mà hầu hết bài so sánh chỉ nhắc Playwright qua loa, thậm chí không nhắc.
Playwright, do Microsoft phát triển, điều khiển Chromium, Firefox và WebKit qua một API duy nhất. Mô hình actionability của nó chờ cho phần tử thật sự hiển thị, ổn định và có thể tương tác rồi mới thực hiện hành động — điều này giảm hẳn lỗi chập chờn liên quan đến timing vốn làm khổ khá nhiều script Selenium. Nó cũng xử lý browser context hiệu quả hơn, cho phép tạo các phiên biệt lập mà không phải tốn overhead khởi động một trình duyệt mới hoàn chỉnh mỗi lần.
Khi Playwright thay thế hoàn toàn Selenium
Riêng cho mục đích scraping — chứ không phải test trình duyệt với hạ tầng Selenium sẵn có — Playwright trong năm 2026 thường là công cụ tốt hơn. Tạo context nhanh hơn, tiêu tốn ít tài nguyên hơn trên mỗi trang, hỗ trợ async gốc và chặn mạng sẵn. Nếu bạn bắt đầu một dự án scraping từ đầu mà không có bộ test Selenium cũ nào cần giữ lại, thật khó có lý do để chọn Selenium trước.
Ngoại lệ: nếu đội của bạn đã có hạ tầng test Selenium, hoặc bạn cần tùy biến profile trình duyệt rất đặc thù mà Playwright không hỗ trợ gọn bằng, Selenium vẫn có chỗ đứng của nó.
scrapy-playwright hoạt động thế nào
scrapy-playwright là một download handler cho Scrapy, chỉ chuyển những request được gắn meta={"playwright": True} qua trình duyệt thật — còn lại vẫn đi trên đường HTTP bất đồng bộ, nhanh của Scrapy. Đây là một spider đơn giản crawl danh mục phân trang, nơi các thẻ sản phẩm được render bằng JS phía client:
import scrapy
class CatalogSpider(scrapy.Spider):
name = "catalog"
def start_requests(self):
yield scrapy.Request(
"https://example.com/products?page=1",
meta={"playwright": True, "playwright_include_page": True},
)
async def parse(self, response):
page = response.meta["playwright_page"]
products = response.css("div.product-card")
for product in products:
yield {
"title": product.css("h3::text").get(),
"price": product.css(".price::text").get(),
}
next_page = response.css("a.next::attr(href)").get()
if next_page:
yield scrapy.Request(
response.urljoin(next_page),
meta={"playwright": True, "playwright_include_page": True},
)
await page.close()
Chỉ những trang thật sự cần render mới đi qua trình duyệt. Đó chính là tinh thần của mô hình lai — bạn không phải trả “thuế trình duyệt” cho mọi request, chỉ cho những request cần nó.
Scrapy-Splash vs. Scrapy-Playwright: Nên dùng middleware nào
Scrapy-Splash yêu cầu dựng một dịch vụ Splash Docker riêng và viết script Lua để tương tác — nó vẫn chạy được, nhưng nặng hơn và cũ hơn. scrapy-playwright tích hợp trực tiếp vào event loop bất đồng bộ của Scrapy, hỗ trợ cả ba engine trình duyệt lớn và xử lý các tương tác phức tạp mà không cần gắn thêm một ngôn ngữ script thứ hai. Nếu bạn bắt đầu dự án mới trong năm 2026, thật sự không có lý do gì để quay lại Splash nữa.
Kiến trúc hybrid sẵn sàng cho production
Phần lớn bài viết nói “bạn có thể kết hợp Scrapy và Selenium” rồi dừng ở đó. Đó không phải kiến trúc. Đó chỉ là một gợi ý. Đây mới là hình dung của một hệ thống production thực sự.
Luồng hoạt động như sau: scheduler của Scrapy chuyển request qua một bộ định tuyến URL để kiểm tra trang đó là tĩnh hay động. Request tĩnh đi thẳng qua downloader chuẩn của Scrapy. Request động được gắn cờ và chuyển tới middleware Playwright, nơi quản lý một cụm browser context. Cả hai luồng đều hội tụ về cùng một item pipeline để validation, khử trùng lặp và xuất dữ liệu — dù dữ liệu đến từ HTML thô hay DOM đã render, nó vẫn đi vào cùng đầu ra JSON, CSV hoặc database.
Một vài lưu ý triển khai nếu bạn đem hệ thống này vào production: hãy container hóa bằng Docker để binary trình duyệt Playwright được đóng gói nhất quán giữa các môi trường, giới hạn số context Playwright đồng thời theo RAM khả dụng (tôi sẽ không vượt quá 8–10 context trên một máy 4 GB tiêu chuẩn), và chạy job theo lịch bằng cron hoặc pipeline CI/CD thay vì để một process chạy mãi không dừng.
Thiết lập này cho bạn mức kiểm soát tối đa. Nhưng đồng thời nó cũng có nghĩa là bạn phải chịu trách nhiệm cập nhật binary trình duyệt, lỗi vòng đời context (page không đóng sẽ làm crawl bị kẹt), xoay proxy, và mọi bản vá chống bot cần gắn thêm. Đó là một cam kết kỹ thuật thực sự, và nên nói rõ trước khi quyết định.
Với những đội muốn có output có cấu trúc mà không muốn tự gánh hạ tầng đó, CLI của Thunderbit tiếp cận cùng vấn đề theo cách khác:
thunderbit batch extract --schema schema.json --file urls.txt
Vẫn ra JSON có cấu trúc. Không cần viết spider, không cần quản lý browser pool, không phải lo phần plumbing chống bot. Bạn đổi một phần khả năng tùy biến để lấy tốc độ triển khai — đó là một đánh đổi hợp lệ, không phải “nâng cấp” cho mọi trường hợp, và hoàn toàn phụ thuộc vào mức độ kiểm soát mà dự án của bạn thực sự cần.
Con đường “bỏ qua framework”: Khi API scraping bằng AI tốt hơn cả hai
Đến một lúc nào đó, một lập trình viên nhận ra họ thật ra không cần một crawling framework. Họ chỉ cần dữ liệu có cấu trúc từ 500 URL đã biết, và việc dựng spider, browser pool cùng lớp chống bot cho việc đó nghe quá tay — vì thường là đúng như vậy.
Đây chính là khoảng trống mà Thunderbit được xây để lấp đầy, và tôi nói luôn từ đầu: nó không phải là sự thay thế cho Scrapy trong một crawl phức tạp, đệ quy, có logic tùy biến. Nó là một công cụ khác cho một bài toán khác, hẹp hơn.
Open API: POST /extract nhận một JSON Schema và trả về dữ liệu có cấu trúc khớp với schema đó — không phải HTML thô, cũng không phải một đống Markdown để bạn tự parse. POST /distill làm nhiệm vụ ngược lại, trả về Markdown sạch để đưa vào pipeline RAG hoặc LLM. Dịch vụ được quản lý này hỗ trợ render JavaScript và xử lý chống bot, nên bạn không phải tự vận hành hạ tầng đó. Hướng dẫn Distill vs. Extract hiện tại cho biết 1 credit cho mỗi trang Distill và 20 credit cho mỗi trang Extract; hãy kiểm tra tài liệu live trước khi tính ngân sách vì điều khoản sản phẩm có thể thay đổi.
MCP Server: với các AI agent như Claude hoặc Cursor, MCP server của Thunderbit mở các chức năng distillation, trích xuất có cấu trúc, gợi ý trường và batch job thành công cụ cho agent, cho phép agent kéo dữ liệu web mới ngay trong lúc làm việc mà không phải rời khỏi môi trường của nó.
CLI: Thunderbit CLI được tài liệu hóa hỗ trợ các lệnh như thunderbit extract <url> --schema schema.json và rất hợp với workflow terminal cùng job theo lịch. Bạn cũng có thể pipe Markdown đã distill sang công cụ khác cho các tác vụ nghiên cứu một lần rất nhanh.
Nếu bạn muốn bỏ luôn phần code, Thunderbit Chrome Extension cung cấp cùng khả năng đó qua giao diện bấm-chọn, rất đáng xem nếu trong team có người không phải lập trình viên nhưng vẫn cần dữ liệu mà không muốn đụng terminal. Tôi cũng đã viết thêm về bức tranh rộng hơn của AI web scraping và web scraping không cần code nếu bạn muốn có cái nhìn đầy đủ hơn.
Hãy thành thật với chính mình xem bạn thuộc nhóm nào: Scrapy vẫn là lựa chọn đúng cho các crawl phức tạp nhiều website, có logic tùy biến và theo liên kết đệ quy. Selenium hoặc Playwright cho các luồng phụ thuộc tương tác. Nhưng “tôi chỉ cần dữ liệu có cấu trúc từ những URL đã biết này” là một bài toán hẹp hơn rất nhiều so với khả năng gốc của cả hai công cụ, và một API có thể thực sự loại bỏ nhu cầu viết spider, phần plumbing chống bot và toàn bộ gánh nặng bảo trì khi bạn tự sở hữu hạ tầng đó.
Scrapy vs. Selenium vs. Playwright vs. AI API: So sánh trực tiếp
| Tính năng | Scrapy | Selenium | Scrapy-Playwright | Thunderbit API |
|---|---|---|---|---|
| Hỗ trợ ngôn ngữ | Chỉ Python | Python, Java, C#, JS, Ruby | Python | REST (mọi ngôn ngữ) |
| Render JS | Không (cần middleware) | Có | Có | Có, có sẵn |
| Async/concurrency | Native, cao | Hạn chế theo từng instance | Native qua Scrapy | Managed ở phía server |
| Xử lý chống bot | Tự làm | Tự làm | Một phần | Có sẵn |
| Pipeline/xuất dữ liệu | Có sẵn | Tự làm | Có sẵn | JSON có cấu trúc |
| Độ phức tạp thiết lập | Trung bình | Thấp lúc bắt đầu, cao khi scale | Trung bình đến cao | Tối thiểu |
| Gánh nặng bảo trì | Thấp-trung bình | Cao | Trung bình | Gần như bằng không |
| Phù hợp nhất cho | Crawl tĩnh khối lượng lớn | Luồng cần tương tác | Website hỗn hợp tĩnh/động | URL đã biết, đầu ra có cấu trúc |
Nếu bạn đang cân nhắc những lựa chọn scraper khác ngoài bốn công cụ này, cũng nên nhìn qua Instant Data Scraper alternatives và best AI web scrapers — thị trường giờ đã rất đông, và không phải công cụ nào cũng giải cùng một bài toán.
Lưu ý pháp lý và đạo đức cho web scraping năm 2026
Tôi nói ngắn gọn vì đây không phải trọng tâm chính, nhưng nó rất quan trọng. Thiết lập ROBOTSTXT_OBEY của Scrapy sẽ buộc spider tôn trọng robots.txt — đây là thực hành tốt, nhưng cũng nên biết rằng bản thân Robots Exclusion Protocol đã nêu rõ rằng các quy tắc của nó không phải là giấy phép truy cập hợp pháp. Selenium và Playwright không có bất kỳ cơ chế tuân thủ robots.txt nào tích hợp sẵn — phần đó hoàn toàn là trách nhiệm của bạn. Dù dùng công cụ nào, hãy kiểm tra điều khoản dịch vụ của website và luật áp dụng tại khu vực của bạn trước khi scrape và tái sử dụng dữ liệu; “nội dung hiển thị công khai” không có nghĩa tự động là hợp pháp ở mọi nơi.
Chọn công cụ phù hợp cho dự án scraping của bạn trong năm 2026
Quyết định thực sự xoay quanh bốn câu hỏi: nội dung là gì, quy mô bao lớn, cần tương tác đến mức nào, và bạn sẵn sàng gánh bao nhiêu chi phí bảo trì lâu dài. Trang tĩnh ở quy mô lớn thật sự, chọn Scrapy. Trang nặng JS với tương tác thực, chọn Selenium hoặc Playwright. Hỗn hợp cả hai, xây mô hình lai. URL đã biết mà chỉ cần dữ liệu có cấu trúc với ít bảo trì nhất, một API như Thunderbit thường tiết kiệm thời gian hơn rất nhiều so với chi phí bỏ ra.
“Scrapy vs. Selenium” từ trước đến nay chưa bao giờ là toàn bộ câu hỏi — chỉ là cách đặt vấn đề phổ biến nhất lúc bấy giờ. Playwright đã thay đổi vùng trung gian, và các AI extraction API đã mở ra hẳn một hướng đi mới cho những ai nhận ra mình đang xây hạ tầng thay vì giải quyết vấn đề kinh doanh. Trước khi cam kết với bất kỳ hướng nào, bạn nên thử luôn gói miễn phí — suggest-fields là miễn phí và distill chỉ tốn 1 credit, nên bạn có thể kiểm tra nhanh xem API có hợp hay không trước khi viết một dòng spider code.
Câu hỏi thường gặp
Scrapy có nhanh hơn Selenium khi web scraping không?
Theo thử nghiệm của tôi, có — thường nhanh hơn rất nhiều trên các trang tĩnh, vì kiến trúc bất đồng bộ của Scrapy bỏ hẳn overhead của trình duyệt. Khoảng cách này thu hẹp lại khi Scrapy dùng middleware Playwright cho các trang nặng JS, nhưng Scrapy vẫn thường thắng về tổng thông lượng ở workload hỗn hợp vì các trang không cần JS vẫn đi trên đường nhanh.
Scrapy có xử lý được trang render bằng JavaScript không?
Không tự thân được — Scrapy chỉ nhìn thấy HTML ban đầu. Thêm scrapy-playwright hoặc Scrapy-Splash cũ hơn làm middleware sẽ cho phép render có chọn lọc từng request qua trình duyệt thật, trong khi phần còn lại của quá trình crawl vẫn chạy trên đường native, nhanh hơn của Scrapy.
Khi nào nên dùng Selenium thay vì Scrapy?
Khi bạn cần tương tác đầy đủ với trình duyệt — đăng nhập nhiều bước, click qua wizard, điền form — và số lượng trang ở mức vừa phải chứ không quá lớn. Đây cũng là lựa chọn hợp lý nếu bạn đã có hạ tầng test dựa trên Selenium và muốn tận dụng lại cho scraping.
Playwright có tốt hơn Selenium cho scraping năm 2026 không?
Riêng cho scraping thì nhìn chung là có — Playwright thường cho hiệu năng tốt hơn, tự động chờ sẵn và tốn ít tài nguyên hơn trên mỗi browser context. Selenium vẫn có lợi thế với các đội đang vận hành bộ test cross-browser đã trưởng thành mà Playwright không được thiết kế để thay thế.
AI scraping API là gì, và khi nào nó thay thế Scrapy hoặc Selenium?
AI scraping API, như Open API của Thunderbit, xử lý render JS, cơ chế chống bot và trích xuất dữ liệu ở phía server, rồi trả về JSON có cấu trúc khớp với schema bạn định nghĩa. Đây là lựa chọn đúng khi bạn có URL đã biết và cần output có cấu trúc mà không muốn xây hay duy trì hạ tầng crawl — nhưng nó không thay thế Scrapy trong các crawl phức tạp, đệ quy, có logic tùy biến.
Tìm hiểu thêm
