Alternative ad Apify per il web scraping su larga scala (oltre 1 milione di pagine)

Alla scala del milione di pagine, raramente è il crawler in sé a determinare la bolletta: a pesare sono la banda proxy, i retry falliti e il rendering del browser. Per questo, quando valuti le alternative ad Apify, confrontare i prezzi di listino non basta: ciò che conta è come ogni strumento gestisce questi costi nella pratica.

Il semplice passaggio da Apify a un'altra piattaforma non rende automaticamente più economico lo scraping. Un primo passo più efficace è separare le pagine che richiedono davvero un browser. Se un'API o una semplice richiesta HTTP restituisce già i dati che ti servono, usala. Solo le attività che comportano rendering JavaScript, clic nella paginazione, invio di moduli o una sessione autenticata devono passare da un browser.

Una volta suddiviso così il carico di lavoro, diventa molto più chiaro quale strumento si adatta a quale compito. Apify, Firecrawl o un crawler self-hosted sono adatti a grandi volumi di dati pubblici e direttamente accessibili. Quando il flusso di lavoro arriva ai passaggi che dipendono davvero dallo stato del browser e dall'interazione, può subentrare ego (lite).

Il motivo è che queste attività non consistono più solo nel recuperare una pagina. L'agente deve lavorare con il contenuto renderizzato, lo stato attuale del browser e l'interazione con la pagina, e l'azione successiva può cambiare in base a ciò che la pagina restituisce. ego (lite) gira direttamente in un browser reale, così l'agente può leggere la pagina corrente, proseguire l'interazione e restituirti il controllo in modo naturale quando un passaggio richiede un giudizio umano o un intervento manuale.

Per i progetti su larga scala, il piano migliore di solito non è trovare un singolo strumento che sostituisca l'intero flusso di lavoro Apify. È piuttosto scegliere la modalità di esecuzione giusta per ogni tipo di attività: mantenere semplici le parti che un'API o una chiamata HTTP possono gestire, affidare il grosso del crawling pubblico a un crawler dedicato e usare ego (lite) per i passaggi che dipendono davvero da un ambiente browser e dall'interazione. Così i costi restano sotto controllo e non paghi tempo di esecuzione del browser per attività che non ne hanno mai avuto bisogno.

Quanto costa un crawl da un milione di pagine su Apify?

Approssimativamente da 430 $ a 1.300 $ con i numeri qui sotto, e oltre l'80% è banda proxy, non crawling.

Le tariffe dietro questo calcolo sono pubblicate su la pagina dei prezzi di Apify.

Come vengono contate le compute unit è documentato su la documentazione di Apify su utilizzo e risorse.

Questa stima si basa sulle tariffe pubblicate di Apify, non su una bolletta o un preventivo. Presuppone un milione di URL di destinazione, un passaggio HTTP in stile Cheerio per la maggioranza portante, il rendering del browser su circa 100.000 pagine che richiedono davvero JavaScript e proxy residenziali per l'intera esecuzione.

Una distinzione conta più di tutte le altre quando pianifichi a questo volume. Il volume delle richieste non è il volume delle pagine. Se l'85% delle tue richieste riesce al primo tentativo, un milione di pagine di destinazione corrisponde più o meno a 1,15-1,3 milioni di richieste dopo i retry. Paghi le richieste e paghi la loro banda, anche quelle che tornano vuote.

Il nostro modello di costo, voce per voce.

Leggilo come un esercizio aritmetico su prezzi pubblicati. Stiamo applicando le tariffe di Apify a un carico di lavoro definito, e le ipotesi sul carico sono dichiarate proprio perché tu possa sostituirle con le tue.

Due numeri in quella tabella meritano un secondo sguardo, perché è lì che i budget vanno davvero fuori strada.

Il primo è la riga dei 1024MB. I nuovi utenti di Apify danno per scontato che pagare più memoria costi di più. In termini di CU non è così: un lavoro che richiede il doppio della memoria finisce nella metà del tempo, e quello per cui paghi è il prodotto delle due cose. La memoria è una manopola di pianificazione, non una leva di costo.

