Headless Tarayıcı mı HTTP İstemcisi mi? Ölçekte Maliyeti Belirleyen Karar

Headless tarayıcı mı HTTP istemcisi mi sorusunun cevabı aracın kendisinde değil, verinin nerede durduğunda saklıdır. Veri sunucudan gelen HTML’in içindeyse ya da sayfanın arka planda çağırdığı bir JSON uç noktasındaysa düz HTTP istemcisi yeter; veri yalnız JavaScript çalıştıktan sonra oluşan DOM’da varsa tarayıcı gerekir. Bu karar sayfa başına harcanan işlemci ve belleği, aktarılan veriyi ve dolayısıyla hangi proxy biriminin (adet bazlı static IPv4 mı, GB bazlı rotating IPv4 mı) daha ucuza geldiğini belirler.

Yayın: 2026-11-11 · Güncelleme: 2026-11-11

Headless Tarayıcı mı HTTP İstemcisi mi? Ölçekte Maliyeti Belirleyen Karar

Veri nerede: kaynak HTML, JavaScript sonrası DOM, yoksa JSON çağrısı mı?

Kararın ilk adımı tarayıcının geliştirici araçlarında üç dakika sürer. Hedef sayfayı açın, aradığınız değeri (fiyat, stok, başlık) kopyalayın ve “sayfa kaynağını görüntüle” penceresinde arayın. Değer orada varsa veri kaynak HTML’dedir; sunucu sayfayı dolu gönderiyordur ve düz HTTP istemcisi aynı HTML’i alır. Değer kaynakta yok ama ekranda varsa ikinci kontrole geçin.

İkinci kontrol ağ sekmesidir. Sayfayı yenileyin, XHR/Fetch filtresini açın ve aynı değeri yanıt gövdelerinde arayın. Çoğu modern sitede fiyat ya da liste verisi, sayfa iskeleti yüklendikten sonra ayrı bir JSON çağrısıyla gelir. O çağrının adresini, yöntemini, başlıklarını ve gövdesini not edin: düz HTTP istemcisi o uç noktaya doğrudan gidebilir ve tarayıcıya gerek kalmaz. Bu, HTML ayrıştırmaktan daha az kırılgan bir yoldur, çünkü JSON alan adları sayfa tasarımından daha yavaş değişir.

Üçüncü durum, değerin ne kaynakta ne de ayrı bir çağrıda olmasıdır: veri JavaScript içinde hesaplanıyor, parçalı olarak birleştiriliyor ya da tarayıcıda çalışan bir koddan türetiliyordur. Yalnız bu durumda tarayıcı gerekir. Üç durumu hedef listenizdeki her sayfa tipi için ayrı ayrı belirleyin; bir sitede ürün sayfası ikinci duruma, arama sonucu sayfası üçüncü duruma düşebilir. Karar sayfa tipi başına verilir, site başına değil.

JSON uç noktasını kullanmadan önce iki şeye bakın: sitenin robots.txt dosyası o yolu kapatıyor mu ve kullanım koşulları otomatik erişimi nasıl düzenliyor. Uç noktanın tarayıcıdan çağrılıyor olması onu herkese açık bir API yapmaz; sayfanın kendisine uyguladığınız kuralların aynısı bu adrese de uygulanır. Hız sınırı ve istek aralığı da sayfa için ne ise burada da odur.

Sayfa başına kaynak: tarayıcı örneği ile HTTP isteğinin yükü

Düz HTTP isteği tek bir TCP bağlantısı, birkaç kilobaytlık istek ve bir gövdedir; işlemci yükü ayrıştırma kadardır ve bellek gövde kadar yer tutar. Headless tarayıcı ise bir işletim sistemi süreci başlatır, sayfayı ve bağlı bütün kaynakları indirir, stilleri hesaplar, JavaScript’i çalıştırır ve DOM’u bellekte tutar. Aradaki farkın kaç kat olduğu sayfaya, tarayıcıya ve makineye göre değişir; satıcı yazılarında geçen katsayılar sizin hedefiniz için bir ölçüm yerine geçmez. Bu yüzden rakamı kendiniz üretin.

