Phần lớn mọi người biết đến Crawlee khi đang cố trả lời một câu hỏi khác: “nên dùng headless browser nào?” Nhưng đó mới là câu hỏi lệch, và Crawlee chính là lý do. Nó không phải là một trình duyệt. Nó là framework Node/TypeScript, có thể bọc một trình duyệt khi cần và bỏ qua nó khi không cần.
Tôi đã dành vài ngày chạy Crawlee 3.17.0 trên một bộ fixture được kiểm soát cùng vài trang demo công khai, với Node v22.22.3 và macOS. Thông điệp chính — một thư viện, một API, bên dưới là crawler HTTP hoặc trình duyệt thật — chính là điều tôi muốn kiểm tra kỹ nhất, vì đây là lời hứa quyết định việc Crawlee có đáng đưa vào stack của bạn hay không, hay bạn chỉ cần dùng thẳng Playwright. Tóm lại: câu chuyện “hai engine” đứng vững, dù vẫn có vài điểm cần lưu ý mà tôi sẽ nói sau.
Crawlee thực chất là gì, và không phải là gì
Crawlee tự mô tả là thư viện web scraping và tự động hóa trình duyệt cho Node.js, được xây dựng để tạo crawler ổn định và đáng tin cậy. Định vị chính thức khá rộng: trích xuất dữ liệu cho AI, LLM, RAG hoặc GPT; tải HTML, PDF, JPG, PNG và nhiều loại tệp khác; hỗ trợ Puppeteer, Playwright, Cheerio, JSDOM và HTTP thô; có thể chạy có giao diện hoặc headless; kèm xoay proxy. Phạm vi quá lớn, nên cũng cần nói rõ Crawlee không phải là gì.
Nó không phải là engine render. Nó không có trình duyệt riêng. Khi bạn cần thực thi JavaScript, Crawlee sẽ điều khiển Playwright hoặc Puppeteer, rồi các công cụ đó mới điều khiển Chromium (hoặc một trình duyệt khác). Nó cũng không phải là dịch vụ cloud gọi qua mạng — nó là một dependency bạn tự cài và tự chạy. Thứ Crawlee thực sự là, chính xác hơn, là lớp nằm trên bộ fetcher: các lớp crawler, request queue, storage, logic lần theo link. Có thể hiểu nó là framework điều phối quá trình crawl, với một engine có thể thay thế ở bên dưới.
Để ghi nhận, phiên bản tôi kiểm tra là 3.17.0 (phát hành 2026-06-04), viết bằng TypeScript, dùng giấy phép Apache-2.0, và repository đạt khoảng 24,6k stars tính đến 2026-07-09 trên apify/crawlee. Số star luôn thay đổi — repo đã tăng thêm 53 star trong hai ngày tôi theo dõi — nên hãy xem con số này là ảnh chụp tại một thời điểm, không phải sự thật cố định.
Hai engine: CheerioCrawler và PlaywrightCrawler
Đây là điểm mà thiết kế của Crawlee thực sự phát huy tác dụng, và cũng là phần tôi dành nhiều thời gian nhất.
CheerioCrawler là đường đi HTTP. Nó lấy HTML thô qua mạng và phân tích bằng Cheerio — không trình duyệt, không chạy JavaScript, không render. Nhanh và tiết kiệm. PlaywrightCrawler là đường đi trình duyệt. Nó khởi chạy Chromium thật, render trang bao gồm mọi thứ JavaScript dùng để dựng DOM, và thậm chí có thể chụp screenshot.
Hai engine khác nhau, với năng lực thực sự khác nhau. Điểm Crawlee muốn nhấn mạnh là chúng trông giống nhau về mặt sử dụng. Cả hai đều nhận requestHandler. Cả hai đều có run(). Cả hai đều crawl link bằng enqueueLinks. Chuyển từ engine này sang engine kia chỉ là thay class, không phải viết lại. Tôi đã xác minh điều đó bằng cách giữ nguyên byte logic trích xuất và chỉ đổi lớp crawler bọc bên ngoài.
Có một chi tiết cần nói thật chính xác, vì đây là ranh giới mà sự tương đồng dừng lại: cách lấy nội dung là khác nhau. Trong handler của CheerioCrawler, bạn có $ — một DOM tĩnh, đã được parse sẵn, truy vấn kiểu jQuery. Trong handler của trình duyệt, bạn có object page đang sống. Vì vậy, queue, routing, và phần “đẩy dữ liệu này, theo link kia” vẫn y nguyên, nhưng đoạn bạn thật sự đọc nội dung trang sẽ thay đổi hình dạng. Tài liệu của Crawlee cũng nói như vậy — phần interface dùng chung chỉ áp dụng cho các thao tác crawl, còn cách truy cập nội dung là phần thay đổi.
| Engine | Cách lấy dữ liệu | Có chạy JavaScript không? | Kết quả chạy của tôi (1 trang động) | Phù hợp nhất cho |
|---|---|---|---|---|
CheerioCrawler | HTTP thô + parse bằng Cheerio | Không | ~0,035s | HTML tĩnh, API JSON, tốc độ |
PlaywrightCrawler | Chromium thật qua Playwright | Có | ~4,967s | Trang render bằng JS, screenshot |
Các con số trên đến từ một máy và một lần chạy — không phải benchmark, chỉ là hình dạng của sự đánh đổi. Đường đi trình duyệt tốn thời gian nhiều hơn khoảng hai bậc độ lớn trên cùng một URL. Đó là cái giá của việc render, và cũng là lý do bạn không nên chọn nó theo mặc định.
Bài test: cùng một URL, 0 so với 8/8
Lời hứa thì dễ nói. Lý do tôi tin câu chuyện hai engine là vì tôi có thể làm nó “trượt” rồi sửa lại bằng cách chỉ đổi một class.
Tôi dựng một fixture động cục bộ — một trang danh mục mà các thẻ sản phẩm được JavaScript chèn vào sau khi tải, đúng kiểu trang đang trở thành mặc định của web hiện đại. Tôi trỏ CheerioCrawler vào đó. Kết quả trả về 0 thẻ sản phẩm. Đó không phải lỗi; đó là vật lý. Cheerio không chạy JavaScript, nên các thẻ đó chưa từng tồn tại trong HTML mà nó parse. Sau đó tôi trỏ PlaywrightCrawler vào đúng URL ấy, không thay gì khác, và nó render được 8/8 sản phẩm, đồng thời chụp screenshot để làm bằng chứng.
Để chắc rằng đó không phải là một trường hợp đặc biệt của fixture tự dựng, tôi áp dụng cùng mô hình lên một trang công khai — trang demo JavaScript Quotes to Scrape, nơi các câu trích dẫn được tạo ở client side. Kết quả vẫn giống nhau theo cùng một hướng: CheerioCrawler thấy 0 câu trích dẫn, PlaywrightCrawler lấy lại được 10.
Tôi muốn nói thật cẩn thận về ý nghĩa của điều này. Đây là một phép tái hiện rõ ràng của điều Crawlee đã tài liệu hóa — framework đã dùng chung base class và interface giữa các loại crawler từ phiên bản 3.0. Vì vậy đây là xác minh, không phải phát hiện mới. Nhưng đó chính là giá trị: thông điệp marketing “một interface, dùng HTTP hay browser đều được” là thật, và đây là bằng chứng 0 → đầy đủ dữ liệu trên cả fixture do tôi kiểm soát lẫn một trang tôi không kiểm soát.
Khi đường HTTP thắng thế
Rất dễ đọc phần trên thành “lúc nào cũng dùng browser.” Đừng làm vậy. Lý do thiết kế hai engine quan trọng là vì trình duyệt là phương án dự phòng đắt đỏ, chứ không phải mặc định.
Với nội dung tĩnh, CheerioCrawler vừa chính xác vừa nhanh. Fixture danh mục tĩnh của tôi trả về 12/12 sản phẩm đầy đủ, lần theo phân trang bằng enqueueLinks({ selector: '.next-page' }), chỉ mất khoảng 0,155 giây. Một trang bài viết trả về tiêu đề và toàn bộ 3/3 đoạn nội dung, đồng thời tách sạch phần login/subscribe/copyright boilerplate khỏi nội dung chính.
Điểm đáng nhớ nhất: một trang có dữ liệu được tải bằng JavaScript thường sẽ có sẵn một API JSON ngay phía sau. Dữ liệu của fixture động tôi dùng nằm ở một endpoint, và khi tôi trỏ thẳng CheerioCrawler vào API đó, nó lấy lại 8/8 sản phẩm — không cần browser, chỉ mất khoảng 0,035 giây. Cùng dữ liệu đó, đường browser mất gần năm giây để render. Bài học cũ nhưng vẫn đúng: nếu bạn tái tạo được request gốc, hãy làm vậy thay vì khởi chạy Chromium. Crawlee cho phép bạn chọn điều đó theo từng crawler mà không phải đổi framework.
Phần “crawl framework” của Crawlee (lý do chọn Crawlee thay vì chỉ dùng một thư viện browser thuần)
Nếu bạn chỉ cần render một trang, bạn không cần Crawlee — chỉ cần Playwright hoặc Puppeteer. Thứ mà một thư viện browser thuần không cung cấp là một quá trình crawl thật sự: queue, khử trùng lặp, kiểm soát depth, retry. Đó là phần của Crawlee không liên quan đến engine.
Tôi chạy một crawl cùng hostname từ gốc fixture bằng enqueueLinks kèm tracking độ sâu. Crawlee đi qua 11 trang ở các độ sâu {0:1, 1:3, 2:7} — một trang gốc, ba trang ở một hop, bảy trang ở hai hop — và tuân thủ maxRequestsPerCrawl như điều kiện dừng. RequestQueue lo toàn bộ bookkeeping. Khi tôi bắn request vào một trang trả về HTTP 500, Crawlee retry rồi cuối cùng đẩy lỗi ra qua failedRequestHandler thay vì âm thầm nuốt lỗi hoặc làm toàn bộ run bị crash.
Đây là lý do mạnh nhất để chọn Crawlee thay vì một công cụ browser độc lập: phần điều phối crawl đã được tích hợp sẵn, và quan trọng là nó giống nhau dù engine bên dưới là HTTP hay browser. Bạn viết logic queue và theo link một lần. Việc có render JavaScript hay không được quyết định riêng cho từng crawler.
Cài đặt và cú download browser ẩn
Việc cài đặt nhìn chung khá êm, nhưng có một cái bẫy dễ khiến người mới vấp phải.
npm install crawlee playwright chạy bình thường — báo 0 lỗ hổng. Nhưng PlaywrightCrawler sẽ không khởi chạy cho đến khi bạn chạy thêm npx playwright install chromium, lệnh này tải về một binary Chromium khoảng 81,7 MiB. Chỉ cài package crawlee thôi thì không tải browser. Nếu bỏ qua bước đó rồi chuyển thẳng sang browser crawler, bạn sẽ gặp lỗi khởi chạy khá khó hiểu nếu chưa quen mô hình đóng gói của Playwright. Đây là hành vi thừa hưởng từ Playwright, không phải lỗi của Crawlee, nhưng vẫn là một điểm gây ma sát ở lần dùng đầu tiên cần được nhắc tới.
Một lưu ý vận hành nữa: theo mặc định Crawlee ghi dữ liệu vào thư mục cục bộ storage/. Bộ test của tôi chuyển chỗ này sang một thư mục tạm và tắt lưu trữ để mọi thứ gọn gàng, nhưng một lần chạy bình thường sẽ để lại thư mục storage/ trong project của bạn. Không phải vấn đề lớn, chỉ là điều nên biết trước khi nó xuất hiện trong git status.
Thêm một engine nữa, nói ngắn gọn
Câu chuyện tương đồng của Crawlee không chỉ dừng ở Cheerio và Playwright. Nó còn có PuppeteerCrawler, và tôi cũng kiểm tra mức độ mà lời hứa “same interface” áp dụng được đến đâu — ở cấp class và API surface, chứ không phải bằng một lần crawl thực tế.
Cả ba lớp crawler đều bắt nguồn từ cùng một base BasicCrawler. CheerioCrawler đi qua HttpCrawler; PlaywrightCrawler và PuppeteerCrawler đều đi qua BrowserCrawler dùng chung. Khi soi package đã cài, có 24 method public được chia sẻ giữa cả ba engine, bao gồm các thao tác queue và storage mà toàn bộ thiết kế dựa vào — run, addRequests, pushData, getData, getDataset, exportData, getRequestQueue, useState, stop. Thực ra PuppeteerCrawler và PlaywrightCrawler còn có bộ method public giống hệt nhau. Khác biệt giữa các engine chỉ nằm ở đường ranh HTTP so với browser, đúng như bạn mong đợi.
Điều cần nói rõ: tôi không chạy live crawl với PuppeteerCrawler. puppeteer là peer dependency tùy chọn và tôi không cài nó trong bộ test, nên nếu muốn kiểm tra thì sẽ cần thêm một lần tải browser nữa. Vì vậy, tính tương đồng của Puppeteer ở đây được xác minh về mặt cấu trúc — cùng base class, cùng method chia sẻ, cùng hình dạng handler context — chứ không phải qua một lần chạy thực tế. Và ngay cả khi interface giống nhau, hành vi bên dưới cũng không hoàn toàn y hệt: hướng dẫn chính thức của Crawlee lưu ý rằng Playwright tự chờ element, còn Puppeteer thì bạn phải chờ rõ ràng. Đó là đặc tính của engine, không phải lỗi của Crawlee, nhưng nó cho thấy “cùng API” không có nghĩa là “bên trong mọi handler đều giống nhau”.
Những gì tôi chưa test
Đây là những gì tôi cố ý để lại, để bạn không hiểu kết quả của tôi rộng hơn mức nó vốn có.
- Quy mô lớn. Mọi thứ đều chạy trên fixture nhỏ và crawl ngắn từ trang công khai. Không có run dài 100–1.000 trang, nên tôi không thể nói về autoscaling hay độ ổn định của Crawlee dưới tải thực.
- Lưu và tiếp tục queue. Tôi không bao giờ dừng ngang một crawl để xem
RequestQueuecó tiếp tục trơn tru sau crash hay không. Đây là khả năng rất quan trọng cho job dài, nhưng tôi chưa kiểm tra. - Export của Dataset và KeyValueStore. Tôi tự viết phần export JSON/CSV trong harness. Trải nghiệm export có sẵn của
Dataset/KeyValueStore— có thể là điểm tiện nhất của framework — tôi chưa dùng đến. - Proxy và session pool. Crawlee có sẵn tính năng xoay proxy và fingerprinting. Tôi chỉ coi chúng như chủ đề vận hành và tuân thủ, không phải điểm bán hàng “vượt anti-bot”, và cũng không stress-test chúng theo hướng nào.
Và toàn bộ thời gian ở trên đều là trên một máy, một lần chạy. Chúng cho thấy hình dạng của chi phí giữa HTTP và browser. Chúng không phải benchmark, và tôi sẽ không trích dẫn chúng như benchmark.
Ưu và nhược điểm
Ưu điểm
- Một bề mặt API xuyên suốt giữa crawl HTTP và browser — việc đổi engine thực sự chỉ là đổi class, được xác nhận bằng kết quả 0 → đầy đủ dữ liệu trên cả fixture cục bộ và trang công khai.
- Một framework crawl đúng nghĩa:
RequestQueue,enqueueLinksvới kiểm soát depth, retry, vàfailedRequestHandler, chứ không chỉ là công cụ render trang. - Trích xuất HTTP chính xác (12/12 tĩnh, 3/3 đoạn bài viết, 8/8 qua API JSON) khi JavaScript không cản trở.
- Đường browser lấy được nội dung mà HTTP không thể nhìn thấy, và có thể chụp screenshot.
- Apache-2.0, TypeScript, được duy trì tích cực.
Nhược điểm
- Các browser crawler cần lệnh riêng
npx playwright install chromium(~81,7 MiB) mànpm install crawleekhông tự làm — rất dễ bỏ sót. - Render bằng browser tốn chi phí thực trên mỗi trang (~5 giây so với dưới 1 giây trong test một trang của tôi).
- Mặc định tạo thư mục
storage/khi chạy bình thường. - Quy mô lớn, lưu/tiếp tục queue, và trải nghiệm export của Dataset chưa được kiểm chứng trong test của tôi.
- Tính năng proxy và fingerprinting phải được dùng đúng theo điều khoản của website và pháp luật — đó là trách nhiệm, không phải một mẹo để lách rào cản.
Khi nào nên chọn Crawlee thay vì một API được quản lý sẵn
Crawlee là công cụ tự xây, và với rất nhiều đội ngũ thì đó là lựa chọn đúng. Hãy dùng nó khi bạn muốn tự sở hữu crawler trong codebase Node của mình, kết hợp crawl HTTP và browser trong cùng một dự án mà không phải đổi framework, và tự kiểm soát queue lẫn storage. Nếu bạn thoải mái vận hành và về sau mở rộng một “đội” browser, Crawlee cho bạn một xương sống sạch sẽ và được thiết kế tốt để treo mọi thứ lên đó.
Hướng đi còn lại là không tự vận hành toàn bộ hạ tầng ấy. Nếu việc phải chăm sóc các instance Chromium, xoay proxy và xử lý anti-bot không phải là cách bạn muốn dùng thời gian kỹ thuật của mình, thì API được quản lý sẵn là lựa chọn thay thế — và đó là chỗ bộ developer stack của Thunderbit phù hợp. Với người dùng kỹ thuật, Thunderbit không phải Chrome extension; nó là API, MCP server và CLI cho AI scraping. Bạn gọi POST /distill để chuyển một trang thành Markdown sạch, sẵn cho LLM, hoặc POST /extract với JSON Schema để nhận dữ liệu có cấu trúc, với renderMode là none, basic, hoặc full để tự quyết khi nào cần render browser đầy đủ. MCP server cho phép một AI agent (Claude, Cursor và các MCP client khác) scrape ngay trong lúc làm nhiệm vụ, còn CLI có thể chạy từ terminal hoặc CI:
Dùng thử Thunderbit để trích xuất dữ liệu web
npx -y @thunderbit/thunderbit-cli distill "<url>" -f markdown > out.md
Điểm khác biệt quan trọng với nhà phát triển: Crawlee đưa cho bạn nguyên liệu thô — HTML đã render, node đã parse — và bạn tự sở hữu toàn bộ pipeline; còn API được quản lý sẽ trả về JSON có cấu trúc khớp schema, kèm render JavaScript, CAPTCHA và anti-bot được xử lý ở phía server. Mỗi công cụ phục vụ một kiểu việc khác nhau. Muốn kiểm soát tối đa và không ngại vận hành thì chọn Crawlee. Muốn có dữ liệu mà không phải tự dựng cụm browser thì chọn con đường managed API. Nhiều đội ngũ cuối cùng dùng cả hai: một cái cho crawl tùy biến, một cái cho các bài toán “chỉ cần dữ liệu có cấu trúc”. Bạn có thể xem phần đánh đổi về chi phí tại bảng giá của Thunderbit.
Kết luận
Có nên dùng Crawlee không? Có — nếu bạn là developer Node hoặc TypeScript và muốn một framework duy nhất bao trùm cả crawl HTTP lẫn browser với một hệ thống queue crawl thực sự bên dưới. Lời hứa “hai engine” chính là lý do để chọn nó, và điều đó được chứng minh khá rõ trên các fixture của tôi: cùng một URL đi từ 0 lên dữ liệu đầy đủ chỉ bằng cách đổi class, trích xuất tĩnh thì nhanh và chính xác, còn crawl theo queue và depth hoạt động đúng như tài liệu.
Nhưng hãy đi vào với hai điều trong đầu. Dành ngân sách cho bản tải browser ẩn trong lần đầu dùng PlaywrightCrawler, và đừng cho rằng những phần tôi chưa test — quy mô lớn, resume sau crash, export tích hợp sẵn — sẽ tốt ngang những phần tôi đã test cho đến khi bạn chạy chúng trên workload của chính mình. Với tư cách nền tảng để tự xây crawler, Crawlee là một công trình kỹ thuật rất mạnh và được thiết kế tốt. Còn như một pipeline dữ liệu hoàn chỉnh, tự động hoàn toàn, nó là điểm khởi đầu, không phải đích đến.
Dùng thử Thunderbit để trích xuất dữ liệu web Get Started Free
Câu hỏi thường gặp
Crawlee có miễn phí không, và dùng giấy phép gì?
Có. Crawlee là mã nguồn mở theo giấy phép Apache-2.0 và cài từ npm (npm install crawlee). Phiên bản tôi kiểm tra là 3.17.0. Để chạy browser crawler, bạn cần tải Chromium riêng qua Playwright; công cụ này cũng miễn phí nhưng sẽ cộng thêm khoảng 81,7 MiB vào bộ cài.
Nên dùng CheerioCrawler hay PlaywrightCrawler?
Hãy dùng CheerioCrawler khi dữ liệu đã có trong HTML thô hoặc một API JSON phía sau nó — nhanh hơn rất nhiều và không bao giờ khởi chạy trình duyệt. Hãy dùng PlaywrightCrawler khi nội dung được render bằng JavaScript, điều bạn có thể nhận ra khi đường HTTP trả về kết quả trống. Trong test của tôi, engine HTTP trả về 0 mục ở trang render bằng JS, còn engine trình duyệt trả về toàn bộ. Vì chúng dùng chung API, việc chuyển đổi chỉ là đổi class, không phải viết lại.
Crawlee có cần trình duyệt để chạy không?
Chỉ với browser crawler thôi. CheerioCrawler không cần trình duyệt. PlaywrightCrawler (và PuppeteerCrawler) cần binary của trình duyệt — cài bằng npx playwright install chromium. Lưu ý rằng chỉ npm install crawlee thôi thì không tải browser, đây là lỗi vấp phổ biến nhất ở lần chạy đầu.
Crawlee có xử lý phân trang và crawl nhiều trang không?
Có, và đây là một trong những lý do cốt lõi để chọn nó thay vì chỉ dùng thư viện browser độc lập. enqueueLinks theo các link (bao gồm selector phân trang như .next-page), RequestQueue khử trùng lặp và quản lý crawl, đồng thời bạn có kiểm soát depth và giới hạn maxRequestsPerCrawl. Trong test, một crawl cùng hostname đi qua 11 trang ở depth 0–2, và request lỗi được đưa ra qua failedRequestHandler.
Crawlee so với một API scraping được quản lý sẵn thì sao?
Crawlee là self-hosted: bạn tự viết và tự chạy crawler, đồng thời tự chịu trách nhiệm về scaling, proxy và anti-bot. Một API được quản lý như các endpoint distill/extract của Thunderbit sẽ trả về Markdown sạch hoặc JSON có cấu trúc khớp schema, với render và anti-bot được xử lý ở phía server, thông qua API, MCP server và CLI. Chọn Crawlee khi bạn muốn kiểm soát tối đa pipeline của mình; chọn API được quản lý khi bạn không muốn tự vận hành và mở rộng hạ tầng browser.