Il secondo è la riga dei proxy. Nota che la piattaforma non può letteralmente essere il costo dominante qui: a 0,20-0,13 $ per CU a seconda del piano, dovresti bruciare oltre 2.000 compute unit per pareggiare una singola bolletta di banda moderata.

Se il tuo crawl costa caro, stai pagando la banda, non l'orchestrazione.

Come fattura davvero il modello a compute unit di Apify?

Una compute unit è 1GB di memoria mantenuto per un'ora, misurato con granularità di un secondo, ed è l'unica unità su cui la piattaforma addebita il crawling.

Memoria per durata. Un'esecuzione che mantiene 1024MB per un'ora consuma esattamente una CU. La stessa esecuzione dimensionata a 4096MB per quindici minuti consuma anch'essa una CU. Ecco perché la colonna delle CU nel nostro modello si muove così poco quando cambi la dimensione dei worker: il lavoro è il lavoro.

Vale la pena interiorizzare alcune proprietà del modello:

1. Cheerio non è una piccola ottimizzazione. La guida di Apify stessa indica un passaggio HTTP in stile Cheerio fino a 20 volte più veloce dello stesso lavoro in un browser. È quel fattore che tiene alla portata 170 CU per un milione di pagine.
2. È la concorrenza, non la dimensione dei worker, a fissare il tempo reale. I limiti per piano vanno da 25 esecuzioni concorrenti sul piano Free fino a 256 su Business, con tetti di memoria combinata di 16.384MB, 65.536MB, 262.144MB e 524.288MB tra questi piani. Con 32 attività concorrenti e circa 3.200 pagine al minuto, un milione di pagine equivale a circa 5,2 ore.
3. Alcuni actor hanno soglie minime di memoria rigide. Un actor browser non parte sotto i 1024MB e lo scraper di Google Maps richiede 4096MB o più. 4096MB è il valore predefinito pragmatico quando preferisci non regolare ogni singolo actor.
4. I crediti non si accumulano. I crediti mensili non utilizzati scadono. Se il tuo crawling è a raffiche, una sola esecuzione enorme ogni trimestre invece di un flusso costante, stai pagando capacità che non hai usato.

Niente di tutto questo è un argomento contro Apify. È una delle poche piattaforme di cui puoi ragionare sull'economia unitaria partendo dalla documentazione pubblicata, e il modello a CU è davvero onesto: addebita il lavoro, non le righe. Il problema è quello che non include.

I proxy. Gli actor ad alto rendering. L'archiviazione che continua ad accumulare mentre un dataset resta lì fermo. Sono queste le voci che decidono se un crawl da un milione di pagine costa centinaia o migliaia di dollari, e sono le stesse voci su ogni alternativa ad Apify che potresti considerare.

Quali sono le principali alternative ad Apify per lo scraping su larga scala?

Esistono quattro tipi di alternativa, e solo uno ha la stessa forma di prezzo di Apify.

La maggior parte delle liste di alternative ad Apify è in realtà una lista di altri strumenti che fanno scraping di siti web, che è una domanda diversa. Se il tuo crawl è costoso anziché irrealizzabile, l'asse rilevante non sono le funzionalità, ma ciò che ogni fornitore ti addebita. Prezzo per ora di calcolo, prezzo per credito, prezzo per gigabyte di traffico proxy e prezzo per ora di operatore si comportano tutti in modo diverso man mano che il volume cresce.