Ölçüm düzeni şudur. Aynı 100 sayfayı önce HTTP istemcisiyle, sonra headless tarayıcıyla, aynı eşzamanlılıkla ve aynı datacenter proxy üzerinden çekin. Her turda dört değer kaydedin: toplam süre, en yüksek bellek kullanımı, işlemci saniyesi (kullanıcı artı sistem) ve proxy panelinde görünen aktarılan veri. Tabloyu sayfa başına bölün: sayfa başına saniye, sayfa başına megabayt bellek, sayfa başına işlemci saniyesi, sayfa başına aktarılan KB. Bu dört sayı sizin hedefiniz için gerçek katsayıdır ve ölçek planının girdisidir.

Eşzamanlılığı iki yöntemde aynı tutmak önemlidir, çünkü tarayıcının asıl darboğazı tek sayfanın süresi değil aynı anda açık tutulabilen sayfa sayısıdır. HTTP istemcisinde eşzamanlılığı bağlantı sayısı sınırlar; tarayıcıda bellek sınırlar. Bir makinede kaç sayfanın paralel açılabileceği ölçülmeden söylenemez; thread ve bağlantı sayısının proxy tarafında nasıl seçileceği ayrı bir rehberde anlatılır, burada yalnız şunu bilin: tarayıcı tarafında “bir sayfa daha” demek bir süreç daha demektir.

Ölçümü proxy’siz yapmayın. Proxy üzerinden giden isteğin bağlantı kurulum süresi doğrudan bağlantıdan uzundur ve tarayıcı her alt kaynak için bu bedeli ayrı öder; proxy’siz ölçüm tarayıcı tarafını olduğundan ucuz gösterir. Gecikmenin bileşenlere nasıl ayrılacağı gecikme ölçümü rehberinde adım adım verilir; buradaki tablo için proxy panelindeki toplam ve zamanlayıcıdaki süre yeter.

Aktarılan veri ve proxy birimi: static adet mi, rotating GB mi?

Tarayıcı sayfayı insan gibi yükler: HTML’in yanında stil dosyaları, betikler, yazı tipleri, görseller ve üçüncü taraf etiketler de iner. HTTP istemcisi yalnız istediğiniz gövdeyi alır. Varsayımlar açık bir örnek: ürün sayfasının HTML’i 80 KB, tam yüklemesi alt kaynaklarla 2 MB olsun. 50.000 sayfada HTTP istemcisi yaklaşık 4 GB, tarayıcı yaklaşık 100 GB aktarır. Sayfanın JSON çağrısı 10 KB ise aynı iş yarım GB’nin altında kalır. Bu üç sayı aynı veriyi üretir; fark yalnız yolun uzunluğudur.

DatacenterProxy kataloğunda bu fark iki ürünün hangisinin ucuza geleceğini değiştirir. GB bazlı rotating IPv4 paketleri 2 GB 1 USD, 10 GB 6 USD, 20 GB 12 USD, 50 GB 30 USD ve 100 GB 60 USD olarak tek seferlik satılır. Örnekteki HTTP düzeni 10 GB paketine sığarken tarayıcı düzeni 100 GB paketini tüketir; aradaki fark aynı 50.000 sayfa için 54 USD’dir. Adet bazlı static IPv4 ise 100 adet 15 USD, 250 adet 25 USD, 500 adet 45 USD ve 1.000 adet 80 USD ile 30 günlük dönem için satılır ve aktarılan GB’yi saymaz; tarayıcının indirdiği 2 MB static adreste ek maliyet değildir.

Buradan çıkan kural ters yönlü görünebilir: tarayıcı kullanmak zorundaysanız GB saymayan static IPv4 çoğu zaman daha ucuzdur, HTTP istemcisiyle az veri taşıyorsanız GB bazlı rotating daha ucuzdur. Static adette hedefin aynı adresten gelen istek sayısına koyduğu sınır belirleyicidir; 100 adres arasında dağıtılan 50.000 sayfa adres başına 500 sayfa demektir ve bu tempo hedefin kaldıracağı tempoysa static düzen çalışır. Hedef adres başına daha sıkıysa rotating GB düzeni kalır ve o zaman tarayıcının indirdiği her alt kaynak faturaya yazılır.

