Web Sitesi Ekran Görüntüsü Almanın Doğru Yolu: Araç Karşılaştırması

Tarayıcı uzantıları: hız ve pratik sınırlar

Tarayıcı uzantıları, kurulum gerektirmeden ya da çok az kurulumla anında kullanılabilir olmalarıyla ilk tercih haline gelir. GoFullPage, Nimbus Screenshot ve benzer uzantılar sayfayı dikey eksende kaydırarak birleştirir ve PNG ya da JPEG olarak indirir. Ortalama bir kullanıcı için kurulumdan ilk çıktıya kadar geçen süre beş dakikayı geçmez.

Avantajın arka yüzü bellidir. Uzantılar tarayıcının gerçek render motorunu kullanır, dolayısıyla JavaScript çalışır, lazy-load içerik yüklenir ve sayfanın görünümü oldukça doğru yansıtılır. Ama pencere genişliği çıktıyı doğrudan etkiler; 1440 piksel genişlikte açık bir tarayıcıyla 1920 piksellik bir çıktı üretemezsiniz. DPR (Device Pixel Ratio) ayarı tarayıcının kendi ekran ölçeğine bağlıdır, elle sabitlenemez. Toplu çalıştırma yoktur; her URL için uzantıyı manuel tetiklemeniz gerekir.

Uzantılar ne zaman doğru seçimdir? Müşteriye sunulacak tek seferlik tasarım belgesi, manuel QA notları ya da belirli bir sayfanın anlık kaydı için yeterlidir. Düzenli aralıklarla otomatik görsel üretilecekse uzantı o noktada devre dışı kalır.

Puppeteer ile tam sayfa ekran görüntüsü

Puppeteer, Node.js tabanlı bir headless Chrome/Chromium kütüphanesidir ve ekran görüntüsü için page.screenshot() metodunu sunar. Asıl güç bu metodun aldığı parametrelerden gelir: viewport boyutu, DPR çarpanı, bekleme stratejisi ve çıktı formatı bunların hepsi kod içinde sabitlenebilir.

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setViewport({ width: 1280, height: 800, deviceScaleFactor: 2 });
await page.goto('https://ornek.com', { waitUntil: 'networkidle2' });
await page.screenshot({ path: 'cikti.png', fullPage: true });
await browser.close();

deviceScaleFactor: 2 ile retina kalitesinde çıktı üretilir; 1280×800 viewport bu ayarla 2560×1600 piksel PNG verir. waitUntil: 'networkidle2' seçeneği ağ isteklerinin durmasını bekler; lazy-load görsel içeren sayfalarda bu parametre atlandığında boş alanlar veya eksik içerik görünür. Sayfada CSS animasyonu ya da zamanlayıcıya bağlı içerik varsa ek bir page.waitForTimeout() çağrısı gerekebilir.

Puppeteer'ın en yaygın kurulum sorunu Chromium bağımlılığıdır. Docker ortamında libnss3, libatk1.0-0, libgbm1 gibi sistem kütüphaneleri kurulu olmazsa başlatma adımında hata alınır. puppeteer-core paketi Chromium indirmez; zaten sisteminizde kurulu tarayıcıyı işaret ederek bu bağımlılığı atlar. Network erişimini engellemek, çerez ayarlamak, sayfaya JavaScript enjekte etmek gibi işlemleri Puppeteer herhangi bir uzantının yapamayacağı biçimde yönetir.

Playwright: çoklu tarayıcı desteği ve farklar

Playwright, Microsoft tarafından geliştirilmiş ve Chromium yanı sıra Firefox ile WebKit'i de destekleyen headless kütüphanedir. API yapısı Puppeteer'a yakındır; temel ayrım çoklu tarayıcı desteği ve bekleme mekanizmalarının daha tutarlı çalışmasıdır.

const { chromium } = require('playwright');
const browser = await chromium.launch();
const page = await browser.newPage();
await page.setViewportSize({ width: 1440, height: 900 });
await page.goto('https://ornek.com', { waitUntil: 'networkidle' });
await page.screenshot({ path: 'cikti.png', fullPage: true });
await browser.close();

