Lähes jokaisessa "parhaat avoimen lähdekoodin scraperit" -koosteessa on yksi hiljainen ongelma: työkaluja ei ajeta samoilla sivuilla. Scrapy testataan uutisartikkelilla, Playwright jollain verkkokaupan demolla, Collyllä sillä, mitä kirjoittajalla sattui olemaan käsillä — ja sitten ne asetetaan vierekkäin kuin nuo luvut olisivat koskaan tarkoittaneet samaa asiaa. Tuo vertailu kertoo enemmän sivuista kuin työkaluista.
Tein siis sen tylsän ja ilmeisen asian, jonka listaukset yleensä ohittavat. Rakensin yhden yhteisen testijoukon ja ajoin kaikki yhdeksän työkalua sen läpi: staattinen katalogi, JavaScriptillä renderöity katalogi, artikkeli, joka on hautautunut navigoinnin ja footerin täytteeseen, tarkoituksella rikottu HTTP 500, pieni sisäisten linkkien crawl-grafi sekä kaksi julkista harjoitussivustoa. Sama totuusdata, samat mittarit, jokainen ajo. Skriptit ja raaka tulos löytyvät yhdestä julkisesta benchmark-reposta, joten voit ajaa kaiken itse uudelleen. Tuloksena ei ollut siistiä pistetaulukkoa, jota roundupit lupaavat — yhtä voittajaa ei ole. On kolme erilaista tehtävää, ja yhdeksän työkalua jakautuvat niihin lähes itsestään.
Kokeile Thunderbitiä verkkodatan poimintaan
Miten testipenkki toimi — ja yksi rajoitus, jonka sanon suoraan
Jokainen työkalu sai eteensä samat fixture-muodot: 12 staattista tuotetta kahdelle sivulle jaettuna, 8 tuotetta, jotka JavaScript lisää viiveen jälkeen, artikkeli, jonka ympärillä on nav/footer-boilerplatea ja kolme oikeaa kappaletta, tarkoituksella tuotettu palvelimen 500-virhe sekä sisäisten linkkien graafi. Juuri tämä rakenne saa tulokset asettumaan samalle linjalle — "8/8 dynaamista tuotetta" tarkoittaa täsmälleen samaa asiaa riippumatta siitä, onko tuotteen tuottanut Puppeteer vai Crawlee.
Tässä on se raja, jonka monet koostelut ohittavat. Kunkin työkalupaketin omat fixture-kopiot vastaavat sen omaa toteutusta, joten absoluuttiset merkkimäärät eivät ole suoraan vertailukelpoisia työkalujen välillä — lue niitä vain saman työkalun sisäisinä signaaleina, älä eri työkalujen välisenä pisteytyksenä. Luvut, jotka ovat vertailukelpoisia, ovat recall (ajattele sitä suoritusasteena), JavaScriptin läpäisy/hylkäys sekä rakenteellinen käyttäytyminen. Sama huomio toisin sanoen: Crawl4AI:n staattisen katalogin ajo koski vain ensimmäistä sivua, joten sen 6/6 on täysi recall kapeammalla otannalla, kun taas muut työkalut crawlailivat molemmat sivut ja päätyivät tulokseen 12/12 — pienempi kattavuus, ei puolikas epäonnistuminen. Koko perustelu fixture kohtaisesti löytyy metodologia-artikkelista.
Yksi varaus vielä ennen numeroita. Jokaisessa paketissa on mukana myös alustava tutkimuspisteytys, mutta en tarkoituksella julkaise niitä ranking-taulukkona. Ne olivat sisäisiä apuvälineitä, joilla tarkistin työkalua sen omaa evidenssiä vasten — eivät sarjataulukko. Jos ne julkaistaisiin sellaisena, syntyisi täsmälleen se valheellisen tarkkuuden ongelma, jota koko harjoitus yrittää välttää. Tämä on synteesi testipenkissä näkyneestä, ei pistetaulukko.
Koko kenttä yhdellä testipenkillä
Lue tästä taulukosta kaksi saraketta — "Renders JS?" ja "Built-in crawl queue" — niin kolme tehtävää paljastuvat käytännössä itsestään.
| Tool | Language | Renders JS? | Static recall | Structured output | Built-in crawl queue | Setup weight | License |
|---|---|---|---|---|---|---|---|
| Crawl4AI | Python | Kyllä (selain) | 6/6 (sivu 1) | CSS-skeema | Sisäänrakennettu BFS/DFS | Raskas (2 selainpinottua) | Apache-2.0 |
| Firecrawl | Itsehostattu | Kyllä (playwright-service) | Täysi Markdown | Kyllä | /v1/crawl | Raskain (6 konttia) | AGPL-3.0 |
| trafilatura | Python | Ei | 3/3 artikkeli | Ei (vain teksti) | Ei | Kevyt | Apache-2.0 |
| Crawlee | Node/TS | Moottori valinnainen | 12/12 | Poiminnan kautta | Kyllä (RequestQueue) | Keskitaso (+~80 MiB) | Apache-2.0 |
| Playwright | Node/moni | Kyllä | 12/12 | Manuaalinen | Ei (itse kirjoitettu BFS) | Keskitaso (selain) | Apache-2.0 |
| Puppeteer | Node | Kyllä (Chrome) | 12/12 | Manuaalinen | Ei (itse kirjoitettu BFS) | Keskitaso (Chrome) | Apache-2.0 |
| Scrapy | Python | Ei | 12/12 | Feed-vienti (JSON/CSV/XML) | Kyllä (sisäänrakennettu) | Keskitaso (Twisted-riippuvuudet) | BSD-3 |
| Colly | Go | Ei | 12/12 | Callbackien kautta | Syvyyden hallinta | Kevyt (1 binääri + Go) | Apache-2.0 |
| Scrapling | Python | Ei (HTTP-fetcher) | 12/12 | Kyllä | Ei | Keskitaso ([fetchers]) | BSD-3 |
Huomio taulukon metatiedoista ja kaikesta alla olevasta: tähtimäärät ja versiot otettiin talteen heinäkuun 2026 alussa, ja molemmat muuttuvat nopeasti. Tarkista ne aina kunkin projektin GitHubista ja pakettisivulta ennen kuin pidät niitä ajantasaisina.
Yksittäisten työkalujen arvostelut
Jokaisella tämän koonnin projektilla on oma syväluotaava arvostelunsa:
- Crawl4AI-arvostelu
- Firecrawl-arvostelu
- trafilatura-arvostelu
- Playwright vs Puppeteer -vertailu
- Crawlee-arvostelu
- Scrapy-arvostelu
- Colly-arvostelu
- Scrapling-arvostelu
Tässä ovat niiden kannet — sekä kaksi oikeaa kuvakaappausta JavaScript-renderöintitestistä, jotta "8/8 dynaamista" ei jää vain numeroksi sivulla.
Tehtävä yksi: muuta sivu LLM-valmiiksi tekstiksi
Jos haluat puhdasta Markdownia RAG-putkeen, kolme työkalua kilpailee — eikä niiden rakenne voisi olla erilaisempi.
Crawl4AI on markkinoinnin alla käytännössä selaimeen nojaava Markdown-generaattori. Kannattaa unohtaa sen ympärillä pyörivä tarina "adaptive intelligence self-learning selectorista": sellaista ei ole — se on täysin toisen kirjaston temppu (palataan siihen Scraplingin kohdalla). Se mitä se oikeasti tekee, se tekee hyvin. Books to Scrape -harjoitussivulla se tuotti 13 476 merkkiä Markdownia, pystyy CSS-skeema-poimintaan rakenteellisia nostoja varten ja sen sisäänrakennettu BFS-syväsahaus kävi crawl-grafiikkafixturellä 5 sivulla samalla kun se renderöi JavaScript-sivun ja nappasi kuvakaappauksen. Kaksi oikeaa miinusta kuitenkin. Raaka Markdown sisältää sivun boilerplatea, ellei sisällön suodatinta kytketä päälle, ja tarkoituksellinen 500 tuli takaisin arvolla success=false — ei siksi, että Crawl4AI olisi siististi tunnistanut HTTP-virheen, vaan koska sen oma sisältöheuristiikka katsoi pientä virhetekstiä ja luokitteli sen minimal_text ... blocked. Lisäksi asennus pudottaa levyllesi kaksi selainpinottua. Versio 0.9.0, Apache-2.0, noin 71k tähteä heinäkuun 2026 alussa.
Firecrawl on raskassarjalainen, ja sen itsehostaus oikeasti toimii — sanon "oikeasti", koska kuuden kontin kokonaisuus (api, playwright-service, redis, rabbitmq, nuq-postgres ja foundationdb) nousi käyntiin ja tuotti samalta Books to Scrape -sivulta 9 222 merkkiä LLM-valmista Markdownia. Se renderöi JavaScript-sivun mukana tulevan playwright-servicen kautta, ja skriptin jälkeen näkyvä Einstein-lainaus ilmestyi outputiin, mikä todisti renderöinnin olleen aito. Kaksi ongelmaa, joihin törmäsin, johtuivat ympäristöstä eivätkä Firecrawlista, ja haluan olla täsmällinen, jotta kukaan ei kopioi väärää korjausta: lähdekoodista tehty build kompastui containerd:n snapshotter-ongelmaan coliman alla (vaihdoin valmiisiin imageihin), ja coliman 198.18.x.x-DNS-alue laukaisi Firecrawl:n SSRF-suojan, jonka poistin käyttämällä ALLOW_LOCAL_WEBHOOKS=true -arvoa — paikalliseen kehitykseen sopiva kiertotie, ei asetus jota pitäisi kytkeä pois oikeassa tuotannossa. Itsehostattu ydin puuttuu myös Fire-enginesta, eli pilven anti-block-kerroksesta, enkä testannut pilvi-API:a. Isompi huomio on lisenssi: Firecrawl’n itsehostattu ydin on AGPL-3.0, eli kyse on oikeasta juridisesta kotiläksystä ennen kaupallista käyttöä, ei alaviitteestä. Noin 148k tähteä heinäkuun alussa.
trafilatura on tämän joukon vastavirran tekijä, ja juuri se, jonka AI-hypen ympärille tehdyt listat unohtavat jatkuvasti. Ei selainta. Ei rakenteellisia rivejä. Vain nopeaa, siistiä artikkelitekstiä puhtaalla Pythonilla. Artikkelifixturellä se poimi otsikon sekä kaikki 3/3 oikeaa kappaletta, riisui boilerplaten kokonaan — mitään "Login", "Subscribe" tai "Copyright" -tekstiä ei vuotanut läpi — ja nappasi lisäksi tekijän ja päivämäärän. Julkisella tuotesivulla se palautti 1 324 merkkiä siistiä tekstiä. Sen raja on juuri se, mitä sen suunnittelu vihjaa: osoita sille katalogi, ja se antaa takaisin 12 tuotenimeä tekstinä mutta 0 rakenteellista riviä — tekstiä kyllä, rakennetta ei, eikä JavaScriptiä renderöidä lainkaan. Versio 2.1.0 (nykyinen julkaisu), Apache-2.0, noin 6,2k tähteä. Pelkkään artikkelipoimintaan tarttuisin tähän ensin.
Nuo kaksi Markdown-merkkimäärää — 13 476 Crawl4AI:lta, 9 222 Firecrawlilta — tulivat samalta julkiselta sivulta, mutta älä lue niitä laatuerona. Ne kertovat eri Markdown-strategioista (kuinka paljon sivun chromea kukin säilyttää), eivät siitä, kumpi output on parempi. Tämä on aiempi within-tool-signal-sääntö käytännössä.
Tehtävä kaksi: renderöi JavaScript luotettavasti
Joissakin datoissa sisältö ei ole HTML:ssä ennen kuin skriptit on ajettu, ja siinä vaiheessa oikea selain ei ole enää valinnainen. Kolme työkalua kattaa tämän tehtävän — ja kaksi niistä osoittautui lähes samaksi työkaluksi.
Playwright ja Puppeteer menivät tasan jokaisessa testissä. Molemmat renderöivät 8/8 dynaamista tuotetta paikallisessa fixturessä ja 10 julkisella Quotes JS -sivustolla, molemmat saavuttivat 12/12 staattisen recallin ja molemmat käsittelivät 500-virheen siististi (Puppeteer palauttaa response-olion eikä heitä poikkeusta). Kummassakaan ei ole omaa crawl-jonoa, joten molemmat tarvitsivat käsin kirjoitetun BFS:n kiertämään 12-sivuisen linkkigraafin. Ainoa todellinen ero on kattavuudessa: Playwright ohjaa Chromiumia, Firefoxia ja WebKitiä sekä puhuu Pythonia ja .NETiä, kun taas Puppeteer on Chrome-ensimmäinen ja vain Node-pohjainen. Kaksi tarkennusta, koska versiot muuttuvat nopeasti: testasin Playwrightia versiolla 1.56.0 verrattuna nykyiseen 1.61.1-versioon ja käytin vain Chromiumia; Puppeteer oli versiossa 24.16.0 verrattuna nykyiseen 25.3.0-versioon — aja testit itse uudelleen tai huomioi ero. Molemmat Apache-2.0; noin 92k ja 95k tähteä.
Crawlee on se, joka ratkaisee jonon ongelman, jonka muut kaksi jättävät auki. Se yhdistää Cheerio- (HTTP) ja Playwright- (selain) moottorin yhden API:n taakse, ja yhden sivun vertailussa koko idea näkyy heti: Cheerio-moottori näki 0 JavaScriptillä lisättyä kohdetta, Playwright-moottori näki paikallisesti kaikki 8/8 (ja 10 julkisella sivustolla), ja moottorien vaihtaminen on yhden rivin muutos. Se antaa myös oikean RequestQueue-jonon, ja juuri siksi se kuuluu tähän tehtävään eikä kolmanteen. Huomio, jota otsikoihin ei yleensä nosteta: selainmoottori tarvitsee erillisen npx playwright install -asennuksen, noin 80 MiB, jota npm install crawlee ei lataa automaattisesti. Versio 3.17.0, TypeScript, Apache-2.0, noin 24,6k tähteä.
Tehtävä kolme: crawlataan nopeasti ilman selainta
Kun sivulla ei ole JavaScriptiä, selain on kallis ylilyönti. Tässä kilpailee kolme HTTP-first-työkalua, kukin oman kielifilosofiansa edustajana, ja niiden erot ovat kiinnostavia.
Scrapy on joukon insinööritason kehys — spiderit, feed-viennit JSON/CSV/XML-muotoon, AutoThrottle, kaikki. Se saavutti 12/12 staattisen recallin, poimi artikkelin 3/3 kappaletta, kulki 11 sivua syvyyksillä 0–2 crawl-grafissa ja nappasi 500-virheen handle_httpstatus_list-käsittelyn kautta. Sen ajattelutapa on se kiinnostava osa: se ei renderöi, vaan toistaa pyynnön. Kun sen eteen laitettiin JavaScript-sivu, se sai 0 solmua — ja sitten juuri sen sivun takana oleva JSON-API antoi sille 8/8. Siinä on Scrapyn filosofia yhdessä datapisteessä: etsi sivun tekemä pyyntö ja toista se, älä ohjaa selainta. Hinta on melko suuri riippuvuuspaketti (Twisted, lxml, parsel), ja testasin sen vain pienillä fixtuureilla. Versio 2.17.0, BSD-3-Clause, noin 63k tähteä.
Colly on Go-vastaus, ja se on virkistävän suoraviivainen siitä, mitä se on: yksi staattinen binääri, callback-ohjattu OnHTML-, OnResponse- ja OnError-logiikan kautta, sekä syvyyden hallinta. Se onnistui 12/12 staattisessa recallissa, poimi 8/8 JSON-API:sta OnResponse-kautta, nappasi 500-virheen OnError-polulla ja saavutti 17 sivua depth-2-crawlessa — ja muotoilen sen juuri noin, koska tuo sivumäärä on testiharnessin oma laskuri, ei lupaus täydellisestä kattavuudesta, jonka Colly antaisi. Se ei renderöi JavaScriptiä: dynaaminen fixture ja Quotes JS -sivusto palasivat molemmat 0 tuloksella, aivan kuten pitääkin. Rakentamiseen tarvitset Go-työkaluketjun, ja moduuliversio (v2.3.0) on tällä hetkellä edellä tagattua julkaisua (v2.2.0). Apache-2.0, noin 25k tähteä.
Scrapling on erikoistyökalu, ja se ansaitsee tuon nimityksen. Sen adaptiiviset selektorit on rakennettu löytämään elementti uudelleen, kun markup muuttuu — eli kun vaihdoin kohteen HTML-luokan product-name-luokasta product-title-luokkaan, tavallinen selektori osui 0:aan, ja adaptiivinen uudelleentunnistus löysi seurattavan elementin silti takaisin. Pelkällä HTTP-poiminnalla se saavutti 12/12 staattisesti ja 8/8 JSON-API:ssa. Sen omat dokumentit eivät peittele tätä: synteettisessä usean elementin testissä se palautti 1/3 — kyse on kestävästä elementinseurannasta, ei täydellisestä palautuksesta, joten älä liioittele sen kykyjä mielessäsi. Perusasennus pip install scrapling tarvitsee myös [fetchers]-lisäosan käynnistyäkseen, ja sen StealthyFetcher on enemmän yhteensopivuusvaroitus kuin ominaisuus, jota laittaisin esityskalvolle. Versio 0.4.10 (nykyinen julkaisu), BSD-3-Clause, noin 68,7k tähteä.
Kolmen tehtävän taustalla oleva kuvio
Kun kaikki yhdeksän asetetaan riviin, paljastuu selkeä kuvio. Täysi staattinen recall — tasainen 12/12 — on kaikille HTTP-first-työkaluille lähtötaso; kukaan ei kompastunut helppoon caseen, joten se ei erottele voittajia. Selaintyökalut oikeuttavat lisäpainonsa vasta, kun JavaScript on oikeasti mukana, ja siitä maksetaan asennuksessa: selainpino, lisäasennus tai kokonainen konttifleet. Ja sarake "built-in crawl queue" on käytännössä raja kehyksen ja moottorin välillä — Scrapy ja Crawlee tuovat orkestraation valmiina, kun taas Playwright ja Puppeteer pakottavat kirjoittamaan BFS:n itse. Siinä kentän rakenne. Kukaan ei voita kokonaisuutena, koska kukaan ei pelaa samaa peliä.
Miten siis oikeasti valitset?
Testipenkki ei suostu kruunaamaan voittajaa, koska oikea vastaus ei ole työkalu vaan kysymys — mitä kolmesta tehtävästä olet tekemässä?
- Tarvitsetko LLM-valmista Markdownia? Valitse trafilatura, kun tavoitteena on puhdas artikkeliteksti; Crawl4AI, kun haluat CSS-poiminnan ja JavaScript-renderöinnin samassa kirjastossa; ja Firecrawl, kun haluat nimenomaan itsehostatun palvelun ja voit hyväksyä sekä AGPL-3.0-lisenssin että kuuden kontin painon.
- Tarvitsetko JavaScript-renderöintiä? Playwright tai Puppeteer itse renderöintiin — valitse moottorin ja kielen mukaan, koska muuten ne ovat tasoissa — ja Crawlee, kun haluat myös crawl-orchestrationin valmiina etkä käsin kirjoitettuna.
- Crawlataanko staattisia sivuja tai toistettavia API-rajapintoja skaalassa? Scrapy täydellisenä Python-kehyksenä, Colly raakanopeaan Go-binääriin ja Scrapling, kun markupin muuttuminen on juuri se toistuva kipu, jonka kanssa kamppailet.
Sovita työkalu tehtävään, niin jokainen näistä on perusteltu valinta. Ota väärä kategoria — selaintyökalu staattisille sivuille tai HTTP-parseri JavaScript-sovellukselle — ja internetin parhaiten arvioitu kirjasto pettää silti.
Mihin hallittu AI API sopii sen sijaan
Kaikki yllä olevat työkalut ovat ilmaisia, avoimen lähdekoodin ratkaisuja ja sinun hallinnassasi. Siinä on myös yhteinen kompromissi, joka testipenkissä tuli jatkuvasti esiin: sinä omistat selainympäristön, crawl-koodin, anti-bot-kilpailun ja kaiken ylläpidon. Monelle tiimille juuri tuo hallinta on pointti, ja lisenssikartta on tärkeä osa päätöstä — suurin osa kentästä on sallivasti lisensoitu (Apache-2.0 Crawl4AI:ssa, Crawleessa, Playwrightissa, Puppeteerissa ja Collyssa; BSD-3 Scrapyssa ja Scraplingissa), ja Firecrawl’n AGPL-3.0 itsehostattu ydin on se, joka vaatii oikeasti tarkkaa arviointia ennen kaupallista käyttöä.
Mutta huomaa myös, mitä testipenkki kartoitti: mitä nämä työkalut eivät tee. Renderöi, crawlkaa, rakenna, kierrä blokit — harvoin kaikki kerralla, eikä koskaan ilman omaa ylläpitoa. Hallittu AI-scraping API puristaa tuon pinon yhdeksi kutsuksi. Thunderbitin oma kehittäjille suunnattu pinta Thunderbit on yksi vaihtoehto, ja tekniselle yleisölle tärkeintä on API, MCP-palvelin ja CLI, ei selainlaajennus. POST /distill palauttaa siistiä Markdownia ja POST /extract skeemaan määriteltyä JSONia, ja JavaScript-renderöinti sekä anti-bot hoidetaan palvelinpuolella eikä omalla koneellasi. Agentteja ja koodaavia avustajia varten on virallinen MCP-palvelin — thunderbit_suggest_fields toimii ilmaiseksi poiminnan suunnitteluun, sitten thunderbit_distill (1 krediitti) ja thunderbit_extract (20 krediittiä) tekevät työn — sekä CLI, jonka saat käyttöön komennolla npx @thunderbit/thunderbit-cli terminaali- ja cron-ajoon. Ei-teknisille tiimiläisille on myös no-code Chrome-laajennus, ja hinnoittelu kattaa molemmat suunnat.
Kompromissi on sama, jonka ympärillä koko tämä testipenkki pyörii: pyöritä ja ylläpidä itse jopa yhdeksää kirjastoa ilman per-kutsu-maksua, tai ulkoista putkisto ja maksa per pyyntö. Kumpikaan ei ole väärä valinta. Kyse on siitä, kuinka suuren osan pinosta oikeasti haluat omistaa. Jos haluat mieluummin nähdä, miltä poiminta näyttää käytännössä, Thunderbitin YouTube-kanava näyttää sen vaihe vaiheelta.
{{INTERNAL_BLOG_LINKS}}
Lopputulos
Yhtä parasta avoimen lähdekoodin scraperia ei ole, ja jokainen lista, joka luovuttaa sinulle sellaisen itsevarmasti, piilottaa hiljaa sen kysymyksen, joka oikeasti ratkaisee kaiken: mitä kolmesta tehtävästä olet tekemässä? Muunnatko sivun tekstiksi, renderöitkö JavaScriptiä vai crawlataanko nopeasti ilman selainta — kenttä jakautuu siististi näihin koriin, ja kunkin sisällä valinta riippuu kielestä ja asennuksen painosta, ei mistään universaalista mestarista.
Jos otat tästä mukaan vain yhden tavan, ota tämä: testaa omilla sivuillasi ennen kuin sitoudut mihinkään. Jokainen tässä mainittu luku on toistettavissa benchmark-repossa juuri tästä syystä — koska työkalu, joka nousee yleisen roundupin kärkeen, ja työkalu, joka kestää sinun oikeat kohteesi, eivät aina ole sama asia.
Kokeile Thunderbitiä verkkodatan poimintaan Get Started Free
Usein kysytyt kysymykset
Mikä on paras avoimen lähdekoodin web scraper? Yhtä ainoaa ei ole — kaikki riippuu tehtävästä. LLM-valmiille tekstille trafilatura tai Crawl4AI; JavaScript-renderöintiin Playwright, Puppeteer tai Crawlee; nopeaan HTTP-crawlaamiseen Scrapy tai Colly. Jaetulla testipenkillä jokainen työkalu oli vahvin omassa kategoriassaan ja selvästi heikompi sen ulkopuolella, minkä vuoksi yhden koon rankingit johtavat harhaan.
Mitkä avoimen lähdekoodin scraperit renderöivät JavaScriptiä? Crawl4AI, Firecrawl, Playwright, Puppeteer sekä Crawlee’n Playwright-moottori renderöivät JavaScriptiä. Scrapy, Colly, trafilatura ja Scraplingin oletus-HTTP-fetcher eivät — ne joko tarvitsevat sivun taakse toistettavan API:n (Scrapyn lähestymistapa, joka poimi 8/8 JSON-endpointista) tai erillisen selainmoden.
Tarvitsenko headless-selaimen sivuston scrapingiin? Vain jos data ilmestyy vasta JavaScriptin ajon jälkeen. Jos tavallinen HTTP-pyyntö ja parseri pääsevät sisältöön käsiksi, selain on kallis ylilyönti — Scrapy, Colly tai Scrapling ovat silloin paljon kevyempiä ja nopeampia.
Kummalla näistä on kaupalliseen käyttöön ystävällisin lisenssi? Useimmat ovat sallivia: Apache-2.0 (Crawl4AI, Crawlee, Playwright, Puppeteer, Colly) tai BSD-3-Clause (Scrapy, Scrapling). Poikkeus on Firecrawl’n itsehostattu ydin, joka on AGPL-3.0 ja joka kannattaa tarkistaa huolella ennen kuin rakennat sen varaan kaupallisen tuotteen.
Ovatko nämä benchmark-luvut toistettavissa? Kyllä. Jokainen ajo, fixture ja raakatulos on julkisessa MIT-lisensoidussa repossa. Yksi huomio kannattaa kuitenkin muistaa: recall- ja rakennetuloksia voi vertailla työkalujen välillä, mutta absoluuttiset merkkimäärät ovat vain saman työkalun sisäisiä signaaleja, koska kukin paketti peilaa fixturejä eikä jaa yhtä kanonista kopiota — vertaa siis osumia ja läpäisyä, älä raakamerkkien kokonaismäärää.