Tarayıcıda gereksiz alt kaynakları engelleyerek GB düşürmek mümkündür; yöntemin ayrıntısı rotating ürünler için ayrı bir rehberde anlatılır ve bu rehberin konusu değildir. Burada önemli olan karar sırasıdır: önce verinin yerine bakıp tarayıcıya gerçekten gerek olup olmadığını belirleyin, sonra birimi seçin, en son engelleme gibi iyileştirmelere geçin. Sıra ters kurulursa gereksiz bir tarayıcı düzeni iyileştirilmeye çalışılır.

Karma düzen: tarayıcı yalnız gereken sayfada, kalanı HTTP istemcisinde

Çoğu hedefte sayfa tiplerinin yalnız bir kısmı tarayıcı ister. Liste sayfaları ve ürün sayfaları HTML’de ya da JSON’da gelirken, bir yapılandırıcı ekranı ya da harita görünümü yalnız tarayıcıda oluşur. Bütün işi en pahalı sayfa tipine göre tarayıcıyla kurmak, ucuz sayfaların da pahalı yoldan geçmesi demektir. Karma düzen bunu ayırır: tek bir iş kuyruğu, iki tür işçi. Kuyruktaki her adres sayfa tipiyle etiketlenir; HTTP işçileri kendi tiplerini, tarayıcı işçileri yalnız tarayıcı gerektiren tipleri alır.

Kuyruk ortak olduğu için hız sınırı da ortak yönetilir: hedefe giden toplam tempo iki işçi türünün toplamıdır ve tek bir sayaçtan izlenir. Proxy tarafında iki işçi türü aynı ürünü ya da farklı ürünleri kullanabilir; HTTP işçileri GB bazlı rotating adresten, tarayıcı işçileri static adet adreslerinden çıkıyorsa tarayıcının taşıdığı megabaytlar GB sayacına girmez. Bu iki üründen birini seçmek yerine ikisini iş tipine göre bölmenin en somut gerekçesidir.

Karma düzende bir sayfa tipinin HTTP’den tarayıcıya ya da tersine taşınması tek satırlık etiket değişikliğidir. Hedef site bir sayfa tipini JSON’dan JavaScript’e taşıdığında yalnız o tip tarayıcı kuyruğuna geçer; geri kalan iş maliyetini korur. HTTP işçisinin aldığı gövdede beklenen alanların bulunup bulunmadığını her yanıtta kontrol edin; alan yoksa o adres tarayıcı kuyruğuna düşer ve değişiklik sessizce geçmez.

Ölçek planı: aynı işi iki yöntemle 100 sayfada denemek

Plan beş adımdır. Birinci adım, hedefteki sayfa tiplerini listeleyip her biri için verinin yerini (HTML, JSON, DOM) geliştirici araçlarıyla belirlemek. İkinci adım, tip başına 100 sayfalık bir örnek seçip yukarıdaki dört değeri (süre, bellek, işlemci, aktarılan veri) iki yöntemle de ölçmek; tarayıcı gerektirmeyen tipte bile tarayıcıyla bir tur atın, çünkü fark raporun en ikna edici satırıdır.

Üçüncü adım, 100 sayfalık değerleri toplam sayfa sayısıyla çarpıp aylık tabloya dönüştürmek: makine saati, toplam GB, adres başına istek sayısı. Dördüncü adım, bu tabloyu ürün birimine çevirmek: toplam GB rotating IPv4 paketlerinden hangisine sığıyor, adres başına istek sayısı hedefin temposuna göre kaç static IPv4 adresi gerektiriyor. Maliyet hesabının adımları maliyet hesaplama rehberinde ayrı bir tabloyla verilir; buradaki ölçüm o tablonun girdilerini üretir.

