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

Her yerde hızlı olan siteler geliştirmek yanıltıcı olabilir. Cihaz özelliklerinin çokluğu ve bağlandıkları ağların kalitesi, bunu aşılmaz bir görev gibi gösterebilir. Yükleme performansını iyileştirmek için tarayıcı özelliklerinden yararlanabiliriz. Ancak kullanıcının cihazının neler yapabildiğini veya ağ bağlantısının kalitesini nasıl bilebiliriz? Çözüm, müşteri ipuçlarıdır.

İstemci ipuçları, kullanıcının cihazının ve bağlı olduğu ağın bu yönleriyle ilgili bize bilgi sağlayan bir isteğe bağlı HTTP isteği başlığı grubudur. Bu bilgi sunucusu tarafından yararlanarak, cihaz ve/veya ağ koşullarına göre içeriği nasıl sunacağımızı değiştirebiliriz. Bu, daha kapsayıcı kullanıcı deneyimleri oluşturmamıza yardımcı olabilir.

İçerik Pazarlığı Her Şeydir

İstemci ipuçları, başka bir içerik pazarlığı yöntemidir. Bu, içerik yanıtlarını tarayıcı istek başlıklarına göre değiştirmek anlamına gelir.

İçerik pazarlığına örnek olarak Accept istek başlığı verilebilir. Tarayıcının anladığı içerik türlerini ve sunucunun yanıt pazarlığı için kullanabileceğini açıklar. Resim istekleri söz konusu olduğunda Chrome'un Accept üst bilgisinin 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 desteklerken Kabul et, bu durumda tarayıcının WebP ve APNG'yi de desteklediğini belirtir. Bu bilgileri kullanarak her tarayıcı için en iyi resim türünü 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 cihaz özellikleri ve ağ koşulları bağlamında olmakla birlikte içerik pazarlığı için başka bir yöntemdir. İstemci ipuçları sayesinde, kritik olmayan kaynakların kötü ağ koşullarına sahip kullanıcılara sunulup sunulmayacağına karar vermek gibi, kullanıcının kişisel deneyimine dayanarak sunucu tarafı performans kararları alabiliyoruz. Bu kılavuzda, mevcut tüm ipuçlarını ve içerik yayınlamayı kullanıcılara daha uygun hale getirmek için bunları kullanabileceğiniz yöntemleri açıklayacağız.

Etkinleştirme

Accept başlığından farklı olarak, istemci ipuçları sihirli bir şekilde görünmez (daha sonra ele alacağımız Save-Data hariç). İstek başlıklarını en az sayıda tutmak isterseniz, bir kullanıcı kaynak istediğinde Accept-CH başlığı göndererek hangi istemci ipuçlarını almak istediğinizi etkinleştirmeniz gerekir:

Accept-CH: Viewport-Width, Downlink

Accept-CH değeri, sitenin sonraki kaynak isteği sonuçlarını belirlemekte kullanacağı istenen ipuçlarının virgülle ayrılmış listesidir. İstemci bu üst bilgiyi okuduğunda, "bu site Viewport-Width ve Downlink istemci ipuçlarını istiyor" mesajı gösterilir. Belirli ipuçlarını merak etmeyin. Birazdan bu konuyu ele alacağız.

Bu etkinleştirme üstbilgilerini herhangi bir arka uç dilinde ayarlayabilirsiniz. Örneğin, PHP’nin header işlevi kullanılabilir. Bu etkinleştirme üstbilgilerini bir <meta> etiketinde http-equiv özelliğiyle de ayarlayabilirsiniz:

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

Tüm müşteri ipuçları!

İstemci ipuçları iki unsurdan birini açıklar: kullanıcılarınızın kullandığı cihaz ve sitenize erişmek için kullandıkları ağ. Kullanabileceğiniz tüm ipuçlarına kısaca değinelim.

Cihaz ipuçları

Bazı istemci ipuçları, kullanıcının cihazının özelliklerini açıklar (genellikle ekran özellikleri). Bunlardan bazıları, belirli bir kullanıcının ekranı için en uygun medya kaynağını seçmenize yardımcı olabilir, ancak bunların tümü medya merkezli olmayabilir.

Bu listeye girmeden önce ekranları ve medya çözünürlüğünü açıklamak için kullanılan birkaç anahtar terimi öğrenmek yararlı olabilir:

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