1. Firecrawl. API di scraping a crediti con output pronto per gli LLM. Uno scraping è un credito, e ogni formato di output opzionale costa di più: la modalità JSON costa +4, l'estrazione di domande o punti salienti +4 per formato, la redazione dei PII +4. I piani vanno da 0 $, 20 $, 106 $, 424 $ e 762 $ per 1.000, 5.000, 100.000, 500.000 e 1.000.000 di crediti al mese.
2. ZenRows. Recupero gestito con rendering JS e rotazione dei proxy. I crediti vanno da 5.000 sul piano da 16 $ a 5 milioni sul piano da 456 $, con concorrenza da 5 a 200 e personalizzata oltre. Il rendering JavaScript moltiplica per 10 il costo in crediti, e la modalità combinata JS più proxy per 25. Le richieste fallite e ritentate non vengono fatturate.
3. ScraperAPI. Recupero a crediti con una scala di concorrenza lineare, da 20 sul piano da 49 $ fino a oltre 500 in cima, su un intervallo da 100.000 a 10,5 milioni di crediti.
4. Bright Data e Oxylabs. Fornitori orientati prima ai proxy che vendono anche scraper gestiti. Oxylabs indica il prezzo SERP tra 0,50 $ e 1,35 $ per sequenza di unità e la banda residenziale da 3 $/GB fino a 2 $/GB con il volume. La pagina web-scraper di Bright Data si appoggia a una dichiarazione di concorrenza illimitata senza pubblicare prezzi, una dichiarazione che non possiamo verificare e che quindi non ripetiamo come fatto.
5. Crawler self-hosted. Una pipeline Scrapy o Playwright sulla tua infrastruttura. Nessun costo per pagina o per CU, e la bolletta dei proxy resta la tua bolletta dei proxy. Il compromesso è che la gestione delle code, i retry, la pianificazione e il monitoraggio diventano un tuo problema, per sempre.
6. Browser guidati da agenti. Questo è il percorso su cui lavoriamo, quindi leggilo tenendolo presente. ego (lite) è un browser Chromium che porta con sé i login e le estensioni che già usi, e un agente di programmazione lo guida tramite la skill ego-browser dentro il suo Space isolato. È dove arriva un flusso di lavoro quando le richieste statiche non bastano più: un passaggio di accesso, una vista che si renderizza solo con JavaScript, una paginazione nascosta dietro un clic, un filtro che è in realtà un modulo, un codice che devi leggere da una casella di posta. È gratuito e oggi gira su macOS, con Windows e Linux in roadmap. Non c'è una tariffa per pagina da confrontare con quella di Apify, quindi la domanda da porsi non è quale costa meno per pagina. È se il tuo flusso di lavoro ha bisogno di una sessione.

Perché la banda proxy domina la bolletta?

Perché è l'unica voce che scala con la dimensione delle pagine che scarichi invece che con la quantità di lavoro che svolgi.

Per capire come si comporta questa via su un'attività browser davvero confrontabile, ego (lite) vs Playwright è il confronto diretto.

Come mantenere attiva una sessione autenticata tra un'esecuzione e l'altra: vedi sessioni browser persistenti tra le esecuzioni di un agente.

Il calcolo scala con il tempo di CPU. La concorrenza scala con il piano. La banda scala con internet. Un megabyte di HTML è un megabyte, che sia arrivato in un millisecondo o in un secondo, e il traffico dei proxy residenziali si paga a gigabyte: 8 $/GB su Apify, da 3 $/GB fino a 2 $/GB con il volume su Oxylabs.

A 50KB di HTML compresso per pagina, un milione di pagine equivale a circa 50GB. Sono 400 $ alla tariffa indicata da Apify, prima ancora di contare i retry, e peggiora quanto più l'obiettivo è ostile: le pagine protette dai bot sono più pesanti, spesso richiedono più richieste per risolversi e possono consumare fino a tre volte le risorse di una pagina amichevole.

Ecco la parte scomoda. Gran parte di quella banda è sprecata, e tu lo sai già. Una pagina di listino prodotti può pesare 400KB tra HTML, CSS, JavaScript, font e pixel di tracciamento, solo perché tu possa leggere un prezzo e una disponibilità, quando il segnale reale è forse 2KB. Stai pagando tariffe residenziali per trasportare l'imballaggio.

Tre leve la riducono, e valgono più di qualsiasi cambio di fornitore. Limita il crawl alle pagine che contengono i dati invece di seguire ogni link. Recupera gli endpoint strutturati dove il sito li espone, dato che le risposte JSON sono una frazione del peso della pagina renderizzata. E renderizza solo dove il rendering è necessario, che nel nostro modello significa 100.000 pagine su un milione.

Come si confrontano le alternative ad Apify?

Alle tariffe pubblicate, la differenza tra il percorso più economico e quello più caro è di circa dieci volte, e niente di tutto ciò deriva dal crawling in sé.

