İstemci İpuçlarıyla Kullanıcılara Uyum Sağlama

Jeremy Wagner

Her yerde hızlı olan siteler geliştirmek zorlu bir süreç olabilir. Çok sayıda cihaz özelliği ve bu cihazların bağlandığı ağların kalitesi, bu işi aşılması zor bir görev gibi gösterebilir. Yükleme performansını artırmak için tarayıcı özelliklerinden yararlanabiliriz ancak kullanıcının cihazının neler yapabileceğini veya ağ bağlantısının kalitesini nasıl bilebiliriz? Çözüm client hints!

İstemci ipuçları, kullanıcının cihazının ve bağlı olduğu ağın bu yönleri hakkında bize bilgi veren, etkinleştirilebilen bir HTTP istek üst bilgileri kümesidir. Bu bilgilere sunucu tarafında erişerek cihaz ve/veya ağ koşullarına göre içerik sunma şeklimizi değiştirebiliriz. Bu sayede daha kapsayıcı kullanıcı deneyimleri oluşturabiliriz.

İçerik anlaşması hakkında

İstemci ipuçları, içerik anlaşması için kullanılan başka bir yöntemdir. Bu yöntem, içerik yanıtlarını tarayıcı isteği üst bilgilerine göre değiştirmek anlamına gelir.

İçerik anlaşmasıyla ilgili bir örnekte Accept istek başlığı kullanılır. Tarayıcının hangi içerik türlerini anladığını açıklar. Sunucu, yanıtı görüşmek için bu bilgiyi kullanabilir. Resim isteklerinde Chrome'un Accept başlığının içeriği şöyledir:

Accept: image/webp,image/apng,image/*,*/*;q=0.8

Tüm tarayıcılar JPEG, PNG ve GIF gibi resim biçimlerini desteklese de bu durumda Accept, tarayıcının WebP ve WebP'yi APNG desteklediğini belirtir. Bu bilgileri kullanarak her tarayıcı için en iyi resim türlerini belirleyebiliriz:

<?php
// Check Accept for an "image/webp" substring.
$webp = stristr($_SERVER["HTTP_ACCEPT"], "image/webp") !== false ? true : false;

// Set the image URL based on the browser's WebP support status.
$imageFile = $webp ? "whats-up.webp" : "whats-up.jpg";
?>
<img src="<?php echo($imageFile); ?>" alt="I'm an image!">

Accept gibi, istemci ipuçları da içerik görüşmesi için başka bir yol sunar ancak cihaz özelliklerinin ve ağ koşullarının bağlamında. İstemci ipuçları sayesinde, kullanıcının bireysel deneyimine göre sunucu tarafında performans kararları alabiliriz. Örneğin, kritik olmayan kaynakların kötü ağ koşullarına sahip kullanıcılara sunulup sunulmayacağına karar verebiliriz. Bu kılavuzda, mevcut tüm ipuçlarını ve içerik yayınını kullanıcılara daha uygun hale getirmek için bu ipuçlarını kullanabileceğiniz bazı yöntemleri açıklayacağız.

Etkinleştirme

Accept başlığının aksine, istemci ipuçları sihirli bir şekilde görünmez (Save-Data hariç, bunu daha sonra ele alacağız). İstek başlıklarını minimum düzeyde tutmak için, bir kullanıcı kaynak istediğinde Accept-CH başlığı göndererek hangi istemci ipuçlarını almak istediğinizi seçmeniz gerekir:

Accept-CH: Viewport-Width, Downlink

Accept-CH değeri, sitenin sonraki kaynak isteği sonuçlarını belirlerken kullanacağı, virgülle ayrılmış bir istenen ipuçları listesidir. İstemci bu başlığı okuduğunda "Bu site, Viewport-Width ve Downlink istemci ipuçlarını istiyor" mesajını alır. İpuçlarının kendileriyle ilgili endişelenmenize gerek yoktur. Bunlara birazdan değineceğiz.

Bu etkinleştirme başlıklarını herhangi bir arka uç dilinde ayarlayabilirsiniz. Örneğin, PHP'nin header işlevi kullanılabilir. Hatta bu etkinleştirme başlıklarını http-equiv özelliği ile <meta> etiketinde de ayarlayabilirsiniz:

<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />

Tüm istemci ipuçları

İstemci ipuçları iki şeyden birini tanımlar: kullanıcılarınızın kullandığı cihaz ve sitenize erişmek için kullandıkları ağ. Mevcut tüm ipuçlarına kısaca göz atalım.

