Headless tarayıcı API'leri: ne zaman render etmeye değer?

Headless tarayıcı, görünür bir pencere olmadan çalışan ve kodla yönetilen gerçek bir tarayıcı motorudur. Headless tarayıcı API'si ise bu motoru bir arayüzün arkasına koyar: ona bir URL ve birkaç talimat verirsiniz; size render edilmiş HTML'i, görünen metni, bir ekran görüntüsünü, bir PDF'i ya da ağ trafiğini döndürür. Ajanlar, düz bir istek boş bir sayfa iskeletiyle döndüğünde ve içerik ancak JavaScript çalıştıktan sonra ortaya çıktığında bu araca başvurur. Güçlü ama pahalı bir araçtır; bu yüzden asıl soru “nasıl kullanırım”dan çok “gerçekten ne zaman gerekir” sorusudur.

Headless tarayıcı API'si ne yapar

Headless bir tarayıcı, ekrana çizim yapmak dışında normal bir tarayıcının yaptığı her şeyi yapar. Sayfayı indirir, betiklerini çalıştırır, stilleri uygular, yönlendirmeleri izler, çerezleri saklar ve bir ziyaretçinin tarayıcısının göndereceği ağ isteklerinin aynısını gönderir. API bunun üzerine kodunuzun şunları yapmasına izin verir:

• sayfayı okumadan önce belirli bir öğeyi, metni ya da ağ yanıtını beklemek;
• bir etkileşimin arkasındaki içeriğe ulaşmak için tıklamak, yazmak, kaydırmak ve göndermek;
• son DOM'u, temizlenmiş metni, bir ekran görüntüsünü ya da bir PDF'i almak;
• ağır kaynakları engellemek ya da sayfanın yüklediği JSON'u yakalamak için isteklerin arasına girmek.

İki biçimde karşınıza çıkar. Onu kendiniz, Playwright, Puppeteer ya da Selenium gibi bir otomasyon kütüphanesiyle çalıştırabilirsiniz; bunlar Chromium'u ve diğer motorları DevTools protokolü ya da WebDriver üzerinden yönetir. Ya da tarayıcı filolarını sizin yerinize işleten ve bunları bir websocket bağlantısı veya basit bir “bu URL'yi render et” uç noktası üzerinden sunan barındırılan bir hizmet kullanabilirsiniz. İlki size denetimi operasyon yüküyle birlikte verir; ikincisi bu yükü kullanıma dayalı faturalandırma ve veri yolunuzdaki üçüncü bir tarafla takas eder.

Önce düz istek, render yalnızca gerektiğinde

Sayfaların çoğu tarayıcı gerektirmez. Bu basamakları sırayla inin ve içeriği veren ilk basamakta durun:

1. Resmî bir yol var mı? Bir API, bir besleme, bir site haritası, bir veri dışa aktarımı ya da bir llms.txt dosyası, herhangi bir sayfadan daha ucuz ve daha kararlıdır.
2. İçerik zaten HTML'in içinde mi? Birçok site sunucu tarafında render eder. Düz bir HTTP isteği ve bir HTML ayrıştırıcı hızlı ve basittir.
3. Sayfa verisini bir JSON uç noktasından mı yüklüyor? Tarayıcının ağ panelinde görünür. Sitenin koşulları izin veriyorsa o uç noktayı doğrudan çağırmak render adımını tamamen atlar.
4. İçerik yalnızca betikler çalıştıktan ya da bir etkileşimden sonra mı oluşuyor? İşte o zaman headless tarayıcı haklı çıkar.

İkinci basamak için hızlı bir test: ham sayfayı çekin ve tarayıcıda gördüğünüz bir ifadeyi arayın:

curl -s https://example.com/pricing | grep -i "per seat"

İfade oradaysa o sayfa için tarayıcıya ihtiyacınız yoktur. Bu tür bir veri çekme işini ölçekli yapmanız gerekiyorsa web kazıma API'si seçimi yazısı seçenekleri karşılaştırıyor.

Render: neyi beklemeli

Render işinin en zor kısmı sayfanın ne zaman hazır olduğunu bilmektir. Yükleme olayı, birçok tek sayfa uygulaması verisini çekmeden önce tetiklenir. “Ağ boşta” durumunu beklemek doğru gibi görünür, ama analiz işaretçileri, uzun yoklama ya da canlı sohbet bileşenleri olan sayfalarda o an hiç gelmez. Güvenilir yaklaşım, gerçekten istediğiniz şeyi beklemektir: bir seçici, bir metin parçası ya da belirli bir yanıt.

Görselleri ve yazı tiplerini engelleyen ve bir sonuç tablosunu bekleyen küçük bir örnek:

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.route("**/*.{png,jpg,jpeg,webp,woff,woff2}", lambda route: route.abort())
    page.goto(url, wait_until="domcontentloaded")
    page.wait_for_selector("table.results", timeout=15000)
    html = page.content()
    browser.close()

Render işini sekteye uğratan başka şeyler de vardır: içeriği örten çerez onay katmanları, tekrar tekrar kaydırma isteyen sonsuz kaydırma, yalnızca görünür olduğunda render edilen tembel yüklenen bölümler, iframe ya da shadow DOM içindeki içerik ve farklı oturumlara farklı işaretleme gösteren A/B testleri. Koda sabit bekleme süreleri serpiştirmek yerine bunların her birini beklemelerinize ve seçicilerinize bilinçli olarak işleyin.

Engelleme, tespit ve uymaya değer kurallar