Yoğunluk düzeltilmiş doğal boyut: Piksel yoğunluğu düzeltildikten sonra medya kaynağının boyutları. Bu değer, resmin cihaz piksel oranına bölünmesiyle elde edilen gerçekçi boyutun değeridir. Ö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 içsel boyutunun 320x240, 2x resminin doğal boyutunun 640x480 olduğunu varsayalım. Bu işaretleme, ekran cihaz piksel oranı 2 olan (ör. Retina ekran) bir cihaza yüklenmiş bir istemci tarafından ayrıştırılırsa 2x resmi istenir. 640x480 bölümünün 2'ye bölümü 320x240 olduğu için 2x resminin yoğunluk düzeltilmiş doğal boyutu 320x240 olur.

Dış boyut: Bir medya kaynağının CSS ve diğer düzen faktörleri (width ve height özellikleri gibi) uygulandıktan sonraki boyutu. Yoğunluğu düzeltilmiş 320x240 boyutundaki bir resmi yükleyen <img> öğenizin olduğunu, ancak aynı zamanda sırasıyla 256px ve 192px değerlerine sahip CSS width ve height özelliklerinin de uygulandığını düşünelim. Bu örnekte, bu <img> öğesinin dış boyutu 256x192 olur.

Şimdi biraz terminolojiye sahip olduğumuzdan, kullanabileceğiniz cihaza özel istemci ipuçlarının listesine geçelim.

Görüntü Alanı-Genişliği

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

Viewport-Width: 320

Bu ipucu, bir resmin belirli ekran boyutları (ör. sanat yönü) için en uygun olan farklı işlemleri (ör. kırpma işlemleri) sağlamak veya geçerli ekran genişliği için gereksiz olan kaynakları atlamak amacıyla ekrana özgü diğer ipuçlarıyla birlikte kullanılabilir.

DPR

Cihaz piksel oranının kısaltması olan DPR, kullanıcı ekranındaki fiziksel piksellerin CSS piksellerine oranını raporlar:

DPR: 2

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

Genişlik

Width ipucu, sizes özelliği kullanılarak <img> veya <source> etiketleri tarafından tetiklenen resim kaynakları isteklerinde görünür. sizes tarayıcıya kaynağın dış boyutunun ne olacağını bildirir. Width bu dış boyutu kullanarak mevcut düzen için ideal olan içsel boyuta sahip bir resim ister.

Örneğin, bir kullanıcının 320 CSS piksel geniş ekranlı ve DPR'si 2 olan bir sayfayı istediğini varsayalım. Cihaz, 85vw değerindeki sizes özellik değerini (ör.<img> tüm ekran boyutlarında görüntü alanı genişliğinin% 85'i). Width ipucu etkinleştirilmişse istemci, <img> src için istekle birlikte şu Width ipucunu sunucuya gönderir:

Width: 544

Bu durumda istemci, sunucuya, istenen resim için optimum içsel genişliğin, görüntü alanı genişliğinin (272 piksel) %85'inin 544 piksele eşit olan ekran DPR'si (2) ile çarpılacağına dair ipucu verir.

Bu ipucu, yalnızca ekranın yoğunluğu tarafından düzeltilen genişliğini hesaba katmakla kalmayıp aynı zamanda bu kritik bilgi parçasını resmin düzen içerisindeki dış boyutuyla eşleştirdiği için özellikle güçlüdür. Bu, sunuculara hem ekran hem de düzen için en uygun resim yanıtları üzerinde pazarlık yapma fırsatı verir.

İçerik DPR

Ekranların cihaz piksel oranı olduğunu zaten biliyor olsanız da kaynakların kendi piksel oranları da vardır. En basit kaynak seçimi kullanım alanlarında, cihazlar ve kaynaklar arasındaki piksel oranları aynı olabilir. Ama! Hem DPR hem de Width üst bilgilerinin kullanıldığı durumlarda, bir kaynağın dış boyutu, ikisinin farklı olduğu senaryolar oluşturabilir. İşte Content-DPR ipucu bu noktada devreye girer.

Diğer istemci ipuçlarından farklı olarak Content-DPR, sunucular tarafından kullanılacak bir istek başlığı değildir. Bunun yerine, kaynak seçmek için DPR ve Width ipuçları her kullanıldığında bir yanıt başlığı sunucularının göndermesi gerekir. Content-DPR değeri şu denklemin sonucu olmalıdır:

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

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