Playwright'ın networkidle bekleme stratejisi karmaşık SPA yapılarında Puppeteer'dan daha az kırılgan davranır; eksik içerikle karşılaşma olasılığı daha düşüktür. WebKit renderını test etmek ya da Safari'de sayfanın nasıl göründüğünü yakalamak istiyorsanız Playwright zorunlu hale gelir. Salt Chromium çıktısı yeterliyse Puppeteer biraz daha hafif kurulum sunar; bu durum dışında iki araç arasında belirleyici bir kalite farkı yoktur.

Her iki araç da aynı temel kısıtı taşır. Kimlik doğrulama gerektiren sayfalar için oturumu programatik olarak açmak ya da çerezi enjekte etmek gerekir. Bunu doğru yapmak ek kod ve test süresi gerektirir; ama cloud API'lerinin çoğunlukla hiç yapamadığı şeyi bu araçlar yapar.

Cloud ekran görüntüsü API'leri: kurulum sıfır, kontrol sınırlı

Kendi sunucunuzda headless tarayıcı çalıştırmak istemediğiniz durumlar için cloud tabanlı ekran görüntüsü API'leri bir seçenek oluşturur. Bu servisler HTTP isteğiyle URL alır, render eder ve görüntü döner. Kurulum gerektirmez; bağımlılık yönetimi ve tarayıcı güncellemeleri karşı tarafın sorumluluğundadır.

Ücretlendirme genellikle istek başınadır. Düşük hacimli kullanım için maliyet ihmal edilebilir; yüksek frekanslı otomasyon için aylık maliyet hesaplanması gerekir. Ağ gecikmesi de bir faktördür: API isteği, render, geri dönüş döngüsü yerel headless çalıştırmaya kıyasla yavaştır ve bu fark yüzlerce URL içeren toplu işlemlerde birikir.

Sınır nettir. Giriş sayfasının arkasındaki bir dashboard ekranını yakalamak istiyorsanız bu API'lerin büyük çoğunluğu bunu yapamaz. Session tabanlı kimlik doğrulama gerektiren sayfalar, belirli bir IP ya da kullanıcı oturumu gerektiren içerikler bu kategoride sorun çıkarır. Public görünümlü içerik yeterliyse ve ölçek düşükse servis mantıklı bir seçenektir; aksi halde headless yaklaşım kaçınılmaz olur.

Retina ve yüksek DPR çıktısı: ne zaman gerekli, ne zaman gereksiz

Retina kalitesi - yani 2× ya da 3× DPR - ile ekran görüntüsü üretmek görsel boyutunu orantılı artırır. 1280×800 viewport için 2× çarpanla 2560×1600 piksel PNG elde edilir; dosya boyutu ise çarpanın karesiyle büyür, yaklaşık dört katına çıkar.

Ne zaman gereklidir? App Store ve Play Store görselleri, yüksek çözünürlük gerektiren sunum dokümanları, retina ekranlı kullanıcılar için üretilen Open Graph görselleri ve fiziksel baskıya gidecek ekran görüntüleri bu kategoriye girer. Rutin blog örneklemesi ya da iç iletişim için alınan görüntülerde 2× çarpan gerekmez; yalnızca disk ve bant genişliği tüketir.

Puppeteer'da deviceScaleFactor parametresi, Playwright'ta ise context oluşturulurken geçilen deviceScaleFactor seçeneği bu değeri sabitler. Hangi makinede çalıştırılırsa çalıştırılsın aynı DPR elde edilir; farklı ekran ölçeklerine sahip CI makinelerinde çıktı tutarsızlığı bu sayede önlenir.

CI/CD entegrasyonu ve zamanlanmış görevler

