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:
- İş akışınız için geçerliyse önce
Viewport-Width
ipucunu kontrol ederek bir resim özelliği (ör. sanata yönelik resimler) seçin. Width
ipucunu veDPR
ipucunu kontrol ederek ve resmin düzen boyutuna ve ekran yoğunluğuna uygun bir kaynak seçerek (x
vew
tanımlayıcılarınınsrcset
içindeki çalışmasına benzer) bir resim çözünürlüğü seçin.- 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:
İ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ı '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.