Google IO 2018'de, web performansını iyileştirmeyi kolaylaştıran araç, kitaplık ve optimizasyon tekniklerinin bir özetini sunmuştuk. Bu makalede, Oodles Theater uygulamasını kullanarak bu özellikleri açıklıyoruz. Ayrıca tahmini yükleme ve yeni Guess.js girişimiyle ilgili denemelerimizden bahsediyoruz.
Geçtiğimiz yıl, Web'i nasıl daha hızlı ve daha performanslı hale getirebileceğimizi bulmaya çalışmakla oldukça meşguldük. Bu, bu makalede sizinle paylaşmak istediğimiz yeni araçlar, yaklaşımlar ve kitaplıklara yol açtı. İlk bölümde, Oodles Theater uygulamasını geliştirirken pratikte kullandığımız bazı optimizasyon tekniklerini göstereceğiz. İkinci bölümde ise tahmini yükleme ve yeni Guess.js girişimiyle ilgili denemelerimizden bahsedeceğiz.
Performans ihtiyacı
İnternet her yıl daha da ağırlaşıyor. Web'in durumunu kontrol ettiğimizde, mobil cihazlarda ortalama bir sayfanın yaklaşık 1,5 MB ağırlığında olduğunu ve bunun büyük kısmının JavaScript ve resimlerden oluştuğunu görebiliriz.
Web sitelerinin artan boyutu, ağ gecikmesi, CPU sınırlamaları, oluşturmayı engelleyen kalıplar veya gereksiz üçüncü taraf kodu gibi diğer faktörlerle birlikte karmaşık performans bulmacasına katkıda bulunur.
Çoğu kullanıcı, hıza ihtiyaçlarının kullanıcı deneyimi hiyerarşisinin en üstünde yer veriyor. Bu durum pek de şaşırtıcı değil. Çünkü bir sayfanın yüklenmesi tamamlanana kadar pek bir şey yapamazsınız. Sayfadan değer elde edemez, estetiğine hayran olamazsınız.
Performansın kullanıcılar için önemli olduğunu biliyoruz. Ancak optimizasyona nereden başlayacağınızı keşfetmek bir sır gibi gelebilir. Neyse ki bu süreçte size yardımcı olabilecek araçlar var.
Lighthouse: Performans iş akışı için temel
Lighthouse, Chrome Geliştirici Araçları'nın bir parçasıdır. Web sitenizi denetlemenize olanak tanır ve sitenizi nasıl iyileştireceğiniz konusunda ipuçları verir.
Kısa süre önce, günlük geliştirme iş akışında gerçekten faydalı olan bir dizi yeni performans denetimi kullanıma sunduk.
Bu özelliklerden nasıl yararlanabileceğinizi pratik bir örnekle inceleyelim: Oodles Theater uygulaması. Bu küçük demo web uygulamasında, en sevdiğimiz etkileşimli Google Doodles'lardan bazılarını deneyebilir ve hatta birkaç oyun oynayabilirsiniz.
Uygulamayı geliştirirken mümkün olduğunca yüksek performanslı olmasını sağlamak istedik. Optimizasyon için başlangıç noktası bir Lighthouse raporuydu.
Lighthouse raporunda görüldüğü üzere, uygulamamızın ilk performansı oldukça kötüydü. 3G ağında, kullanıcının ilk anlamlı boya için veya uygulamanın etkileşimli hale gelmesi için 15 saniye beklemesi gerekiyordu. Lighthouse, sitemizdeki birçok sorunu vurguladı ve 23 olan genel performans puanı da bunu tam olarak yansıtıyordu.
Sayfanın boyutu yaklaşık 3,4 MB olduğundan, bazı gereksiz öğeleri kaldırmamız gerekiyordu.
Bu, ilk performans sorunumuzu başlattı: Genel deneyimi etkilemeden kolayca kaldırabileceğimiz öğeleri bulmak.
Performans optimizasyonu fırsatları
Gereksiz kaynakları kaldırın
Güvenle kaldırılabilecek bazı belirgin öğeler vardır: Boşluklar ve yorumlar.
Lighthouse, Sıkıştırılmamış CSS ve JavaScript denetiminde bu fırsatı vurgular. Derleme sürecimiz için webpack kullanıyorduk. Bu nedenle, küçültme işlemini yapmak için Uglify JS eklentisini kullandık.
Kod sıkıştırma yaygın bir işlem olduğundan, kullandığınız derleme işlemi için hazır bir çözüm bulabilirsiniz.
Bu alandaki diğer faydalı denetimlerden biri de Metin sıkıştırmayı etkinleştirin seçeneğidir. Sıkıştırılmamış dosyalar göndermenin bir anlamı yoktur ve CDN'lerin çoğu bu özelliği artık varsayılan olarak desteklemektedir.
Kodumuzu barındırmak için Firebase Hosting'i kullanıyorduk ve Firebase varsayılan olarak gzip sıkıştırmasını etkinleştiriyordu. Bu nedenle, kodumuzu makul bir CDN'de barındırdığımız için bu özelliği ücretsiz olarak elde ettik.
gzip çok popüler bir sıkıştırma yöntemi olsa da Zopfli ve Brotli gibi diğer mekanizmalar da ilgi görüyor. Brotli, çoğu tarayıcıda destekleniyor. Öğelerinizi sunucuya göndermeden önce önceden sıkıştırmak için bir ikili dosya kullanabilirsiniz.
Verimli önbellek politikaları kullanın
Sonraki adımımız, gereksiz olduğunda kaynakları iki kez göndermemeyi sağlamaktı.
Lighthouse'taki Verimli olmayan önbelleğe alma politikası denetimi, tam olarak bunu başarmak için önbelleğe alma stratejilerimizi optimize edebileceğimizi fark etmemize yardımcı oldu. Sunucumuzda bir "max-age" geçerlilik süresi başlığı ayarlayarak kullanıcının tekrar ziyaret ettiğinde daha önce indirdiği kaynakları yeniden kullanabilmesini sağladık.
İdeal olarak, mümkün olduğunca çok kaynağı mümkün olan en uzun süre boyunca mümkün olduğunca güvenli bir şekilde önbelleğe almayı ve güncellenen kaynakların verimli bir şekilde yeniden doğrulanması için doğrulama jetonları sağlamayı hedeflemeniz gerekir.
Kullanılmayan kodları kaldırın
Şimdiye kadar gereksiz indirme işleminin belirgin olan kısımlarını kaldırdık. Peki daha az belirgin olan kısımlar ne olacak? Örneğin, kullanılmayan kod.
Bazen uygulamalarımıza gerçekten gerekli olmayan kodlar ekleriz. Bu durum özellikle uygulamanız üzerinde uzun süre çalışırsanız, ekibiniz veya bağımlılıklarınızda değişiklik olursa ve bazen de sahipsiz bir kitaplık bırakılırsa ortaya çıkar. Tam olarak bizim de başımıza gelen bu.
Başlangıçta uygulamamızın prototipini hızlıca oluşturmak için Material Components kitaplığını kullanıyorduk. Zamanla daha özel bir görünüme ve tarza geçtik ve bu kitaplığı tamamen unuttuk. Neyse ki kod kapsamı kontrolü, bu kodu paketimizde yeniden keşfetmemize yardımcı oldu.
Hem çalışma zamanı hem de uygulamanızın yükleme süresi için kod kapsamı istatistiklerinizi DevTools'da kontrol edebilirsiniz. Alttaki ekran görüntüsünde iki büyük kırmızı şerit görebilirsiniz. CSS'mizin %95'inden fazlası ve çok sayıda JavaScript kullanılmamıştı.
Lighthouse, kullanılmayan CSS kuralları denetiminde de bu sorunu tespit etti. 400 KB'dan fazla potansiyel tasarruf sağladığını gösterdi. Bu nedenle, kodumuza geri döndük ve söz konusu kitaplığın hem JavaScript hem de CSS bölümünü kaldırdık.
Bu sayede CSS paketimizin boyutunu 20 kat azalttık. Bu, iki satırlık küçük bir taahhüt için oldukça iyi bir sonuç.
Bu, performans puanımızın yükselmesine ve etkileşime geçme süresinin çok daha iyi hale gelmesine neden oldu.
Ancak bu tür değişikliklerde yalnızca metriklerinizi ve puanlarınızı kontrol etmek yeterli değildir. Gerçek kodu kaldırmak hiçbir zaman risksiz değildir. Bu nedenle, her zaman olası gerilemelere dikkat etmeniz gerekir.
Kodumuzun %95'i kullanılmadı. %5'i hâlâ bir yerlerde. Görünüşe göre bileşenlerimizden biri hâlâ bu kitaplıktaki stilleri (karalama slaytındaki küçük oklar) kullanıyordu. Ancak bu değişiklik çok küçük olduğu için bu stilleri düğmelere manuel olarak geri dahil edebildik.
Bu nedenle, kod kaldırırsanız olası görsel gerilemelere karşı korunmanıza yardımcı olacak uygun bir test iş akışına sahip olduğunuzdan emin olun.
Çok büyük ağ yüklerinden kaçının
Büyük kaynakların web sayfası yüklemelerini yavaşlatabileceğini biliyoruz. Bu tür içerikler kullanıcılarımıza para kaybettirebilir ve veri planlarını büyük ölçüde etkileyebilir. Bu nedenle, bu tür içeriklere dikkat etmeniz çok önemlidir.
Lighthouse, Devasa ağ yükü denetimini kullanarak ağ yükülerimizin bazılarıyla ilgili bir sorun yaşadığımızı tespit etti.
Burada, 3 MB'dan fazla kod gönderdiğimizi gördük. Bu, özellikle mobil cihazlarda oldukça fazla bir değer.
Bu listenin en üstünde Lighthouse, sıkıştırılmamış 2 MB kod içeren bir JavaScript tedarikçi paketimiz olduğunu vurguladı. Bu, webpack tarafından da vurgulanan bir sorundur.
Ne demişler? En hızlı istek, hiç yapılmayan istektir.
İdeal olarak, kullanıcılarınıza sunduğunuz her bir öğenin değerini ölçmeli, bu öğelerin performansını ölçmeli ve ilk deneyimle birlikte sunmanın gerçekten de değerli olup olmadığına karar vermelisiniz. Çünkü bu öğeler bazen ertelenebilir, yavaşça yüklenebilir veya boş zamanlarında işlenebilir.
Bizim durumumuzda, çok sayıda JavaScript paketiyle uğraştığımız için JavaScript topluluğunun zengin bir JavaScript paketi denetimi araçları grubuna sahip olmasından yararlandık.
Webpack bundle analyzer ile başladık. Bu araç, unicode adlı bir bağımlılık eklediğimizi bildirdi. Bu bağımlılık, ayrıştırılmış 1,6 MB JavaScript olduğundan oldukça büyüktü.
Ardından düzenleyicimize gittik ve Görsel kod için içe aktarma maliyeti eklentisini kullanarak içe aktardığımız her modülün maliyetini görselleştirebildik. Bu sayede, bu modüle referans veren kodun hangi bileşende yer aldığını keşfettik.
Ardından BundlePhobia adlı başka bir araca geçtik. Bu araç, herhangi bir NPM paketinin adını girip sıkıştırılmış ve sıkıştırılmamış boyutunun ne kadar olduğunu tahmin etmenize olanak tanır. Kullandığımız slug modülü için yalnızca 2, 2 KB boyutunda olan güzel bir alternatif bulduk ve bu modüle geçtik.
Bu durum performansımızı büyük ölçüde etkiledi. Bu değişiklik ve JavaScript paketi boyutumuzu küçültmek için keşfettiğimiz diğer fırsatlar sayesinde 2, 1 MB kod tasarruf ettik.
Bu paketlerin sıkıştırılmış ve küçültülmüş boyutunu hesaba kattığımızda, genel olarak% 65 oranında iyileştirme elde ettik. Bu sürecin gerçekten de yapılmasına değer olduğunu gördük.
Bu nedenle, genel olarak sitelerinizde ve uygulamalarınızda gereksiz indirmeleri ortadan kaldırmaya çalışın. Öğelerinizin envanterini çıkarmak ve performans üzerindeki etkilerini ölçmek gerçekten büyük bir fark yaratabilir. Bu nedenle, öğelerinizi düzenli olarak denetlediğinizden emin olun.
Kod bölmeyle JavaScript'in açılış süresini kısaltma
Büyük ağ yükü, uygulamamızı büyük ölçüde etkileyebilir. Ancak JavaScript de uygulamanızı büyük ölçüde etkileyebilir.
JavaScript, en pahalı öğenizdir. Mobil cihazlarda büyük JavaScript paketleri gönderirseniz kullanıcılarınızın kullanıcı arayüzü bileşenlerinizle ne kadar sürede etkileşime geçebileceği gecikebilir. Yani kullanıcılar, anlamlı bir şey gerçekleşmeden kullanıcı arayüzüne dokunabilir. Bu nedenle, JavaScript'in neden bu kadar pahalı olduğunu anlamamız önemlidir.
Tarayıcılar JavaScript'i bu şekilde işler.
Öncelikle bu komut dosyasını indirmemiz gerekiyor. Sonrasında bu kodu ayrıştırması, derlemesi ve yürütmesi gereken bir JavaScript motorumuz var.
Bu aşamalar, masaüstü bilgisayar veya dizüstü bilgisayar gibi ileri teknoloji cihazlarda, hatta ileri teknoloji telefonlarda çok fazla zaman almaz. Ancak ortalama bir cep telefonunda bu işlem beş ila on kat daha uzun sürebilir. Etkileşimi geciktirmenin nedeni budur. Bu nedenle, bu boyutu azaltmayı denememiz önemlidir.
Uygulamanızdaki bu sorunları keşfetmenize yardımcı olmak için Lighthouse'a yeni bir JavaScript başlatma süresi denetimi ekledik.
Oodle uygulamasında ise JavaScript'in başlatılması 1, 8 saniye sürdüğünü öğrendik. Tüm rotalarımızı ve bileşenlerimizi tek bir monolitik JavaScript paketine statik olarak içe aktarıyorduk.
Bu sorunun üstesinden gelmenin bir yolu kod bölme işlemini kullanmaktır.
Kod bölme, kullanıcılarınıza bir pizza değerinde JavaScript yerine, ihtiyaç duydukları anda tek seferde yalnızca bir dilim JavaScript vermeyi ifade eder.
Kod bölme, rota düzeyinde veya bileşen düzeyinde uygulanabilir. React ve React Loadable, Vue.js, Angular, Polymer, Preact ve diğer birçok kitaplıkla mükemmel çalışır.
Uygulamamıza kod bölme özelliğini dahil ettik, statik içe aktarmalardan dinamik içe aktarmalara geçtik. Böylece, gerektiğinde kodu eşzamansız olarak gecikmeli olarak yükleyebildik.
Bu, hem paketlerimizin boyutunu küçülttü hem de JavaScript'in başlatma süresini azalttı. Bu sayede uygulamanın hızını% 56 artırarak 0, 78 saniyeye düşürdük.
Genel olarak, JavaScript'e yoğun bir deneyim oluşturuyorsanız kullanıcıya yalnızca ihtiyaç duyduğu kodu gönderdiğinizden emin olun.
Kod bölme gibi kavramlardan yararlanın, ağaç sallama gibi fikirleri keşfedin ve webpack kullanıyorsanız kitaplığınız boyutunu nasıl küçülteceğinizle ilgili birkaç fikir için webpack-libs-optimizations reposuna göz atın.
Resimleri optimize edin
Oodle uygulamasında çok fazla resim kullanıyoruz. Maalesef Lighthouse bu konuda bizim kadar hevesli değildi. Aslında, resimle ilgili üç denetimin de başarısız olduğunu görüyoruz.
Resimlerimizi optimize etmeyi unutmuştuk, doğru boyutlarda ayarlamıyorduk ve diğer resim biçimlerini kullanmaktan da bazı kazanımlar elde edebiliriz.
Öncelikle resimlerimizi optimize etmeye başladık.
Tek seferlik optimizasyon turu için ImageOptim veya XNConvert gibi görsel araçları kullanabilirsiniz.
Daha otomatik bir yaklaşım, imagemin gibi kitaplıklarla derleme sürecinize bir resim optimizasyonu adımı eklemektir.
Bu sayede, gelecekte eklenen resimlerin otomatik olarak optimize edilmesini sağlayabilirsiniz. Akamai gibi bazı CDN'ler veya Cloudinary, Fastly ya da Uploadcare gibi üçüncü taraf çözümler size kapsamlı resim optimizasyon çözümleri sunar. Böylece resimlerinizi bu hizmetlerde barındırabilirsiniz.
Maliyet veya gecikme sorunları nedeniyle bunu yapmak istemiyorsanız Thumbor veya Imageflow gibi projeler kendi kendine barındırılan alternatifler sunar.
Arka plan PNG'miz webpack'ta büyük olarak işaretlendi ve haklı olarak da öyleydi. Görüntüleme alanına uygun şekilde boyutlandırdıktan ve ImageOptim üzerinden çalıştırdıktan sonra 100 KB'a düşürdük. Bu kabul edilebilir bir boyut.
Bu işlemi sitemizdeki birden fazla resim için tekrarlayarak genel sayfa ağırlığını önemli ölçüde düşürebildik.
Animasyonlu içerik için doğru biçimi kullanın
GIF'ler çok pahalı olabilir. Şaşırtıcı bir şekilde, GIF biçimi başlangıçta bir animasyon platformu olarak tasarlanmamıştı. Bu nedenle, daha uygun bir video biçimine geçmek dosya boyutu açısından size büyük tasarruflar sağlar.
Oodle uygulamasında, ana sayfada giriş sekansı olarak GIF kullanıyorduk. Lighthouse'a göre, daha verimli bir video biçimine geçerek 7 MB'dan fazla tasarruf edebiliriz. Klibimiz yaklaşık 7,3 MB ağırlığındaydı.Bu, makul bir web sitesi için çok fazla olduğundan klibi, daha geniş tarayıcı desteği için bir mp4 ve WebM olmak üzere iki kaynak dosyası içeren bir video öğesine dönüştürdük.
Animasyon GIF'imizi mp4 dosyasına dönüştürmek için FFmpeg aracını kullandık. WebM biçimi size daha da fazla tasarruf sağlar. ImageOptim API, bu tür dönüşümleri sizin için yapabilir.
ffmpeg -i animation.gif -b:v 0 -crf 40 -vf scale=600:-1 video.mp4
Bu dönüşüm sayesinde toplam ağırlığımızın% 80'inden fazlasını azaltmayı başardık. Bu sayede boyutu yaklaşık 1 MB'a düşürdük.
Yine de 1 MB, özellikle bant genişliği kısıtlı bir kullanıcı için ağ üzerinden aktarılacak büyük bir kaynaktır. Neyse ki Effective Type API'yi kullanarak kullanıcıların yavaş bir bant genişliğinde olduğunu tespit edip bunun yerine çok daha küçük bir JPEG sunabiliyoruz.
Bu arayüz, kullanıcının kullandığı ağ türünü tahmin etmek için etkili gidiş dönüş süresini ve azaltma değerlerini kullanır. Yalnızca yavaş 2G, 2G, 3G veya 4G dizesini döndürür. Bu değere bağlı olarak, kullanıcı 4G'nin altındaysa video öğesini resimle değiştirebiliriz.
if (navigator.connection.effectiveType) { ... }
Bu, deneyimden biraz uzaklaşmanıza neden olsa da en azından site yavaş bir bağlantıda kullanılabilir.
Ekran dışındaki resimleri geç yükleme
Bantlar, kaydırma çubukları veya çok uzun sayfalar genellikle kullanıcılar sayfayı açtığında görsel yüklese de bu görselleri hemen göremez.
Lighthouse, ekran dışı resimler denetiminde bu davranışı işaretler. Bu davranışı DevTools'un ağ panelinde de görebilirsiniz. Sayfada yalnızca birkaç resim görünürken çok sayıda resim geldiğini görüyorsanız bunları yavaş yüklemeyi tercih edebilirsiniz.
Yavaş yükleme henüz tarayıcıda doğal olarak desteklenmediğinden bu özelliği eklemek için JavaScript'i kullanmamız gerekiyor. Oodle kapaklarımıza gecikmeli yükleme davranışı eklemek için Lazysizes kitaplığını kullandık.
<!-- Import library -->
import lazysizes from 'lazysizes' <!-- or -->
<script src="lazysizes.min.js"></script>
<!-- Use it -->
<img data-src="image.jpg" class="lazyload"/>
<img class="lazyload"
data-sizes="auto"
data-src="image2.jpg"
data-srcset="image1.jpg 300w,
image2.jpg 600w,
image3.jpg 900w"/>
Lazysizes, yalnızca öğenin görünürlük değişikliklerini izlemekle kalmayıp optimum kullanıcı deneyimi için görüntü alanına yakın öğeleri proaktif olarak önceden getirmesi nedeniyle akıllıdır.
Ayrıca, IntersectionObserver
ile isteğe bağlı entegrasyon sunar. Bu entegrasyon, çok verimli görünürlük aramaları yapmanızı sağlar.
Bu değişiklikten sonra resimlerimiz isteğe bağlı olarak getiriliyor. Bu konuyu daha ayrıntılı şekilde incelemek isterseniz çok kullanışlı ve kapsamlı bir kaynak olan images.guide sitesine göz atın.
Tarayıcının kritik kaynakları erken yayınlamasına yardımcı olun
Kablo üzerinden tarayıcıya gönderilen her bayt aynı önem derecesine sahip değildir ve tarayıcı bunu bilir. Birçok tarayıcı, önce neleri getirmeleri gerektiğine karar vermek için sezgisel yöntemlere sahiptir. Bu nedenle, bazen resimlerden veya komut dosyalarından önce CSS'yi getirirler.
Sayfanın yazarları olarak, tarayıcıya bizim için gerçekten önemli olanları bildirmemiz yararlı olabilir. Neyse ki son birkaç yıldır tarayıcı tedarikçileri bu konuda bize yardımcı olacak çeşitli özellikler ekliyor. Örneğin, link rel=preconnect
, preload
veya prefetch
gibi kaynak ipuçları.
Web platformuna eklenen bu özellikler, tarayıcının doğru öğeyi doğru zamanda getirmesine yardımcı olur ve komut dosyası kullanılarak yapılan bazı özel yükleme, mantık temelli yaklaşımlardan biraz daha verimli olabilir.
Lighthouse'ın bu özelliklerin bazılarını etkili bir şekilde kullanma konusunda bize nasıl rehberlik ettiğini görelim.
Lighthouse'un bize ilk söylediği şey, herhangi bir kaynağa birden fazla pahalı gidiş dönüşten kaçınmaktır.
Oodle uygulamasında aslında Google Fonts'u yoğun bir şekilde kullanıyoruz. Sayfanıza bir Google Yazı Tipi stil sayfası eklediğinizde bu sayfa iki alt alan adına bağlanır. Lighthouse, bu bağlantıyı ısıtabilseydik ilk bağlantı süremizde 300 milisaniyeye kadar tasarruf edebileceğimizi söylüyor.
link rel ön bağlantısından yararlanarak bu bağlantı gecikmesini etkili bir şekilde maskeleyebiliriz.
Özellikle yazı tipi CSS'mizin googleapis.com'da, yazı tipi kaynaklarımızın ise Gstatic'te barındırıldığı Google Yazı Tipleri gibi durumlarda bu durum çok büyük bir etki yaratabilir. Bu optimizasyonu uygulayarak birkaç yüz milisaniyelik bir kazanç elde ettik.
Lighthouse'ın önerdiği bir sonraki adım, önemli isteklerini önceden yüklemektir.
<link rel=preload>
gerçekten güçlüdür. Tarayıcıyı mevcut gezinmenin bir parçası olarak bir kaynağa ihtiyaç duyduğunu bildirir ve tarayıcının kaynağı en kısa sürede getirmesini sağlamaya çalışır.
Burada Lighthouse, iki web yazı tipi yüklediğimiz için temel web yazı tipi kaynaklarımızı önceden yüklememiz gerektiğini söylüyor.
Web yazı tipinde ön yükleme şu şekilde yapılır: rel=preload
'yi belirtirsiniz, yazı tipi türüyle birlikte as
'yi iletirsiniz ve ardından yüklemeye çalıştığınız yazı tipi türünü (ör. woff2) belirtirsiniz.
Bu durumun sayfanız üzerinde oldukça ciddi bir etkisi olabilir.
Normalde, bağlantı rel ön yükleme kullanılmıyorsa ve web yazı tipleri sayfanız için kritik öneme sahipse tarayıcı öncelikle HTML'nizi getirmeli, CSS'nizi ayrıştırmalı ve daha sonra web yazı tiplerinizi getirmelidir.
Bağlantı rel preload'ı kullanarak tarayıcı, HTML'nizi ayrıştırır ayrıştırmaz bu web yazı tiplerini çok daha erken getirmeye başlayabilir. Uygulamamız söz konusu olduğunda, bu sayede web yazı tiplerimizi kullanarak metin oluşturma işlemini bir saniye daha kısa sürede tamamlayabildik.
Google Fonts'u kullanarak yazı tiplerini önceden yüklemeyi deneyecekseniz bu işlem o kadar basit değildir.
Stil sayfalarımızdaki yazı tipi yüzlerimizde belirttiğimiz Google yazı tipi URL'leri, yazı tipi ekibinin oldukça düzenli olarak güncellediği bir şeydi. Bu URL'lerin süresi dolabilir veya düzenli olarak güncellenebilir. Bu nedenle, yazı tipi yükleme deneyiminiz üzerinde tam kontrol sahibi olmak istiyorsanız web yazı tiplerinizi kendiniz barındırmanızı öneririz. Bu, bağlantı rel ön yükleme gibi öğelere erişmenizi sağladığı için çok yararlı olabilir.
Bizim durumumuzda, Google Web Yazı Tipleri Yardımcı aracının bu web yazı tiplerinden bazılarını çevrimdışı hale getirmemize ve yerel olarak ayarlamamıza yardımcı olması açısından çok faydalı olduğunu gördük. Bu aracı denemenizi öneririz.
Kritik kaynaklarınız kapsamında web yazı tipleri kullanıyorsanız veya JavaScript kullanıyorsanız tarayıcıya kritik kaynaklarınızı bir an önce sunmasına yardımcı olmaya çalışın.
Deneysel: Öncelik İpuçları
Bugün sizinle paylaşmak istediğimiz özel bir haberimiz var. Kaynak ipuçları ve önceden yükleme gibi özelliklerin yanı sıra öncelik ipuçları adını verdiğimiz yepyeni bir deneysel tarayıcı özelliği üzerinde çalışıyoruz.
Bu, tarayıcıya bir kaynağın ne kadar önemli olduğunu ima etmenize olanak tanıyan yeni bir özelliktir. Düşük, yüksek veya otomatik değerlerine sahip yeni bir özellik (önem) gösterir.
Bu sayede, önemli olmayan kaynakların (ör. kritik olmayan stiller, resimler veya fetch API çağrıları) önceliğini düşürerek anlaşmazlıkları azaltabiliriz. Ayrıca, hero resimlerimiz gibi daha önemli öğelerin önceliğini de artırabiliriz.
Oodle uygulamamız söz konusu olduğunda bu, optimize edebileceğimiz tek bir pratik yere yol açtı.
Resimlerimize gecikmeli yükleme özelliğini eklemeden önce, tarayıcıda tüm karalamalarımıza sahip bir resim bandı vardı. Tarayıcı, bandın en başındaki tüm resimleri yüksek öncelikli olarak getiriyordu. Maalesef kullanıcı için en önemli resimler bantın ortasındaki resimlerdi. Bu nedenle, arka plan resimlerinin önemini çok düşük, ön plan resimlerinin önemini ise çok yüksek olarak belirledik. Bu, yavaş 3G'de iki saniyelik bir etki ve bu resimleri ne kadar hızlı alıp oluşturabildiğimizi etkiledi. Yani güzel ve olumlu bir deneyim.
Bu özelliği birkaç hafta içinde Canary'ye sunmayı planlıyoruz.
Web yazı tipi yükleme stratejiniz olmalıdır.
İyi bir tasarımın temelinde yazı tipi vardır. Web yazı tipleri kullanıyorsanız metninizin oluşturulmasını engellemek istemezsiniz ve kesinlikle görünmez metin göstermek istemezsiniz.
Bu durumu artık Lighthouse'ta web yazı tipleri yüklenirken görünmez metin kullanmaktan kaçının denetimiyle vurguluyoruz.
Web yazı tiplerinizi bir yazı tipi yüzü bloğu kullanarak yüklerseniz söz konusu web yazı tipinin getirilmesi uzun sürerse ne yapılacağına tarayıcı karar verir. Bazı tarayıcılar, sistem yazı tipine geri dönmeden önce bu işlem için üç saniyeye kadar bekler ve indirilen yazı tipiyle değiştirir.
Bu görünmez metni önlemeye çalışıyoruz. Bu durumda, web yazı tipi çok uzun sürerse bu haftaki klasik doodle'ları göremezdik. Neyse ki font-display
adlı yeni bir özellik sayesinde bu süreç üzerinde çok daha fazla kontrole sahipsiniz.
@font-face {
font-family: 'Montserrat';
font-style: normal;
font-display: swap;
font-weight: 400;
src: local('Montserrat Regular'), local('Montserrat-Regular'),
/* Chrome 26+, Opera 23+, Firefox 39+ */
url('montserrat-v12-latin-regular.woff2') format('woff2'),
/* Chrome 6+, Firefox 3.6+, IE 9+, Safari 5.1+ */
url('montserrat-v12-latin-regular.woff') format('woff');
}
Yazı tipi görüntüleme, web yazı tiplerinin nasıl oluşturulacağına veya değiştirilmelerinin ne kadar sürdüğüne göre yedek yazı tipinin nasıl kullanılacağına karar vermenize yardımcı olur.
Bu örnekte yazı tipi görüntüleme değişimini kullanıyoruz. Değişim, yazı tipi yüzüne sıfır saniyelik bir engelleme süresi ve sonsuz bir değişim süresi verir. Bu, yazı tipinin yüklenmesi biraz zaman alırsa tarayıcının metninizi hemen yedek yazı tipiyle çizeceği anlamına gelir. Yazı tipi kullanılabilir olduğunda bunu değiştirecektir.
Uygulamamız söz konusu olduğunda bu, çok erken bir aşamada anlamlı metinler göstermemize ve hazır olduğunda web yazı tipine geçiş yapmamıza olanak tanıdığı için çok faydalı oldu.
Genel olarak, web'in büyük bir yüzdesi gibi web yazı tipleri kullanıyorsanız iyi bir web yazı tipi yükleme stratejiniz olmalıdır.
Yazı tipi yükleme deneyiminizi optimize etmek için kullanabileceğiniz birçok web platformu özelliği vardır. Bununla birlikte, Zach Leatherman'ın Web Font Recipes (Web Yazı Tipi Tarifleri) deposuna da göz atın. Bu depo gerçekten çok kullanışlıdır.
Oluşturmayı engelleyen komut dosyalarını azaltma
Uygulamamızın, en azından bazı temel kullanıcı deneyimlerini biraz daha erken sağlamak için indirme zincirinin daha başlarında yayınlayabileceğimiz başka bölümleri de var.
Lighthouse zaman çizelgesi şeridinde, tüm kaynakların yüklendiği ilk birkaç saniye boyunca kullanıcının hiçbir içerik göremediğini görebilirsiniz.
Harici stil sayfalarının indirilmesi ve işlenmesi, oluşturma sürecimizin ilerlemesini engelliyor.
Stillerin bir kısmını biraz daha erken sunarak kritik oluşturma yolumuzu optimize etmeyi deneyebiliriz.
Bu ilk oluşturma işleminden sorumlu stilleri ayıklayıp HTML'mize satır içi olarak eklersek tarayıcı, harici stil sayfalarının gelmesini beklemeden bunları hemen oluşturabilir.
Bizim durumumuzda, kritik içeriğimizi bir derleme adımı sırasında index.html dosyasına satır içi yapmak için Critical adlı bir NPM modülü kullandık.
Bu modül, ağır işlerin çoğunu bizim için üstlense de bu modülün farklı rotalarda sorunsuz bir şekilde çalışmasını sağlamak biraz zordu.
Dikkatli olmazsanız veya sitenizin yapısı gerçekten karmaşıksa baştan uygulama kabuğu mimarisini planlamadıysanız bu tür bir kalıbı uygulamak gerçekten zor olabilir.
Bu nedenle, performansı erkenden hesaba katmak çok önemlidir. Baştan itibaren performansı göz önünde bulundurarak tasarım yapmazsanız daha sonra performansla ilgili sorunlarla karşılaşma olasılığınız yüksektir.
Riskimiz sonunda karşılığını verdi. Bu yöntemi uygulamayı başardık ve uygulama çok daha erken içerik yayınlamaya başladı. Bu da ilk anlamlı gösterim süremizi önemli ölçüde iyileştirdi.
Sonuç
Bu, sitemize uyguladığımız performans optimizasyonlarının uzun bir listesiydi. Sonuca bakalım. Uygulamamız, optimizasyondan önce ve sonra 3G ağındaki orta düzey bir mobil cihaza bu şekilde yüklendi.
Lighthouse performans puanı 23'ten 91'e yükseldi. Hız açısından oldukça iyi bir ilerleme kaydettiniz. Tüm değişiklikler, Lighthouse raporunu sürekli olarak kontrol edip takip etmemiz sayesinde gerçekleşti. Tüm iyileştirmeleri teknik olarak nasıl uyguladığımızı kontrol etmek isterseniz repo'muza, özellikle de buraya eklenen PR'lere göz atabilirsiniz.
Tahmini performans: Veriye dayalı kullanıcı deneyimleri
Makine öğreniminin birçok alanda gelecek için heyecan verici bir fırsat sunduğunu düşünüyoruz. Gelecekte daha fazla deneme yapılmasını umduğumuz fikirlerden biri, gerçek verilerin oluşturduğumuz kullanıcı deneyimlerine gerçekten rehberlik edebilmesidir.
Günümüzde, kullanıcının ne isteyebileceği veya neye ihtiyaç duyabileceği ve dolayısıyla nelerin önceden getirilmeye, önceden yüklenmeye veya önceden önbelleğe alınmaya değer olduğu konusunda birçok keyfi karar alıyoruz. Doğru tahmin edersek az miktarda kaynağa öncelik verebiliriz ancak bunu web sitesinin tamamına ölçeklendirmek gerçekten zordur.
Aslında, optimizasyonlarımızı daha iyi bilgilendirmek için kullanabileceğimiz veriler var. Google Analytics Reporting API'yi kullanarak, sitemizdeki herhangi bir URL'nin bir sonraki en üst sayfasına ve çıkış yüzdelerine bakabilir, böylece hangi kaynaklara öncelik vermemiz gerektiğine dair sonuçlara varabiliriz.
Bunu iyi bir olasılık modeliyle birleştirirsek içeriği agresif bir şekilde aşırı ön besleyerek kullanıcılarımızın verilerini israf etmeyi önleriz. Bu tür modelleri uygulamak için Google Analytics verilerinden yararlanabilir, makine öğrenimini ve Markov zincirleri ya da sinir ağı gibi modelleri kullanabiliriz.
Bu denemeleri kolaylaştırmak için Guess.js adını verdiğimiz yeni bir girişimi duyurmaktan memnuniyet duyuyoruz.
Guess.js, web için veri odaklı kullanıcı deneyimlerine odaklanan bir projedir. Bu özelliğin, web performansını iyileştirmek ve daha da ötesine geçmek için verileri kullanmayı keşfetmenize ilham vereceğini umuyoruz. Bunların tümü açık kaynaklıdır ve şu anda GitHub'da kullanılabilir. Bu araç, Minko Gechev, Gatsby'den Kyle Matthews, Katie Hempenius ve diğer birçok kişi tarafından açık kaynak topluluğuyla birlikte geliştirildi.
Guess.js'ye göz atın ve ne düşündüğünüzü bize bildirin.
Özet
Puanlar ve metrikler, web'in hızını artırmada faydalıdır ancak bunlar hedefler değil, yalnızca araçlardır.
Hepimiz hareket halindeyken sayfaların yavaş yüklendiğini deneyimledik. Artık kullanıcılarımıza çok hızlı yüklenen, daha keyifli deneyimler sunma fırsatımız var.
Performansı iyileştirmek uzun bir yolculuktur. Birçok küçük değişiklik büyük kazançlar sağlayabilir. Doğru optimizasyon araçlarını kullanarak ve Lighthouse raporlarını takip ederek kullanıcılarınıza daha iyi ve daha kapsayıcı bir deneyim sunabilirsiniz.
Özel teşekkürler: Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse ve Google Doodles.