Cihazla ilgili ipuçları

Bazı istemci ipuçları, kullanıcının cihazının özelliklerini (genellikle ekran özelliklerini) açıklar. Bunlardan bazıları belirli bir kullanıcının ekranı için en uygun medya kaynağını seçmenize yardımcı olabilir ancak hepsi medya odaklı değildir.

Bu listeye geçmeden önce ekranları ve medya çözünürlüğünü tanımlamak için kullanılan birkaç temel terimi öğrenmek faydalı olabilir:

Doğal boyut: Bir medya kaynağının gerçek boyutları. Örneğin, Photoshop'ta bir resmi açtığınızda, resim boyutu iletişim kutusunda gösterilen boyutlar, resmin gerçek boyutunu açıklar.

Yoğunluk düzeltmeli doğal boyut: Piksel yoğunluğu düzeltildikten sonraki medya kaynağının boyutları. Bu değer, resmin gerçek boyutunun cihaz piksel oranına bölünmesiyle elde edilir. Örneğin, şu işaretlemeyi ele alalım:

<img
  src="whats-up-1x.png"
  srcset="whats-up-2x.png 2x, whats-up-1x.png 1x"
  alt="I'm that image you wanted."
/>

Bu örnekte 1x resminin doğal boyutunun 320x240, 2x resminin doğal boyutunun ise 640x480 olduğunu varsayalım. Bu işaretleme, ekran cihaz piksel oranı 2 olan bir cihaza (ör. Retina ekran) yüklenen bir istemci tarafından ayrıştırılırsa 2x resmi istenir. 640x480, 2'ye bölündüğünde 320x240 olduğu için 2x resminin yoğunluk düzeltmeli doğal boyutu 320x240'tır.

Harici boyut: CSS ve diğer düzen faktörleri (ör. width ve height özellikleri) uygulandıktan sonraki medya kaynağının boyutu. Yoğunluk düzeltilmiş 320x240 boyutunda bir resmi yükleyen bir <img> öğeniz olduğunu varsayalım. Ancak bu öğeye sırasıyla 256px ve 192px değerlerine sahip CSS width ve height özellikleri de uygulanmış. Bu örnekte, <img> öğesinin harici boyutu 256x192 olur.

Bazı terimleri öğrendiğimize göre, artık cihazlara özel olarak kullanabileceğiniz istemci ipuçlarının listesine geçebiliriz.

Görüntü alanı genişliği

Viewport-Width, kullanıcının görüntü alanının CSS piksel cinsinden genişliğidir:

Viewport-Width: 320

Bu ipucu, belirli ekran boyutları için ideal olan bir resmin farklı işlemlerini (ör. kırpma) sunmak (ör. sanat yönetimi) veya mevcut ekran genişliği için gereksiz olan kaynakları atlamak amacıyla ekrana özel diğer ipuçlarıyla birlikte kullanılabilir.

DPR

DPR (cihaz piksel oranı), kullanıcının ekranındaki fiziksel piksellerin CSS piksellerine oranını bildirir:

DPR: 2

Bu ipucu, bir ekranın piksel yoğunluğuna karşılık gelen görüntü kaynaklarını seçerken (ör. srcset özelliğindeki x tanımlayıcıları gibi) faydalıdır.

Genişlik

Width ipucu, sizes özelliğini kullanan <img> veya <source> etiketleri tarafından tetiklenen resim kaynakları isteklerinde gösterilir. sizes, tarayıcıya kaynağın harici boyutunun ne olacağını söyler; Width, geçerli düzen için ideal olan bir iç boyuta sahip resmi istemek üzere bu harici boyutu kullanır.

Örneğin, bir kullanıcının 2 DPR'ye sahip 320 CSS piksel genişliğinde bir ekranı olan bir sayfa istediğini varsayalım. Cihaz, 85vw sizes özellik değerine sahip bir <img> öğesi içeren bir doküman yüklüyor (ör. Tüm ekran boyutları için görüntü alanı genişliğinin% 85'i). Width ipucu etkinleştirilmişse istemci, <img>'nin src isteğiyle birlikte bu Width ipucunu sunucuya gönderir:

Width: 544

Bu durumda istemci, istenen resim için optimum doğal genişliğin, görüntü alanı genişliğinin (272 piksel) %85'i ile ekranın DPR'si (2) çarpılarak elde edilen 544 piksel olacağını sunucuya bildiriyor.