Leggi ogni riga per due cose: per cosa ti addebita il fornitore e cosa ti impedisce di fare. Un prezzo senza tetto è marketing. Un tetto senza prezzo è una chiamata commerciale.

La riga di Firecrawl è quella che le persone leggono male, quindi vale la pena spiegarla. Un milione di crediti sembra un milione di pagine, e per uno scraping puro lo è. Aggiungi l'estrazione JSON e hai speso cinque crediti per pagina, quindi gli stessi 749 $ coprono 200.000 pagine. Non è un trucco di prezzo. È un costo reale per un lavoro reale, e significa che il numero che metti a budget non è quello sulla scheda del piano.

La documentazione di Firecrawl è insolitamente schietta sull'altro vincolo: il tuo vero collo di bottiglia saranno i browser concorrenti. Il piano Free parte da due, Hobby da cinque, Standard da 25, Growth da 50, Scale da oltre 100. Con 100 pagine concorrenti e due secondi generosi ciascuna, sono circa 50 pagine al secondo, ovvero più o meno 5,6 ore per un milione. Funziona, ma non puoi aggirarlo comprando altri crediti.

I livelli di concorrenza di Firecrawl provengono da la sua pagina dei prezzi.

Per il confronto tra librerie di scraping dietro questa scelta, vedi Playwright vs Puppeteer per il web scraping.

ZenRows risolve una versione diversa dello stesso problema rendendo gratuiti i retry. Non pagare le richieste fallite o ritentate è un vero vantaggio su obiettivi ostili, ed è il tipo di cosa che vale la pena verificare prima di dare per scontato che vinca una tariffa di facciata più bassa.

Quali criteri determinano la scelta di un'alternativa ad Apify?

A deciderlo sono quattro numeri, e tre di essi sono proprietà del tuo carico di lavoro, non di un fornitore.

Le matrici di funzionalità a questa scala sono per lo più rumore, perché ogni fornitore fa lo stesso lavoro di base. A distinguerli è come si comporta la loro fatturazione quando il tuo crawl cresce di un ordine di grandezza, e se il tetto che impongono arriva prima o dopo quella crescita.

Nota quanto poco di quella tabella riguardi le funzionalità. I fornitori che competono per la query «alternative ad Apify» si sfidano per lo più sulla stessa lista di controllo: pool di proxy, rendering JS, gestione dei CAPTCHA, integrazioni. Quelle liste tendono a convergere. La forma della fatturazione non converge, ed è la parte che decide la tua fattura.

Come scegliere un'alternativa ad Apify?

Fai corrispondere la risposta al tuo rapporto di rendering e al tuo stato di autorizzazione, e la lista si riduce a una sola riga.

1. HTML statico, pubblico, oltre un milione di pagine. Resta su una piattaforma con prezzo a CU o fai self-hosting, e investi le tue energie sulle tariffe dei proxy e sulla riduzione del peso delle pagine. Spostarsi tra piattaforme a questo rapporto di rendering fa risparmiare percentuali a una cifra.
2. Prevalentemente statico, con una minoranza renderizzata ostinata. Suddividi il crawl. Recuperi economici per la maggioranza, un percorso di rendering per il resto. È la singola decisione con il rendimento più alto disponibile, e non costa nulla.
3. Pesante di JavaScript ovunque, dati pubblici. Le API a crediti guadagnano il loro sovrapprezzo qui se fanno l'estrazione per te, perché stai comprando token e output strutturato, non solo byte. Metti a budget i moltiplicatori di formato prima di scegliere un piano.
4. Obiettivi ostili e blocchi frequenti. Valuta i retry, non le richieste. Un fornitore che non fattura i fallimenti può costare meno pur avendo una tariffa di facciata più alta.
5. Dietro un login o una dashboard interna. Smetti di confrontare i prezzi dei crawler. Questo è lavoro autorizzato e dipendente da una sessione, e gira in un browser che possiede già la sessione, che è il motivo per cui esiste ego (lite). Vedi le nostre note su lo scraping dietro i muri di login per i meccanismi, ed è chiaro che nessuno strumento qui aggira i controlli di accesso di un sito.
6. Qualche centinaio di pagine, aggiornate spesso. Niente di tutto questo si applica. Non sei nel regime di volume che rende interessanti i modelli di costo, e uno strumento no-code è probabilmente la scelta giusta. La nostra guida agli strumenti di web scraping con AI copre i percorsi no-code, API e agent-browser proprio con quello scopo in mente.