Beşinci adım, karar ve kayıt: her sayfa tipi için seçilen yöntem, seçilen proxy birimi ve ölçüm tarihi bir tabloda tutulur. Hedef site değiştiğinde 100 sayfalık ölçüm tekrarlanır ve tablo güncellenir. Ölçüm yapılmadan büyütülen bir hat, ilk faturada ya da ilk bellek hatasında planın yanlış olduğunu söyler; 100 sayfalık deneme bunu bir saate sığdırır.

Proxy’nin devrede olduğunu ve zaman aşımı değerlerinin iki yöntemde de uygun kurulduğunu ölçümden önce doğrulayın. Tarayıcı tarafında sayfa yükleme zaman aşımı, HTTP tarafında bağlantı ve okuma zaman aşımı ayrı ayarlardır ve yanlış kurulduğunda ölçüm tablosunu bozar; hangi değerin nerede ayarlanacağı zaman aşımı rehberinde anlatılır.

Karar listesi

Veri kaynak HTML’de: HTTP istemcisi. Aktarılan veri az olduğu için GB bazlı rotating IPv4 genellikle en ucuz birimdir; hedef adres başına tempoya toleranslıysa static IPv4 de çalışır. Veri sayfanın JSON çağrısında: HTTP istemcisi, doğrudan uç noktaya; robots.txt ve kullanım koşulları kontrol edildikten sonra. Aktarılan veri en düşük düzeydedir.

Veri yalnız JavaScript sonrası DOM’da: headless tarayıcı. Aktarılan veri yüksek olduğu için GB saymayan static IPv4 adetleri çoğu zaman daha ucuzdur; hedef adres başına sıkıysa rotating GB düzeni kalır ve alt kaynak engelleme değerlendirilir. Sayfa tipleri karışık: karma düzen, tek kuyruk, iki işçi türü, gerekirse iki ürün.

Her durumda: önce 100 sayfalık ölçüm, sonra ürün seçimi. Satıcı yazılarındaki katsayılar ve “tarayıcı şu kadar pahalı” genellemeleri sizin hedefiniz için bir veri değildir; dört sayıyı kendiniz ölçün ve tabloya tarih yazın.

İlgili ürünler

İç bağlantılar

SSS

Tarayıcı kullanmak engellenmeyi azaltır mı?

Bu rehberin sorusu bu değildir. Karar, verinin nerede olduğuna ve kaynak maliyetine göre verilir; tarayıcı, veri yalnız JavaScript sonrası DOM’da olduğunda gerekir. Hedefin kurallarına uymak, hız sınırını aşmamak ve robots.txt’yi okumak her iki yöntemde de aynı şekilde geçerlidir.

Playwright ile bir makinede kaç sayfa paralel açılabilir?

Makineye, sayfaya ve tarayıcıya bağlıdır; genel bir sayı yoktur. Ölçün: aynı 100 sayfayı artan eşzamanlılıkla çalıştırıp en yüksek bellek kullanımını ve sayfa başına süreyi kaydedin, süre uzamaya ya da bellek hatası görünmeye başladığı noktanın altında kalın. Bu değer sizin tablonuzdaki gerçek sınırdır.

Sayfanın JSON çağrısını doğrudan kullanmak serbest mi?

Uç noktanın tarayıcıdan çağrılması onu herkese açık bir API yapmaz. Sitenin robots.txt dosyasına ve kullanım koşullarına sayfa için nasıl bakıyorsanız bu adres için de öyle bakın; hız sınırı ve istek aralığı aynı kalır. Kurallar izin veriyorsa JSON çağrısı en az veri taşıyan ve en az kırılan yoldur.

Static IPv4 mi rotating GB mi?

Tarayıcı zorunluysa ve hedef adres başına tempoya toleranslıysa GB saymayan static IPv4 genellikle daha ucuzdur; HTTP istemcisiyle az veri taşıyorsanız GB bazlı rotating IPv4 daha ucuzdur. Kesin cevap 100 sayfalık ölçümden çıkan GB ve adres başına istek sayısıyla verilir; hesabın adımları maliyet hesaplama rehberindedir.