Hầu như mọi bài tổng hợp “open source web scrapers tốt nhất” đều dính cùng một lỗi âm thầm: chẳng ai chạy mấy tool đó trên cùng một bộ trang. Scrapy được test trên một bài tin tức, Playwright trên một demo thương mại điện tử nào đó, Colly thì trên thứ tác giả tiện tay có sẵn — rồi chúng được đem ra xếp hạng trực diện, như thể những con số đó có cùng một ý nghĩa. Cách xếp hạng ấy nói cho bạn biết nhiều về website, chứ không nói được bao nhiêu về công cụ.
Vì vậy, tôi đã làm đúng cái đơn giản nhưng ít người chịu làm trong những danh sách kiểu này. Tôi tự dựng một bộ fixture thống nhất rồi cho cả 9 công cụ chạy qua: một catalog tĩnh, một catalog render bằng JavaScript, một bài viết bị nhét giữa cả đống rác ở thanh điều hướng và footer, một lỗi HTTP 500 có chủ đích, một đồ thị crawl liên kết nội bộ nhỏ, cộng thêm hai website luyện tập công khai. Tất cả đều dùng cùng ground truth, cùng thước đo, và được chạy y hệt nhau ở từng lượt. Script và dữ liệu thô đều nằm trong một repo benchmark công khai, nên bạn có thể tự chạy lại bất kỳ phần nào. Kết quả không phải một bảng xếp hạng gọn ghẽ như mấy bài roundup thường hứa — vì thật ra không có người thắng tuyệt đối. Có ba kiểu công việc khác nhau, và chín công cụ này gần như tự động chia nhau vào từng nhóm.
Dùng thử Thunderbit để trích xuất dữ liệu web
Cách bài test được xây dựng, và một giới hạn tôi muốn nói rõ luôn
Tất cả công cụ đều chạy trên cùng các dạng fixture: 12 sản phẩm tĩnh trải trên hai trang, 8 sản phẩm được chèn bằng JavaScript sau một khoảng trễ, một bài viết bị bao quanh bởi phần tử điều hướng/chân trang rác nhưng chỉ có ba đoạn nội dung thật, một phản hồi server 500 được tạo ra có chủ đích, và một đồ thị các liên kết nội bộ. Chính cách thiết kế đó làm cho kết quả có thể so sánh được — “8/8 sản phẩm động” có cùng một nghĩa dù dữ liệu được tạo ra bởi Puppeteer hay Crawlee.
Nhưng đây là ranh giới mà nhiều bài roundup hay bỏ qua. Bộ dữ liệu đi kèm của từng công cụ phản chiếu đúng chính những fixture đó, nên số lượng ký tự tuyệt đối không thể so sánh chéo giữa các công cụ một cách nghiêm ngặt — hãy đọc chúng như tín hiệu bên trong từng công cụ, chứ không phải điểm số giữa các công cụ. Những con số có thể so sánh là recall (nên xem như một tỷ lệ), trạng thái đạt/không đạt ở JavaScript, và hành vi cấu trúc. Có thêm một lưu ý tương tự: bài chạy của Crawl4AI trên catalog tĩnh chỉ bao phủ trang một, nên 6/6 của nó là recall đầy đủ trên một lát cắt hẹp hơn, trong khi các công cụ khác crawl cả hai trang để đạt 12/12 — đó là phạm vi nhỏ hơn, không phải hụt một phần. Phần giải thích đầy đủ, theo từng fixture, nằm trong bản mô tả methodology.
Thêm một lưu ý nữa trước khi nhìn số liệu. Mỗi bộ dữ liệu cũng có một điểm nghiên cứu tạm thời, nhưng tôi cố tình không biến chúng thành bảng xếp hạng. Chúng chỉ là công cụ nội bộ để đối chiếu từng tool với bằng chứng của chính nó, chứ không phải bảng thi đấu — và nếu đem công bố theo kiểu đó thì sẽ lặp lại đúng cái vấn đề “chính xác giả” mà toàn bộ bài test này muốn tránh. Đây là phần tổng hợp những gì bài benchmark cho thấy, chứ không phải bảng điểm.
Toàn bộ bức tranh, đặt lên cùng một bàn test
Hãy nhìn xuống hai cột của bảng này — “Render JS?” và “Hàng đợi crawl tích hợp” — bạn sẽ thấy ba nhóm công việc gần như tự lộ diện.
| Công cụ | Ngôn ngữ | Render JS? | Recall tĩnh | Đầu ra có cấu trúc | Hàng đợi crawl tích hợp | Khối lượng thiết lập | Giấy phép |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Có (browser) | 6/6 (trang 1) | CSS schema | BFS/DFS tích hợp | Nặng (2 bộ browser stack) | Apache-2.0 |
| Firecrawl | Self-hosted | Có (playwright-service) | Markdown đầy đủ | Có | /v1/crawl | Nặng nhất (6 container) | AGPL-3.0 |
| trafilatura | Python | Không | 3/3 bài viết | Không (chỉ văn bản) | Không | Nhẹ | Apache-2.0 |
| Crawlee | Node/TS | Tùy engine | 12/12 | Thông qua extraction | Có (RequestQueue) | Trung bình (+~80 MiB) | Apache-2.0 |
| Playwright | Node/nhiều môi trường | Có | 12/12 | Thủ công | Không (tự viết BFS) | Trung bình (browser) | Apache-2.0 |
| Puppeteer | Node | Có (Chrome) | 12/12 | Thủ công | Không (tự viết BFS) | Trung bình (Chrome) | Apache-2.0 |
| Scrapy | Python | Không | 12/12 | Feed export (JSON/CSV/XML) | Có (tích hợp sẵn) | Trung bình (phụ thuộc Twisted) | BSD-3 |
| Colly | Go | Không | 12/12 | Thông qua callback | Kiểm soát độ sâu | Nhẹ (1 binary + Go) | Apache-2.0 |
| Scrapling | Python | Không (HTTP fetcher) | 12/12 | Có | Không | Trung bình ([fetchers]) | BSD-3 |
Lưu ý về metadata trong bảng này và ở các phần dưới: số sao và phiên bản được chụp vào đầu tháng 7 năm 2026, và chúng thay đổi rất nhanh. Hãy cập nhật lại từ GitHub và trang package của từng dự án trước khi xem chúng là hiện tại.
Mục lục bài review cho từng công cụ
Mỗi dự án trong roundup này đều có một bài review chuyên sâu tương ứng:
- Bài review Crawl4AI
- Bài review Firecrawl
- Bài review trafilatura
- So sánh Playwright vs Puppeteer
- Bài review Crawlee
- Bài review Scrapy
- Bài review Colly
- Bài review Scrapling
Đây là bìa của chúng — kèm theo hai ảnh chụp thật từ bài test render JavaScript, để claim “8/8 dynamic” không chỉ là một con số trên trang.
Công việc số 1: biến một trang thành văn bản sẵn cho LLM
Nếu thứ bạn cần là Markdown sạch để đưa vào pipeline RAG, có ba công cụ cạnh tranh — và chúng khác nhau gần như hoàn toàn về bản chất.
Crawl4AI về thực chất là một bộ tạo Markdown dựa trên browser, dù marketing có nói gì đi nữa. Cũng nên bỏ qua câu chuyện “adaptive intelligence self-learning selector” hay đi kèm nó trên kết quả tìm kiếm: thực ra nó không có tính năng đó — đó là chiêu của một thư viện khác hoàn toàn (tôi sẽ nói kỹ hơn khi tới Scrapling). Nhưng thứ nó làm được thì làm khá tốt. Trên site luyện tập Books to Scrape, nó xuất ra 13.476 ký tự Markdown, hỗ trợ trích xuất bằng CSS schema cho các trường có cấu trúc, và bộ BFS deep crawl tích hợp của nó đi qua 5 trang ở fixture crawl graph trong khi vẫn render một trang JavaScript và chụp ảnh màn hình. Tuy nhiên có hai điểm trừ rõ ràng. Markdown thô của nó vẫn mang theo phần boilerplate của trang nếu bạn không bật bộ lọc nội dung, và lỗi 500 có chủ đích trả về success=false — không phải vì Crawl4AI bắt lỗi HTTP một cách gọn gàng, mà vì heuristic nội dung của chính nó nhìn vào phần thân lỗi rất ngắn rồi gắn nhãn minimal_text ... blocked. Việc thiết lập cũng kéo hai bộ browser stack lên ổ đĩa của bạn. Phiên bản 0.9.0, Apache-2.0, khoảng 71k sao tính đến đầu tháng 7.
Firecrawl là công cụ nặng đô nhất, và việc tự host nó thực sự hoạt động — tôi nói “thực sự” vì stack 6 container (api, playwright-service, redis, rabbitmq, nuq-postgres, và foundationdb) đã khởi động thành công và tạo ra 9.222 ký tự Markdown sẵn cho LLM từ cùng trang Books to Scrape đó. Nó render một trang JavaScript thông qua playwright-service đi kèm, và câu trích dẫn Einstein sau script xuất hiện trong output, chứng minh rằng việc render là có thật. Hai trục trặc tôi gặp đều do môi trường chứ không phải do Firecrawl, và tôi muốn nói thật chính xác để không ai áp dụng nhầm cách sửa: bản build từ source vấp vào lỗi snapshotter của containerd dưới colima (tôi chuyển sang dùng image dựng sẵn), và dải DNS 198.18.x.x của colima kích hoạt cơ chế bảo vệ SSRF của Firecrawl, tôi đã gỡ bằng ALLOW_LOCAL_WEBHOOKS=true — đây là mẹo cho local-dev, không phải thứ nên tắt trong môi trường triển khai thật. Core self-hosted của nó cũng không có Fire-engine, lớp chống chặn trên cloud, và tôi không thử API cloud. Vấn đề lớn hơn là giấy phép: core self-hosted của Firecrawl là AGPL-3.0, nghĩa là trước khi dùng cho mục đích thương mại bạn phải xem xét pháp lý rất nghiêm túc, chứ không phải một dòng chú thích cho có. Khoảng 148k sao tính đến đầu tháng 7.
trafilatura là công cụ khác biệt nhất trong nhóm, và cũng là thứ mà các danh sách theo cơn sốt AI hay quên mất. Không browser. Không hàng cấu trúc. Chỉ là text bài viết sạch, nhanh, viết hoàn toàn bằng Python thuần. Trên fixture bài viết, nó lấy được tiêu đề và đủ cả 3/3 đoạn nội dung thật, lọc sạch boilerplate — không hề rò rỉ “Login,” “Subscribe,” hay “Copyright” — và còn lấy được tác giả cùng ngày tháng. Trên một trang sản phẩm công khai, nó trả về 1.324 ký tự text sạch. Giới hạn của nó đúng như thiết kế: đưa nó vào một catalog là nó sẽ trả về 12 tên sản phẩm dưới dạng text nhưng 0 hàng có cấu trúc — text thì có, cấu trúc thì không, và nó không render JavaScript. Phiên bản 2.1.0 (bản hiện tại), Apache-2.0, khoảng 6.2k sao. Nếu chỉ cần trích xuất bài viết thuần túy, đây là thứ tôi sẽ chọn đầu tiên.
Hai con số ký tự Markdown đó — 13.476 từ Crawl4AI, 9.222 từ Firecrawl — được lấy từ cùng một trang công khai, nhưng đừng hiểu chúng như một chênh lệch về chất lượng. Chúng phản ánh chiến lược Markdown khác nhau (mỗi tool giữ lại bao nhiêu phần giao diện của trang), chứ không phải phán quyết xem output nào tốt hơn. Đó chính là quy tắc tín hiệu trong từng công cụ ở trên, đang thể hiện công khai.
Công việc số 2: render JavaScript một cách đáng tin cậy
Một số dữ liệu đơn giản là không nằm trong HTML cho đến khi script chạy xong, và lúc đó thì browser thật sự không còn là lựa chọn tùy ý nữa. Có ba công cụ xử lý việc này — và trong đó hai công cụ gần như là cùng một thứ.
Playwright và Puppeteer hòa nhau trên mọi bài test tôi ném vào. Cả hai đều render được 8/8 sản phẩm động trên fixture nội bộ và 10 trên site Quotes JS công khai, cả hai đều đạt 12/12 ở recall tĩnh, và cả hai đều xử lý lỗi 500 một cách sạch sẽ (Puppeteer trả về một response object thay vì quăng exception). Không công cụ nào có sẵn hàng đợi crawl, nên cả hai đều phải dùng BFS viết tay để đi qua đồ thị liên kết 12 trang. Khác biệt thực sự duy nhất là phạm vi hỗ trợ: Playwright điều khiển được Chromium, Firefox và WebKit, đồng thời nói được Python và .NET; còn Puppeteer thì ưu tiên Chrome và chỉ dùng Node. Có hai lưu ý vì phiên bản đổi rất nhanh: tôi test Playwright 1.56.0 so với bản hiện tại 1.61.1 và chỉ dùng Chromium; Puppeteer thì là 24.16.0 so với bản hiện tại 25.3.0 — hãy tự chạy lại hoặc giảm mức tin cậy tương ứng. Cả hai đều Apache-2.0; khoảng 92k và 95k sao tương ứng.
Crawlee là công cụ giải quyết đúng cái bài toán hàng đợi mà hai tool trên để ngỏ. Nó bọc một engine Cheerio (HTTP) và một engine Playwright (browser) dưới cùng một API, và sự đối lập trên cùng một trang chính là toàn bộ lời hứa của nó: engine Cheerio nhìn thấy 0 item được chèn bằng JavaScript, còn engine Playwright thấy đủ 8/8 ở local (và 10 trên site công khai), và việc chuyển đổi giữa hai engine chỉ là thay một dòng. Nó còn cung cấp RequestQueue thật sự, đó là lý do nó xứng đáng nằm ở công việc này chứ không phải công việc số 3. Nhưng có một điều không ai ghi ngay ở tiêu đề: browser engine cần thêm bước npx playwright install riêng, tức khoảng 80 MiB mà npm install crawlee không tự kéo về cho bạn. Phiên bản 3.17.0, TypeScript, Apache-2.0, khoảng 24.6k sao.
Công việc số 3: crawl nhanh mà không cần browser
Khi trang không có JavaScript, dùng browser là quá nặng và phí tài nguyên. Ba công cụ thiên về HTTP cạnh tranh ở đây, mỗi công cụ theo một triết lý ngôn ngữ khác nhau, và họ cũng cho ra những khác biệt thú vị.
Scrapy là framework mang tính kỹ thuật cao nhất trong nhóm — spider, xuất feed ra JSON/CSV/XML, AutoThrottle, đầy đủ cả bộ. Nó đạt 12/12 ở recall tĩnh, lấy được 3/3 đoạn của bài viết, đi qua 11 trang ở độ sâu 0–2 trên crawl graph, và bắt được lỗi 500 nhờ handle_httpstatus_list. Điểm đáng chú ý nằm ở tư duy của nó: nó không render, nó tái hiện lại request. Khi ném vào trang JavaScript, nó nhận về 0 node — rồi ngay chính JSON API nằm sau trang đó lại cho nó 8/8. Đó là triết lý Scrapy trong một dữ kiện: tìm request mà trang gọi rồi replay lại, chứ không điều khiển browser. Cái giá phải trả là một stack phụ thuộc khá lớn (Twisted, lxml, parsel), và tôi chỉ test nó trên các fixture nhỏ. Phiên bản 2.17.0, BSD-3-Clause, khoảng 63k sao.
Colly là câu trả lời của Go, và nó nói rất thẳng thắn về bản chất của mình: một binary tĩnh duy nhất, vận hành theo callback qua OnHTML, OnResponse, và OnError, kèm kiểm soát độ sâu. Nó đạt 12/12 ở recall tĩnh, lấy được 8/8 từ JSON API qua OnResponse, bắt được lỗi 500 qua OnError, và đi tới 17 trang trong một lượt crawl độ sâu 2 — tôi cố ý diễn đạt đúng như vậy, vì con số trang đó là bộ đếm của harness, không phải lời hứa về độ đầy đủ mà Colly tự đưa ra. Điều nó không làm là JavaScript: fixture động và site Quotes JS đều trả về 0, đúng theo thiết kế. Bạn sẽ cần Go toolchain để build nó, và version module (v2.3.0) hiện đang đi trước bản release được gắn tag (v2.2.0). Apache-2.0, khoảng 25k sao.
Scrapling là công cụ chuyên biệt, và cái nhãn đó hoàn toàn xứng đáng. Bộ chọn thích nghi của nó được tạo ra để tìm lại một element sau khi markup thay đổi — vì vậy khi tôi đổi class HTML của một target từ product-name thành product-title, selector thường sẽ khớp 0, còn cơ chế adaptive re-match vẫn kéo lại được element đang theo dõi. Với trích xuất HTTP thuần túy, nó đạt 12/12 ở static và 8/8 trên JSON API. Nhưng tài liệu của nó cũng không giấu điều này: trong một bài test tổng hợp nhiều element, nó chỉ khôi phục được 1/3 — đây là khả năng bám theo element bền bỉ, chứ không phải phục hồi toàn bộ, nên đừng tự thổi phồng nó trong đầu. Cài đặt cơ bản pip install scrapling cũng cần thêm [fetchers] mới chạy được, còn StealthyFetcher là một lưu ý về tuân thủ, không phải một tính năng tôi muốn đưa lên slide. Phiên bản 0.4.10 (bản hiện tại), BSD-3-Clause, khoảng 68.7k sao.
Mô hình nằm bên dưới ba nhóm công việc
Xếp cả 9 công cụ cạnh nhau, một mô hình rất rõ sẽ hiện ra. Recall tĩnh đầy đủ — một mức 12/12 trọn vẹn — là tiêu chuẩn tối thiểu cho mọi tool thiên về HTTP; không tool nào vấp ở case dễ này, nên đó không phải điểm phân biệt. Các tool dùng browser chỉ đáng với khối lượng bổ sung khi JavaScript thực sự có mặt, và họ đều phải trả giá ở khâu thiết lập: một browser stack, thêm một bước cài đặt, hoặc cả một cụm container. Còn cột “hàng đợi crawl tích hợp” thực ra là ranh giới giữa một framework và một engine — Scrapy và Crawlee có orchestration sẵn, trong khi Playwright và Puppeteer buộc bạn tự viết BFS. Đó là hình dạng của cả thị trường. Không ai thắng chung cuộc vì chẳng ai đang chơi cùng một trò.
Vậy cuối cùng bạn nên chọn cái nào
Bài benchmark này không trao vương miện cho ai, vì câu trả lời đúng không phải là tên một tool — mà là câu hỏi: bạn đang làm kiểu công việc nào?
- Cần Markdown sẵn cho LLM? Chọn trafilatura khi bạn cần text bài viết sạch; chọn Crawl4AI khi bạn muốn vừa có CSS extraction vừa có render JavaScript trong cùng một thư viện; chọn Firecrawl khi bạn đặc biệt cần dịch vụ self-hosted và chấp nhận cả giấy phép AGPL-3.0 lẫn trọng lượng sáu container.
- Cần render JavaScript? Chọn Playwright hoặc Puppeteer cho phần render thô — ưu tiên theo engine và ngôn ngữ vì hai bên gần như hòa nhau; chọn Crawlee khi bạn muốn có luôn orchestration crawl thay vì tự viết.
- Crawl trang tĩnh hoặc API lặp lại ở quy mô lớn? Chọn Scrapy nếu muốn một framework Python đầy đủ; chọn Colly nếu muốn tốc độ Go thuần trong một binary duy nhất; chọn Scrapling khi vấn đề bạn gặp đi gặp lại là markup thay đổi liên tục và bạn cần chịu được nó.
Ghép đúng tool với đúng công việc, và tất cả những lựa chọn này đều hoàn toàn có lý. Nhưng nếu lấy sai nhóm — dùng browser tool cho trang tĩnh, hoặc parser HTTP cho một ứng dụng JavaScript — thì thư viện được chấm cao nhất trên internet vẫn sẽ làm bạn thất vọng.
Khi nào một API AI được quản lý sẽ phù hợp hơn
Tất cả công cụ ở trên đều miễn phí, mã nguồn mở, và bạn có thể tự chạy. Nhưng đó cũng là cái giá chung mà bài benchmark này liên tục chỉ ra: bạn phải tự quản lý môi trường browser, code crawl, cuộc đua chống bot, và mọi khâu vận hành đi kèm. Với nhiều đội nhóm, khả năng kiểm soát ấy chính là lý do họ chọn các công cụ này; và bản đồ giấy phép cũng rất quan trọng khi bạn đưa chúng vào thực tế — phần lớn thị trường là giấy phép dễ chịu (Apache-2.0 ở Crawl4AI, Crawlee, Playwright, Puppeteer, và Colly; BSD-3 ở Scrapy và Scrapling), trong khi core self-hosted AGPL-3.0 của Firecrawl là thứ cần được xem xét nghiêm túc trước khi dùng cho mục đích thương mại.
Nhưng hãy để ý điều mà bài benchmark này cũng đã chỉ ra: những thứ các tool này không làm được. Render, crawl, cấu trúc dữ liệu, và xoay vòng để vượt chặn — hiếm khi nào có đủ cả, và càng không phải không cần bảo trì. Một API AI scraping được quản lý sẽ gom toàn bộ lớp đó lại thành một lời gọi. Bộ công cụ dành cho developer của chúng tôi tại Thunderbit là một lựa chọn ở mảng đó, và với người dùng kỹ thuật thì API, MCP server, và CLI mới là thứ đáng chú ý, chứ không phải extension trình duyệt. POST /distill trả về Markdown sạch, còn POST /extract trả về JSON theo schema, với phần render JavaScript và chống bot được xử lý phía server chứ không phải trên máy của bạn. Có một MCP server chính thức cho agent và trợ lý lập trình — thunderbit_suggest_fields miễn phí để lên kế hoạch trích xuất, rồi thunderbit_distill (1 credit) và thunderbit_extract (20 credits) sẽ thực hiện công việc — cùng một CLI có thể cài bằng npx @thunderbit/thunderbit-cli để dùng trong terminal và cron job. Với người không viết code trong team, còn có cả Chrome extension no-code, và bảng giá bao phủ cả hai hướng.
Đổi lại, cái bạn phải cân nhắc vẫn là điều mà cả bài benchmark này xoay quanh: tự vận hành và bảo trì tới 9 thư viện với chi phí mỗi lần gọi là 0, hay giao phần hạ tầng đó đi và trả tiền theo request. Không có lựa chọn nào sai cả. Nó chỉ phụ thuộc vào việc bạn thật sự muốn sở hữu bao nhiêu phần của toàn bộ stack. Nếu bạn muốn xem cách trích xuất hoạt động trong thực tế, kênh YouTube của Thunderbit có hướng dẫn từng bước.
{{INTERNAL_BLOG_LINKS}}
Kết luận
Không có open source web scrapers nào là tốt nhất cho mọi trường hợp, và bất kỳ danh sách nào khẳng định chắc nịch một cái tên đều đang âm thầm giấu đi câu hỏi thật sự quyết định mọi thứ: bạn đang làm kiểu công việc nào? Biến một trang thành text, render JavaScript, hay crawl nhanh mà không cần browser — thị trường này chia rất rõ thành ba nhóm, và trong mỗi nhóm, lựa chọn cuối cùng chủ yếu phụ thuộc vào ngôn ngữ và độ nặng của khâu thiết lập, chứ không có một nhà vô địch phổ quát nào cả.
Nếu bạn chỉ lấy một thói quen từ bài này, thì hãy lấy thói quen này: test trên chính trang của bạn trước khi quyết định. Mọi con số ở đây đều có thể tái tạo trong repo benchmark đúng vì lý do đó — vì công cụ đứng đầu một roundup chung chung và công cụ sống sót trên mục tiêu thật của bạn không phải lúc nào cũng là cùng một cái tên.
Dùng thử Thunderbit để trích xuất dữ liệu web Get Started Free
Câu hỏi thường gặp
Trình scraper web mã nguồn mở nào tốt nhất? Không có một cái tên duy nhất — nó phụ thuộc vào công việc. Nếu cần text sẵn cho LLM, chọn trafilatura hoặc Crawl4AI; nếu cần render JavaScript, chọn Playwright, Puppeteer hoặc Crawlee; nếu cần crawl HTTP nhanh, chọn Scrapy hoặc Colly. Trên cùng một bàn test, mỗi công cụ mạnh nhất trong nhóm của riêng nó và yếu thấy rõ khi bước ra ngoài nhóm đó, vì vậy kiểu xếp hạng “một cho tất cả” rất dễ gây hiểu nhầm.
Những trình scraper web mã nguồn mở nào render được JavaScript? Crawl4AI, Firecrawl, Playwright, Puppeteer, và engine Playwright của Crawlee đều render được JavaScript. Scrapy, Colly, trafilatura, và HTTP fetcher mặc định của Scrapling thì không — chúng либо cần một API có thể tái tạo phía sau trang (cách tiếp cận của Scrapy, và nó lấy được 8/8 từ JSON endpoint) hoặc cần một chế độ browser riêng.
Tôi có cần headless browser để scrape một website không? Chỉ khi dữ liệu xuất hiện sau khi JavaScript chạy xong. Nếu chỉ cần một HTTP request bình thường cộng với parser là chạm được vào nội dung, browser là quá nặng và lãng phí — trong trường hợp đó Scrapy, Colly, hoặc Scrapling sẽ nhẹ và nhanh hơn nhiều.
Trong số này, công cụ nào có giấy phép thân thiện nhất cho mục đích thương mại? Phần lớn đều là giấy phép dễ chịu: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) hoặc BSD-3-Clause (Scrapy, Scrapling). Ngoại lệ là core self-hosted của Firecrawl, vốn là AGPL-3.0 và cần được xem xét giấy phép thật kỹ trước khi bạn xây sản phẩm thương mại trên đó.
Các con số benchmark này có thể tái tạo không? Có. Mọi runner, fixture và kết quả thô đều nằm trong một repo công khai có giấy phép MIT. Điều cần nhớ là: recall và kết quả cấu trúc có thể so sánh chéo giữa các công cụ, nhưng số ký tự tuyệt đối chỉ là tín hiệu trong từng công cụ, vì mỗi bộ dữ liệu phản chiếu chính fixture thay vì dùng chung một bản canonical — nên hãy so sánh tỷ lệ và pass/fail, đừng so sánh tổng số ký tự thô.
