Scrapy hamnar ofta i facket "klarar inte moderna webbplatser" eftersom det inte kör JavaScript. Men den bilden är felvänd. Att inte rendera sidan är hela poängen, och när man väl ser idén i praktiken känns det inte längre som en sak som saknas.
Jag bevisade det för mig själv i ett enda körningstillfälle. Jag byggde ett katalogtest som renderas med JavaScript, pekade Scrapy mot sidan som en webbläsare skulle visa, och fick tillbaka 0 produktkort. Sedan riktade jag samma spider mot JSON-endpointen som sidan i smyg anropade i bakgrunden och fick 8/8 objekt, helt rent. Samma verktyg, samma session, helt olika resultat — och just glappet mellan de två siffrorna är hela poängen med den här recensionen.
Vad Scrapy faktiskt är — och inte är
Scrapy är ett Python-ramverk för att crawla webbplatser och plocka ut strukturerad data. Det är deras egen beskrivning i översiktsdokumentationen, och efter att ha använt det stämmer det bra — ingen marknadsföring behöver tonas ned. Det är tillräckligt gammalt och etablerat för att vara standardsvaret när en Pythonutvecklare frågar vad seriösa folk använder för scraping, och GitHub-statistiken bekräftar det: ungefär 62 981 GitHub-stjärnor per 2026-07-07 (scrapy/scrapy), med 11 773 forks och 590 öppna ärenden samma dag. BSD-3-Clause-licens, Python 3.10 eller nyare, och versionen jag testade var 2.17.0, som råkade släppas samma morgon som jag körde dessa tester — alltså ingen “föråldrad version”-brasklapp här.
Här går skiljelinjen mot den nyare AI-crawler-världen: Scrapy är som standard endast HTTP. Ingen webbläsare. Ingen renderingsmotor. Den hämtar HTML över nätet, skickar den till en parser och låter dig lyfta ut fält med CSS-selektorer eller XPath. Att kalla det en begränsning är delvis rätt, men det missar själva designen. Scrapys utgångspunkt är att starta en headless Chrome för en rutinmässig scraping ofta är fel väg — den smartare vägen är att hitta den dataförfrågan sidan redan gör och anropa den direkt.
Det är inte bara min tolkning av verktyget. I de officiella dokumenten om dynamiskt innehåll sägs det rakt ut: hitta och återupprepa den underliggande dataförfrågan först, och använd en headless browser först som reservlösning när det inte är praktiskt att reproducera den. De flesta scrapers öppnar webbläsaren direkt och tänker aldrig på API:t. Scrapy vänder på standardläget.
Viktiga funktioner och designvalet bakom varje del
Under huven består Scrapy av flera delar som alla utgår från samma sak: att du är en utvecklare som vill ha kontroll, inte en guide där allt sker med ett klick.
Spiders. Du skriver en klass, ger den start-URL:er och definierar en parse-callback som lämnar vidare data eller följer fler länkar. Det är mer kod än i en no-code-extraktor — extraktionsreglerna skriver du själv — men i gengäld får du exakt kontroll över vad som samlas in och vart crawlen ska härnäst.
Selektorer. Parsningen bygger på parsel, som i sin tur använder lxml. CSS och XPath är båda förstklassiga medborgare, inte tillägg. Att lxml ligger under huven är också skälet till att selektionen är snabb och att extraktionskoden känns uttrycksfull istället för som ett virrvarr av strängmanipulation.
Feed exports. Rikta en spider mot en fil så serialiserar Scrapy dina objekt till JSON, JSON Lines, CSV eller XML utan extra infrastruktur. I min körning skrev en spider för en statisk katalog ut både JSON och CSV utan att jag behövde skriva en enda rad exportkod — feed export-delen är verklig och gör det den lovar.
AutoThrottle och crawl-kontroller. Förfrågningar schemaläggs asynkront via Twisted, och du får gränser för samtidighet, nedladdningsfördröjning, djupbegränsningar, AutoThrottle för adaptiv rate limiting samt respekt för robots.txt. Det här är kontrollerna som hindrar en bred crawl från att bli en servermisshandel.
Endast HTTP, fast som en styrka. Ingen webbläsare betyder låg minnesanvändning, hög throughput och ingen renderingsmotor att underhålla — förutsatt att datan du vill åt går att nå via vanlig HTTP. Och det gör den, oftare än webbläsarförst-lägret brukar anta.
Installation: beroendestacken som ingen visar i skärmdumpar
Installationen var odramatisk, och för ett ramverk i den här storleken är det värt att säga rakt ut. pip install Scrapy==2.17.0 gick igenom utan problem i en ny virtuell miljö på macOS arm64, med binära wheels och utan att något behövde kompileras till döds. Inget särskilt att rapportera — och det är just poängen.
Men titta på vad som faktiskt följde med. scrapy version -v visade att Scrapy 2.17.0 körde ovanpå lxml 6.1.1, Twisted 26.4.0, pyOpenSSL 26.3.0 och cryptography 49.0.0, med parsel, cssselect och tldextract som kompletterande delar. Det är en rejäl footprint — ett helt crawlningsramverk med tillhörande beroenden, inte en ensam HTML-parser i en fil. På just den här maskinen fanns wheels för allt och installationen förblev smidig. På andra miljöer varnar den officiella dokumentationen fortfarande för plattformsberoende friktion, och historiskt är det ofta cryptography- och Twisted-delen av stacken som ställer till det, så planera för det om du kör på något ovanligt. Här gick allt bra; men storleken på det som installeras är fortfarande bra att känna till innan du bestämmer dig, eftersom du faktiskt tar in ett ramverk — och ett ramverk väger som ett ramverk.
Praktiskt test: det som höll ihop
När det väl var installerat fungerade den statiska vägen utan problem. Full träffsäkerhet, inget som tappades.
| Test | Resultat | Körningstid |
|---|---|---|
| Lokal statisk katalog + paginering | 12/12 produkter | 0.557s |
| CSV-export från statisk katalog | 12 rader skrivna | (samma körning) |
| Artikelutvinning | titel + 3/3 brödtextstycken | 0.416s |
| Crawl-graf, DEPTH_LIMIT=2 | 11 sidor över djup 0/1/2 | 0.904s |
| Lokal 500-sida | status 500 fångad, inget kraschat | 0.424s |
| Books to Scrape (publik) | 20 produkter | 2.053s |
| Quotes to Scrape spider (publik) | 12 citatobjekt | 3.465s |
Spidern för den statiska katalogen följde pagineringen från sida ett till sida två och fångade 12/12 förväntade poster, och skrev sedan ut dem som JSON och CSV i samma körning. Artikeltestet är det som är mest intressant att stanna vid. Scrapy försökte inte automatiskt städa sidan till snygg Markdown — istället lät det mig rikta in mig på article-fält med explicita selektorer och hålla meny- och sidfotsinnehåll i separata fält, så jag fick 3/3 stycken i brödtexten medan standardtexten isolerades istället för att blandas in i resultatet. Det är kompromissen: du skriver selektorerna, och du får exakt det du bad om — inte mer, inte mindre.
Crawl-kontrollen fungerade även i liten skala. Med DEPTH_LIMIT=2, kort nedladdningsfördröjning, begränsad samtidighet per domän och robots.txt aktiverat såg crawl-grafen 11 sidor över djup 0, 1 och 2, och djupberäkningen betedde sig som den skulle. Felhanteringen var lika odramatisk. Den avsiktliga 500-sidan kom tillbaka som ett strukturerat objekt med status 500 exponerad via handle_httpstatus_list — inget undantag, ingen död körning. Scrapy behandlar felstatus som något du hanterar i spiderlogiken, inte som en överraskning som fäller hela crawlen.
Praktiskt test: JavaScript-väggen och dörren bredvid
Nu till resultatet som den här recensionen egentligen kretsar kring.
Jag riktade Scrapys HTTP-fetchar mot ett katalogtest som renderas med JavaScript. Den hämtade käll-HTML, hittade 0 .product-card-noder och gick vidare — eftersom den aldrig körde skriptet som skulle ritat upp korten. Den publika Quotes to Scrape JS-sidan visade samma sak: 0 renderade citatnoder. Hade testet slutat där hade man lätt avfärdat Scrapy som oanvändbart för allt som byggts det här decenniet.
Men man ska inte sluta där. JavaScript-katalogen fylldes i bakgrunden av ett JSON API, precis som de flesta sådana sidor gör. Jag pekade samma Scrapy-spider mot den endpointen och fick 8/8 produkter på 0.416s — ingen webbläsare, ingen rendering, bara en förfrågan till den URL sidan redan använde och en tolkning av JSON-svaret.
Den jämförelsen är en liten version av filosofin att återupprepa förfrågan. Den renderade sidan är en rökridå; datan låg bakom ett API hela tiden, och Scrapys design styr dig mot att anropa det direkt istället för att betala för att en headless browser ska sitta och titta på hur sidan byggs upp. Det är snabbare, lättare och går sönder mer sällan — ett API-avtal är stabilare att lita på än en massa klientgenererad DOM. Men det finns en hake: du måste göra jobbet själv. Du behöver öppna nätverksfliken, hitta anropet och återskapa dess headers och parametrar. Scrapy hittar inte API:t åt dig; det gör bara anropet trivialt när du väl har hittat det.
Två gränser, tydligt uttryckta. När det verkligen inte finns någon underliggande förfrågan att återupprepa — alltså när datan är inbyggd i klientrenderingen utan något API bakom — behöver Scrapy en headless-browser-integration som du kopplar in själv, och den vägen testade jag inte här. Och allt ovan kördes på små testmiljöer och publika demosidor. Jag körde inte en crawl på 100 till 1 000 sidor, så jag gör inga påståenden om minnesanvändning, throughput eller retry-beteende i stor skala — den asynkrona kärnan och crawl-kontrollerna är starka signaler, men en signal är inte ett mätresultat.
För- och nackdelar
Fördelar:
- HTTP-only-designen är snabb och lätt — 12/12 på statisk data på ungefär en halv sekund, 8/8 från ett JSON API på 0.416s, utan webbläsaröverhead.
- Metoden att återupprepa förfrågan fungerar på riktigt: en JavaScript-sida som gav 0 släppte ifrån sig alla 8 objekt via sitt bakomliggande API.
lxml-baserade CSS- och XPath-selektorer gör extraktionskoden lättläst och snabb.- Feed exports till JSON/CSV/XML utan att du behöver skriva exportlogik.
- Tydlig felhantering — en 500:a kommer tillbaka som status att fånga, inte som krasch.
- Mogna crawl-kontroller: samtidighet, fördröjningar, djupgränser, AutoThrottle och robots.txt.
- Tillåtande BSD-3-Clause-licens; ren installation på en modern maskin.
Nackdelar:
- Renderar inte JavaScript per design — 0 noder på en klientrenderad sida tills du själv hittar API:t.
- Det manuella steget att hitta den underliggande förfrågan ligger på dig; Scrapy pekar inte ut endpointen.
- Ganska stor beroendestack (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract) — gick smidigt här, men har historiskt varit en friktionspunkt på ovanliga plattformar.
- Mer kod än no-code- eller auto-extraktionsverktyg; spiders är något du själv skriver och underhåller.
- Min testning omfattade små testfall och demosidor, inte stora crawls — skalerbarheten är alltså inte bevisad i denna genomgång.
Vem det passar för — och vem som bör gå vidare
Scrapy är för utvecklare som vill ha kontroll på kodnivå och tänker i förfrågningar, inte i sidor. Om din spontana tanke när en JavaScript-tung sajt är långsam är "det finns säkert ett API här någonstans", då är verktyget byggt för just den instinkten. Det passar dem som är bekväma med att skriva selektorer, läsa nätverksfliken och äga sin extraktionslogik från början till slut. För statiska sajter, paginerade kataloger och allt som backas av ett upptäckbart JSON-endpoint är det både snabbt och exakt.
Gå vidare från det — eller kombinera med något annat — om du inte vill lägga tid på att skriva och underhålla spiderkod, eller om dina mål sidor renderar allt helt klient-side utan någon reproducerbar förfrågan och du helst inte vill koppla in en headless browser själv. Och om drömmen var att peka ett verktyg mot en URL och få ut ren, strukturerad data utan att skriva extraktionsregler, då var det aldrig Scrapys uppgift — och det har det heller aldrig låtsats vara.
Alternativ, och var Thunderbit passar in
Prova Thunderbit för webbdatarapportering
Utgå från vad du faktiskt skriver upp dig för: ett gratis ramverk med öppen källkod som du själv kör och underhåller. Du äger spiders, beroendestack och arbetet med att hitta varje sajts dataförfrågan. I gengäld betalar du inget per request, behåller allt internt och får exakt kontroll. För många team är det rätt beslut, och den här recensionen försöker inte övertala någon om motsatsen.
Avvägningen ligger i problemet med rendering och förändringar, och Scrapys svar är att du löser det: du hittar API:t, du återskapar förfrågan och du hanterar fallet utan API genom att själv koppla in en webbläsare. En hanterad AI-scraping-API-tjänst lyfter bort det lagret från ditt bord. Det är i det utrymmet Thunderbits utvecklarstack passar för tekniska läsare — ett AI-scraping-API plus MCP-server plus CLI, inte webbläsartillägget som sälj- och driftteam använder. POST /distill gör om en sida till ren, LLM-vänlig Markdown; POST /extract ger strukturerad JSON enligt ett schema du definierar; och båda hanterar JavaScript-rendering, anti-bot-skydd och dynamiskt innehåll på serversidan — inklusive fallet där en klientrenderad sida är ett läge där Scrapy vill att du tar till en webbläsare. Det finns en MCP-server för AI-agenter och kodassistenter (med gratis thunderbit_suggest_fields för att avgränsa en sida innan du spenderar något), och en CLI via npx @thunderbit/thunderbit-cli för terminal, CI eller cron-jobb.
Skillnaden handlar inte om kvalitet, utan om ägarskap. Scrapy är ett uttalat ingenjörsramverk: du underhåller spidern, pipelinen och strategin för JavaScript, och du får total kontroll utan kostnad per anrop. Thunderbits stack tar över renderings- och extraktionslagret som en hanterad tjänst, så du slipper gräva i nätverksfliken och betalar per anrop istället. Litet, koddrivet och du vill äga varje steg? Då passar Scrapys kontroll bättre. Ska du skala över hundra sajter och vill slippa återskapa en förfrågan per sajt för hand? Då tar den hanterade vägen bort hela den arbetskategorin.
För det bredare fältet täcker de här jämförelseartiklarna grannarna: den fullständiga jämförelsen av open source-scrapers, Collys recension av den webbläsarlösa Go-crawlen och Scraplings recension av adaptiva selektorer.
Slutsats
Bör du använda Scrapy? Ja — om du är en utvecklare som vill ha kontroll och köper världsbilden: rendera inte sidan, hitta förfrågan bakom den. I testen betalade den filosofin av sig exakt som utlovat. En JavaScript-katalog gav HTTP-fetcharen 0 kort; JSON-API:t som matade den gav ifrån sig alla 8 objekt till samma spider. Statisk extraktion träffade 12/12, artikel-selektorer höll 3/3 stycken fria från standardtext, crawl-grafen respekterade sin djupgräns över 11 sidor och en 500:a kom tillbaka som hanterad status istället för krasch.
Men var noga med att växla rätt nivå på påståendena. Scrapy renderar inte JavaScript, och det hittar inte API:t åt dig — den instinkten måste du bygga själv. Beroendestacken är omfattande och kan ställa till det på udda plattformar, även om den var problemfri här. Och jag testade testfall och demosidor, inte en crawl på tusen sidor, så behandla skalbarhetsdelen som lovande men ännu obevisad. Inom de ramarna är Scrapy verktyget som bäst står för en tyst radikal idé: den snabbaste vägen genom en webbsida är ofta inte genom webbsidan alls.
Prova Thunderbit för webbdatarapportering Get Started Free
Vanliga frågor
Kan Scrapy extrahera från sidor som renderas med JavaScript? Inte med sin standardiserade HTTP-fetchar — den gav 0 noder både på ett JS-testfall och på den publika Quotes JS-sidan, eftersom den hämtar HTML utan att köra någon webbläsare. Den tänkta vägen är att hitta den underliggande dataförfrågan som sidan gör och anropa den direkt; i mitt test gav JSON-API:t bakom en JavaScript-katalog ifrån sig alla 8 objekt. För sidor utan någon reproducerbar förfrågan behöver du själv koppla in en headless browser.
Vad betyder egentligen att “återupprepa förfrågan”? De flesta dynamiska sidor hämtar sin data från ett JSON API i bakgrunden och renderar den sedan i webbläsaren. Istället för att köra en webbläsare och titta på när det händer, öppnar du nätverksfliken, hittar API-anropet och pekar Scrapy direkt mot det. Det är snabbare och stabilare än att rendera sidan — ett API-avtal går sönder mer sällan än en DOM — men det är manuellt arbete, och Scrapy hittar inte endpointen åt dig.
Är Scrapy svårt att installera?
För mig var det smidigt — pip install Scrapy==2.17.0 gick igenom utan kompileringsfel i en ny venv på macOS med binära wheels. Men det drar in en ganska stor stack (Twisted, lxml, cryptography, pyOpenSSL, parsel, tldextract), och den officiella dokumentationen varnar fortfarande för plattformsberoende beroenden på vissa system, så räkna med det om du kör på något ovanligt.
Vilka utdataformat stöder Scrapy? Feed exports täcker JSON, JSON Lines, CSV och XML direkt ur lådan — peka en spider mot en fil så serialiseras objekten utan extra kod. I min körning producerade en spider både JSON och CSV i samma pass. Tänk på att den exporterar de fält du själv valt; den städar inte automatiskt en sida till Markdown.
Är Scrapy gratis för kommersiell användning? Det är BSD-3-Clause, vilket är ett tillåtande och kommersiellt vänligt licensupplägg. Som alltid bör du dubbelkolla den aktuella licensen i repo:t innan du bygger vidare, och hålla dina val av user-agent, proxy och rate limit ansvarsfulla — kapacitet är inte samma sak som tillåtelse.