Ekran görüntüsü alma işlemini CI/CD sürecine entegre etmek, Puppeteer ya da Playwright olmadan pratikte mümkün değildir. GitHub Actions ya da GitLab CI üzerinde bu kütüphaneleri çalıştırmak Node.js kurulumu ve birkaç sistem bağımlılığını gerektirir; bu bağımlılıklar çoğu standart CI görüntüsünde eksiktir ve workflow tanımına ek kurulum adımları eklenmesi gerekir.

Docker kullanıyorsanız --no-sandbox ve --disable-setuid-sandbox bayraklarını Chromium'a geçirmeniz gerekir. Konteyner ortamlarında sandbox mekanizması farklı yapılandırılmıştır; bu bayraklar olmadan Chromium başlatma adımında hata alınır. Bu bayrakların izole konteyner dışında, doğrudan bir sunucuda kullanılması güvenlik riski taşır; ortamı ayırt etmek önemlidir.

Görsel regresyon testi için Percy ve Chromatic gibi araçlar ekran görüntülerini karşılaştırır, değişen pikselleri işaretler ve UI kırılmalarını otomatik saptar. Salt sosyal medya görseli üretimi ya da periyodik arşivleme için bunlar gerekmez; Puppeteer ile zamanlanmış görev (cron) kombinasyonu yeterlidir ve kurulumu basit kalır.

Çıktı formatı ve dosya boyutu dengesi

Puppeteer varsayılan olarak PNG üretir. JPEG için { type: 'jpeg', quality: 85 }, WebP için { type: 'webp', quality: 85 } parametresi yeterlidir; WebP çıktısı Chromium 112 ve üzerinde çalışır, daha eski Chromium sürümü kuruluysa bu seçenek hata verir.

Format seçimi içeriğe ve kullanım amacına göre ayrışır. PNG şeffaf arka plan gerektiren UI görselleri ve tam renk doğruluğu istenen teknik ekran görüntüleri için uygundur. JPEG fotoğraf ağırlıklı sayfa görünümlerinde ya da büyük tam sayfa çıktılarda boyut avantajı sağlar; şeffaflık gerektirmeyen senaryolarda PNG'ye kıyasla dosya boyutu belirgin biçimde düşer. WebP modern pipeline'larda JPEG'den daha küçük çıktı üretir; eski sistemlere ya da e-posta gövdesine gönderilecekse uyumluluk sorunları çıkabilir.

İçerik yoğun bir tam sayfa ekran görüntüsünde PNG birkaç megabaytı aşabilir; özellikle yüksek DPR ile birleştiğinde bu boyut katlanır. Arşivleme ya da ağda iletim amacıyla üretiyorsanız format seçimi boyutu doğrudan etkiler. Şeffaflık gerekmiyorsa ve sayfa fotoğrafik nitelikte içerik taşıyorsa JPEG ya da WebP tercih edilmesi mantıklıdır.

Araç seçimi bağlamı doğru okumakla başlar. Tek seferlik bir sunum görseli için tarayıcı uzantısı yeterlidir ve hızlıdır; aynı araçla haftalık görsel arşivi oluşturmaya çalışmak gereksiz manuel yük getirir. Puppeteer ya da Playwright, otomasyon ihtiyacı olan her senaryoda başlangıç noktası olarak doğru seçimdir; ancak sunucu kurulumu ve bağımlılık yönetimi beraberinde gelir. Cloud API'leri altyapı yükü taşımak istemediğinizde mantıklıdır; kimlik doğrulama gerektiren sayfalarda ise headless yaklaşım kaçınılmaz hale gelir.

Retina çıktısı her kullanım senaryosu için gerekli değildir. Neyi ürettiğinizi ve nerede kullanacağınızı bilmeden iki kat büyüklükte dosya üretmek kaynak israfıdır; aynı şekilde cloud API'sine yönlendirip ardından oturum kısıtlamasına takılmak da önlenebilir bir kayıptır. Her araç bir senaryo için tasarlanmıştır ve bu karşılaştırmadaki kriterler, hangi soruyu sormak gerektiğini görmek için yeterli bir çerçeve sunar.