Se stai valutando infrastruttura browser ospitata invece che crawler nello specifico, la stessa logica si applica un livello più in basso: browser headless contro browser reale è la decisione che determina se il tuo costo per pagina è dominato dal rendering.

Quando vale la pena aggiungere ego (lite) al flusso di lavoro?

Una richiesta statica smette di bastare in cinque momenti specifici: un accesso, una vista che si renderizza solo con JavaScript, una paginazione dietro un clic, un filtro che è davvero un modulo e un passaggio di verifica.

Vale la pena nominarli perché sono quelli da cui un recupero non riesce a riprendersi da solo. curl restituisce la pagina di login e riporta 200. L'HTML arriva e le righe non ci sono. La pagina due esiste, ma solo dopo un clic che non avviene mai dentro una richiesta. I dati che vuoi stanno dietro un modulo invece che in una query string. L'account chiede un codice da una casella di posta che hai aperto in un'altra scheda.

Quando succede, la soluzione non è un crawler più grande. È eseguire lo stesso flusso di lavoro in un browser che porta già con sé la sessione.

Per non lasciare tutto in teoria, abbiamo eseguito la stessa attività in entrambi i modi e conservato le prove. L'attività: estrarre i primi tre annunci di olio di pesce non sponsorizzati da una ricerca su Amazon, con nome, marca, prezzo, valutazione, numero di recensioni e formato. Un passaggio con ego (lite), un passaggio via HTTP semplice con uno script. Entrambi eseguiti sulla stessa macchina lo stesso giorno, e mostriamo di seguito entrambe le esecuzioni.

Il percorso del browser, passo dopo passo

Il passaggio nel browser si articola in quattro parti: gli input che fornisci, i passaggi che esegue l'agente, cosa succede quando incontra qualcosa che non dovrebbe decidere da solo e come verifichi il risultato. Ecco ciascuna applicata a una ricerca prodotti reale.

1. Input. L'URL di ricerca, un account Amazon già connesso e una frase che descrive i campi da raccogliere. ego (lite) è Chromium e porta con sé i login, le estensioni e la cronologia esistenti, quindi non serve esportare cookie né incollare credenziali da qualche parte. La skill ego-browser è legata al browser e viene installata insieme a ego (lite), e tu la attivi digitando /ego-browser nella casella della chat dell'agente.

1. Passaggi chiave. L'agente apre il proprio Space, una finestra separata contrassegnata da un bagliore blu, così non guida le schede che stai usando tu. Al suo interno l'agente naviga, prende snapshot della pagina per leggerne la struttura e cattura quello che trova. Quegli snapshot leggono iframe annidati, che è il punto in cui l'estrazione dipendente dal rendering di solito cede.

3. Recupero dagli errori. Quando l'esecuzione arriva a un accesso, a un codice di verifica o a qualsiasi altra cosa che non dovrebbe decidere da sola, si ferma e ti chiama nel suo Space invece di tirare a indovinare. Il comportamento documentato vale anche sul fronte più rischioso: una candidatura di lavoro aspetta che tu confermi prima dell'invio finale, e un flusso di prenotazione arriva fino alla pagina di pagamento e lì si ferma. Un crawler che incontra un muro di login registra un 200 e va avanti. Questo invece chiede.
4. Convalida dei risultati. Controlla le righe raccolte rispetto alla pagina su cui l'agente si trovava davvero, non rispetto all'URL che gli hai passato. Lo snapshot da cui l'agente ha lavorato è la prova. È qui che è emersa l'unica vera anomalia dell'esecuzione, ed è il tipo di cosa che esiste solo su una pagina renderizzata.

La stessa attività via HTTP semplice

Ecco l'altra metà onesta, perché il risultato interessante non è che HTTP ha fallito, ma dove ha faticato e quanto è costato farlo funzionare.

Il passaggio HTTP ha eseguito la stessa attività con uno script e senza browser. Alla fine ce l'ha fatta. Il log è la testimonianza di quanto lavoro di trasporto si è frapposto tra i due.

