Retina Ekranlar İçin 2x ve 3x Görsel Hazırlama

Retina ve cihaz piksel oranı ne demek?

Retina ifadesi marka kökenli olsa da günlük kullanımda yüksek piksel yoğunluklu ekranları anlatmak için kullanılıyor. Teknik tarafta önemli olan kavram cihaz piksel oranıdır, yani device pixel ratio. Basit anlatımla, tarayıcıdaki bir CSS pikselinin ekranda kaç fiziksel pikselle çizildiğini söyler. Oran 2 ise 1 CSS pikseli için 2x2, yani 4 fiziksel piksel kullanılır. Oran 3 ise bu yoğunluk daha da artar.

Bu fark görsel netliğini doğrudan etkiler. 100 CSS piksel genişliğinde bir alanı düşünün. DPR 1 ekranda 100 piksellik bir dosya yeterli görünür. DPR 2 ekranda aynı alanın gerçekten keskin görünmesi için yaklaşık 200 piksellik kaynak gerekebilir. DPR 3 ekranda bu ihtiyaç 300 piksele kadar çıkabilir. İşte 1x, 2x ve 3x mantığı buradan doğar.

Ancak her şeyi salt matematik gibi düşünmek hatalı olur. İnsan gözü, görsel türüne göre netlik kaybını farklı algılar. Küçük metinli ekran görüntüsünde 1x kaynak hızla bulanık görünürken, yumuşak arka planlı bir fotoğrafta aynı eksik daha az fark edilir. Bu yüzden piksel oranı kararın sadece ilk katmanıdır; tek katmanı değildir.

2x ve 3x gerçekten hangi piksel ihtiyacını anlatır?

Buradaki x tanımı, görselin CSS kutusuna göre kaç kat çözünürlük taşıdığını anlatır. Örneğin sayfada 48x48 CSS piksel olarak gösterilen bir ikon varsa, 1x sürüm 48x48 piksel olabilir. 2x sürüm 96x96, 3x sürüm ise 144x144 piksel olur. Aynı mantık daha büyük alanlar için de geçerlidir. 300 CSS piksel genişliğinde gösterilen bir kart resmi için 2x kaynak yaklaşık 600 piksel genişlikte olabilir.

Buradaki kritik nokta şudur: 2x veya 3x kaynak, görselin ekranda daha büyük görünmesi için değil, aynı görünüm boyutunda daha keskin kalması için hazırlanır. Bu ayrım bazen atlanıyor ve yüksek çözünürlüklü kaynak, yanlışlıkla daha büyük gösterilecek dosya gibi düşünülüyor. Oysa amaç daha büyük sunum değil; daha yoğun ekranda daha temiz sonuç elde etmektir.

Fakat 3x her zaman 2x'ten iyi demek değildir. 3x dosya daha fazla veri taşır. Eğer fark gözle seçilmeyecekse, 3x yalnızca gereksiz aktarım maliyeti yaratır. Bu yüzden 2x ve 3x kararları cihaz yoğunluğu kadar görselin içeriği ve kullanım boyutuyla birlikte verilmelidir.

Hangi alanlarda 2x gerçekten gereklidir?

2x kaynak en çok küçük ama netlik hassasiyeti yüksek yüzeylerde anlamlıdır. Uygulama benzeri ikonlar, avatarlar, küçük kart görselleri, ürün küçük önizlemeleri, arayüz içi semboller ve yazı içeren ekran görüntüleri bu gruba girer. Çünkü bu öğelerde birkaç piksel kaybı bile kenar yumuşaması, metin bulanıklığı veya çizgi kaybı olarak görünür.

Özellikle ekran görüntülerinde 2x farkı hızlı hissedilir. İnce tipografi ve küçük UI detayları 1x kaynağa sıkıştırıldığında bir anda bulanıklaşır. Bu yüzden dokümantasyon, blog örneği veya panel ekranı gibi içeriklerde 2x hazırlık çoğu zaman doğru yatırımdır. Buna karşılık geniş fotoğrafik kapaklarda aynı fark her zaman bu kadar görünür olmayabilir.