Cihaz-Bellek

Teknik olarak Cihaz Belleği API'sinin bir parçası olan Device-Memory, geçerli cihazın GiB cinsinden yaklaşık bellek miktarını gösterir:

Device-Memory: 2

JavaScript, tarayıcıların genellikle en fazla kaynak kullandığı içerik türü olduğundan, sınırlı belleğe sahip cihazlardaki tarayıcılara gönderilen JavaScript miktarını azaltmak bu ipucu için olası bir kullanım alanıdır. Alternatif olarak, kodu çözmek için daha az bellek kullandıklarından daha düşük DPR resimleri 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 sunar. Bana sorarsanız bunlar en faydalı ipuçları. Bu araçlar sayesinde, yavaş bağlantılara sahip müşterilere kaynak sağlama şeklimizi değiştirerek deneyimleri kullanıcılara uygun hale getirebiliyoruz.

RTT

RTT ipucu, uygulama katmanında milisaniye cinsinden yaklaşık Gidiş Dönüş Süresi'ni sağlar. RTT ipucu, aktarım katmanı RTT'sinin aksine sunucu işleme süresini içerir.

RTT: 125

Bu ipucu, yükleme performansındaki gecikmenin oynadığı rol nedeniyle yararlıdır. RTT ipucunu kullanarak ağ duyarlılığına dayalı kararlar alabiliriz.Bu, tüm deneyimin daha hızlı sunulmasına yardımcı olabilir (ör. bazı istekleri atlayarak).

Aşağı bağlantı

Performans yüklemede gecikme önemli olsa da bant genişliği de etkilidir. Saniyedeki megabit (Mb/sn) cinsinden ifade edilen Downlink ipucu, kullanıcının bağlantısının yaklaşık aşağı akış hızını ortaya çıkarır:

Downlink: 2.5

RTT ile birlikte Downlink, içeriğin kullanıcılara sunulma şeklini ağ bağlantısının kalitesine göre değiştirme konusunda faydalı olabilir.

ECT

ECT ipucu, Etkili Bağlantı Türü anlamına gelir. Değeri, her biri hem RTT hem de Downlink değerlerinden oluşan belirtilen aralıklardaki bir bağlantıyı ifade eden numaralanmış bir bağlantı türleri listesinden biridir.

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 edip en çok hangi ağ profiline benzediğini belirler. Örneğin, kablosuz ağ üzerinden yavaş bir ağa bağlanırsanız ECT için 2g değeriyle doldurulabilir. Bu, etkili bağlantıya en yakın tahmini değerdir:

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 ardından RTT ve Downlink ipuçlarını kullanarak incelenebilir.

Verileri Kaydet

Save-Data, ağ koşullarını açıklayan bir ipucu değildir. Sayfaların daha az veri göndermesi gerektiğini belirten bir kullanıcı tercihidir.

Save-Data ile yapacağınız birçok şey diğer ağ ipuçlarına benzediğinden Save-Data öğesini ağ ipucu olarak sınıflandırmayı tercih ediyorum. Kullanıcılar bu özelliği yüksek gecikmeli/düşük bant genişliğine sahip ortamlarda da etkinleştirebilir. Bu ipucu mevcut olduğunda her zaman şöyle görünür:

Save-Data: on

Google'da, Save-Data ile yapabileceklerinizden bahsettik. Performans üzerinde çok büyük bir etkisi olabilir. Bu, kullanıcıların gerçekten daha az öğe göndermenizi istedikleri bir sinyaldir! Bu sinyali dinleyip harekete geçerseniz kullanıcılar bunu beğenecek.

Hepsini bir araya getirme

Müşteri ipuçlarıyla ne yapacağınız size bağlıdır. Çok fazla bilgi sundukları için önünüzde pek çok seçenek var. Yeni fikirlerin hayata geçmesi için, müşteri ipuçlarının Yukarı Orta Batı'nın kırsal kesiminde bulunan kurgusal SconnieTimber şirketi için neler yapabileceğine bakalım. Uzak alanlarda çoğu zaman olduğu gibi ağ bağlantıları kırılgan olabilir. İşte bu noktada istemci ipuçları gibi bir teknoloji kullanıcılar için gerçekten fark yaratabilir.