Una richiesta oggetto di challenge è un arresto definitivo. Ma la maggior parte dei 503 qui non erano challenge, e distinguere gli uni dagli altri ha richiesto un esperimento.

Riscrivere il trasporto è stato la metà del problema, non la sua fine. Poi l'estrattore ha dovuto essere corretto due volte sulla stessa pagina.

Quindi entrambi i passaggi hanno raggiunto i tre prodotti. La differenza è quanto ciascuno ha speso per arrivarci. L'esecuzione nel browser ha aperto uno Space, letto le pagine e finito con uno screenshot per ogni valore riportato. L'esecuzione HTTP ha scritto sei script, cambiato il suo client HTTP per una mancata corrispondenza del fingerprint, aggiunto un livello di retry, corretto un bug nel rilevamento degli sponsor, corretto un bug di valuta e chiuso con un rapporto che ammetteva di non avere output per il primo prodotto.

È questa la parte che un modello di costo per pagina non vede. Nessuno dei due approcci è sbagliato, e i contatori di token e di tempo reale in quegli screenshot sono abbastanza vicini che la sola velocità non basta a decidere. A separarli è dove finisce il tempo. Un percorso lo spende leggendo una pagina. L'altro lo spende costruendo e mettendo a punto il macchinario che sostituisce l'aver letto una pagina.

Per tre prodotti, quel macchinario è l'intero costo e non si ripaga. A centomila pagine lo stesso codice gira senza sorveglianza per un giorno e l'aritmetica si ribalta completamente.

Quando ego (lite) non ti serve affatto

L'HTTP semplice copre più di questo lavoro di quanto suggerisca la discussione sugli strumenti. Se la pagina restituisce i suoi dati nell'HTML, recuperali. Se il sito pubblica un'API, usa l'API, perché è la via di accesso che il sito intende e sopravvive ai redesign che rompono i selettori. E se un grande crawl pubblico è l'intero lavoro, senza alcun passaggio che richieda una sessione, una piattaforma ospitata o un'API a crediti batteranno un browser locale in throughput.

Leggi anche il caso Amazon nella giusta misura. Non è la prova che HTTP sia rotto, perché HTTP ha raggiunto i dati. E non è la prova che il browser sia stato veloce, perché anche l'esecuzione nel browser ha impiegato oltre venti minuti e il suo stesso rapporto registra un fallimento. Quello che mostra è dove è finito il lavoro da ciascuna parte. L'unico vero problema del percorso browser era del sito, non dello strumento. I problemi del percorso HTTP erano tutti suoi.

Aggiungere un browser a un flusso di lavoro che non ne ha bisogno è il modo più comune per rendere un lavoro di scraping più lento e più costoso del necessario. Controlla prima il percorso economico, e annota quanto costa quando l'obiettivo richiede una sessione.

Vale ancora la pena ospitare in proprio il crawler?

Spesso sì, e il motivo è aritmetico più che artigianale: a volume stai pagando una coda e uno scheduler, e entrambi sono commodity.

Scrapy e Playwright sono gratuiti, ben documentati e noiosi nel modo in cui dovrebbe esserlo l'infrastruttura di produzione. Se il tuo crawl è un lavoro ricorrente su obiettivi stabili, una pipeline self-hosted elimina del tutto il costo della piattaforma e ti lascia con il costo del server e la bolletta dei proxy che avresti pagato comunque.

Il contrappeso onesto è che il costo della piattaforma compra qualcosa di reale. Logica di retry che gestisce cinque modalità di errore diverse. Uno scheduler che non va alla deriva. Archiviazione, logging e la possibilità di rieseguire un dataset senza toccare la produzione. I team sottovalutano costantemente quanto tutto questo costi in ore di ingegneria, perché quelle ore compaiono nel calendario di una persona, non su una fattura.

Una regola approssimativa: fai self-hosting quando il crawl è ricorrente e gli obiettivi sono stabili. Affitta quando il crawl è esplorativo, o quando il sito che stai coprendo cambia forma ogni poche settimane. Il costo della piattaforma è per lo più un costo di gestione del cambiamento.