Retina hazırlığında ilk güçlü aday çoğu zaman 2x'tir. Çünkü birçok modern cihaz için iyi denge sağlar. Görsel netliğini belirgin biçimde iyileştirirken dosya maliyeti 3x kadar agresif büyümez. Çoğu projede karar zinciri “önce 2x gerekli mi?” sorusuyla başlamalıdır. 3x ise ancak gerçekten gerekirse masaya gelmelidir.

3x ne zaman mantıklıdır, ne zaman gereksizdir?

3x kaynak daha çok küçük ama çok keskin görünmesi beklenen yüzeylerde düşünülebilir. Örneğin yüksek yoğunluklu telefonlarda uygulama benzeri küçük ikonlar, bazı marka işaretleri veya detayın gözle fark edildiği mikro UI parçaları bu gruba girebilir. Eğer eleman 24-32 CSS piksel gibi çok küçük boyutta gösteriliyor ve ince çizgiler taşıyorsa, 3x farkı bazen anlamlı olabilir.

Ama aynı yaklaşımı her görsele yaymak doğru değildir. 1200 CSS piksel genişliğinde gösterilen bir hero görsel için 3x üretmek, 3600 piksel kaynak demektir. Çoğu içerik sitesinde bu gereksiz büyüklüktür. Kullanıcı fark etmeyeceği kadar küçük keskinlik artışı için büyük veri maliyeti öder. Özellikle fotoğrafik görsellerde 3x çoğu zaman savunulamaz hale gelir.

Kısacası 3x istisna olmalı, otomatik standart değil. Eğer 3x olmadan görsel gözle belirgin biçimde zayıflamıyorsa, yüksek ihtimalle 2x ile kalmak daha doğru olur.

Sabit yüzey ile akışkan yüzey aynı mantıkla mı çözülür?

Bu konu en çok karışan alanlardan biridir. Sabit boyutlu veya yaklaşık sabit boyutlu yüzeylerde 1x, 2x, gerekiyorsa 3x mantığı daha anlaşılırdır. Örneğin 48 CSS piksel avatar için avatar.png 1x, [email protected] 2x yazmak doğrudur. Çünkü gösterim alanı aşağı yukarı sabittir; değişen şey cihaz yoğunluğudur.

Buna karşılık akışkan yerleşimlerde, yani kart genişliği veya içerik görseli viewport'a göre değişiyorsa çoğu zaman w tanımlayıcısı daha uygundur. Çünkü burada sadece piksel yoğunluğu değil, gerçek gösterim genişliği de değişir. Bu mantık özellikle srcset kurulumunda önem kazanır. Yanlış tanımlayıcı seçimi, fazla büyük veya gereksiz küçük kaynağın seçilmesine yol açabilir.

<img
  src="/img/avatar.png"
  srcset="/img/avatar.png 1x, /img/[email protected] 2x"
  width="48"
  height="48"
  alt="Profil görseli">

Bu yapı avatar gibi sabit yüzeylerde temizdir. Ama genişliği kırılımlara göre değişen kart görselinde aynı mantık her zaman doğru olmaz. Orada çoğu zaman genişlik adayları gerekir. Yani 2x/3x mantığı ile responsive kaynak mantığı birbirine yakın görünse de aynı problem alanı değildir.

Logo, ikon ve çizgisel öğelerde önce SVG düşünülmeli mi?

Evet, çoğu durumda evet. Eğer öğe çizgisel, geometrik ve vektör mantığıyla kurulabiliyorsa, önce raster 2x/3x paketleri üretmek yerine SVG düşünmek daha temiz olur. Çünkü aynı dosya farklı yoğunluklarda keskin kalır ve ayrı ayrı 1x, 2x, 3x sürüm üretme ihtiyacını azaltır. Bu nedenle SVG ile PNG ayrımı retina hazırlığında çok kritiktir.