Duyarlı Resimler

En basit duyarlı resim kullanım alanları hariç tümü karmaşık hale gelebilir. Farklı ekran boyutları ve farklı biçimler için aynı resimlerin birden fazla işlemi ve varyantları varsa ne olur? Bu işaretleme hızlı bir şekilde çok karmaşık ve bir hal alır. Kolayca yanlış anlaşılabilir ve önemli kavramlar (sizes gibi) kolayca unutulabilir ya da yanlış anlaşılabilir.

<picture> ve srcset inanılmaz harika araçlar olsa da karmaşık kullanım alanları için geliştirme ve bakım çok zaman alabilir. İşaretleme oluşturmayı otomatikleştirebiliriz ancak bunu yapmak da zordur. Çünkü <picture> ve srcset, otomasyonlarının sağladıkları esnekliği koruyacak şekilde yapılmasını gerektirecek kadar karmaşıktır.

İstemci ipuçları bu işlemi kolaylaştırabilir. Resim yanıtlarını istemci ipuçlarıyla görüşmek için aşağıdaki gibi görünebilir:

1. İş akışınız için geçerliyse önce Viewport-Width ipucunu kontrol ederek bir resim özelliği (ör. sanata yönelik resimler) seçin.
2. Width ipucunu ve DPR ipucunu kontrol ederek ve resmin düzen boyutuna ve ekran yoğunluğuna uygun bir kaynak seçerek (x ve w tanımlayıcılarının srcset içindeki çalışmasına benzer) bir resim çözünürlüğü seçin.
3. Tarayıcının desteklediği en uygun dosya biçimini seçin (Accept öğesi çoğu tarayıcıda yapmamıza yardımcı olur).

Hayali ahşap şirketi müşterim endişeli olduğunda, PHP'de istemci ipuçlarını kullanan, naif duyarlı bir resim seçme rutini geliştirdim. Bunun için, bu işaretlemenin tüm kullanıcılara gönderilmesi gerekmez:

<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>

Bağımsız tarayıcı desteğine göre bu sayıyı aşağıdaki seviyeye indirebildim:

<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 ile yeniden yazılan parametrelerin takip ettiği bir PHP komut dosyasıdır. Arka uç komut dosyasının verilen koşullarda en iyi resmi seçmesine yardımcı olmak için bir resim dosya adı ve ek parametreler gerekir.

Anlıyorum. İlk sorunuz, "Ama bu sadece arka uçta <picture> ve srcset'yi yeniden uygulamak değil mi?".

Bir bakıma evet ama önemli bir ayrım var: Bir uygulama medya yanıtları oluşturmak için istemci ipuçlarını kullandığında, işin çoğunun (tümü olmasa da) otomatikleştirilmesi çok daha kolay olur. Bu da sizin adınıza bunu yapabilecek bir hizmeti (CD gibi) içerebilir. HTML çözümlerinde ise her kullanım alanını sağlaması için yeni işaretlemelerin yazılması gerekir. Elbette, işaretleme oluşturmayı otomatik alabilirsiniz. Ancak tasarımınız veya gereklilikleriniz değişirse gelecekte otomasyon stratejinizi yeniden gözden geçirmeniz gerekebilir.

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

Elbette, resim seçim mantığını sizin yazmanız gerekmez. w_auto parametresini kullandığınızda resim yanıtları oluşturmak için istemci ipuçlarını kullanan Cloudinary, istemci ipuçlarını destekleyen tarayıcıları kullanırken ortanca kullanıcıların% 42 daha az bayt indirdiğini gözlemledi.

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

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

Uyarlanabilir performans, istemcinin bize sağladığı bilgilere (özellikle de kullanıcının ağ bağlantısının mevcut durumuyla ilgili bilgilere) bağlı olarak kaynakları sunma şeklimizi ayarlayabiliriz.

Sconnie Timber'ın sitesi söz konusu olduğunda, ağlar yavaş olduğunda yükü hafifletmek için adımlar atarız. Save-Data, ECT, RTT ve Downlink başlıkları arka uç kodumuzda incelenmektedir. Bu işlemin ardından daha iyi bir kullanıcı deneyimi için müdahalede bulunmamız gerekip gerekmediğini belirlemek amacıyla kullanabileceğimiz bir ağ kalite puanı oluştururuz. Bu ağ puanı 0 ile 1 arasındadır. Burada 0, olası en kötü ağ kalitesi, 1 ise en iyi seçenektir.