Dove si rompono tutte queste opzioni?

Tre punti, e sono quelli che trasformano un modello di costo pulito in uno sforamento.

Il primo è che le promesse di marketing di ogni fornitore superano la sua documentazione, e il divario è più ampio proprio dove ti serve precisione. La pagina web-scraper di Bright Data dichiara concorrenza illimitata e non pubblica prezzi sulla stessa pagina. Non è una menzogna che possiamo smentire; è una dichiarazione che non possiamo verificare, che è una cosa diversa e più utile da sapere. Tratta qualsiasi dicitura «illimitato», «enterprise-grade» o «infinito» come un invito a trovare il numero, e se il numero non è pubblicato, dai per scontato che il tetto esista e sia negoziabile.

Il secondo è la protezione anti-bot, che non è una funzionalità che compri ma una condizione in cui operi. I guadagni di efficienza di un percorso di recupero più veloce svaniscono quando ogni richiesta ha bisogno di un IP residenziale, di una sessione calda e di un budget di retry. Il nostro modello arriva a 1.300 $ non perché qualche fornitore stia speculando, ma perché obiettivi più difficili significano pagine più pesanti e più richieste sprecate.

Il terzo è quello che nessuno mette su una tabella di confronto: questa è infrastruttura per dati pubblici, e usarla così è tua responsabilità. Termini di servizio, direttive robots, dati personali ai sensi del GDPR o del CCPA e la differenza tra le pagine pubbliche di un sito e le informazioni private dei suoi utenti sono tutte questioni separate dallo strumento che scegli. Un crawler economico non rende lecito un crawl illecito. Non siamo avvocati e questo non è un parere legale, ma il crawl più economico è quello che la tua organizzazione può davvero difendere.

FAQ

Qual è l'alternativa ad Apify più economica per un milione di pagine?

Alle tariffe pubblicate, una pipeline Scrapy self-hosted con proxy economici, perché non c'è alcun costo di piattaforma. Tra le opzioni gestite, una piattaforma con prezzo a CU che esegue un passaggio HTTP batte le API a crediti sul volume puro. Ma la risposta onesta è che la scelta della piattaforma è la metà minore della bolletta: a 8 $/GB di traffico residenziale, un milione di pagine da 50KB costa circa 400 $ di banda, chiunque faccia il recupero.

Firecrawl è un buon sostituto di Apify?

Per markdown pronto per gli LLM ed estrazione strutturata, sì: è più semplice da prevedere e l'output ti risparmia un livello di parsing. Per un recupero puro da un milione di pagine, il suo tetto di concorrenza diventa il vincolo prima del suo saldo di crediti. Il piano Free consente due browser concorrenti e il piano Scale oltre 100, quindi il throughput è limitato dal piano, non dalla spesa.

Apify addebita le richieste fallite?

Sì, indirettamente. Le compute unit si accumulano per il tempo di esecuzione, indipendentemente da cosa ha restituito la richiesta, e la banda proxy viene consumata per il trasferimento. Una richiesta ritentata viene fatturata due volte, senza nulla da mostrare per il primo tentativo.

Perché le alternative ad Apify sono spesso più care su larga scala?

Di solito non lo sono, in termini di piattaforma. Sembrano care perché i moltiplicatori dei crediti non si mappano in modo pulito sulle pagine: uno scraping è un credito, ma la modalità JSON ne vale cinque, e il rendering JavaScript su un fornitore basato su proxy può essere dieci o venticinque volte un recupero semplice. Moltiplica la tariffa di facciata per il moltiplicatore che ti serve davvero e il divario si chiude o si inverte.

Serve il rendering del browser per un milione di pagine?

Quasi mai per tutte. Un'ipotesi di lavoro è che il 90% delle pagine sia leggibile come HTML statico e il 10% richieda JavaScript, ed è per questo che il nostro modello renderizza 100.000 pagine e recupera le altre. Misura il tuo rapporto su un campione di 1.000 pagine prima di fare il budget, perché sposta il costo più di qualsiasi scelta di fornitore.

E Bright Data e Oxylabs come alternative ad Apify?