Özellikle logo, basit ikon seti ve arayüz sembollerinde yüksek yoğunluk ihtiyacını raster varyasyonla çözmeye çalışmak bakım maliyetini gereksiz büyütür. Tek bir simgede sorun görünmeyebilir; ama 40 ikonlu bir sistemde 1x, 2x, 3x varyasyonlar bir anda devasa arşive dönüşür. SVG bu yükü ciddi biçimde azaltabilir.

Elbette her şey SVG ile çözülmez. Piksel tabanlı ekran görüntüsü, doku içeren küçük grafik, efektli rozet veya özel raster detay taşıyan öğeler hâlâ PNG ya da WebP ailesi isteyebilir. Ama retina hazırlığında ilk refleks her zaman “3x PNG çıkaralım” olmamalı. Önce öğenin doğası vektör mü raster mı diye bakmak gerekir.

Ekran görüntüsü ve arayüz görsellerinde neden daha dikkatli olunmalı?

Ekran görüntüsü görselleri retina kararı açısından en hassas alanlardan biridir. Çünkü bu dosyalar hem küçük metin hem ince çizgi hem de arayüz sınırı taşır. 1x kaynak ekran yoğunluğu arttıkça hızla yumuşar. Özellikle ürün tanıtım sayfalarında, rehber içeriklerde ve dokümantasyon ekranlarında bu problem hemen görünür hale gelir.

Bu tür görsellerde yalnızca yüksek çözünürlük değil, doğru gösterim boyutu da önemlidir. 3x ekran görüntüsü hazırlayıp sonra onu 320 CSS piksele sıkıştırmak her zaman akıllıca değildir. Önce gerçek kullanım alanını belirlemek gerekir. Ardından 2x çoğu zaman iyi başlangıç olur; eğer küçük metin yoğunluğu çok yüksekse 3x test edilebilir. Ama bu kararı gerçek cihaz görüntüsüne bakmadan vermek zordur.

Özellikle ekran görüntülerini dosya boyutunu küçültme sürecinden geçirirken dikkatli olmak gerekir. Fotoğraflar için kabul edilebilir kalite ayarı, arayüz ekranında yazı netliğini bozabilir. Retina hazırlığı ile sıkıştırma ayarı burada birbirine doğrudan bağlıdır.

Dosya boyutu kontrolden çıkmadan nasıl yönetilir?

2x ve 3x hazırlığın en büyük riski budur: Her şeyi daha keskin yapmaya çalışırken ağ maliyetini büyütmek. Bu yüzden yüksek yoğunluk kaynakları yalnızca ihtiyaç duyulan yüzeylerde üretmek gerekir. “Her varlığın 1x, 2x, 3x paketi olsun” gibi kural, küçük projede bile gereksiz kalabalık yaratır. Önce hangi bileşenler gerçekten yüksek yoğunluk isteyecek, onu çıkarın.

Bu denge kurulmadığında retina optimizasyonu hızla tersine döner. Sayfa teknik olarak daha keskin görünür, ama daha ağır açılır. Özellikle mobil ağ koşullarında bu takas çoğu zaman kullanıcı lehine değildir. O yüzden retina hazırlığı, kalite takıntısı değil ölçülü netlik kararı olarak düşünülmelidir.

Export zinciri ve ekip alışkanlığı bu işi nerede dağıtır?

Bir ekip 2x ve 3x kaynak üretmeye karar verdiğinde sorun yalnızca HTML işaretlemesi değildir. Tasarım, çıktı adlandırma, medya yükleme ve içerik düzenleme süreçleri de etkilenir. Hangi dosya nerede kullanılacak? Editör yanlışlıkla 1x olanı mı yükledi? Tasarımcı export sırasında 2x yerine 3x mi verdi? Bu soruların net cevabı yoksa sistem kısa sürede dağılır.

CMS tarafında özellikle kart, galeri ve öne çıkan içerik modülleri ayrı ayrı incelenmelidir. Bazı yüzeyler sabit boyutludur ve x tanımlayıcıları için uygundur. Bazıları akışkan davranır ve genişlik odaklı plan ister. Tek bir kuralla bütün siteyi yönetmeye çalışmak, bakım kolaylığı gibi görünse de pratikte daha çok istisna üretir.