Başlangıçta Save-Data olup olmadığını kontrol ederiz. Etkinse puan 0 olarak ayarlanır. Burada, kullanıcının deneyimi daha hafif ve hızlı hale getirmek için ne yapılması gerektiğini varsayıyoruz.

Bununla birlikte, Save-Data yoksa devam edip ECT, RTT ve Downlink ipuçlarının değerlerini tartarak ağ bağlantısı kalitesini açıklayan bir puanı hesaplarız. Ağ puanı oluşturma kaynak kodu GitHub'da mevcuttur. Bu çıkarım, ağla ilgili ipuçlarını bazı şekillerde kullanırsak yavaş ağlara sahip kullanıcılar için deneyimleri daha iyi hale getirebiliriz.

Siteler, müşterilerin verdiği ipuçlarına uyum sağladığında "ya hep ya hiç" yaklaşımını benimsemek zorunda değiliz. Hangi kaynakların gönderileceğine akıllı bir şekilde karar verebiliyoruz. Ağ kalitesi kötü olduğunda yükleme performansını hızlandırmak amacıyla duyarlı resim seçme mantığımızı, belirli bir ekran için daha düşük kaliteli resimler gönderecek şekilde değiştirebiliriz.

Bu örnekte, yavaş ağlardaki sitelerin performansını iyileştirme söz konusu olduğunda istemci ipuçlarının etkisini görebiliyoruz. Aşağıda, istemci ipuçlarına uyum sağlamayan, yavaş bir ağdaki bir sitenin WebPagetest şelalesi yer almaktadır:

Şimdi aynı yavaş bağlantı üzerinde aynı site için bir şelale var. Ancak bu sefer site, kritik olmayan sayfa kaynaklarını ortadan kaldırmak için istemci ipuçlarını kullanır:

İstemci ipuçları, sayfa yüklenme süresini 45 saniyeden fazlayken sürenin onda birinden daha kısa bir süreye indirdi. Bu senaryoda müşteri ipuçlarının faydaları yeterince vurgulanamaz ve yavaş ağlar üzerinden kritik bilgiler arayan kullanıcılar için büyük bir iyilik olabilir.

Dahası, istemci ipuçlarını desteklemeyen tarayıcıların deneyimini bozmadan kullanmak da mümkündür. Örneğin, desteklenmeyen tarayıcılar için tam deneyimi sunmaya devam ederken ECT ipucunun değerine bağlı olarak kaynak teslimini düzenlemek isterseniz yedeği şu şekilde varsayılan bir değere ayarlayabiliriz:

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

Burada "4g", ECT başlığında açıklanan 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. FTW'yu seçin

Şu önbelleklere dikkat edin!

HTTP üstbilgisine dayalı bir yanıtı değiştirdiğinizde önbelleklerin bu kaynak için gelecekteki getirmeleri nasıl ele alacağını bilmeniz gerekir. Vary üst bilgisi, önbellek girişlerini kendisine sağlanan istek başlıklarının değerine ayarladığından burada vazgeçilmezdir. Basitçe ifade etmek gerekirse, herhangi bir yanıtı belirli bir HTTP istek başlığına göre değiştirirseniz bu başlığı şu şekilde hemen her zaman Vary öğesine eklemeniz gerekir:

Vary: DPR, Width

Yine de bu konuda büyük bir uyarı vardır: Sık değişen bir başlıkta (Cookie gibi) önbelleğe alınabilir yanıtları hiçbir zaman Vary istemezsiniz çünkü bu kaynaklar etkili bir şekilde önbelleğe alınamaz hale gelir. Çok sık değişebilecek bağlantı faktörleri olduğundan, bu bilgiyle, RTT veya Downlink gibi istemci ipucu başlıklarında Vary kullanmamak iyi bir fikir olabilir. Bu üst bilgilerdeki yanıtları değiştirmek isterseniz önbellekte bulunmama sayısını en aza indirmek için yalnızca ECT üst bilgisine anahtar eklemeyi düşünün.

