Scrapy blir ofte plassert i boksen «klarer ikke moderne nettsteder» fordi det ikke kjører JavaScript. Det ryktet er egentlig bakvendt. Å ikke rendere siden er selve poenget, og når du ser det i praksis, slutter det å se ut som en manglende funksjon.
Jeg beviste det for meg selv i én enkelt kjøring. Jeg bygde en katalogtest som ble rendret med JavaScript, pekte Scrapy mot siden slik en nettleser ville vist den, og fikk tilbake 0 produktkort. Så rettet jeg den samme spideren mot JSON-endepunktet siden i all stillhet kalte i bakgrunnen, og fikk 8/8 elementer tilbake, rent og pent. Samme verktøy, samme økt, helt motsatte resultater — og gapet mellom de to tallene er hele utgangspunktet for denne anmeldelsen.
Hva Scrapy egentlig er (og ikke er)
Scrapy er et Python-rammeverk for å krype gjennom nettsteder og hente ut strukturert data. Det er utviklernes egen beskrivelse i oversiktsdokumentasjonen, og etter å ha brukt det kan jeg si at den stemmer — ingen markedsføringsmessig overdrivelse å korrigere her. Det er gammelt og etablert nok til å være standardsvaret når en Python-utvikler spør hva seriøse folk bruker til scraping, og repositoriet bekrefter det: omtrent 62 981 GitHub-stjerner per 2026-07-07 (scrapy/scrapy), med 11 773 forks og 590 åpne issues samme dag. BSD-3-Clause-lisens, Python 3.10 eller nyere, og versjonen jeg testet var 2.17.0, som tilfeldigvis ble sluppet morgenen jeg kjørte disse testene — så her er det ingen «gammel versjon»-forbehold.
Her er linjen som skiller det fra den nyere AI-crawler-gjengen: Scrapy er som standard kun HTTP-basert. Ingen nettleser. Ingen renderingsmotor. Det laster ned HTML over nettet, sender det til en parser, og lar deg hente ut felter med CSS-selektorer eller XPath. Å kalle det en begrensning er delvis sant, men det bommer på hele designideen. Premisset til Scrapy er at det som oftest er feil å starte en headless Chrome for en rutinemessig scraping-oppgave — den smartere veien er å finne data-forespørselen siden allerede gjør, og treffe den direkte.
Det premisset er ikke noe jeg legger over på verktøyet. Den offisielle dokumentasjonen om dynamisk innhold sier det rett ut: finn og gjenskap den underliggende dataforespørselen først, og bruk headless nettleser bare som en reserve når det ikke er praktisk å reprodusere forespørselen. De fleste scrapers åpner nettleseren først og tenker aldri på API-et. Scrapy snur standardvalget.
Viktige funksjoner, og designvalget bak hver av dem
Under panseret er Scrapy satt sammen av flere deler, og hver av dem tar ett utgangspunkt for gitt: at du er en utvikler som vil ha kontroll, ikke en tryllestav med ett klikk.
Spiders. Du skriver en klasse, gir den start-URL-er og definerer en parse-callback som enten sender ut items eller følger flere lenker. Det er mer å skrive enn i en no-code-uttrekker — du eier selv reglene for uthenting — men til gjengjeld får du presis kontroll over hva som samles inn og hvor crawlen går videre.
Selektorer. Parsing bygger på parsel, som igjen ligger på lxml. Både CSS og XPath er førsteklasses, ikke påmonterte tillegg. Det er lxml-grunnmuren som gjør at utvelgelsen holder seg rask, og som gjør at koden leses som en intensjon i stedet for som et virvar av strengmanipulering.
Feed-eksport. Pek en spider mot en fil, så serialiserer Scrapy itemene dine til JSON, JSON Lines, CSV eller XML uten ekstra limkode. I min kjøring skrev én spider både JSON og CSV uten at jeg måtte skrive en eneste linje med eksportkode — feed export-historien er ekte, og den gjør det den lover.
AutoThrottle og crawl-kontroller. Forespørsler planlegges asynkront på Twisted, og du får grenser for samtidighet, nedlastingsforsinkelser, dybdebegrensninger, AutoThrottle for adaptiv hastighetskontroll og obeying av robots.txt. Dette er kontrollene som hindrer at en bred crawl blir til en serverhamrende hendelse.
Kun HTTP, omtalt på nytt som en styrke. Ingen nettleser betyr lavt minneforbruk, høy throughput og ingen renderingsmotor å holde i gang — så lenge dataene du vil ha er tilgjengelige over vanlig HTTP. Og det er de, oftere enn browser-first-miljøet tror.
Oppsett: avhengighetsstakken ingen tar skjermbilde av
Installasjonen var helt udramatisk, og for et rammeverk i denne størrelsen er det verdt å si eksplisitt. pip install Scrapy==2.17.0 gikk rent i et ferskt virtuelt miljø på macOS arm64, med binærhjul og uten at noe måtte kompileres i stykker. Ingenting spektakulært å rapportere — og det er poenget.
Men se på hva som faktisk ble installert. scrapy version -v viste Scrapy 2.17.0 oppå lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 og cryptography 49.0.0, med parsel, cssselect og tldextract som resten av følget. Det er en ekte fotavtrykk — hele settet av avhengigheter som hører til et crawl-rammeverk, ikke en enkel HTML-parser i én fil. På denne maskinen fantes det wheels for alt, så installasjonen forble smertefri. På andre oppsett advarer de offisielle dokumentene fortsatt om plattformspesifikk friksjon, og historisk er det ofte cryptography- og Twisted-delen av stakken som skaper trøbbel, så regn med det hvis du kjører på noe uvanlig. Oppsettet var smidig her; størrelsen på det som installeres er likevel nyttig å vite før du bestemmer deg, fordi du faktisk drar inn et rammeverk — og et rammeverk veier som et rammeverk.
Praktisk test: hva som holdt mål
Da det først var installert, fungerte den statiske veien uten problemer. Full treffrate, ingenting falt ut.
| Test | Resultat | Kjøretid |
|---|---|---|
| Lokal statisk katalog + paginering | 12/12 produkter | 0,557s |
| CSV-eksport av statisk katalog | 12 rader skrevet | (samme kjøring) |
| Artikkeluttrekk | tittel + 3/3 brødtekstavsnitt | 0,416s |
| Crawl-graf, DEPTH_LIMIT=2 | 11 sider på dybde 0/1/2 | 0,904s |
| Lokal 500-side | status 500 fanget, ingen krasj | 0,424s |
| Books to Scrape (offentlig) | 20 produkter | 2,053s |
| Quotes to Scrape spider (offentlig) | 12 sitat-elementer | 3,465s |
Spideren for den statiske katalogen gikk gjennom pagineringen fra side én til side to og fanget 12/12 forventede poster, og skrev dem deretter ut som JSON og CSV i samme pass. Artikkeltesten er den som er mest verdt å dvele ved. Scrapy forsøkte ikke å auto-renske siden til pen Markdown — i stedet lot det meg målrette article-felter med eksplisitte selektorer og la navigasjon og bunntekst i egne felt, så jeg fikk 3/3 brødtekstavsnitt med standardtekst holdt i sjakk i stedet for smurt utover outputen. Det er byttet: du skriver selektorene, og får akkurat det du ba om — og ikke noe du ikke ba om.
Crawl-kontrollen fungerte fint i liten skala. Med DEPTH_LIMIT=2, en kort nedlastingsforsinkelse, per-domene-samtidighet og robots.txt på, så crawl-grafen 11 sider på tvers av dybdene 0, 1 og 2, og dybdetellingen oppførte seg som den skulle. Feilhåndteringen var like udramatisk. Den bevisst feilende 500-siden kom tilbake som et strukturert item med status 500 synlig via handle_httpstatus_list — ingen exception, ingen død kjøring. Scrapy behandler en feilkode som noe du håndterer i spider-logikken, ikke som en overraskelse som velter hele crawlen.
Praktisk test: JavaScript-veggen og døren ved siden av
Nå til resultatet hele denne anmeldelsen bygger på.
Jeg pekte Scrapy sin HTTP-føler mot en katalogtest som ble rendret med JavaScript. Den lastet ned kilde-HTML-en, fant 0 .product-card-noder og gikk videre — fordi den aldri kjørte skriptet som ville ha tegnet kortene. Den offentlige Quotes to Scrape JS-siden fortalte samme historie: 0 rendrerte sitatnoder. Hadde testen stoppet der, ville du skrevet av Scrapy som ubrukelig for alt som er bygget dette tiåret.
Men ikke stopp der. Den JS-katalogen ble fylt via et JSON-API i bakgrunnen, slik de fleste av dem blir. Jeg pekte samme Scrapy-spider mot det endepunktet og fikk 8/8 produkter tilbake på 0,416s — ingen nettleser, ingen rendering, bare en forespørsel til URL-en siden allerede kalte og en parse av JSON-en som kom tilbake.
Den side-ved-side-testen er filosofien om å gjenskape forespørselen i miniatyr. Den rendrerte siden er et skalkeskjul; dataene lå bak et API hele tiden, og designet til Scrapy leder deg mot å treffe det direkte i stedet for å betale for at en headless nettleser skal stå og se en side bygges opp. Det er raskere, lettere og mindre skjørt — en API-kontrakt er mer stabil å stole på enn en haug med DOM som bygges på klientsiden. Ulempen er at det er manuelt. Du må åpne nettverksfanen, finne forespørselen og gjenskape headere og parametere selv. Scrapy finner ikke API-et for deg; det gjør bare treffet trivielt når du først har funnet det.
To grenser, sagt helt tydelig. Når det faktisk ikke finnes noen underliggende forespørsel å gjenskape — data er bygd inn via klientside-rendering uten noe API bak — trenger Scrapy en headless-browser-integrasjon du selv kobler inn, og den veien testet jeg ikke i denne runden. Og alt over kjørte på små testoppsett og offentlige demosider. Jeg kjørte ikke en crawl på 100 til 1 000 sider, så jeg sier ingenting om minnebruk, throughput eller retry-atferd i stor skala — den asynkrone kjernen og crawl-kontrollene er sterke signaler, men et signal er ikke en måling.
Fordeler og ulemper
Fordeler:
- HTTP-only-designen er rask og lett — 12/12 statisk treffrate på omtrent et halvt sekund, 8/8 fra et JSON-API på 0,416s, og null nettleseroverhead.
- Tilnærmingen med å gjenskape forespørselen leverer faktisk: en JS-side som ga 0, slapp alle 8 elementene gjennom det underliggende API-et.
- CSS- og XPath-selektorer basert på
lxmlgjør uttrekket lesbart og raskt. - Feed-eksport til JSON/CSV/XML uten at du må skrive eksportkode.
- Tydelig feilhåndtering — en 500 kommer tilbake som en status du kan fange, ikke som et krasj.
- Modne crawl-kontroller: samtidighet, forsinkelser, dybdegrenser, AutoThrottle og robots.txt.
- BSD-3-Clause-lisens med god vilje for bruk i kommersielle prosjekter; ren installasjon på en moderne maskin.
Ulemper:
- Renderer ikke JavaScript per design — 0 noder på en klientside-rendret side før du selv finner API-et.
- Det er manuelt å finne den underliggende forespørselen; Scrapy peker deg ikke til endepunktet.
- Stor avhengighetsstakk (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — gikk fint her, men har historisk vært en friksjonskilde på uvanlige plattformer.
- Mer kode enn no-code- eller auto-uttrekksverktøy; spiders må du skrive og vedlikeholde selv.
- Testingen min dekket små testoppsett og demosider, ikke store crawls — stabilitet i stor skala er ikke bevist i denne runden.
Hvem det passer for, og hvem som bør gå videre
Scrapy passer for utviklere som vil ha kontroll på kodenivå og tenker i forespørsler, ikke i sider. Hvis den første reaksjonen din på et tregt JavaScript-nettsted er «det finnes sikkert et API et sted her», er dette verktøyet laget for akkurat den instinkten. Det belønner folk som er komfortable med å skrive selektorer, lese nettverksfanen og eie hele ekstraksjonslogikken fra ende til annen. For statiske nettsteder, paginerte kataloger og alt som ligger bak et oppdagbart JSON-endepunkt, er det raskt og presist.
Gå videre — eller koble det i det minste sammen med noe annet — hvis du ikke ønsker å bruke tiden din på å skrive og vedlikeholde spiderkode, eller hvis målene dine rendrer dataene rent klientside uten noe reproduserbart forespørselsspørsmål og du ikke vil bygge på en headless nettleser selv. Og hvis drømmen var å peke et verktøy mot en URL og få ut ren strukturert data uten å skrive ekstraksjonsregler, så var det aldri Scrapy sin jobb — og det har det aldri utgitt seg for å være.
Alternativer, og hvor Thunderbit passer inn
Prøv Thunderbit for uttrekk av webdata
Start med hva du faktisk forplikter deg til: et gratis, åpen kildekode-rammeverk du kjører og vedlikeholder selv. Du eier spiderne, avhengighetsstakken og arbeidet med å finne dataforespørselen for hvert enkelt nettsted. Til gjengjeld betaler du ingenting per forespørsel, beholder alt internt og får nøyaktig kontroll. For mange team er det det riktige valget, og denne anmeldelsen er ikke her for å overtale noen bort fra det.
Avveiningen ligger i problemet med rendering og endringer i nettsider, og Scrapy sitt svar er at du løser det: du finner API-et, gjenskaper forespørselen og håndterer tilfeller uten API ved å koble inn en nettleser selv. Et administrert AI-scraping-API løfter det laget av skuldrene dine i stedet. Det er der Thunderbit-stakken passer for tekniske lesere — et AI-scraping-API pluss MCP-server pluss CLI, ikke nettleserutvidelsen salg- og driftsfolk bruker. POST /distill gjør en side om til ren Markdown klar for LLM-er; POST /extract returnerer strukturert JSON basert på et skjema du definerer; og begge håndterer JavaScript-rendering, anti-bot og dynamisk innhold på serversiden — også klientside-rendret innhold der Scrapy ber deg om å bruke nettleser. Det finnes en MCP-server for AI-agenter og kodeassistenter (med gratis thunderbit_suggest_fields for å kartlegge en side før du bruker noe som helst), og en CLI via npx @thunderbit/thunderbit-cli for terminal, CI eller cron-jobber.
Forskjellen handler ikke om kvalitet, men om eierskap. Scrapy er et eksplisitt ingeniørrammeverk: du vedlikeholder spideren, pipelinen og JS-strategien, og får full kontroll uten kostnad per kall. Thunderbit-stakken tar over render- og uthentingslaget som en administrert tjeneste, så du slipper å grave i nettverksfanen og betaler per kall i stedet. Lite, kodeorientert og du liker å eie hvert steg? Da passer Scrapy bedre. Skal du skalere på tvers av hundre nettsteder og helst slippe å gjenskape en forespørsel manuelt for hvert nettsted? Den administrerte veien fjerner hele den kategorien arbeid.
For det bredere feltet dekker disse benchmark-artiklene naboene: den fullstendige sammenligningen av åpen kildekode-scrapere, Colly-anmeldelsen av den nettleserløse Go-crawleren og Scrapling-anmeldelsen av adaptive selektorer.
Konklusjon
Bør du bruke Scrapy? Ja — hvis du er utvikler, vil ha kontroll og kjøper verdensbildet: ikke render siden, finn forespørselen bak den. I testene fungerte den filosofien akkurat slik den lover. En JavaScript-katalog ga HTTP-føleren 0 kort; JSON-API-et som matet den ga opp alle 8 elementene til samme spider. Statisk uttrekk traff 12/12, artikkelselektorene holdt 3/3 avsnitt fri for standardtekst, crawl-grafen respekterte dybdegrensen over 11 sider, og en 500-feil kom tilbake som en håndtert status i stedet for et krasj.
Men vær nøye med å vekte påstandene riktig. Scrapy renderer ikke JavaScript, og det finner ikke API-et for deg — den refleksen må du bygge selv. Avhengighetsstakken er stor nok til å ligne et ekte rammeverk, og kan bite på rare plattformer selv om det gikk rent her. Og jeg testet testoppsett og demosider, ikke en crawl på tusen sider, så behandl skaleringshistorien som lovende, men ikke bevist. Innenfor de rammene er Scrapy verktøyet som mest konsekvent omfavner en stille radikal idé: den raskeste veien gjennom en nettside går ofte ikke gjennom nettsiden i det hele tatt.
Prøv Thunderbit for uttrekk av webdata Get Started Free
Vanlige spørsmål
Kan Scrapy skrape JavaScript-rendrerte sider? Ikke med standard HTTP-føler — den ga 0 noder både på en JS-test og på den offentlige Quotes JS-siden, fordi den laster ned HTML uten å kjøre en nettleser. Den tiltenkte veien er å finne den underliggende dataforespørselen siden bruker, og treffe den direkte; i testen min ga JSON-API-et bak en JS-katalog opp alle 8 elementene. For sider uten en reproduserbar forespørsel må du selv koble inn en headless nettleser.
Hva betyr egentlig «gjenskape forespørselen»? De fleste dynamiske sider laster inn data fra et JSON-API i bakgrunnen, og rendrer det deretter på klientsiden. I stedet for å kjøre en nettleser og se det skje, åpner du nettverksfanen, finner API-kallet og peker Scrapy direkte mot det. Det er raskere og mer stabilt enn rendering — en API-kontrakt bryter sjeldnere enn en DOM — men det er manuelt arbeid, og Scrapy finner ikke endepunktet for deg.
Er Scrapy vanskelig å installere?
For meg var det rett frem — pip install Scrapy==2.17.0 fullførte uten kompileringsfeil i et ferskt venv på macOS med binærhjul. Men det drar inn en ganske stor stakk (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), og de offisielle dokumentene advarer fortsatt om plattformspesifikk friksjon på enkelte systemer, så ta høyde for det hvis du kjører på noe uvanlig.
Hvilke output-formater støtter Scrapy? Feed-eksport dekker JSON, JSON Lines, CSV og XML rett ut av boksen — pek en spider mot en fil, så serialiserer den itemene dine uten ekstra kode. I min kjøring produserte én spider både JSON og CSV i én og samme runde. Merk at den eksporterer feltene du har valgt; den gjør ikke automatisk en side om til Markdown.
Er Scrapy gratis til kommersiell bruk? Det er BSD-3-Clause, som er permisiv og godt egnet for kommersiell bruk. Som alltid bør du bekrefte gjeldende lisens i repoet før du bygger videre på det, og sørge for ansvarlige valg av user-agent, proxy og rate limit — evne er ikke det samme som tillatelse.