Siteler otomasyonu fark eder. Tarayıcı parmak izlerine, headless işaretlerine, IP itibarına, istek hızına ve davranışa bakar; doğrulama ekranları, CAPTCHA'lar, hız sınırlaması ya da doğrudan engellemeyle karşılık verir. Bu savunmaların arasından sızmak için kurulmuş, gizlenme eklentileri ve dönen proxy'lerden oluşan koca bir sektör de vardır.

Bir şirket adına hareket eden bir ajan için sağlam tutum daha basittir. robots.txt dosyasını ve sitenin koşullarını okuyun ve bunlara uyun. İstemcinizi dürüstçe tanıtın, istek hızını düşük tutun, zaten çektiğiniz şeyi önbelleğe alın ve 429 ile 403 yanıtlarında geri çekilin. Bir CAPTCHA ya da giriş duvarı, sitenin “hayır” demesidir; onu bir mühendislik sorunu değil, bir sınır olarak ele alın. Engellenen bir sayfayı, yüklenip boş çıkan bir sayfadan ayrı olarak “engellendi” diye kaydedin; böylece ileride kimse bir reddi bir yokluk sanmaz. Crawler görgü kuralları için web crawler nedir ve sorumlu ajan erişimi sayfalarına bakın.

Tarayıcı işletmenin gerçek maliyeti

Render edilen bir sayfa, düz istekle çekilen bir sayfadan çok daha pahalıdır ve fark yalnızca işlem gücünde değildir. Şunları hesaba katın:

• Bellek ve işlemci. Her oturum tam bir tarayıcı sürecidir. Eşzamanlılığı bant genişliğinden çok önce bellek sınırlar.
• Süre. Düz bir istek saniyenin küçük bir kesrinde biterken sayfaların oturması saniyeler sürer; bir kişinin beklediği bir ajan döngüsünde bu fark önemlidir.
• Süreç düzeni. Havuzlar, çökme sonrası toparlanma, sahipsiz kalan süreçler, uzun oturumlarda giderek şişen bellek ve her adımda zaman aşımları.
• Sürüm değişimi. Tarayıcı güncellemeleri davranışı değiştirir, site yenilemeleri seçicileri bozar, tespit sistemleri de haber vermeden değişir.
• Depolama. Kanıt olarak saklarsanız ekran görüntüleri, PDF'ler ve HTML anlık görüntüleri birikir.
• Barındırılan hizmet takası. Barındırılan bir hizmet operasyon yükünü kaldırır, ama oturum ya da dakika başına faturalandırır ve sayfalarınız ile çerezleriniz onun altyapısından geçer. Nerede çalıştığını, neyi ve ne kadar süre sakladığını kontrol edin.

Karar vermeden önce kaba bir boyutlandırma yapın: günde gerçekten kaç sayfanın render edilmesi gerekiyor, her biri ne kadar sürüyor ve kaçının aynı anda çalışması gerekiyor? Çoğu zaman dürüst yanıt, sayfaların küçük bir kısmının tarayıcıya ihtiyaç duyduğu, geri kalanının düz istekle çekilebileceğidir.

Bir ajanın içinde headless tarayıcı

Bir ajana render aracı verdiğinizde aracın çıktısını küçük ve kullanışlı tutun. Ham HTML yerine temizlenmiş metin ya da Markdown döndürün, gezinme menülerini ve alt bilgileri ayıklayın, yönlendirmelerden sonraki son URL'yi ve alınma zamanını ekleyin. Bu son iki alan, bir iddianın sonradan kontrol edilebilmesini sağlar: nerede ve ne zaman okunduğunu söyleyen bir bulgu doğrulanabilir; yalnızca “web'den” diyen bir bulgu doğrulanamaz. Temizleme adımı için makale çıkarma yazısına bakabilirsiniz.

Render etmeyi karar vermekten ayrı tutun. İstek üzerine bir sayfayı render eden araç bir getiricidir. Modelin canlı sitelerde tıklamasına ve yazmasına izin veren araç ise bir tarayıcı ajanıdır; risk profili farklıdır ve sonuç doğuran adımlardan önce onay gerektirir.

GoCux bu resmin render tarafında değil, yönetişim tarafında durur. Bir crawler değildir ve açık web'i kendi başına okumaz. Web malzemesi bir GoCux projesine yetkilendirilmiş bir tarama ya da dışa aktarma adımıyla girer ve özgün sayfa adresi ile alınma tarihiyle birlikte içe aktarılır; böylece kanıt izi, sayfanın okunduğu noktadan başlar. Browser Link yalnızca açıkça izin verilmiş tarayıcı görevlerini çalıştırır ve bir URL hiçbir zaman bir girişi aşma izni sayılmaz. Bu malzemenin gözden geçirilebilir bir şeye nasıl dönüştüğünü web bilgisinden gözden geçirilebilir kanıta sayfası anlatıyor.

Headless tarayıcı eklemeden önce kontrol listesi

• Önce bir API, besleme, dışa aktarma ya da llms.txt aradınız.
• Ham bir istek, içeriğin sunucu HTML'inde bulunmadığını doğruladı.
• Beklemeler sabit süreleri ya da “ağ boşta” durumunu değil, belirli seçicileri veya yanıtları hedefliyor.
• Gerekmedikçe görseller, yazı tipleri ve izleyiciler engelleniyor.
• robots.txt, site koşulları ve hız sınırlarına uyuluyor; engellemeler engelleme olarak kaydediliyor.
• Render edilen her sonuç son URL'sini ve alınma zamanını koruyor.
• Bellek, eşzamanlılık ve depolama boyutlandırıldı ya da barındırılan hizmetin veri işleyişi kontrol edildi.
• Render araçları ile eylem araçları ayrı ve eylem araçları sonuç doğuran adımlardan önce duruyor.