Bu nedenle ekip içi en sağlıklı yaklaşım, bileşen bazlı karar tablosu çıkarmaktır. Avatar 2x, ikon mümkünse SVG, kart görseli genişlik bazlı, ekran görüntüsü en az 2x gibi net kurallar üretildiğinde sistem sürdürülebilir olur. Aksi halde retina hazırlığı birkaç iyi niyetli export kararından ibaret kalır.

Gerçek cihaz testi: 2x ile 3x arasındaki çizgi

Retina hazırlığın gerçekten işe yarayıp yaramadığını anlamak için tek başına masaüstü monitöre bakmak yetmez. Farklı yoğunluklu gerçek cihazlarda veya güvenilir simülasyonlarda test yapmak gerekir. Çünkü 1x ile 2x arasındaki fark standart yoğunluklu ekranda belirgin görünmeyebilir, ama yüksek yoğunluklu cihazda hemen ortaya çıkar. Özellikle küçük metin ve ince sınır taşıyan görsellerde bu test zorunludur.

İkinci kontrol dosya ağırlığıdır. Daha keskin görünüyor diye her karar iyi değildir. 3x sürüm anlamlı görsel kazanç üretmiyor ama dosya boyutunu ciddi artırıyorsa, o karar geri alınmalıdır. Bu yüzden retina optimizasyonu yalnızca göz testi değil, ağ testi de ister. Netlik ve aktarım maliyeti birlikte değerlendirilmelidir.

Üçüncü kontrol HTML seçimidir. Tarayıcı gerçekten beklenen kaynağı mı indiriyor? Sabit yüzey için 1x/2x zinciri doğru çalışıyor mu? Akışkan alanda yanlışlıkla x tanımlayıcısına mı kaldınız? Kaynak planı kağıt üstünde doğru görünse bile, gerçek çıktıda yanlış dosya seçiliyor olabilir. Bu yüzden geliştirici araçlarında network ve element denetimi birlikte yapılmalıdır.

Bir de farklı işletim sistemi ölçekleme davranışlarına dikkat etmek gerekir. Aynı ekran yoğunluğu, tarayıcı yakınlaştırması ya da sistem ölçeklemesi yüzünden farklı algılanabilir. Özellikle masaüstünde yüzde 125 veya yüzde 150 gibi sistem ölçekleri kullanıldığında, bazı küçük görsellerin netliği beklenenden daha hassas hale gelir. Bu yüzden testleri yalnızca teorik DPR değeri üzerinden değil, gerçek kullanım koşullarında yapmak daha güvenilir sonuç verir.

Son kontrol de içerik türüne göre yapılmalıdır. İkon, ekran görüntüsü ve fotoğrafı aynı gözle değerlendirmeyin. Birinde kabul edilebilir görünen sonuç, diğerinde hemen zayıf hissedilebilir. Retina testi her zaman yüzeyin kendi bağlamında anlam kazanır.

Duruş noktası: ne zaman 2x yeterlidir?

Kuralı karmaşıklaştırmadan da doğru karar verebilirsiniz: küçük ve hassas yüzeylerde önce 2x düşünün, 3x'i ise yalnızca fark gerçekten gözle görünüyorsa açın. Çizgisel öğelerde vektör ihtimalini önceleyin, geniş fotoğrafik alanlarda yoğunluk yarışına girmeyin. En çok hata, bütün varlıkları tek kalıpla çözmeye çalışırken çıkar.

Retina hazırlığı bir piksel büyütme alışkanlığı değildir. Asıl iş, hangi yüzeyin gerçekten ek bilgi istediğini bilip geri kalanını sakin bırakmaktır. Olgun dosya sistemi bu ayrım netleştiğinde ortaya çıkar: her şeyi değil, yalnızca hassas yerleri ayrı ele alır.