Elbette bu yalnızca en başta bir yanıtı önbelleğe alıyorsanız geçerlidir. Örneğin, içerikleri dinamik olan HTML öğelerini önbelleğe almazsınız. Bu durum, yinelenen ziyaretlerde kullanıcı deneyimini bozabilir. Bu gibi durumlarda, Vary konusunda endişelenmeden bu yanıtları gerekli gördüğünüz herhangi bir temelde değiştirebilirsiniz.

Service Worker'larda istemci ipuçları

İçerik pazarlığı artık yalnızca sunucular için değildir! Hizmet çalışanları, istemciler ve sunucular arasında proxy olarak görev yaptığından kaynakların JavaScript aracılığıyla nasıl iletileceğini siz kontrol edersiniz. İstemci ipuçları da buna dahildir. Service Worker fetch etkinliğinde event nesnesinin request.headers.get yöntemini kullanarak kaynağın istek başlıklarını aşağıdaki gibi okuyabilirsiniz:

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 herhangi bir istemci ipucu başlığı bu şekilde okunabilir. Yine de bu bilgilerden bazılarını elde etmenin tek yolu bu değildir. Ağa özel ipuçları, navigator nesnesindeki şu eşdeğer JavaScript özelliklerinde okunabilir:

Dosya türleri için Imagemin eklentileri.

İstemci ipucu	JS eşdeğeri
"ECT"	`navigator.connection.effectiveType`
"RTT"	"navigator.connection.rtt"
"Verileri Kaydet"	`navigator.connection.saveData`
"Downlink"	`navigator.connection.downlink`
"Cihaz-Belleki"	"navigator.deviceMemory"

Bu API'ler, in operatörüyle özellik denetimi yapılması gereken her yerde kullanılamadığından:

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

Burada, istemci ipuçlarıyla içerik üzerinde anlaşmak için bir sunucuya ihtiyacınız olmaması dışında, sunucuda kullanacağınıza benzer bir mantık kullanabilirsiniz. Kullanıcı çevrimdışıyken içerik sunma olanağı, yalnızca hizmet çalışanları tarafından, deneyimleri daha hızlı ve daha dayanıklı hale getirme gücüne sahiptir.

Özet

İstemci ipuçları sayesinde deneyimleri kullanıcılar için tamamen aşamalı bir şekilde hızlandırma gücüne sahibiz. Kullanıcının cihaz yeteneklerine göre medyalar yayınlayabilir, özellikle de karmaşık kullanım alanlarında <picture> ve srcset kullanmaya kıyasla duyarlı resimler sunmayı daha kolay hale getirebiliriz. Bu hem geliştirme tarafında harcanan zamanı ve çabayı azaltmamızı hem de kaynakları, özellikle de resimleri, kullanıcının ekranlarını ve srcset'ten daha hassas bir şekilde hedefleyecek şekilde optimize etmemizi sağlıyor.

Belki daha da önemlisi, gönderdiğimiz içeriği ve gönderme şeklimizi değiştirerek zayıf ağ bağlantılarını saptayabilir ve kullanıcılar için boşluğu kapatabiliriz. Bu durum, hassas ağlardaki kullanıcıların sitelere daha kolay erişmelerini sağlamada uzun bir yol sağlayabilir. Service Worker'larla birlikte, internet bağlantısı olmadan kullanılabilen son derece hızlı siteler oluşturabiliriz.

İstemci ipuçları yalnızca Chrome ve Chromium tabanlı tarayıcılarda kullanılabilse de, bunları desteklemeyen tarayıcıları engellemeyecek şekilde kullanmak mümkündür. Her kullanıcının cihazındaki özellikleri ve bağlandığı ağları bilen, gerçekten kapsayıcı ve uyarlanabilir deneyimler oluşturmak için istemci ipuçlarını kullanmayı düşünün. Diğer tarayıcı tedarikçilerinin de kendi değerini göreceğini ve uygulama konusunda istekli olacağını umuyoruz.

Kaynaklar

• İstemci İpuçları ile Otomatik Duyarlı Resimler
• İstemci İpuçları ve Duyarlı Resimler - Chrome'da Neler Değişti? 67
• (Müşteri) İpucu Alın (Slaytlar)
• Save-Data ile Hızlı ve Hafif Uygulamalar Sunma

Bu makaledeki 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.