Sono più forti quando il problema sono i proxy. Oxylabs indica la banda residenziale da 3 $/GB fino a 2 $/GB con il volume, ben al di sotto degli 8 $/GB di Apify, e il prezzo SERP tra 0,50 $ e 1,35 $ per sequenza di unità. Bright Data non pubblica prezzi sulla sua pagina web-scraper e si appoggia a una dichiarazione di concorrenza illimitata che non abbiamo potuto verificare, quindi trattala come un preventivo da richiedere, non come un fatto su cui pianificare.

Le tariffe di banda residenziale citate qui sono elencate su la pagina dei prezzi di Oxylabs.

I piani di Bright Data, che non pubblicano tariffe per GB sulla pagina dello scraper, partono da la sua pagina dei prezzi.

Posso sostituire Apify con ego (lite)?

Coprono passaggi diversi, quindi si legge meno come una sostituzione e più come un passaggio di consegne. Apify esegue crawl ospitati su larga scala. ego (lite) è un browser macOS gratuito che un agente di programmazione guida attraverso una sessione a cui sei già connesso, e ci ricorri quando un passaggio richiede un login, una vista renderizzata, un clic attraverso la paginazione, un modulo o un codice di verifica. Se il tuo lavoro è un grande crawl pubblico e nulla in esso richiede una sessione, non ti serve affatto ego (lite) nella pipeline.

Come stimo la banda proxy prima di un crawl?

Recupera 1.000 URL rappresentativi, misura le dimensioni delle risposte compresse e moltiplica. Poi aggiungi il fattore retry: con un tasso di successo dell'85% al primo passaggio, un milione di obiettivi equivale a 1,15-1,3 milioni di richieste. Metti a budget il numero più alto, perché il peso delle pagine cresce con la protezione anti-bot.

Apify è ancora la scelta giusta a questo volume?

A volte sì. Il suo modello a CU è trasparente, addebita il lavoro e non le righe, e il suo ecosistema di actor elimina molto codice di collegamento. Se il tuo crawl è di poche centinaia di migliaia di pagine e i tuoi proxy vengono da un fornitore più economico, la piattaforma non è il tuo problema. Il motivo per andarsene riguarda di solito crediti che scadono, concorrenza legata al piano che arriva prima che tu sia pronto o tariffe di banda che puoi battere altrove.

Cosa si rompe per primo a un milione di pagine?

Il budget, non la tecnologia. I tetti di concorrenza e la fatturazione dei retry sono documentati e prevedibili. Quello che sorprende i team è la bolletta della banda, l'ipotesi su quante pagine richiedano il rendering e quanta parte del crawl si riveli essere pagine che nessuno aveva chiesto. Sistema lo scope prima di sistemare il fornitore.

La maggior parte dei confronti tra alternative ad Apify risponde a una domanda sulle funzionalità. La domanda che costa denaro a un milione di pagine riguarda la forma della fatturazione, e ha tre parti: per cosa moltiplica il fornitore, qual è il suo tetto e chi paga una richiesta fallita?

Apify risponde bene a queste domande. La sua compute unit è un'unità di lavoro pulita, e ti addebita la navigazione delle pagine invece di contare le righe. Quello che non controlla è la parte della bolletta che guarderai davvero: la banda residenziale a 8 $/GB, su pagine in cui la maggior parte dei byte è impalcatura.

Quindi la mossa utile non è cambiare piattaforma. È ridurre il crawl alle pagine che contengono i dati, recuperare la maggioranza statica con qualcosa 20 volte più economico di un browser e renderizzare il 10% che ne ha bisogno. Fatto questo, il confronto tra fornitori diventa una decisione di arrotondamento.

Le parti che un crawler non può raggiungere, le pagine con login e gli strumenti interni sono il punto in cui il crawl si ferma e inizia una sessione. ego (lite) esegue lo stesso flusso di lavoro con il login già collegato e si ferma a chiedere a te quando un passaggio richiede una persona. E quando un semplice recupero restituisce già le righe, quella è tutta la risposta. Lascia fuori il browser.

Siamo entrati in quel primo crawl da un milione di pagine aspettandoci che la parte costosa fosse la piattaforma. A rispondere è stata la banda.