Her yerde hızlı olan siteler geliştirmek zor olabilir. Cihaz özelliklerinin çeşitliliği ve bağlandıkları ağların kalitesi, bu görevi imkansız gibi gösterebilir. Yükleme performansını iyileştirmek 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, istemci ipuçlarıdır.
İstemci ipuçları, kullanıcının cihazının bu yönleri ve bağlandıkları ağ hakkında bilgi veren bir dizi etkinleştirilebilir HTTP istek başlığıdır. Sunucu tarafında bu bilgileri kullanarak, cihaz ve/veya ağ koşullarına göre içeriği nasıl sunacağımızı değiştirebiliriz. Bu sayede daha kapsayıcı kullanıcı deneyimleri oluşturabiliriz.
İçerik pazarlığı her şeydir
İstemci ipuçları, tarayıcı istek başlıklarına göre içerik yanıtlarını değiştiren başka bir içerik anlaşması yöntemidir.
İçerik pazarlığına örnek olarak Accept istek başlığı verilebilir. Tarayıcının hangi içerik türlerini anladığını açıklar. Sunucu, yanıtı belirlemek için bu bilgiyi kullanabilir. Resim istekleri için Chrome'un Accept üstbilgisinin 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 Accept, 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ü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 anlaşması için başka bir yöntemdir ancak cihaz özellikleri ve ağ koşulları bağlamında kullanılır. İstemci ipuçları sayesinde, kullanıcıların bireysel deneyimlerine göre sunucu tarafı performans kararları verebiliriz. Örneğin, kritik olmayan kaynakların ağ koşulları kötü olan kullanıcılara sunulup sunulmayacağına karar verebiliriz. 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 bazı yöntemleri açıklayacağız.
Etkinleştirme
Accept başlığının aksine, istemci ipuçları sihirli bir şekilde görünmez (daha sonra ele alacağımız Save-Data hariç). İstek başlıklarını minimumda tutmak için, bir kullanıcı bir 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ğinin sonuçlarını belirlemek için kullanacağı istenen ipuçlarının virgülle ayrılmış bir 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 ne olduğu konusunda endişelenmeyin.
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ı bir <meta> etiketinde http-equiv özelliğiyle ayarlayabilirsiniz:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tüm istemci ipuçları
İstemci ipuçları iki şeyden birini açıklar: 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 değinelim.
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 tümü medya odaklı değildir.
Bu listeye geçmeden önce, ekranları ve medya çözünürlüğünü tanımlamak için kullanılan birkaç önemli terimi öğrenmek faydalı olabilir:
İç boyut: Bir medya kaynağının gerçek boyutları. Örneğin, Photoshop'ta bir resim açarsanız resim boyutu iletişim kutusunda gösterilen boyutlar, resmin iç boyutunu tanımlar.
Yoğunluğu düzeltilmiş iç boyut: Piksel yoğunluğu düzeltildikten sonra bir medya kaynağının boyutlarıdır. 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 gerçek boyutunun 320x240, 2x resminin gerçek boyutunun ise 640x480 olduğunu varsayalım. Bu işaretleme, ekran cihaz piksel oranı 2 olan bir cihaza (ör. Retina ekran) yüklenmiş bir istemci tarafından ayrıştırılırsa 2x resmi istenir. 2x resminin yoğunluğu düzeltilmiş iç boyutu 320x240'tır. Çünkü 640x480'in 2'ye bölümü 320x240'tır.
Dış boyut: CSS ve diğer düzen faktörleri (width ve height özellikleri gibi) uygulandıktan sonra bir medya kaynağının boyutu. Yoğunluğu düzeltilmiş iç boyutu 320x240 olan bir resim yükleyen bir <img> öğeniz olduğunu, ancak bu öğenin sırasıyla 256px ve 192px değerlerine sahip CSS width ve height özelliklerine de sahip olduğunu varsayalım. Bu örnekte, <img> öğesinin dışsal boyutu 256x192 olur.
width: 256px; ve height: 192px; CSS kurallarını uygulamak, 320x240 boyutundaki bir resmi 256x192 boyutuna dönüştürür.Bazı terimleri öğrendiğimize göre, kullanabileceğiniz cihaza özel istemci ipuçları listesine geçelim.
Görüntü Alanı Genişliği
Viewport-Width, kullanıcının görüntü alanının CSS pikseli cinsinden genişliğidir:
Viewport-Width: 320
Bu ipucu, belirli ekran boyutları için en uygun olan bir resmin farklı işlemlerini (ör. kırpmalar) sunmak (ör. sanat yönetimi) veya mevcut ekran genişliği için gereksiz olan kaynakları atlamak amacıyla ekrana özgü diğer ipuçlarıyla birlikte kullanılabilir.
DPR
DPR, cihaz piksel oranının kısaltmasıdır ve 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 resim kaynaklarını seçerken kullanışlıdır (srcset özelliğindeki x tanımlayıcıları gibi).
Genişlik
Width ipucu, sizes özelliği kullanılarak <img> veya <source> etiketleri tarafından tetiklenen resim kaynağı isteklerinde görünür.
sizes, tarayıcıya kaynağın dış boyutunun ne olacağını söyler; Width, mevcut düzen için en uygun iç boyuta sahip bir resim istemek üzere bu dış boyutu kullanır.
Örneğin, bir kullanıcının 320 CSS piksel genişliğinde ve 2 DPR'ye sahip bir ekranla sayfa istediğini varsayalım. Cihaz, 85vw değerine sahip bir sizes özellik değeri içeren <img> öğesine sahip bir doküman yükler (ör. %85'i kadar olmalıdır). Width ipucu etkinleştirildiyse istemci, <img>'nin src isteğiyle birlikte bu Width ipucunu sunucuya gönderir:
Width: 544
Bu durumda istemci, sunucuya istenen resim için optimum iç genişliğin, görüntü alanı genişliğinin %85'i (272 piksel) ile ekranın DPR'sinin (2) çarpımı olan 544 piksel olacağını belirtir.
Bu ipucu, yalnızca ekranın yoğunluğu düzeltilmiş genişliğini hesaba katmakla kalmayıp bu kritik bilgiyi resmin düzendeki dış boyutuyla da uyumlu hale getirdiği için özellikle güçlüdür. Bu sayede sunucular, hem ekran hem de düzen için en uygun resim yanıtlarını belirleyebilir.
Content-DPR
Ekranların cihaz piksel oranı olduğunu zaten biliyorsunuz. 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 başlıklarının kullanıldığı durumlarda, bir kaynağın dış boyutu ikisinin farklı olduğu senaryolar oluşturabilir. Content-DPR ipucu bu noktada devreye girer.
Diğer istemci ipuçlarının aksine Content-DPR, sunucular tarafından kullanılacak bir istek başlığı değil, bir kaynak seçmek için DPR ve Width ipuçları kullanıldığında sunucuların göndermesi gereken bir yanıt başlığıdır. 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ı, verilen resmi ekranın cihaz piksel oranına ve düzene göre nasıl ölçeklendireceğini bilir. Bu özellik olmadan resimler
doğru şekilde ölçeklendirilmeyebilir.
Cihaz Belleği
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 ipucunun olası bir kullanım alanı, sınırlı belleğe sahip cihazlardaki tarayıcılara gönderilen JavaScript miktarını azaltmak olabilir. JavaScript, tarayıcıların genellikle yüklediği en yoğun kaynak kullanan içerik türüdür. Daha düşük DPR'ye sahip resimler de gönderebilirsiniz. Bu resimlerin kodu daha az bellek kullanılarak çözülür.
Ağ ipuçları
Network Information API, kullanıcının ağ bağlantısının performansını açıklayan başka bir istemci ipuçları kategorisi sağlar. Bence en faydalı ipuçları bunlar. Bunlar sayesinde, yavaş bağlantılarda istemcilere kaynakları sunma şeklimizi değiştirerek deneyimleri kullanıcılara göre uyarlayabiliriz.
RTT
RTT ipucu, uygulama katmanında milisaniye cinsinden yaklaşık gidiş dönüş süresini sağlar. RTT ipucu, taşıma katmanı RTT'sinden farklı olarak sunucu işleme süresini içerir.
RTT: 125
Bu ipucu, gecikmenin yükleme performansında oynadığı rol nedeniyle faydalıdır.
RTT ipucunu kullanarak ağın yanıt verme hızına göre kararlar verebiliriz.Bu da tüm deneyimin sunumunu hızlandırmaya yardımcı olabilir (ör. bazı istekleri atlayarak).
Uydu bağlantısı
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 göre içeriğin kullanıcılara sunulma şeklini değiştirmede yararlı olabilir.
ECT
ECT ipucu, Etkin Bağlantı Türü anlamına gelir. Değeri, bağlantı türlerinin numaralandırılmış bir listesinden biridir. Bu türlerin her biri, hem RTT hem de Downlink değerlerinin belirtilen aralıkları içindeki 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 bir 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 ağ üzerinden yavaş bir ağa bağlanırsanız ECT, etkin bağlantıya en yakın değer olan 2g değeriyle doldurulabilir:
ECT: 2g
ECT için geçerli değerler 4g, 3g, 2g ve slow-2g şeklindedir. Bu ipucu, bağlantı kalitesini değerlendirmek için başlangıç noktası olarak kullanılabilir ve daha sonra RTT ve Downlink ipuçları kullanılarak hassaslaştırılabilir.
Save-Data
Save-Data, ağ koşullarını açıklayan bir ipucu olmaktan çok, sayfaların daha az veri göndermesi gerektiğini belirten bir kullanıcı tercihidir.
Save-Data'i bir ağ ipucu olarak sınıflandırmayı tercih ediyorum çünkü onunla yapacağınız birçok şey diğer ağ ipuçlarına benzer. Kullanıcılar, yüksek gecikme süreli/düşük bant genişliğine sahip ortamlarda da bu özelliği etkinleştirebilir. Bu ipucu, mevcut olduğunda her zaman şu şekilde görünür:
Save-Data: on
Google'da, Save-Data ile neler yapabileceğinizden bahsettik.
Bu durumun performans üzerindeki etkisi büyük olabilir. Bu, kullanıcıların sizden daha az e-posta göndermenizi istediğinin bir işaretidir. Bu sinyali dinleyip harekete geçerseniz
kullanıcılar bunu takdir edecektir.
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 istemci ipuçlarının, ABD'nin Yukarı Orta Batı bölgesinin kırsal kesiminde yer alan kurgusal bir kereste şirketi olan Sconnie Timber için neler yapabileceğine bakalım. Uzak bölgelerde sıkça görüldüğü gibi ağ bağlantıları hassas olabilir. İstemci ipuçları gibi bir teknoloji, kullanıcılar için gerçekten fark yaratabilir.
Uyumlu görseller
En basit duyarlı resim kullanım alanları dışındaki tüm kullanım alanları karmaşık hale gelebilir. Farklı ekran boyutları için aynı resimlerin birden fazla işleme ve varyantı ve farklı biçimleri varsa ne olur? Bu işaretleme çok hızlı bir şekilde çok karmaşık hale gelir.
Yanlış anlamak, önemli kavramları (ör. sizes) unutmak veya yanlış yorumlamak kolaydır.
<picture> ve srcset şüphesiz mükemmel araçlar olsa da karmaşık kullanım alanları için bunları geliştirmek ve sürdürmek zaman alabilir. İşaretleme oluşturma sürecini otomatikleştirebiliriz ancak <picture> ve srcset tarafından sağlanan işlevler, otomasyonun sağladıkları esnekliği koruyacak şekilde yapılmasını gerektirecek kadar karmaşık olduğundan bu da zordur.
İstemci ipuçları bu süreci basitleştirebilir. İstemci ipuçlarıyla resim yanıtları için pazarlık yapmak şuna benzer:
- İş akışınız için geçerliyse önce
Viewport-Widthipucunu kontrol ederek bir resim işleme (ör. sanat yönetimi uygulanmış görüntüler) seçin. Widthipucunu veDPRipucunu kontrol ederek bir resim çözünürlüğü seçin ve resmin düzen boyutuna ve ekran yoğunluğuna uyan bir kaynak seçin (xvewtanımlayıcılarınınsrcsetiçinde çalışma şekline benzer).- Tarayıcının desteklediği en uygun dosya biçimini seçin (
Accept, çoğu tarayıcıda bunu yapmamıza yardımcı olur).
Hayali kereste şirketi müşterim için PHP'de istemci ipuçlarını kullanan basit bir duyarlı resim seçme rutini geliştirdim. Bu, tüm kullanıcılara bu işaretlemeyi 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ı desteğine 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 takip ettiği bir PHP komut dosyasıdır. Bir resim dosya adı ve arka uç komut dosyasının belirli koşullarda en iyi resmi seçmesine yardımcı olacak ek parametreler alır.
İlk sorunuzun "Ancak bu, arka uçta <picture> ve srcset'yi yeniden uygulamak anlamına gelmiyor mu?" olduğunu tahmin ediyorum.
Bir bakıma evet, ancak önemli bir fark var: 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 otomatikleştirilebilir. Bu, sizin adınıza bunu yapabilecek bir hizmeti (ör. CDN) içerebilir. HTML çözümlerinde ise her kullanım alanı için yeni işaretleme yazılması gerekir. Elbette, işaretleme oluşturma işlemini 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 herhangi bir ekran ve düzen kombinasyonu için optimum olacak şekilde dinamik olarak yeniden boyutlandırılabilir. Tarayıcının seçebileceği sabit bir olası resim adayları listesi oluşturmanızı gerektiren srcset öğesinin aksine 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ı destekli bir çözüm, devasa bir işaretleme yığını olmadan tüm genişliklere hizmet verebilir.
Elbette resim 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, çapraz kaynak 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 sağladığı bilgilere (özellikle de kullanıcının ağ bağlantısının mevcut durumuyla ilgili bilgilere) göre ayarlayabileceğimiz fikridir.
Sconnie Timber'ın sitesi söz konusu olduğunda, ağlar yavaş olduğunda yükü hafifletmek için adımlar atarız. Bu kapsamda, arka uç kodumuzda Save-Data, ECT, RTT ve Downlink başlıkları incelenir. Bu işlem tamamlandığında, daha iyi bir kullanıcı deneyimi için müdahale etmemiz gerekip gerekmediğ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 gösterir.
İlk olarak Save-Data öğesinin mevcut olup olmadığını kontrol ederiz. Öyleyse puan 0 olarak ayarlanır. Çünkü kullanıcının, deneyimi daha hafif ve daha hızlı hale getirmek için gereken her şeyi yapmamızı istediğini varsayarız.
Ancak Save-Data yoksa devam eder ve ağ bağlantısı 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. Buradan çıkarılacak sonuç, ağla ilgili ipuçlarını bir şekilde kullanırsak yavaş ağlardaki kullanıcılar için deneyimleri daha iyi hale getirebileceğimizdir.
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 duyarlı resim seçim mantığımızı, belirli bir ekran için daha düşük kaliteli resimler gönderecek şekilde değiştirebiliriz.
Bu örnekte, istemci ipuçlarının daha yavaş ağlardaki sitelerin performansını artırma konusunda ne kadar etkili olduğunu görebiliriz. Aşağıda, istemci ipuçlarına uyum sağlamayan yavaş bir ağdaki bir sitenin WebPagetest şelalesi gösterilmektedir:
Şimdi de aynı yavaş bağlantıda aynı site için bir şelale grafiği göreceksiniz. 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ükleme 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ğlar üzerinden kritik bilgiler arayan kullanıcılar için ciddi bir avantaj olabilir.
Ayrıca, istemci ipuçlarını desteklemeyen tarayıcılar için deneyimi bozmadan istemci ipuçlarını kullanmak mümkündür. Örneğin, desteklemeyen tarayıcılar için tam deneyimi sunmaya devam ederken ECT ipucunun değerini kullanarak kaynak yayınlamayı ayarlamak istiyorsak varsayılan bir değere geri dönmeyi ş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 ilk kullanıma hazırlarsak İstemci İpuçları'nı desteklemeyen tarayıcılar etkilenmez. Etkinleştirin ve kazanın.
Önbelleklere dikkat edin.
Bir yanıtı HTTP üstbilgisine göre her değiştirdiğinizde, önbelleklerin bu kaynak için gelecekteki getirme işlemlerini nasıl işleyeceğini bilmeniz gerekir. Vary başlığı, önbellek girişlerini kendisine sağlanan istek başlıklarının değerine göre anahtarladığı için burada vazgeçilmezdir. Basitçe söylemek gerekirse, belirli bir HTTP istek başlığına göre herhangi bir yanıtı değiştirirseniz neredeyse her zaman bu başlığı Vary içine şu şekilde eklemeniz gerekir:
Vary: DPR, Width
Ancak bu konuda büyük bir uyarı var: Sık sık değişen bir başlıkta (Cookie gibi) önbelleğe alınabilir yanıtları asla Vary 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 Vary yapmaktan kaçınabilirsiniz. Çünkü bunlar, oldukça sık değişebilen bağlantı faktörleridir. Bu başlıklardaki yanıtları değiştirmek istiyorsanız yalnızca ECT başlığını anahtar olarak kullanın. Böylece önbellekte yok durumunu en aza indirebilirsiniz.
Elbette bu, yalnızca bir yanıtı önbelleğe alıyorsanız geçerlidir.
Örneğin, içeriği dinamik olan HTML öğelerini önbelleğe almazsınız. Çünkü bu durum, tekrar eden ziyaretlerde kullanıcı deneyimini bozabilir. Bu gibi durumlarda, gerekli gördüğünüz her türlü değişikliği yapabilir ve Vary ile ilgili endişelenmenize gerek kalmaz.
Hizmet çalışanlarındaki istemci ipuçları
İçerik pazarlığı artık yalnızca sunucular için değil. Hizmet çalışanları, istemciler ile sunucular arasında proxy görevi gördüğünden, kaynakların JavaScript aracılığıyla nasıl sunulacağını kontrol edebilirsiniz. İstemci ipuçları da buna dahildir. Hizmet çalışanının fetch etkinliğinde, bir kaynağın istek başlıklarını okumak için event nesnesinin request.headers.get yöntemini şu şekilde 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!
})(),
);
});
Kapsamına dahil olduğunuz tüm istemci ipucu başlıkları bu şekilde okunabilir. Ancak bu bilgilerin bir kısmını elde etmenin tek yolu bu değildir. Ağa özgü ipuçları, navigator nesnesindeki şu eşdeğer JavaScript özelliklerinde okunabilir:
| İstemci ipucu | JS eşdeğeri |
|---|---|
| `ECT` | `navigator.connection.effectiveType` |
| `RTT` | `navigator.connection.rtt` |
| `Save-Data` | `navigator.connection.saveData` |
| `Downlink` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Bu API'ler her yerde kullanılamadığından in operatörüyle özellik kontrolü yapmanız gerekir:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Burada, sunucuda kullanacağınız mantığa benzer bir mantık kullanabilirsiniz. Tek fark, istemci ipuçlarıyla içerik anlaşması yapmak için sunucuya ihtiyacınız olmamasıdır. Hizmet çalışanları, kullanıcı çevrimdışıyken içerik sunma özelliği sayesinde deneyimleri daha hızlı ve daha dayanıklı hale getirme gücüne sahiptir.
Özet
İstemci ipuçları sayesinde, kullanıcılar için deneyimleri tamamen aşamalı bir şekilde hızlandırma gücüne sahibiz. Özellikle karmaşık kullanım alanlarında, <picture> ve srcset'e güvenmek yerine duyarlı resimlerin sunulmasını kolaylaştıracak şekilde, kullanıcının cihaz özelliklerine göre medya sunabiliriz. Bu sayede, geliştirme tarafında harcanan zamanı ve çabayı azaltmakla kalmıyor, aynı zamanda kaynakları (özellikle de resimleri) kullanıcıların ekranlarını
Daha da önemlisi, zayıf ağ bağlantılarını tespit edip gönderdiğimiz verileri ve gönderme şeklimizi değiştirerek kullanıcılar için bu boşluğu doldurabiliriz. Bu, sitelerin zayıf ağlardaki kullanıcılar için daha kolay erişilebilir hale getirilmesinde büyük bir fark yaratabilir. Hizmet çalışanlarıyla birleştirildiğinde, çevrimdışı kullanılabilen inanılmaz hızlı siteler oluşturabiliriz.
İstemci ipuçları yalnızca Chrome ve Chromium tabanlı tarayıcılarda kullanılabilir ancak bunları desteklemeyen tarayıcıları engellemeyecek şekilde kullanmak mümkündür. Her kullanıcının cihaz özelliklerini ve bağlandıkları ağları dikkate alan, gerçekten kapsayıcı ve uyarlanabilir deneyimler oluşturmak için istemci ipuçlarını kullanabilirsiniz. Diğer tarayıcı tedarikçilerinin de bu özelliklerin değerini anlayıp uygulamaya koyacağını umuyoruz.
Kaynaklar
- İstemci İpuçları ile Otomatik Duyarlı Resimler
- Client Hints and Responsive Images—What Changed in Chrome 67
- İstemci İpuçları'nı kullanın (Slaytlar)
Save-Dataile Hızlı ve Hafif Uygulamalar Sunma
Bu makaleyle ilgili değerli geri bildirimleri ve düzenlemeleri için Ilya Grigorik, Eric Portis, Jeff Posnick, Yoav Weiss ve Estelle Weyl'a teşekkür ederiz.