Bu ipucu, yalnızca ekranın yoğunluk düzeltmeli genişliğini dikkate almakla kalmayıp bu önemli bilgiyi düzen içindeki resmin harici boyutuyla da uzlaştırdığı için özellikle güçlüdür. Bu, sunuculara hem ekran hem de düzen için optimum olan resim yanıtları üzerinde anlaşma fırsatı verir.

Content-DPR

Ekranların cihaz piksel oranına sahip olduğunu biliyor olsanız da kaynakların da kendi piksel oranları vardır. En basit kaynak seçimi kullanım alanlarında, cihazlar ve kaynaklar arasındaki piksel oranları aynı olabilir. Ancak! Hem DPR hem de Width üstbilgilerinin kullanıldığı durumlarda, bir kaynağın harici boyutu, ikisinin farklı olduğu senaryolar oluşturabilir. Bu noktada Content-DPRipucu devreye girer.

Diğer istemci ipuçlarının aksine Content-DPR, sunucular tarafından kullanılacak bir istek başlığı değil, DPR ve Width ipuçları bir kaynak seçmek için kullanıldığında sunucuların göndermesi gereken bir yanıt başlığıdır. Content-DPR değeri aşağıdaki denklemin sonucu olmalıdır:

Content-DPR = [Seçili resim kaynağı boyutu] / ([Width] / [DPR])

Content-DPR istek başlığı gönderildiğinde tarayıcı, verilen resmi ekranın cihaz piksel oranı ve düzene göre nasıl ölçekleyeceğini bilir. Bu olmadan, resimler düzgün şekilde ölçeklenmeyebilir.

Device-Memory

Teknik olarak Device Memory API'nin bir parçası olan Device-Memory, mevcut cihazın GiB cinsinden yaklaşık bellek miktarını gösterir:

Device-Memory: 2

Bu ipucu, sınırlı belleğe sahip cihazlardaki tarayıcılara gönderilen JavaScript miktarını azaltmak için kullanılabilir. JavaScript, tarayıcıların genellikle yüklediği en kaynak yoğun içerik türüdür. Alternatif olarak, daha az bellek kullandıkları için daha düşük DPR'li resimler gönderebilirsiniz.

Ağ ipuçları

Network Information API, kullanıcının ağ bağlantısının performansını açıklayan başka bir istemci ipucu kategorisi sağlar. Bana göre bu ipuçları en faydalı olanlar. Bu sayede, yavaş bağlantı kullanan müşterilere kaynakları sunma şeklimizi değiştirerek deneyimleri kullanıcılara göre uyarlayabiliriz.

RTT

RTT ipucu, uygulama katmanında yaklaşık gidiş dönüş süresini milisaniye cinsinden sağlar. RTT ipucu, taşıma katmanı RTT'sinden farklı olarak sunucu işlem süresini içerir.

RTT: 125

Bu ipucu, yükleme performansında gecikmenin rolü nedeniyle faydalıdır. RTT ipucunu kullanarak ağın yanıt verme hızına göre kararlar verebiliriz. Bu, bazı istekleri atlayarak tüm deneyimin daha hızlı sunulmasına yardımcı olabilir.

Downlink

Yükleme performansında gecikme önemli olsa da bant genişliği de etkilidir. Saniyede megabit (Mb/sn) cinsinden ifade edilen Downlink ipucu, kullanıcının bağlantısının yaklaşık indirme hızını gösterir:

Downlink: 2.5

RTT ile birlikte Downlink, ağ bağlantısının kalitesine bağlı olarak içeriğin kullanıcılara nasıl sunulacağını değiştirmek için kullanılabilir.

ECT

ECT ipucu, Geçerli Bağlantı Türü anlamına gelir. Değeri, bağlantı türlerinin numaralandırılmış listesinden biridir. Bu türlerin her biri, hem RTT hem de Downlink değerlerinin belirtilen aralıklarındaki bir bağlantıyı açıklar.

Bu başlık, gerçek bağlantı türünün ne olduğunu açıklamaz. Örneğin, ağ geçidinizin baz istasyonu mu yoksa kablosuz erişim noktası mı olduğunu bildirmez. Bunun yerine, mevcut bağlantının gecikmesini ve bant genişliğini analiz eder ve en çok hangi ağ profiline benzediğini belirler. Örneğin, kablosuz bağlantı üzerinden yavaş bir ağa bağlanırsanız ECT, etkili bağlantının en yakın tahmini olan 2g değeriyle doldurulabilir:

ECT: 2g

ECT için geçerli değerler 4g, 3g, 2g ve slow-2g'dir. Bu ipucu, bağlantı kalitesini değerlendirmek için başlangıç noktası olarak kullanılabilir ve daha sonra RTT ile Downlink ipuçları kullanılarak iyileştirilebilir.

Save-Data

Save-Data, ağ koşullarını açıklayan bir ipucundan ziyade sayfaların daha az veri göndermesi gerektiğini belirten bir kullanıcı tercihi gibidir.

Save-Data'yı ağ ipucu olarak sınıflandırmayı tercih ediyorum çünkü onunla yapacağınız birçok şey diğer ağ ipuçlarına benziyor. Kullanıcılar, yüksek gecikme süresi/düşük bant genişliği olan ortamlarda da bu özelliği etkinleştirebilir. Bu ipucu, mevcut olduğunda her zaman şu şekilde görünür:

Save-Data: on

Google olarak Save-Data ile neler yapabileceğinizden bahsettik. Bu durum, performansı önemli ölçüde etkileyebilir. Bu sinyal, kullanıcıların size daha az içerik göndermenizi istediği anlamına gelir. Bu sinyali dikkate alıp buna göre hareket ederseniz kullanıcılar bunu takdir eder.

Hepsini bir araya getirme

İstemci ipuçlarıyla ne yapacağınız size bağlıdır. Çok fazla bilgi sundukları için birçok seçeneğiniz vardır. Fikir edinmek için, kırsal Upper Midwest'te bulunan kurgusal bir kereste şirketi olan Sconnie Timber için istemci ipuçlarının neler yapabileceğine bakalım. Genellikle uzak bölgelerde olduğu gibi, ağ bağlantıları zayıf olabilir. Bu noktada, istemci ipuçları gibi bir teknoloji kullanıcılar için gerçekten fark yaratabilir.

Duyarlı Görseller

En basit duyarlı resim kullanım alanları dışında tüm kullanım alanları karmaşık olabilir. Farklı ekran boyutları ve farklı biçimler için aynı görsellerin birden fazla işleme ve varyantı varsa ne olur? Bu işaretleme çok hızlı bir şekilde çok karmaşık hale gelir. Bu kavramları yanlış anlamak, unutmak veya önemli kavramları (ör. sizes) yanlış yorumlamak kolaydır.

<picture> ve srcset, tartışmasız harika araçlar olsa da karmaşık kullanım alanları için geliştirilmesi ve bakımı zaman alabilir. İşaretleme oluşturma sürecini otomatikleştirebiliriz ancak bu işlevlerin <picture> ve srcset sağladığı işlevler, otomasyonlarının sundukları esnekliği koruyacak şekilde yapılması gerektiğinden bu işlem de zordur.

İstemci ipuçları bu süreci basitleştirebilir. Müşteri ipuçlarıyla görüntü yanıtları için pazarlık yapma süreci şu şekilde olabilir:

