Her yerde hızlı olan siteler geliştirmek zor olabilir. Cihazların çok sayıdaki özelliği ve bağlandıkları ağların kalitesi, bu görevi aşılmaz bir iş 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 istemci ipuçları.
İstemci ipuçları, kullanıcının cihazının ve bağlı olduğu ağın bu yönleriyle ilgili bize bilgi veren, isteğe bağlı HTTP istek başlıkları kümesidir. Sunucu tarafında bu bilgilerden yararlanarak, cihaz ve/veya ağ koşullarına göre içeriği nasıl yayınladığımızı değiştirebiliriz. Bu, daha kapsayıcı kullanıcı deneyimleri oluşturmamıza yardımcı olabilir.
İçerik pazarlığı çok önemlidir
İstemci ipuçları, içerik pazarlığı için kullanılan başka bir yöntemdir. Bu yöntemde, içerik yanıtları tarayıcı istek üst bilgilerine göre değiştirilir.
İçerik pazarlığına örnek olarak Accept istek başlığı verilebilir. Tarayıcının hangi içerik türlerini anladığını ve sunucunun yanıt pazarlığı yapmak için kullanabileceğini açıklar. Resim isteklerinde Chrome'un Accept üstbilgisinin içeriği şudur:
Accept: image/webp,image/apng,image/*,*/*;q=0.8
Tüm tarayıcılar JPEG, PNG ve GIF gibi resim biçimlerini desteklese de Kabul et seçeneği bu durumda tarayıcının WebP ve APNG'yi de desteklediğini de belirtir. Bu bilgileri kullanarak her tarayıcı için en iyi resim türleri konusunda pazarlık yapabiliriz:
<?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 için pazarlık yapmanın başka bir yoludur ancak cihaz özellikleri ve ağ koşulları bağlamında kullanılır. İstemci ipuçları sayesinde, kritik olmayan kaynakların kötü ağ koşullarına sahip kullanıcılara sunulup sunulmayacağına karar vermek gibi, sunucu tarafı performans kararlarını kullanıcının bireysel deneyimine dayanarak verebiliriz. Bu kılavuzda, mevcut tüm ipuçlarını ve içerik yayınlamayı kullanıcılar için daha uygun hale getirmek amacıyla 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 (daha sonra ele alacağımız Save-Data hariç). İstek üstbilgilerinin sayısını en aza indirmek için, kullanıcı bir kaynak istediğinde Accept-CH üstbilgisi göndererek almak istediğiniz istemci ipuçları etkinleştirmeniz gerekir:
Accept-CH: Viewport-Width, Downlink
Accept-CH değeri, sitenin sonraki kaynak isteklerinin sonuçlarını belirlemede 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ı istiyor" şeklinde bir mesaj alır. Belirli ipuçları hakkında endişelenmeyin.
Bu konulara birazdan değineceğiz.
Bu etkinleştirme üstbilgilerini herhangi bir arka uç dilinde ayarlayabilirsiniz. Örneğin, PHP'nin header işlevi kullanılabilir.
Bu etkinleştirme üstbilgilerini, <meta> etiketinde http-equiv özelliğini kullanarak da ayarlayabilirsiniz:
<meta http-equiv="Accept-CH" content="Viewport-Width, Downlink" />
Tüm istemci ipuçlarını inceleyin.
İ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ını kısaca ele alalı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 bunların 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:
Yerleşik boyut: Bir 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 tanımlar.
Yoğunluk düzeltmeli doğal boyut: Bir medya kaynağının, piksel yoğunluğu için düzeltildikten sonraki boyutları. Bu değer, resmin gerçek boyutunun cihaz piksel oranına bölünmesiyle hesaplanır. Örneğin, şu işaretlemeyi kabul edelim:
<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 durumda 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üklenmiş 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ğunluğu düzeltilmiş yerleşik boyutu 320x240'tır.
Dış boyut: Bir medya kaynağına CSS ve diğer düzen faktörleri (width ve height özellikleri gibi) uygulandıktan sonraki boyutu. Yoğunluk düzeltilmiş doğal boyutu 320x240 olan bir resim yükleyen bir <img> öğeniz olduğunu varsayalım. Bu öğenin, sırasıyla 256px ve 192px değerlerinin uygulandığı CSS width ve height özellikleri de olduğunu varsayalım. Bu örnekte, söz konusu <img> öğesinin dış boyutu 256x192 olur.
width: 256px; ve height: 192px; CSS kurallarının uygulanması, 320x240 doğal boyutlu bir resmi 256x192 harici boyutlu bir resme dönüştürür.Terimleri öğrendikten sonra, kullanabileceğiniz cihaza özel istemci ipuçları listesine geçelim.
Viewport-Width
Viewport-Width, kullanıcının görüntü alanının CSS piksel cinsinden genişliğidir:
Viewport-Width: 320
Bu ipucu, ekrana özgü diğer ipuçlarıyla birlikte kullanılarak bir resmin belirli ekran boyutları (ör. resim yönüne göre) için en uygun şekilde işlenmesi (ör. kırpma) veya mevcut ekran genişliği için gereksiz olan kaynakların atlanması sağlanabilir.
DPR
Cihaz piksel oranının kısaltması olan DPR, kullanıcının ekranındaki fiziksel piksellerin CSS piksellerine oranını bildirir:
DPR: 2
Bu ipucu, ekranın piksel yoğunluğuna karşılık gelen resim kaynaklarını seçerken (x tanımlayıcıların srcset özelliğinde yaptığı gibi) yararlıdır.
Genişlik
Width ipucu, sizes özelliği kullanılarak <img> veya <source> etiketleri tarafından gönderilen resim kaynakları isteklerinde görünür.
sizes, tarayıcıya kaynağın harici boyutunun ne olacağını söyler; Width, mevcut düzen için ideal olan bir içsel boyuta sahip bir resim 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 içeren bir sayfa istediğini varsayalım. Cihaz, 85vw değerine sahip bir sizes özelliği içeren bir <img> öğesi içeren bir doküman yükler (ör. tüm ekran boyutlarında görüntü alanı
genişliğinin% 85'i kadar). Width ipucu etkinleştirildiyse istemci, <img>'un src özelliği için istekle 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) ekranın DPR'siyle (2) (544 piksele eşit) %85'iyle çarpılması gerektiği konusunda sunucuya ipucu verir.
Bu ipucu, yalnızca ekranın yoğunluğuna göre düzeltilmiş genişliği hesaba katmakla kalmayıp bu önemli bilgi parçasını resmin düzen içindeki dış boyutuyla uyumlu hale getirdiği için özellikle güçlüdür. Bu sayede sunucular hem ekran hem de düzen için optimum olan resim yanıtları üzerinde pazarlık yapabilir.
İçerik-DPR
Ekranların cihaz piksel oranına sahip olduğunu zaten biliyorsunuzdur. Kaynakların da kendi piksel oranları vardır. En basit kaynak seçimi kullanım alanlarında, cihazlar ile kaynaklar arasındaki piksel oranları aynı olabilir. Ama! Hem DPR hem de Width üstbilgilerinin kullanıldığı durumlarda, bir kaynağın harici boyutu, bu ikisinin farklı olduğu senaryolar oluşturabilir. Bu noktada Content-DPR ipucu devreye girer.
Diğer istemci ipuçlarından farklı olarak Content-DPR, sunucular tarafından kullanılacak bir request başlığı değildir. Bunun yerine, kaynak seçmek için DPR ve Width ipuçları her kullanıldığında yanıt başlık sunucuları göndermelidir. Content-DPR değeri, aşağıdaki denklemin sonucu olmalıdır:
Content-DPR = [Seçilen resim kaynağı boyutu] / ([Width] / [DPR])
Bir Content-DPR istek başlığı gönderildiğinde tarayıcı, ekranın cihaz piksel oranı ve düzeni için belirli resmi nasıl ölçekleyeceğini bilir. Aksi takdirde, resimler düzgün şekilde ölçeklendirilemeyebilir.
Cihaz-Bellek
Teknik olarak Cihaz Belleği API'sinin bir parçası olan Device-Memory, geçerli cihazın GiB'de yaklaşık olarak sahip olduğu 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ı azaltmaktır. JavaScript, tarayıcıların genellikle yüklediği en fazla kaynak kullanan içerik türüdür. Kod çözme işlemi için daha az bellek kullandıkları için daha düşük DPR resimleri de 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 bunlar en faydalı ipuçları. Bu sayede, 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üresi'ni sağlar. RTT ipucu, taşıma katmanı RTT'sinin aksine sunucu işlem süresini içerir.
RTT: 125
Bu ipucu, gecikmenin yükleme performansındaki rolü nedeniyle yararlıdır.
RTT ipucunu kullanarak ağ yanıt hızına göre kararlar verebiliriz. Bu da deneyimin tamamının daha hızlı sunulmasına yardımcı olabilir (ör. bazı isteklerin atlanması yoluyla).
Aşağı bağlantı
Yükleme performansında gecikmenin önemli olduğu kadar 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 yayın 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 yayınlanma şeklini değiştirmede yararlı olabilir.
ECT
ECT ipucu, Etkili Bağlantı Türü anlamına gelir. Değeri, her biri belirtilen RTT ve Downlink değerleri aralıkları içindeki bir bağlantıyı tanımlayan, listelenen bağlantı türlerinden biridir.
Bu başlık, gerçek bağlantı türünün ne olduğunu açıklamaz. Örneğin, ağ geçidinizin hücre kulesi mi 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, etkili bağlantıya en yakın yaklaşık değer 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 ve Downlink ipuçlarıyla hassaslaştırılabilir.
Veri Tasarrufu
Save-Data, ağ koşullarını açıklayan bir ipucundan çok fazla değildir. Bu, sayfaların daha az veri göndermesi gerektiğini belirten bir kullanıcı tercihidir.
Save-Data ile yapacağınız işlemlerin çoğu diğer ağ ipuçlarına benzer olduğundan Save-Data'ü bir ağ ipucu olarak sınıflandırmayı tercih ediyorum. Kullanıcılar, yüksek gecikmeli/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 durum, performansı ciddi ölçüde etkileyebilir. Bu, kullanıcıların size daha az içerik göndermenizi istediklerinin bir göstergesidir. Bu sinyale kulak verip 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. Bazı fikirlerin akışını sağlamak için, istemci ipuçlarının kırsal Upper Midwest'te bulunan hayali bir ahşap şirketi olan SconnieTimber'a neler yapabileceğine bakalım. Uzak bölgelerde genellikle 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 bir fark yaratabilir.
Duyarlı görseller
En basit duyarlı resim kullanım alanları dışındaki tüm kullanım alanları karmaşık olabilir. Farklı ekran boyutları ve farklı biçimler için aynı resimlerin birden fazla işlenmiş ve varyantı varsa ne yapmalısınız? Bu işaretleme çok karmaşık hale çok çabuk gelir.
Kolayca yanlışlanabilir ve önemli kavramlar (ör. sizes) kolayca unutulabilir ya da yanlış anlaşılabilir.
<picture> ve srcset şüphesiz harika araçlar olsa da karmaşık kullanım alanları için geliştirmek ve sürdürmek zaman alıcı olabilir. İşaretleme oluşturma işlemini otomatikleştirebiliriz ancak <picture> ve srcset'un sunduğu işlevler o kadar karmaşıktır ki otomasyonlarının, sağladıkları esnekliği koruyacak şekilde yapılması gerekir.
Müşteri ipuçları bunu basitleştirebilir. İstemci ipuçlarıyla resim yanıtları için pazarlık yapmak aşağıdaki gibi görünebilir:
- İş akışınız için kullanılabiliyorsa önce
Viewport-Widthipucunu kontrol ederek bir resim işleme (ör. sanat odaklı görüntüler) seçin. WidthveDPRipuçlarını kontrol ederek ve resmin düzen boyutuna ve ekran yoğunluğuna uygun bir kaynak seçerek (srcset'tekixvewtanımlayıcılarının işleyişine benzer şekilde) bir resim çözünürlüğü seçin.- Tarayıcının desteklediği en uygun dosya biçimini seçin (
Acceptbu, çoğu tarayıcıda yapmamıza yardımcı olur).
Kereste firması olan hayali bir müşterimin endişesi nedeniyle PHP'de istemci ipuçlarını kullanan naif duyarlı bir resim seçme rutini geliştirdim. Bu, bu işaretlemeyi 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ı desteğine göre bunu aşağıdaki şekilde azaltabildim:
<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. Arka uç komut dosyasının belirli koşullarda en iyi resmi seçmesine yardımcı olmak için bir resim dosyası adı ve ek parametreler alır.
İlk sorunuz “Ama bu sadece <picture> ve srcset özelliklerini arka uçta yeniden
uygulamak değil mi?” diye düşünüyorum.
Bir bakıma evet, ancak önemli bir fark var: Bir uygulama, medya yanıtları oluşturmak için istemci ipuçları kullandığında, işin çoğunun (tümü olmasa da) otomasyonu çok daha kolaydır. Bu, sizin adınıza bu işlemi yapabilecek bir hizmet (CDN gibi) içerebilir. HTML çözümlerinde ise her kullanım alanı için yeni işaretlemelerin yazılması gerekir. Evet, işaretleme oluşturmayı otomatikleştirebilirsiniz. Ancak tasarımınız veya gereksinimleriniz değişirse gelecekte otomasyon stratejinizi tekrar 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 dinamik olarak yeniden boyutlandırılarak herhangi bir ekran ve düzen kombinasyonu için en uygun hale getirilebilir. Tarayıcının seçebileceği olası görüntü adaylarının sabit bir listesini sıralamanızı gerektiren srcset'nin 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ıyla desteklenen bir çözüm, dev bir işaretleme yığını olmadan tüm genişlikleri sunabilir.
Elbette, resim seçim mantığını kendiniz yazmak zorunda değilsiniz. Cloudinary, w_auto parametresini kullandığınızda görüntü yanıtları oluşturmak için istemci ipuçlarından yararlanmıştır ve ortanca kullanıcıların istemci ipuçlarını destekleyen tarayıcılar kullanırken% 42 daha az bayt indirdiğini gözlemlemiştir.
Ancak dikkatli olun. Chrome 67'nin masaüstü sürümünde yapılan 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. Özellik Politikası ile ilgili çalışmalar tamamlandığında bu kısıtlamalar tüm platformlar için tamamen kaldırılacaktır.
Yavaş ağlarda kullanıcılara yardımcı olma
Uyarlanabilir performans, kaynakları sunma şeklimizi, istemci ipuçlarının bize sağladığı bilgilere (özellikle kullanıcının ağ bağlantısının geçerli durumu hakkındaki bilgilere) göre ayarlayabilmemizi sağlayan fikirdir.
Sconnie Timber'ın sitesi söz konusu olduğunda, ağlar yavaş olduğunda yükü hafifletmek için adımlar atıyoruz. Bu adımlarda, arka uç kodumuzda Save-Data, ECT, RTT ve Downlink üstbilgileri 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 değerinin olup olmadığını kontrol ederiz. Bu durumda, kullanıcının deneyimi daha hafif ve daha hızlı hale getirmek için gerekli olan her şeyi yapmamızı istediği varsayıldığından puan 0 olarak ayarlanır.
Ancak Save-Data yoksa devam edip ağ bağlantısı kalitesini tanımlayan bir puan hesaplamak için ECT, RTT ve Downlink ipuçlarının değerlerini ağırlıklı olarak değerlendiririz. Ağ puanı oluşturma kaynak kodu GitHub'da mevcuttur. Özetlemek gerekirse, ağla ilgili ipuçlarını bir şekilde kullanırsak yavaş ağlarda bulunan kullanıcılar için deneyimleri iyileştirebiliriz.
Siteler, istemci ipuçlarında sağlanan bilgilere uyum sağladığında "ya hep ya hiç" yaklaşımını benimsememiz gerekmez. Hangi kaynakları göndereceğimize 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ı iyileştirme konusundaki etkisini görebiliriz. Aşağıda, yavaş bir ağda yer alan ve istemci ipuçlarına uyarlanmayan bir sitenin WebPagetest şelalesi verilmiştir:
Şimdi de aynı yavaş bağlantıda aynı sitenin şelalesi gösterilmektedir. Bu sefer site, kritik olmayan sayfa kaynaklarını ortadan kaldırmak için istemci ipuçları kullanmaktadır:
İstemci ipuçları, 45 saniyeden uzun sayfa yüklenme süresini bu sürenin onda birinden azına indirdi. 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ı desteklenmeyen tarayıcılarda deneyimi bozmadan kullanılabilir. Örneğin, desteklemeyen tarayıcılara tam deneyimi sunmaya devam ederken ECT ipucunun değerini kullanarak kaynak yayınını ayarlamak isterseniz yedek değeri şu şekilde varsayılan bir değere ayarlayabilirsiniz:
// 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ı desteklenmeyen tarayıcılar bu durumdan etkilenmez. FTW'yi etkinleştir!
Bu önbelleklere dikkat edin!
HTTP başlığına göre bir yanıtı her değiştirdiğinizde, önbelleklerin bu kaynak için gelecekteki getirme işlemlerini nasıl ele alacağını bilmeniz gerekir. Önbellek girişlerini kendisine sağlanan istek başlıklarının değerine göre anahtarladığından Vary başlığı 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 aşağıdaki gibi eklemeniz gerekir:
Vary: DPR, Width
Bununla birlikte, bu konuda önemli bir uyarı vardır: Sık sık değişen bir başlıkta (Cookie gibi) Vary önbelleğe alınabilir yanıtlar istemezsiniz. Çünkü bu kaynaklar etkili bir şekilde önbelleğe alınamaz. Bu nedenle, RTT veya Downlink gibi istemci ipucu üstbilgilerini kullanmaktan kaçınabilirsiniz. Çünkü bunlar oldukça sık değişebilen bağlantı faktörleridir. Bu üst bilgilerdeki yanıtları değiştirmek istiyorsanız yalnızca ECT başlığını anahtarlamayı düşünebilirsiniz. Bu, önbellekteki eksiklikleri en aza indirecektir.
Elbette bu durum yalnızca bir yanıtı önbelleğe alıyorsanız geçerlidir.
Örneğin, içeriklerinin dinamik olması yinelenen ziyaretlerde kullanıcı deneyimini bozabileceği için HTML öğelerini önbelleğe almazsınız. Bu gibi durumlarda, bu tür yanıtları gerekli gördüğünüz şekilde değiştirmekten çekinmeyin ve Vary ile ilgili endişelenmeyin.
Hizmet çalışanlarındaki istemci ipuçları
İçerik pazarlığı artık yalnızca sunuculardan ibaret değil. Hizmet çalışanları, istemciler ile sunucular arasında proxy olarak çalıştığından, kaynakların JavaScript aracılığıyla nasıl yayınlanacağı üzerinde kontrol sahibi olursunuz. İstemci ipuçları da buna dahildir. Hizmet çalışanı fetch etkinliğinde, bir kaynağın istek üst bilgilerini okumak için event nesnesinin request.headers.get yöntemini aşağıdaki gibi 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 başlıkları bu şekilde okunabilir. Ancak bu bilgilerin bir kısmını edinmenin tek yolu bu değildir. Ağa özgü ipuçları, navigator nesnesinde bu 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` |
| `Aşağı bağlantı` | `navigator.connection.downlink` |
| `Device-Memory` | `navigator.deviceMemory` |
Bu API'ler, in operatörü ile özellik kontrolü yapmanız gereken her yerde kullanılamadığından:
if ('connection' in navigator) {
// Work with netinfo API properties in JavaScript!
}
Burada, sunucudaki mantığa benzer bir mantık kullanabilirsiniz. Bununla birlikte, istemci ipuçlarıyla içerik için pazarlık yapmak üzere bir sunucuya ihtiyacınız yoktur. Yalnızca hizmet çalışanları, kullanıcı çevrimdışıyken içerik yayınlama özelliği sayesinde deneyimleri daha hızlı ve daha dayanıklı hale getirebilir.
Özet
İstemci ipuçlarıyla, kullanıcılar için tamamen progresif bir şekilde deneyimleri daha hızlı hale getirme gücüne sahibiz. Kullanıcının cihaz özelliklerine göre medya sunabiliriz. Bu sayede, özellikle karmaşık kullanım alanları için duyarlı resimlerin sunulmasını <picture> ve srcset'a güvenmekten daha kolay hale getirebiliriz. Bu sayede, hem geliştirme tarafında zaman ve çaba tasarrufu sağlıyoruz hem de kaynakları (özellikle görselleri)
Daha da önemlisi, gönderdiğimiz içeriği ve gönderme şeklimizi değiştirerek zayıf ağ bağlantılarını tespit edebilir ve kullanıcılar için bu boşluğu doldurabiliriz. Bu, zayıf ağlardaki kullanıcıların sitelere erişimini kolaylaştırmak için çok faydalı olabilir. Hizmet işçileriyle birlikte, çevrimdışı olarak 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ı etkilemeyecek şekilde kullanmak mümkündür. Her kullanıcının cihaz özelliklerini ve bağlandıkları ağları hesaba katan, gerçekten kapsayıcı ve uyarlanabilir deneyimler oluşturmak için istemci ipuçlarından yararlanabilirsiniz. Diğer tarayıcı tedarikçilerinin bunların değerini göreceğini ve uygulama niyetini göstereceğini umuyoruz.
Kaynaklar
- İstemci İpuçları ile Otomatik Duyarlı Resimler
- İstemci İpuçları ve Duyarlı Resimler - Chrome'da Ne Değişti? 67
- (İstemci) İpucu Alın! (Slaytlar)
Save-Dataile Hızlı ve Hafif Uygulamalar Yayınlama
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.