Scrapy leimataan helposti kategoriaan "ei pärjää nykyaikaisille sivustoille", koska se ei aja JavaScriptiä. Se maine on nurinpäin. Sivun renderöimättä jättäminen on koko idean ydin, ja kun näet sen käytännössä, se ei enää tunnu puutteelta.
Todistin sen itselleni yhdellä ajolla. Rakensin JavaScriptillä renderöityvän katalogin testisivun, ohjasin Scrapyn siihen sivuun, jonka selain näyttäisi, ja sain takaisin 0 tuotekorttia. Sitten kohdistin saman spiderin sivun hiljaisesti taustalla kutsumaan JSON-päätepisteeseen ja sain 8/8 kohdetta siististi. Sama työkalu, sama sessio, täysin eri lopputulos — ja juuri tuo ero on tämän arvion ydin.
Mitä Scrapy oikeastaan on — ja mitä se ei ole
Scrapy on Python-kehys sivustojen läpikäyntiin ja jäsennellyn datan poimimiseen. Näin ylläpitäjät itse kuvaavat sitä yleiskatsausdokumentaatiossa, ja käytön jälkeen kuvaus on osuva — mitään markkinointipuhetta ei tarvitse oikoa. Se on tarpeeksi vanha ja vakiintunut ollakseen vakiovastaus, kun Python-kehittäjä kysyy, millä tosissaan dataa kaapitaan. Myös repositorio vahvistaa tämän: noin 62 981 GitHub-tähteä 2026-07-07 (scrapy/scrapy), 11 773 forkia ja 590 avointa issuea samana päivänä. Lisenssi on BSD-3-Clause, Python 3.10 tai uudempi, ja testaamani versio oli 2.17.0 — joka sattui ilmestymään juuri testipäivän aamuna, joten tästä ei tarvitse tähdätä mitään vanhentumismerkintää.
Tässä on se raja, joka erottaa Scrapyn uudemmasta AI-kaapurin joukosta: oletus on HTTP-only. Ei selainta. Ei renderöintimoottoria. Se hakee HTML:n verkon yli, syöttää sen parserille ja antaa sinun poimia kentät CSS-valitsimilla tai XPathilla. Tätä on helppo kutsua rajoitteeksi, mutta se ohittaa koko suunnittelun idean. Scrapyn lähtökohta on, että headless Chromen pyörittäminen tavalliseen kaappaukseen on yleensä väärä ratkaisu — fiksumpi tapa on löytää sivun jo tekemä datapyyntö ja osua siihen suoraan.
Tämä ei ole vain oma tulkintani työkalusta. Viralliset dynaamisen sisällön ohjeet sanovat sen suoraan: etsi ja toista taustalla tehtävä datapyyntö ensin, ja käytä headless-selainta vasta viimeisenä keinona, jos pyynnön toistaminen ei ole käytännöllistä. Useimmat kaapurit avaavat selaimen ensin eivätkä koskaan mieti API:a. Scrapy kääntää oletuksen toisinpäin.
Keskeiset ominaisuudet ja suunnitteluratkaisut niiden taustalla
Taustalla Scrapy koostuu useista osista, ja jokainen niistä lähtee samasta oletuksesta: olet kehittäjä, joka haluaa hallintaa, et yhden klikkauksen taikuria.
Spiderit. Kirjoitat luokan, annat sille aloitus-URL:t ja määrittelet parse-kutsun, joka palauttaa kohteita tai seuraa linkkejä eteenpäin. Tämä on enemmän kirjoittamista kuin no-code-poimijassa — poimintasäännöt ovat sinun määriteltävissäsi — mutta vastineeksi saat tarkan päätäntävallan siitä, mitä talteen otetaan ja minne läpikäynti jatkuu.
Valitsimet. Jäsentäminen perustuu parsel-kirjastoon, jonka alla on lxml. CSS ja XPath ovat molemmat ensiluokkaisia, eivät lisäosia. lxml-pohja pitää valinnan nopeana ja tekee poimintakoodista tarkoituksenmukaista eikä sekavaa merkkijonojen silpomista.
Feed-exportit. Kun ohjaat spiderin tiedostoon, Scrapy serialisoi kohteet JSONiksi, JSON Linesiksi, CSV:ksi tai XML:ksi ilman ylimääräistä liimakoodia. Omassa ajossani yksi staattisen katalogin spideri kirjoitti ulos sekä JSONin että CSV:n ilman ainoatakaan riviä export-koodia — feed export on oikeasti olemassa, ja se tekee sen mitä lupaa.
AutoThrottle ja läpikäynnin hallinta. Pyynnöt ajastetaan asynkronisesti Twistedin päällä, ja käytössäsi ovat rinnakkaisuuden rajat, latausviiveet, syvyysrajat, AutoThrottle mukautuvaan nopeuden säätöön sekä robots.txt:n noudattaminen. Nämä ovat juuri ne hallintakeinot, joilla laaja kaappaus pysyy kurissa eikä muutu palvelinta kuormittavaksi ongelmaksi.
HTTP-only ominaisuutena, ei puutteena. Ilman selainta muistijälki on pieni, läpimeno suuri eikä renderöintimoottoria tarvitse hoivata — kunhan haluamasi data on saatavilla tavallisen HTTP:n kautta. Ja useammin kuin selaintoi-prioriteettia suosiva väki olettaa, näin on.
Asennus: se riippuvuusketju, josta kukaan ei ota kuvakaappausta
Asennus meni käytännössä huomaamatta, ja näin ison kehyksen kohdalla se on syytä sanoa ääneen. pip install Scrapy==2.17.0 valmistui siististi uudessa virtuaaliympäristössä macOS arm64:lla, binääripyörät haettiin valmiina eikä mikään alkanut kääntyä seinää päin. Ei mitään dramaattista raportoitavaa — ja juuri siinä on pointti.
Katsotaan silti, mitä koneeseen tuli. scrapy version -v raportoi Scrapyn 2.17.0:n pyörivän lxml 6.1.1:n, Twisted 26.4.0:n, pyOpenSSL 26.3.0:n ja cryptography 49.0.0:n varassa, ja lisäksi mukana olivat parsel, cssselect ja tldextract. Tämä on aito jalanjälki — kokonaisen läpikäyntikehyksen verran riippuvuuksia, ei vain yksi HTML-parseri. Tällä koneella kaikille löytyi wheelit, joten asennus oli kivuton. Toisissa ympäristöissä virallinen dokumentaatio varoittaa edelleen alustakohtaisesta kitkasta, ja perinteisesti juuri cryptography- ja Twisted-puoli on ollut herkkä kohta, joten siihen kannattaa varautua, jos käytät jotain poikkeavaa alustaa. Asennus oli täällä sulava; silti on reilua tietää etukäteen, kuinka paljon tavaraa mukana tulee, koska kyseessä on oikea kehys ja se painaa juuri sen verran kuin kehys painaa.
Käytännön testit: mikä kesti ja mikä ei
Kun asennus oli tehty, staattinen polku toimi moitteetta. Täysi kattavuus, mitään ei pudonnut matkasta.
| Testi | Tulos | Ajoaika |
|---|---|---|
| Paikallinen staattinen katalogi + sivutus | 12/12 tuotetta | 0.557s |
| Staattisen katalogin CSV-export | 12 riviä kirjoitettu | (sama ajo) |
| Artikkelin poiminta | otsikko + 3/3 leipätekstikappaletta | 0.416s |
| Läpikäyntikaavio, DEPTH_LIMIT=2 | 11 sivua syvyyksissä 0/1/2 | 0.904s |
| Paikallinen 500-sivu | status 500 tallennettu, ei kaatumista | 0.424s |
| Books to Scrape (julkinen) | 20 tuotetta | 2.053s |
| Quotes to Scrape spider (julkinen) | 12 sitaattikohdetta | 3.465s |
Staattisen katalogin spider kulki sivutuksen sivulta yksi sivulle kaksi ja poimi 12/12 odotettua tietuetta, minkä jälkeen se kirjoitti ne ulos sekä JSONina että CSV:nä samalla ajolla. Artikkelipohja on se, johon kannattaa pysähtyä. Scrapy ei yrittänyt automaattisesti siivota sivua siistiksi Markdowniksi — sen sijaan pystyin kohdistamaan article-kenttiin tarkat valitsimet ja pitämään navigaation ja alatunnisteen erillisinä kenttinä, jolloin sain 3/3 leipätekstikappaletta ja samalla turhateksti pysyi eristettynä eikä sekoittunut tulokseen. Tässä on vaihtokauppa: kirjoitat valitsimet itse, saat juuri sen mitä pyysit — et mitään ylimääräistä.
Läpikäynnin hallinta toimi pienessä mittakaavassa hyvin. Kun käytössä oli DEPTH_LIMIT=2, lyhyt latausviive, domain-kohtainen rinnakkaisuus ja robots.txt päällä, läpikäyntikaavio näki 11 sivua syvyyksissä 0, 1 ja 2, ja syvyyslaskenta toimi oikein. Virheenkäsittely oli yhtä arkista. Tahallisesti rakennettu 500-sivu palasi jäsenneltynä iteminä, jossa status 500 tuli näkyviin handle_httpstatus_listin kautta — ei poikkeusta, ei kuollutta ajoa. Scrapy käsittelee virhetilan asiana, jonka hoidat spiderin logiikassa, eikä yllätyksenä, joka kaataa koko läpikäynnin.
Käytännön testi: JavaScript-seinä ja sen vieressä oleva ovi
Nyt siihen tulokseen, jonka ympärille tämä arvio rakentuu.
Ohjasin Scrapyn HTTP-hakijan JavaScriptillä renderöityvään katalogin testisivuun. Se latasi lähde-HTML:n, löysi 0 .product-card-solmua ja jatkoi eteenpäin — koska se ei koskaan ajanut skriptiä, joka olisi piirtänyt nämä kortit näkyviin. Sama tarina näkyi julkisella Quotes to Scrape JS -sivulla: 0 renderöityä sitaattisolmua. Jos lopettoisit testin tähän, pitäisit Scrapyä sopimattomana kaikkeen, mikä on rakennettu tällä vuosikymmenellä.
Mutta siihen ei pidä lopettaa. Kyseinen JS-katalogi täyttyi taustalla JSON API:sta, kuten useimmat vastaavat sivut tekevät. Kohdistin saman Scrapy-spiderin siihen päätepisteeseen ja sain 8/8 tuotetta 0.416 sekunnissa — ei selainta, ei renderöintiä, vain pyyntö siihen URL:iin, jota sivu jo valmiiksi kutsui, ja saapuneen JSONin jäsentäminen.
Tämä rinnakkaisnäyttö on pienoismalli ajatuksesta “toista pyyntö”. Renderöity sivu on harhautus; data oli koko ajan API:n takana, ja Scrapyn suunnittelu ohjaa sinut osumaan suoraan siihen sen sijaan, että maksaisit headless-selaimelle siitä, että se istuu katsomassa sivun rakentumista. Se on nopeampaa, kevyempää ja hajoaa harvemmin — API-sopimus on vakaampi kohde kuin joukko client-side DOMia. Mutta tässä on koukku: se on manuaalista työtä. Sinun täytyy avata verkkovälilehti, löytää pyyntö ja toistaa sen otsikot ja parametrit itse. Scrapy ei etsi API:a puolestasi; se tekee siihen osumisesta helppoa vasta, kun olet jo löytänyt sen.
Kaksi rajaa, suoraan sanottuna. Kun taustalla ei oikeasti ole toistettavaa pyyntöä — eli data on upotettu client-side-renderöintiin ilman API:a — Scrapy tarvitsee headless-selaimen integraation, jonka joudut itse kytkemään, enkä testannut tuota polkua tässä arviossa. Ja kaikki yllä oleva ajettiin pienillä testiaineistoilla ja julkisilla demoisivustoilla. En ajanut 100–1 000 sivun läpikäyntiä, joten en väitä mitään muistinkäytöstä, läpimenosta tai retry-käyttäytymisestä skaalassa — asynkroninen ydin ja läpikäynnin hallinta lupaavat paljon, mutta lupaus ei ole vielä mittaus.
Plussat ja miinukset
Plussat:
- HTTP-only-malli on nopea ja kevyt — 12/12 staattista tulosta noin puolessa sekunnissa, 8/8 JSON API:sta 0.416 sekunnissa, ei selaimen overheadia.
- Toista-pyyntö-ajattelu toimii oikeasti: JS-sivu, joka palautti 0, antoi kaikki 8 itemiä taustalla olevan API:n kautta.
lxml-pohjaiset CSS- ja XPath-valitsimet pitävät poimintakoodin luettavana ja nopeana.- Feed-exportit JSONiin/CSV:hen/XML:ään ilman erillistä export-koodia.
- Selkeä virheenkäsittely — 500 palautuu käsiteltävänä statuksena, ei kaatumisena.
- Vakiintunut läpikäynnin hallinta: rinnakkaisuus, viiveet, syvyysrajat, AutoThrottle, robots.txt.
- BSD-3-Clause-lisenssi; siisti asennus nykykoneella.
Miinukset:
- Ei renderöi JavaScriptiä oletuksena — client-renderöidyllä sivulla näkyy 0 solmua, kunnes löydät API:n itse.
- Taustalla olevan pyynnön löytäminen on manuaalista; Scrapy ei ohjaa sinua päätepisteeseen.
- Melko suuri riippuvuusketju (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — tässä kaikki toimi hyvin, mutta poikkeavilla alustoilla se on ollut perinteisesti kitkakohta.
- Enemmän koodia kuin no-code- tai automaattiset poimintatyökalut; spiderit kirjoitat ja ylläpidät itse.
- Testini kattoi pieniä aineistoja ja demosivustoja, ei suuria massaläpykäyntejä — skaalautuvuuden luotettavuutta ei ole tässä passissa vielä todistettu.
Kenelle tämä sopii — ja kenen kannattaa kulkea ohi
Scrapy on kehittäjille, jotka haluavat kooditason hallintaa ja ajattelevat pyyntöinä, eivät sivuina. Jos hidas JavaScript-sivusto saa sinut ajattelemaan: "tässä on varmasti API jossain", työkalu on rakennettu juuri tuolle vaistolle. Se palkitsee ihmisiä, joille valitsimien kirjoittaminen, verkkovälilehden lukeminen ja poimintalogiikan omistaminen päästä end-to-end on luontevaa. Staattisille sivustoille, sivutetuille katalogeille ja kaikelle, mikä perustuu löydettävissä olevaan JSON-päätepisteeseen, se on nopea ja tarkka.
Kävele ohi — tai ainakin yhdistä se johonkin muuhun — jos spider-koodin kirjoittaminen ja ylläpito ei ole tapasi käyttää aikaasi, tai jos kohteesi renderöivät datan täysin client-side ilman toistettavaa pyyntöä ja et halua itse lisätä headless-selainta mukaan. Ja jos unelma oli osoittaa työkalu URL:iin ja saada siisti jäsennelty tulos ilman poimintasääntöjen kirjoittamista, se ei koskaan ollut Scrapyn tehtävä, eikä se ole koskaan väittänyt olevansa sitä.
Vaihtoehdot ja missä Thunderbit tulee kuvaan
Kokeile Thunderbitia verkkodatan poimintaan
Lähde liikkeelle siitä, mihin sitoudut: ilmaiseen, avoimen lähdekoodin kehykseen, jota ajat ja ylläpidät itse. Omistat spiderit, riippuvuusketjun ja työn, jolla löydät kunkin sivuston datapyynnön. Vastineeksi et maksa per pyyntö, pidät kaiken omissa käsissäsi ja saat tarkan hallinnan. Monelle tiimille tämä on oikea ratkaisu, eikä tämän arvion tarkoitus ole puhua ketään siitä pois.
Vaihtokauppa näkyy renderöinti- ja drift-ongelmassa, ja Scrapyn vastaus on, että sinä ratkaiset sen: etsit API:n, toistat pyynnön ja hoidat API-vapaan tapauksen kytkemällä selaimen itse mukaan. Hallittu AI-kaappaus-API ottaa tuon kerroksen pois harteiltasi. Siihen lokeroon Thunderbit asettuu teknisille lukijoille — AI-kaappaus-API, MCP-serveri ja CLI, ei selainlaajennus, jota myynti- ja operatiivinen porukka käyttää. POST /distill muuntaa sivun siistiksi, LLM-valmiiksi Markdowniksi; POST /extract palauttaa jäsennellyn JSONin määrittelemäsi skeeman mukaan; ja molemmat käsittelevät JavaScript-renderöinnin, bottisuojat ja dynaamisen sisällön palvelinpuolella — myös sen client-side-renderöidyn tapauksen, jossa Scrapy kehottaa sinua tarttumaan selaimeen. Mukana on MCP-serveri AI-agenteille ja koodausavustajille (sekä ilmainen thunderbit_suggest_fields, jolla voit rajata sivun ennen kuin kulutat mitään), ja CLI npx @thunderbit/thunderbit-cli -komennolla terminaali-, CI- tai cron-ajoon.
Ero ei ole laatu, vaan omistus. Scrapy on selkeä kehitysframework: ylläpidät spiderin, putken ja JavaScript-strategian itse, ja saat täyden kontrollin ilman per-kutsun kustannusta. Thunderbitin stack siirtää renderöinti- ja poimintakerroksen hallittuna palveluna ulos omista käsistäsi, joten voit skipata verkkovälilehden penkomisen ja maksaa sen sijaan per kutsu. Pieni, koodikeskeinen tiimi ja tykkäät omistaa jokaisen vaiheen? Scrapyn kontrolli sopii paremmin. Skaalaat sadan sivuston yli etkä halua toistaa pyyntöä käsin jokaiselle? Hallittu malli poistaa koko työluokan.
Laajempaan kenttään liittyen nämä benchmark-kirjoitukset käsittelevät naapureita: täysi avoimen lähdekoodin kaapureiden vertailu, Collyn selaimettoman Go-crawlerin arvio ja Scraplingin adaptiivisten valitsimien arvio.
Tuomio
Kannattaako Scrapyä käyttää? Kyllä — jos olet kehittäjä, joka haluaa kontrollia ja hyväksyy maailmankuvan: älä renderöi sivua, vaan etsi sen takana oleva pyyntö. Testeissä tämä filosofia toimi juuri niin kuin lupaus antaa ymmärtää. JavaScript-katalogi antoi HTTP-hakijalle 0 korttia; sitä ruokkiva JSON API luovutti kaikki 8 kohdetta samalle spiderille. Staattinen poiminta osui 12/12 oikein, artikkelivalitsimet pitivät 3/3 kappaletta puhtaina turhatekstistä, läpikäyntikaavio kunnioitti syvyysrajaa 11 sivun läpi, ja 500 palautui käsiteltynä statuksena eikä kaatumisena.
Pidä kuitenkin väitteet oikeassa mittakaavassa. Scrapy ei renderöi JavaScriptiä, eikä se löydä API:a puolestasi — tuo vaisto on sinun rakennettava. Riippuvuusketju on aidosti kehysluokkaa ja voi pureutua oudoilla alustoilla, vaikka täällä kaikki meni siististi. Ja koska testasin testiaineistoja ja demosivuja enkä tuhannen sivun läpikäyntiä, skaalaa koskeva tarina kannattaa nähdä lupaavana, ei vielä todistettuna. Näiden rajojen sisällä Scrapy on työkalu, joka sitoutuu hiljaisen radikaaliin ajatukseen: nopein tie web-sivun läpi ei useimmiten kulje web-sivun kautta lainkaan.
Kokeile Thunderbitia verkkodatan poimintaan Get Started Free
Usein kysytyt kysymykset
Voiko Scrapy kaapia JavaScriptillä renderöityjä sivuja? Ei oletus-HTTP-hakijallaan — se palautti 0 solmua sekä JS-testisivulla että julkisella Quotes JS -sivulla, koska se lataa HTML:n ilman selaimen ajamista. Tarkoitus on löytää sivun tekemä taustadata-pyyntö ja osua siihen suoraan; omassa testissä JSON API, joka ruokki JS-katalogia, luovutti kaikki 8 kohdetta. Sivuille, joilla ei ole toistettavaa pyyntöä, kytket headless-selaimen itse mukaan.
Mitä "toista pyyntö" käytännössä tarkoittaa? Useimmat dynaamiset sivut lataavat datansa taustalla JSON API:sta ja renderöivät sen sitten client-side. Sen sijaan, että ajaisit selainta katsomaan tuota prosessia, avaat verkkovälilehden, etsit kyseisen API-kutsun ja ohjaat Scrapyn suoraan siihen. Se on nopeampaa ja vakaampaa kuin renderöinti — API-sopimus hajoaa harvemmin kuin DOM — mutta se on manuaalista työtä, eikä Scrapy löydä päätepistettä puolestasi.
Onko Scrapy vaikea asentaa?
Minulle se oli helppo — pip install Scrapy==2.17.0 valmistui ilman käännösvirheitä uudessa venvissä macOS:lla binääripyörien avulla. Mutta se vetää mukanaan melkoisen pinon (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), ja virallinen dokumentaatio varoittaa edelleen alustakohtaisesta kitkasta joillain järjestelmillä, joten siihen kannattaa varautua, jos käytät jotain erikoisempaa.
Mitä tiedostomuotoja Scrapy tukee? Feed-exportit kattavat oletuksena JSONin, JSON Linesin, CSV:n ja XML:n — ohjaa spider tiedostoon, ja se serialisoi kohteesi ilman lisäkoodia. Omassa ajossani yksi spider tuotti yhdellä ajolla sekä JSONin että CSV:n. Huomaa, että se exportoi valitsemasi kentät; se ei automaattisesti siivoa sivua Markdowniksi.
Onko Scrapy ilmainen kaupalliseen käyttöön? Kyllä, se on BSD-3-Clause-lisensoitu, eli salliva ja kaupallisesti ystävällinen. Kuten aina, tarkista ajantasainen lisenssi repositoriosta ennen kuin rakennat sen varaan, ja pidä käyttäjäagentti-, proxy- ja rate limit -valintasi vastuullisina — kyvykkyys ei ole sama asia kuin lupa.