1. İş akışınız için geçerliyse önce Viewport-Width ipucunu işaretleyerek bir görüntü işleme (ör. sanat yönetmenliği yapılmış görüntüler) seçin.
2. Width ipucunu ve DPR ipucunu işaretleyerek bir görüntü çözünürlüğü seçin ve görüntünün düzen boyutuna ve ekran yoğunluğuna uygun bir kaynak seçin (x ve w tanımlayıcılarının srcset'deki işleyiş şekline benzer).
3. Tarayıcının desteklediği en uygun dosya biçimini seçin (bu, Accept çoğu tarayıcıda yapmamıza yardımcı olur).

Kurgusal kereste şirketi müşterim için, istemci ipuçlarını kullanan PHP'de basit bir duyarlı resim seçme rutini geliştirdim. Bu, aşağıdaki biçimlendirmeyi tüm kullanıcılara göndermek yerine:

<picture>
  <source
    srcset="
      company-photo-256w.webp   256w,
      company-photo-512w.webp   512w,
      company-photo-768w.webp   768w,
      company-photo-1024w.webp 1024w,
      company-photo-1280w.webp 1280w
    "
    type="image/webp"
  />
  <img
    srcset="
      company-photo-256w.jpg   256w,
      company-photo-512w.jpg   512w,
      company-photo-768w.jpg   768w,
      company-photo-1024w.jpg 1024w,
      company-photo-1280w.jpg 1280w
    "
    src="company-photo-256w.jpg"
    sizes="(min-width: 560px) 251px, 88.43vw"
    alt="The Sconnie Timber Staff!"
  />
</picture>

Tarayıcıların tek tek destek durumuna göre bu listeyi aşağıdaki gibi daralttım:

<img
  src="/image/sizes:true/company-photo.jpg"
  sizes="(min-width: 560px) 251px, 88.43vw"
  alt="SAY CHEESY PICKLES."
/>

Bu örnekte, /image URL'si, mod_rewrite tarafından yeniden yazılan parametrelerin ardından gelen bir PHP komut dosyasıdır. Bu işlev, arka uç komut dosyasının belirli koşullarda en iyi resmi seçmesine yardımcı olmak için bir resim dosya adı ve ek parametreler alır.

"Ancak bu, arka uçta <picture> ve srcset'nin yeniden uygulanması değil mi?" diye düşündüğünüzü tahmin ediyoruz.

Bir bakıma evet, ancak önemli bir farkla: Bir uygulama, medya yanıtları oluşturmak için istemci ipuçlarını kullandığında işin çoğu (hepsi olmasa da) çok daha kolay bir şekilde otomatikleştirilebilir. Bu, sizin adınıza bu işlemi yapabilecek bir hizmeti (ör. CDN) içerebilir. HTML çözümlerinde ise her kullanım alanı için yeni biçimlendirme yazılması gerekir. Evet, işaretleme oluşturmayı otomatikleştirebilirsiniz. Ancak tasarımınız veya gereksinimleriniz değişirse gelecekte otomasyon stratejinizi yeniden gözden geçirmeniz gerekebilir.

İstemci ipuçları, kayıpsız ve yüksek çözünürlüklü bir resimle başlamayı mümkün kılar. Bu resim daha sonra ekran ve düzenin herhangi bir kombinasyonu için en uygun olacak şekilde dinamik olarak yeniden boyutlandırılabilir. Tarayıcının seçim yapabileceği olası resim adaylarının sabit bir listesini sıralamanızı gerektiren srcset'dan farklı olarak bu yaklaşım daha esnek olabilir. srcset, tarayıcılara kaba bir varyant grubu (ör. 256w, 512w, 768w ve 1024w) sunmanızı zorunlu kılarken istemci ipuçlarıyla desteklenen bir çözüm, büyük bir işaretleme yığını olmadan tüm genişliklere hizmet edebilir.

Elbette, görüntü seçme mantığını kendiniz yazmak zorunda değilsiniz. Cloudinary, w_auto parametresini kullandığınızda resim yanıtları oluşturmak için istemci ipuçlarını kullanır ve istemci ipuçlarını destekleyen tarayıcıları kullanan ortalama kullanıcıların% 42 daha az bayt indirdiğini gözlemlemiştir.

Ancak dikkatli olun. Chrome 67'nin masaüstü sürümündeki değişiklikler, kaynaklar arası istemci ipuçları desteğini kaldırdı. Neyse ki bu kısıtlamalar Chrome'un mobil sürümlerini etkilemiyor ve Özellik Politikası ile ilgili çalışmalar tamamlandığında tüm platformlar için tamamen kaldırılacak.

Yavaş ağlardaki kullanıcılara yardımcı olma

Uyarlanabilir performans, kaynakları sunma şeklimizi istemci ipuçlarının bize sunduğu bilgilere göre ayarlayabileceğimiz fikrine dayanır. Bu bilgiler özellikle kullanıcının ağ bağlantısının mevcut durumuyla ilgili bilgilerdir.

Sconnie Timber'ın sitesi söz konusu olduğunda, ağlar yavaşladığında yükü hafifletmek için adımlar atıyoruz. Arka uç kodumuzda Save-Data, ECT, RTT ve Downlink başlıkları inceleniyor. Bu işlem tamamlandığında, daha iyi bir kullanıcı deneyimi için müdahale edip etmememiz gerektiğini belirlemek üzere kullanabileceğimiz bir ağ kalitesi puanı oluştururuz. Bu ağ puanı 0 ile 1 arasındadır. 0, mümkün olan en kötü ağ kalitesini, 1 ise en iyi ağ kalitesini ifade eder.

Öncelikle Save-Data simgesinin bulunup bulunmadığını kontrol ederiz. Bu durumda, kullanıcının deneyimi daha hafif ve hızlı hale getirmek için gereken her şeyi yapmamızı istediğini varsaydığımızdan puan 0 olarak ayarlanır.

Ancak Save-Data yoksa ağ bağlantı kalitesini açıklayan bir puan hesaplamak için ECT, RTT ve Downlink ipuçlarının değerlerini değerlendiririz. Ağ puanı oluşturma kaynak kodu Github'da mevcuttur. Özetle, ağla ilgili ipuçlarını bir şekilde kullanırsak yavaş ağ kullananlar için deneyimleri daha iyi hale getirebiliriz.

Siteler, istemci ipuçlarının sağladığı bilgilere uyum sağladığında "ya hep ya hiç" yaklaşımını benimsememiz gerekmez. Hangi kaynakların gönderileceğine akıllıca karar verebiliriz. Ağ kalitesi düşük olduğunda yükleme performansını hızlandırmak için belirli bir ekran için daha düşük kaliteli resimler göndermek üzere duyarlı resim seçimi mantığımızı değiştirebiliriz.

Bu örnekte, istemci ipuçlarının daha yavaş ağlardaki sitelerin performansını artırma konusundaki etkisini görebiliriz. Aşağıda, istemci ipuçlarına uyum sağlamayan yavaş bir ağdaki siteye ait WebPagetest şelalesi gösterilmektedir:

Şimdi de aynı yavaş bağlantıda aynı site için bir sıralı yükleme grafiği gösteriliyor. Ancak bu kez site, kritik olmayan sayfa kaynaklarını ortadan kaldırmak için istemci ipuçlarını kullanıyor:

İstemci ipuçları, sayfa yüklenme süresini 45 saniyeden bu sürenin onda birinden daha azına düşürdü. Bu senaryoda istemci ipuçlarının avantajları yeterince vurgulanamaz ve yavaş ağlarda kritik bilgiler arayan kullanıcılar için ciddi bir avantaj olabilir.

Ayrıca, istemci ipuçlarını desteklemeyen tarayıcılarda deneyimi bozmadan kullanmak da mümkündür. Örneğin, desteklenmeyen tarayıcılarda tam deneyimi sunmaya devam ederken ECT ipucunun değerini kullanarak kaynak teslimini ayarlamak istiyorsak geri dönüşü varsayılan bir değere şu şekilde ayarlayabiliriz:

// Set the ECT value to "4g" by default.
$ect = isset($_SERVER["HTTP_ECT"]) ? $_SERVER["HTTP_ECT"] : "4g";

Burada "4g", ECT başlığının tanımladığı en yüksek kaliteli ağ bağlantısını temsil eder. $ect değerini "4g" olarak başlatırsak istemci ipuçlarını desteklemeyen tarayıcılar etkilenmez. Opt-in FTW!

Önbelleklere dikkat edin.

Bir yanıtı HTTP üstbilgisine göre her değiştirdiğinizde, önbelleklerin bu kaynağın gelecekteki getirme işlemlerini nasıl ele alacağını bilmeniz gerekir. Vary başlığı, kendisine sağlanan istek başlıklarının değerine göre önbellek girişlerini anahtarladığından burada vazgeçilmezdir. Basitçe söylemek gerekirse, belirli bir HTTP istek başlığına göre herhangi bir yanıtı değiştirirseniz bu başlığı neredeyse her zaman şu şekilde Vary isteğine dahil etmeniz gerekir:

Vary: DPR, Width

Ancak bu konuda büyük bir uyarı var: Sık değişen bir üstbilgide (ör. Cookie) hiçbir zaman Vary önbelleğe alınabilir yanıtlar istemezsiniz. Çünkü bu kaynaklar etkili bir şekilde önbelleğe alınamaz hale gelir. Bu nedenle, RTT veya Downlink gibi istemci ipucu başlıklarına güvenmekten kaçınmak isteyebilirsiniz. Çünkü bunlar, oldukça sık değişebilen bağlantı faktörleridir.Vary Bu üstbilgilerdeki yanıtları değiştirmek istiyorsanız yalnızca ECT üstbilgisini anahtarlamayı düşünebilirsiniz. Bu, önbellek kaçırmalarını en aza indirir.

Elbette bu durum yalnızca yanıtı önbelleğe alıyorsanız geçerlidir. Örneğin, içerikleri dinamik olan HTML öğelerini önbelleğe almazsınız. Çünkü bu, tekrar eden ziyaretlerde kullanıcı deneyimini bozabilir. Bu gibi durumlarda, bu tür yanıtları gerekli gördüğünüz şekilde değiştirebilirsiniz ve Vary ile ilgili endişelenmenize gerek yoktur.

Service worker'larda istemci ipuçları

İçerik pazarlığı artık yalnızca sunucular için değil. Service worker'lar, istemciler ile sunucular arasında proxy görevi gördüğünden kaynakların JavaScript üzerinden nasıl sunulacağı konusunda kontrol sahibi olursunuz. İstemci ipuçları da buna dahildir. Service worker fetch etkinliğinde, bir kaynağın istek üstbilgilerini aşağıdaki gibi okumak için event nesnesinin request.headers.get yöntemini kullanabilirsiniz:

self.addEventListener('fetch', (event) => {
  let dpr = event.request.headers.get('DPR');
  let viewportWidth = event.request.headers.get('Viewport-Width');
  let width = event.request.headers.get('Width');

  event.respondWith(
    (async function () {
      // Do what you will with these hints!
    })(),
  );
});

Etkinleştirdiğiniz tüm istemci ipucu üstbilgileri bu şekilde okunabilir. Ancak bu bilgilerin bir kısmını edinmenin tek yolu bu değildir. Ağa özgü ipuçları, navigator nesnesindeki şu eşdeğer JavaScript özelliklerinde okunabilir:

Bu API'ler her yerde kullanılamadığından in operator ile özellik kontrolü yapmanız gerekir:

if ('connection' in navigator) {
  // Work with netinfo API properties in JavaScript!
}

Buradan, sunucuda kullanacağınız mantığa benzer bir mantık kullanabilirsiniz. Ancak, içerik için istemci ipuçlarıyla anlaşmak üzere bir sunucuya ihtiyacınız yoktur. Yalnızca hizmet çalışanları, kullanıcı çevrimdışı olduğunda içerik sunma özelliği sayesinde deneyimleri daha hızlı ve daha esnek hale getirebilir.

Özet

İstemci ipuçları sayesinde, kullanıcı deneyimlerini tamamen aşamalı bir şekilde hızlandırabiliriz. Kullanıcının cihaz özelliklerine göre medya sunabiliriz. Bu sayede, özellikle karmaşık kullanım alanlarında <picture> ve srcset'ye güvenmek yerine duyarlı resimler sunmak daha kolay hale gelir. Bu sayede, geliştirme tarafında harcanan zaman ve çabayı azaltmanın yanı sıra kaynakları (özellikle resimleri) ve srcset'in yapabileceğinden daha hassas bir şekilde kullanıcı ekranlarını hedefleyecek şekilde optimize edebiliriz.

Belki daha da önemlisi, zayıf ağ bağlantılarını tespit edip gönderdiğimiz içeriği ve gönderme şeklimizi değiştirerek kullanıcılar arasındaki boşluğu kapatabiliriz. Bu, zayıf ağlardaki kullanıcıların sitelere erişmesini büyük ölçüde kolaylaştırabilir. Service worker'larla birlikte, çevrimdışı olarak kullanılabilen inanılmaz derecede hızlı siteler oluşturabiliriz.

İstemci ipuçları yalnızca Chrome'da ve Chromium tabanlı tarayıcılarda kullanılabilir. Ancak bu ipuçlarını, desteklemeyen tarayıcıları zorlamayacak şekilde kullanmak mümkündür. Her kullanıcının cihaz özelliklerinin ve bağlandığı ağların farkında olan, gerçekten kapsayıcı ve uyarlanabilir deneyimler oluşturmak için istemci ipuçlarını kullanmayı düşünebilirsiniz. Diğer tarayıcı satıcılarının da bu özelliklerin değerini göreceğini ve bunları uygulamaya yönelik niyetlerini göstereceğini umuyoruz.

Kaynaklar

• İstemci İpuçları ile Otomatik Duyarlı Resimler
• İstemci ipuçları ve duyarlı resimler: Chrome 67'de neler değişti?
• İstemci İpuçları (Slaytlar)
• Save-Data ile Hızlı ve Hafif Uygulamalar Yayınlama

Bu makaleyle ilgili değerli geri bildirimleri ve düzenlemeleri için Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss ve Estelle Weyl'e teşekkür ederiz.