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 neleri 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 ve bağlı olduğu ağın bu yönleri hakkında bilgi veren etkinleştirilebilir bir HTTP istek üst bilgileri grubudur. 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 üstbilgisi verilebilir. Tarayıcının anladığı içerik türlerini tanımlar. Sunucu, yanıt için pazarlık yapmak üzere bu türleri kullanabilir. 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, bu durumda tarayıcının WebP ve APNG'yi ayrıca desteklediğini 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, kullanıcının bireysel deneyimine göre sunucu tarafı performans kararları verebiliriz (ör. kritik olmayan kaynakların, ağ koşulları zayıf olan kullanıcılara sunulup sunulmayacağına karar verme). 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 isteğiyle ilgili sonuçları belirlerken 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, Photoshop'ta bir resim açarsanız resim boyutu iletişim kutusunda gösterilen boyutlar, resmin öz 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ı. Resmin öz 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 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'ün 2'ye bölünmesi 320x240 olduğundan 2x resminin yoğunluk düzeltmeli doğal 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, belirli ekran boyutları (ör. resim yönüne) için optimal olan farklı resim işleme yöntemleri (ör. kırpma) sunmak 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
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 yararlıdır (ör. srcset özelliğindeki x tanımlayıcıları).
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 en uygun dahili 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ı için görüntü alanı genişliğinin% 85'i). 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, sunucuya istenen resim için en uygun doğal genişliğin, ekranın DPR'si (2) ile görüntü alanı genişliğinin (272 piksel) %85'inin çarpımı (544 piksel) olacağını ima eder.
Bu ipucu, ekranın yoğunluk düzeltilmiş genişliğini hesaba katmanın yanı sıra bu önemli bilgi parçasını, düzen içindeki resmin 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 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. Ancak! 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ı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ğerinin, aşağıdaki denklemin sonucu olması gerekir:
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 Bellek API'sinin 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ı 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üresini 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ında oynadığı 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 nasıl sunulacağını değiştirmede yararlı olabilir.
ECT
ECT ipucu, Geçerli 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'tir. 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 daha da ayrıntılı hale getirilebilir.
Veri Tasarrufu
Save-Data, ağ koşullarını açıklayan bir ipucu değil, 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'ü 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. Fikir edinmek için, Orta Batı'nın kırsal kesiminde bulunan kurgusal bir kereste şirketi olan Sconnie Timber için müşteri ipuçlarının neler yapabileceğini görelim. Uzak bölgelerde genellikle olduğu gibi, ağ bağlantıları hassas 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ışı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.
Bu tür ifadeleri yanlış anlamak, önemli kavramları (sizes gibi) unutmak veya yanlış anlamak kolaydır.
<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ı bu işlemi 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 uygunsa önce
Viewport-Widthipucunu işaretleyerek bir resim işlemi (ör. sanat yönetmenliğindeki 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).
Hayali kereste şirketi müşterim söz konusu olduğunda, PHP'de istemci ipuçları kullanan basit bir duyarlı resim seçim 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'yi arka uçta yeniden uygulamak değil mi?" şeklinde olacak.
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.
Müşteri 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 aralarından seçim yapabileceği olası resim adaylarının sabit bir listesini belirtmenizi gerektiren srcset'den 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, 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 resim yanıtları oluşturmak için istemci ipuçlarından yararlanır. Ortalama kullanıcıların, istemci ipuçlarını destekleyen tarayıcılar kullanırken% 42 daha az bayt indirdiği gözlemlenmiştir.
Ancak dikkatli olun. Chrome 67'nin masaüstü sürümünde yapılan değişikliklerle kaynak farklı istemci ipuçları desteği kaldırıldı. Neyse ki bu kısıtlamalar Chrome'un mobil sürümlerini etkilemez ve Özellik Politikası ile ilgili çalışmalar tamamlandığında tüm platformlar için tamamen kaldırılacaktır.
Yavaş ağlarda kullanıcılara yardımcı olma
Uyarlanabilir performans, istemcinin bize sunduğu bilgilere (özellikle de kullanıcının ağ bağlantısının mevcut durumuyla ilgili bilgilere) göre kaynakları nasıl yayınlayacağımızı ayarlayabileceğimiz fikridir.
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.
Öncelikle 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, 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ı sitenin şelalesi gösterilmektedir. Bu sefer site, kritik olmayan sayfa kaynaklarını kaldırmak için istemci ipuçları kullanmaktadır:
İstemci ipuçları, sayfa yüklenme süresini 45 saniyeden bu sürenin onda birine 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ı 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. Etkinleştirme FTW!
Önbellekleri göz önünde bulundurun.
Bir yanıtı HTTP üst bilgisine göre değiştirdiğinizde, önbellekleri bu kaynağın 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ığı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 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.Vary Bu üstbilgilerdeki yanıtları değiştirmek istiyorsanız yalnızca ECT üstbilgisini anahtar olarak kullanabilirsiniz. Bu, önbellek kaçırmalarını en aza indirir.
Elbette bu durum yalnızca bir yanıtı önbelleğe alıyorsanız geçerlidir.
Örneğin, içeriği dinamik olan HTML öğeleri, tekrarlanan ziyaretlerde kullanıcı deneyimini bozabileceği için önbelleğe alınmaz. 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 sunucular için 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 her yerde kullanılamadığından inoperatörüyle özellik kontrolü yapmanız gerekir:
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
Müşteri ipuçları sayesinde, kullanıcılar için deneyimleri tamamen aşamalı bir şekilde hızlandırma 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ı resimler sunmak <picture> ve srcset'a güvenmekten daha kolay hale gelir. Bu sayede, geliştirme tarafında hem zaman ve çabayı azaltabilir 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 de bu özelliklerin değerini anlayıp bunları uygulamak istediğini umuyoruz.
Kaynaklar
- İstemci İpuçları ile Otomatik Duyarlı Görüntüler
- İstemci İpuçları ve Duyarlı Resimler: Chrome 67'de Neler Değişti?
- (İ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.