Google IO 2018'de, web performansını iyileştirmeyi kolaylaştıran araçlar, kitaplıklar ve optimizasyon tekniklerinin bir özetini sunduk. Burada, Oodles Theater uygulamasını kullanarak bunları açıklıyoruz. Ayrıca tahmine dayalı yükleme ve yeni Guess.js girişimiyle ilgili denemelerimizden de 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 süreçte, bu makalede sizinle paylaşmak istediğimiz yeni araçlar, yaklaşımlar ve kitaplıklar ortaya çıktı. İlk bölümde, Oodles Theater uygulamasını geliştirirken kullandığımız bazı optimizasyon tekniklerini göstereceğiz. İkinci bölümde ise tahmine dayalı 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 edersek mobil cihazlardaki ortalama bir sayfanın yaklaşık 1, 5 MB olduğunu ve bunun büyük bir kısmının JavaScript ve resimlerden oluştuğunu görebiliriz.
Web sitelerinin boyutunun büyümesi, ağ gecikmesi, CPU sınırlamaları, oluşturmayı engelleyen kalıplar veya gereksiz üçüncü taraf kodları gibi diğer faktörlerle birlikte karmaşık performans sorununa katkıda bulunur.
Çoğu kullanıcı, hızın kullanıcı deneyimi hiyerarşisinde en üst sırada yer aldığını belirtiyor. Bu çok şaşırtıcı değil çünkü sayfanın yüklenmesi tamamlanana kadar pek bir şey yapamazsınız. Sayfadan değer elde edemez, estetiğine hayran kalamazsınız.
Performansın kullanıcılar için önemli olduğunu biliyoruz ancak optimizasyona nereden başlayacağınızı bulmak bazen bir sırrı çözmek 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 daha iyi hale getireceğinizle ilgili ipuçları verir.
Kısa süre önce, günlük geliştirme iş akışında çok faydalı olan bir dizi yeni performans denetimi kullanıma sunduk.
Bunlardan nasıl yararlanabileceğinizi pratik bir örnekle inceleyelim: Oodles Theater uygulaması. Bu, en sevdiğimiz etkileşimli Google Doodle'larından bazılarını deneyebileceğiniz ve hatta bir iki oyun oynayabileceğiniz küçük bir demo web uygulamasıdır.
Uygulamayı geliştirirken mümkün olduğunca yüksek performanslı olmasını 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ı boyama için veya uygulamanın etkileşimli hale gelmesi için 15 saniye beklemesi gerekiyordu. Lighthouse, sitemizle ilgili birçok sorunu vurguladı ve 23 olan genel performans puanı da tam olarak bunu yansıtıyordu.
Sayfanın ağırlığı yaklaşık 3,4 MB idi.Bu ağırlığı mutlaka azaltmamız gerekiyordu.
Bu, ilk performans sorunumuzu başlattı: Genel deneyimi etkilemeden kolayca kaldırabileceğimiz öğeleri bulmak.
Performans optimizasyonu fırsatları
Gereksiz kaynakları kaldırma
Güvenli bir şekilde kaldırılabilecek bazı bariz şeyler vardır: boşluklar ve yorumlar.
Lighthouse, Küçültülmemiş CSS ve JavaScript denetiminde bu fırsatı vurgular. Derleme sürecimiz için webpack kullanıyorduk. Bu nedenle, sadeleştirme için Uglify JS eklentisini kullandık.
Sadeleştirme yaygın bir görevdir. Bu nedenle, kullandığınız derleme süreci için hazır bir çözüm bulabilirsiniz.
Bu alandaki bir diğer yararlı denetim de Metin sıkıştırmayı etkinleştir'dir. Sıkıştırılmamış dosyalar göndermek için hiçbir neden yoktur ve çoğu CDN bunu varsayılan olarak destekler.
Kodumuzu barındırmak için Firebase Hosting kullanıyorduk. Firebase, gzip'i varsayılan olarak etkinleştirir. Bu nedenle, kodumuzu makul bir CDN'de barındırmanın avantajıyla bu özelliği ücretsiz olarak kullandık.
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 desteklenir ve öğelerinizi sunucuya göndermeden önce önceden sıkıştırmak için bir ikili program kullanabilirsiniz.
Verimli önbellek politikaları kullanma
Bir sonraki adımımız, kaynakları gereksiz yere iki kez göndermediğimizden emin olmaktı.
Lighthouse'taki Verimsiz önbellek 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 sayıda kaynağı mümkün olan en uzun süre boyunca güvenli bir şekilde önbelleğe almayı ve güncellenen kaynakların verimli bir şekilde yeniden doğrulanması için onay anahtarları sağlamayı hedeflemelisiniz.
Kullanılmayan kodları kaldırın
Şimdiye kadar gereksiz indirme işleminin bariz kısımlarını kaldırdık ancak 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ıştığınızda, ekibiniz veya bağımlılıklarınız değiştiğinde ve bazen de artık kullanılmayan bir kitaplık geride kaldığında ortaya çıkar. Bizim başımıza gelen de tam olarak buydu.
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üm ve hisse geçtik ve bu kitaplığı tamamen unuttuk. Neyse ki kod kapsamı kontrolü, bu kodu paketimizde yeniden keşfetmemize yardımcı oldu.
Uygulamanızın hem çalışma zamanı hem de yükleme süresi için kod kapsamı istatistiklerinizi Geliştirici Araçları'nda kontrol edebilirsiniz. Alttaki ekran görüntüsünde iki büyük kırmızı şerit görebilirsiniz. CSS'imizin %95'inden fazlası ve JavaScript'in büyük bir kısmı kullanılmıyordu.
Lighthouse, kullanılmayan CSS kuralları denetiminde de bu sorunu tespit etti. 400 KB'tan fazla tasarruf edilebileceğini gösterdi. Bu nedenle kodumuza geri döndük ve bu kitaplığın hem JavaScript hem de CSS bölümünü kaldırdık.
Bu sayede CSS paketimiz 20 kat küçüldü. Bu, iki satırlık küçük bir commit için oldukça iyi bir sonuç.
Bu sayede performans puanımız yükseldi ve Time to Interactive çok daha iyi hale geldi.
Ancak bu tür değişikliklerde yalnızca metriklerinizi ve puanlarınızı kontrol etmek yeterli değildir. Gerçek kodu kaldırmak her zaman risklidir. Bu nedenle, olası gerilemelere karşı her zaman dikkatli olmanız gerekir.
Kodumuz %95 oranında kullanılmadı. Geriye kalan %5'lik kısım ise bir yerlerde duruyor. Bileşenlerimizden biri, o kitaplıktaki stilleri kullanmaya devam ediyormuş: Doodle kaydırıcısındaki küçük oklar. Ancak çok küçük olduğu için bu stilleri düğmelere manuel olarak tekrar ekleyebiliriz.
Bu nedenle, kodu kaldırırsanız olası görsel gerilemelere karşı korunmanıza yardımcı olacak uygun bir test iş akışınız olduğundan 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. Kullanıcılarımızın para kaybetmesine ve veri planlarının etkilenmesine neden olabilirler. Bu nedenle, bu konuya dikkat etmek çok önemlidir.
Lighthouse, Devasa ağ yükü denetimini kullanarak ağ yüklerimizden bazılarında sorun olduğunu tespit edebildi.
Burada, 3 MB'tan fazla kodun gönderildiğini gördük. Bu, özellikle mobil cihazlarda oldukça fazla.
Bu listenin en üstünde Lighthouse, 2 MB sıkıştırılmamış kod içeren bir JavaScript tedarikçi paketi olduğunu vurguladı. Bu, webpack tarafından da vurgulanan bir sorundur.
Bir deyiş vardır: En hızlı istek, yapılmayan istektir.
İdeal olarak, kullanıcılarınıza sunduğunuz her bir öğenin değerini ölçmeniz, bu öğelerin performansını ölçmeniz ve ilk deneyimle birlikte sunulmaya değer olup olmadığına karar vermeniz gerekir. Çünkü bazen bu öğeler ertelenebilir, geç yüklenebilir veya boşta kalma süresi boyunca işlenebilir.
Bizim durumumuzda, çok sayıda JavaScript paketiyle uğraştığımız için şanslıydık çünkü JavaScript topluluğunda zengin bir JavaScript paketi denetleme araçları seti var.
Webpack paket analiz aracıyla başladık. Bu araç, 1, 6 MB ayrıştırılmış JavaScript olan unicode adlı bir bağımlılık eklediğimizi bildirdi. Bu oldukça fazla.
Ardından düzenleyicimize geçtik ve Visual Studio Code için Import Cost eklentisini kullanarak içe aktardığımız her modülün maliyetini görselleştirebildik. Bu sayede, hangi bileşenin bu modüle referans veren kod içerdiğini keşfedebildik.
Ardından başka bir araca, BundlePhobia'ya geçtik. Bu araç, herhangi bir NPM paketinin adını girmenize ve sadeleştirilmiş ve gzip ile sıkıştırılmış boyutunun tahmini olarak ne kadar olduğunu görmenize olanak tanır. Kullandığımız kısa ad modülü için yalnızca 2, 2 KB ağırlığında iyi 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 paket boyutunu küçültmek için diğer fırsatları keşfetmemiz sayesinde 2, 1 MB kod tasarrufu sağladık.
Bu paketlerin gzip ile sıkıştırılmış ve sadeleştirilmiş boyutunu hesaba kattığınızda genel olarak %65'lik bir iyileşme gördük. Bu sürecin gerçekten de buna değdiğini gördük.
Bu nedenle, genel olarak sitelerinizde ve uygulamalarınızda gereksiz indirmeleri ortadan kaldırmaya çalışın. Öğelerinizin envanterini çıkarıp performans üzerindeki etkilerini ölçmek büyük bir fark yaratabilir. Bu nedenle, öğelerinizi düzenli olarak denetlediğinizden emin olun.
Kod bölme ile JavaScript başlatma süresini kısaltma
Büyük ağ yükleri uygulamamız üzerinde büyük bir etkiye sahip olsa da, gerçekten büyük bir etkiye sahip olabilecek başka bir şey daha vardır: JavaScript.
JavaScript, en pahalı öğenizdir. Mobil cihazlarda büyük JavaScript paketleri gönderiyorsanız kullanıcılarınızın kullanıcı arayüzü bileşenlerinizle etkileşime geçebilme süresi gecikebilir. Bu da kullanıcıların kullanıcı arayüzüne dokunmalarına rağmen anlamlı bir şey gerçekleşmediği anlamına gelir. Bu nedenle, JavaScript'in neden bu kadar maliyetli olduğunu anlamamız önemlidir.
Tarayıcılar JavaScript'i bu şekilde işler.
Öncelikle bu komut dosyasını indirmemiz gerekir. Ardından, bu kodu ayrıştırması, derlemesi ve yürütmesi gereken bir JavaScript motorumuz vardır.
Bu aşamalar, masaüstü bilgisayar veya dizüstü bilgisayar gibi üst düzey bir cihazda, hatta üst düzey bir telefonda çok fazla zaman almaz. Ancak ortalama bir cep telefonunda bu işlem beş ila on kat daha uzun sürebilir. Etkileşimi geciktiren şey budur. Bu nedenle, bunu azaltmaya çalışmamız ö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, JavaScript başlatma süresinin 1,8 saniye olduğunu gördük. Tüm rotalarımızı ve bileşenlerimizi tek bir monolitik JavaScript paketine statik olarak aktarıyorduk.
Bu sorunu çözmek için kod bölme tekniğini kullanabilirsiniz.
Kod bölme, kullanıcılarınıza bir pizza dolusu JavaScript vermek yerine, ihtiyaç duydukları anda yalnızca bir dilim vermenizdir.
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 ekledik, statik içe aktarmalardan dinamik içe aktarmalara geçtik. Bu sayede, ihtiyaç duyduğumuzda kodu eşzamansız olarak geç yükleyebiliyoruz.
Bu sayede hem paketlerimizin boyutunu küçülttük hem de JavaScript başlatma süremizi kısalttık. Bu süreyi 0, 78 saniyeye indirerek uygulamayı %56 daha hızlı hale getirdi.
Genel olarak, JavaScript ağırlıklı 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ık boyutunuzu nasıl küçültebileceğinizle ilgili birkaç fikir için webpack-libs-optimizations deposuna göz atın.
Resimleri optimize edin
Oodle uygulamasında çok sayıda resim kullanıyoruz. Maalesef Lighthouse, bu konuda bizim kadar heyecanlı değildi. Aslında, resimle ilgili üç denetimin hepsinde başarısız olduk.
Resimlerimizi optimize etmeyi unuttuk, doğru boyutlandırmadık ve diğer resim biçimlerini kullanarak da biraz kazanç elde edebilirdik.
İlk olarak resimlerimizi optimize ettik.
Tek seferlik optimizasyon 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ğlarsınız. Akamai gibi bazı CDN'ler veya Cloudinary, Fastly ya da Uploadcare gibi üçüncü taraf çözümleri, kapsamlı resim optimizasyonu çözümleri sunar. Bu sayede resimlerinizi bu hizmetlerde de barındırabilirsiniz.
Maliyet veya gecikme sorunları nedeniyle bunu yapmak istemiyorsanız Thumbor veya Imageflow gibi projeler, kendi barındırdığınız alternatifler sunar.
Arka plan PNG'miz webpack'te büyük olarak işaretlendi ve bu doğruydu. Görüntü alanına göre doğru şekilde boyutlandırıp ImageOptim'den geçirdikten sonra 100 KB'a indirdik. Bu, kabul edilebilir bir değerdir.
Bu işlemi sitemizdeki birden fazla resim için tekrarlayarak genel sayfa ağırlığını önemli ölçüde azaltabildik.
Animasyonlu içerikler için doğru biçimi kullanma
GIF'ler çok pahalı olabilir. Şaşırtıcı bir şekilde, GIF formatı aslında hiçbir zaman bir animasyon platformu olarak tasarlanmamıştı. Bu nedenle, daha uygun bir video biçimine geçmek dosya boyutu açısından büyük tasarruf sağlar.
Oodle uygulamasında, ana sayfada giriş sekansı olarak bir GIF kullanıyorduk. Lighthouse'a göre, daha verimli bir video biçimine geçerek 7 MB'tan fazla tasarruf edebiliriz. Klibimiz yaklaşık 7,3 MB boyutundaydı. Bu, herhangi bir web sitesi için çok fazla. Bu nedenle, klibi iki kaynak dosyası olan bir video öğesine dönüştürdük. Daha geniş tarayıcı desteği için MP4 ve WebM biçimlerini kullandık.
Hareketli GIF'imizi mp4 dosyasına dönüştürmek için FFmpeg aracını kullandık. WebM biçimi daha da fazla tasarruf sağlar. ImageOptim API bu dönüşümü 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 sınırlı bant genişliğine sahip bir kullanıcı için ağ üzerinden gönderilecek büyük bir kaynaktır. Neyse ki Effective Type API'yi kullanarak kullanıcının bant genişliğinin düşük olduğunu anlayabilir ve çok daha küçük bir JPEG gönderebiliriz.
Bu arayüz, kullanıcının kullandığı ağ türünü tahmin etmek için etkili gidiş dönüş süresi ve indirme değerlerini kullanır. Bu API, 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 durum, deneyimi biraz olumsuz etkilese de en azından site yavaş bağlantılarda kullanılabilir hale gelir.
Ekran dışı resimleri geç yükleme
Kullanıcı sayfada hemen göremese bile bantlar, kaydırıcılar veya çok uzun sayfalar genellikle resimleri yükler.
Lighthouse, ekran dışı resimler denetiminde bu davranışı işaretler. Bu davranışı Geliştirici Araçları'nın ağ panelinde de görebilirsiniz. Sayfada yalnızca birkaç resim görünürken çok sayıda resim yüklendiğini görüyorsanız bunları geç yüklemeyi düşünebilirsiniz.
Geç yükleme henüz tarayıcıda yerel olarak desteklenmediğinden bu özelliği eklemek için JavaScript kullanmamız gerekir. Oodle kapaklarımıza geç 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 aynı zamanda en iyi kullanıcı deneyimi için görünüme yakın öğeleri proaktif olarak önceden getirdiği için akıllı bir çözümdür.
Ayrıca, IntersectionObserver ile isteğe bağlı entegrasyon sunarak görünürlük aramalarını çok verimli bir şekilde yapmanızı sağlar.
Bu değişiklikten sonra resimlerimiz isteğe bağlı olarak getiriliyor. Bu konuyu daha ayrıntılı incelemek isterseniz çok kullanışlı ve kapsamlı bir kaynak olan images.guide adresine göz atın.
Tarayıcının kritik kaynakları erken sunmasına yardımcı olma
Tarayıcıya gönderilen her bayt aynı derecede önemli değildir ve tarayıcı bunu bilir. Birçok tarayıcıda, ilk olarak neyin getirilmesi gerektiğine karar vermek için sezgisel yöntemler kullanılır. Bu nedenle bazen CSS'yi resimlerden veya komut dosyalarından önce getirirler.
Sayfanın yazarları olarak tarayıcıya bizim için gerçekten önemli olan şeyleri bildirmemiz faydalı olabilir. Neyse ki son birkaç yıldır tarayıcı tedarikçileri, bu konuda bize yardımcı olacak bir dizi özellik ekliyor. Örneğin, link rel=preconnect, preload veya prefetch gibi kaynak ipuçları.
Web platformuna getirilen 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 tabanlı yaklaşımlardan biraz daha verimli olabilir.
Lighthouse'un bu özelliklerden bazılarını etkili bir şekilde kullanmamıza nasıl yardımcı olduğuna bakalım.
Lighthouse'un bize söylediği ilk şey, herhangi bir kaynağa birden fazla maliyetli gidiş dönüşten kaçınmamız gerektiğidir.
Oodle uygulamasında Google Fonts'u yoğun bir şekilde kullanıyoruz. Sayfanıza bir Google Fonts stil sayfası eklediğinizde bu sayfa en fazla iki alt alan adına bağlanır. Lighthouse, bu bağlantıyı önceden kurabilseydik ilk bağlantı süresinde 300 milisaniyeye kadar tasarruf edebileceğimizi söylüyor.
Link rel preconnect özelliğinden yararlanarak bu bağlantı gecikmesini etkili bir şekilde maskeleyebiliriz.
Özellikle yazı tipi yüzü CSS'mizin googleapis.com'da, yazı tipi kaynaklarımızın ise Gstatic'te barındırıldığı Google Fonts gibi bir hizmette bunun çok büyük bir etkisi olabilir. Bu optimizasyonu uyguladık ve birkaç yüz milisaniye kazandık.
Lighthouse'un bir sonraki önerisi, önemli istekleri önceden yüklememizdir.
<link rel=preload>, tarayıcıya mevcut gezinme kapsamında bir kaynağın gerekli olduğunu bildiren ve tarayıcının bu kaynağı mümkün olan en kısa sürede getirmesini sağlayan çok güçlü bir araçtır.
Lighthouse, iki web yazı tipi yüklediğimiz için anahtar web yazı tipi kaynaklarımızı önceden yüklememiz gerektiğini söylüyor.
Web yazı tipini önceden yüklemek için rel=preload öğesini belirtir, yazı tipi türüyle birlikte as öğesini iletir ve ardından yüklemeye çalıştığınız yazı tipi türünü (ör. woff2) belirtirsiniz.
Bu durumun sayfanız üzerindeki etkisi oldukça belirgindir.
Normalde, link rel preload kullanmadığınızda web yazı tipleri sayfanız için kritik öneme sahipse tarayıcının önce HTML'nizi getirmesi, CSS'nizi ayrıştırması ve çok daha sonra web yazı tiplerinizi getirmesi gerekir.
Link rel preload kullanarak, tarayıcı HTML'nizi ayrıştırdığı anda bu web yazı tiplerini çok daha erken getirmeye başlayabilir. Uygulamamızda bu, web yazı tiplerimizi kullanarak metin oluşturmamız için gereken süreyi bir saniye kısalttı.
Google Fonts'u kullanarak yazı tiplerini önceden yüklemeye çalışırsanız bu o kadar kolay olmaz. Bir sorun var.
Stil sayfalarımızdaki yazı tipi yüzlerinde belirttiğimiz Google Fonts 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, link rel preload gibi özelliklere erişmenizi sağladığı için çok faydalı olabilir.
Bizim durumumuzda, Google Web Fonts Helper aracının bu web yazı tiplerinden bazılarını çevrimdışı hale getirmemize ve yerel olarak ayarlamamıza yardımcı olduğunu gördük. Bu araca göz atmanızı öneririz.
Kritik kaynaklarınızın bir parçası olarak web yazı tipleri veya JavaScript kullanıyorsanız tarayıcının kritik kaynaklarınızı mümkün olan en kısa sürede sunmasına yardımcı olmaya çalışın.
Deneysel: Öncelik İpuçları
Bugün sizinle özel bir haber paylaşmak istiyoruz. 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, bir kaynağın ne kadar önemli olduğunu tarayıcıya bildirmenize olanak tanıyan yeni bir özelliktir. Düşük, yüksek veya otomatik değerleriyle yeni bir özellik (önem) sunar.
Bu sayede, çekişmeyi azaltmak için kritik olmayan stiller, resimler veya getirme API'si çağrıları gibi daha az önemli kaynakların önceliğini düşürebiliriz. Hero resimlerimiz gibi daha önemli şeylerin önceliğini de artırabiliriz.
Oodle uygulamamızda bu durum, optimizasyon yapabileceğimiz pratik bir alan sağladı.
Resimlerimize geç yükleme eklemeden önce tarayıcı, tüm doodle'larımızın yer aldığı resim rulosundaki tüm resimleri rulo başlar başlamaz yüksek öncelikli olarak getiriyordu. Maalesef kullanıcı için en önemli olan resimler, rulonun ortasındaki resimlerdi. Biz de bu arka plan resimlerinin önemini çok düşük, ön plandakilerin önemini ise çok yüksek olarak ayarladık. Bu sayede, yavaş 3G bağlantısı üzerinden bu resimleri iki saniye daha hızlı getirip oluşturabildik. Yani olumlu bir deneyim.
Bu özelliği birkaç hafta içinde Canary'ye getirmeyi umuyoruz. Bu nedenle, takipte kalın.
Web yazı tipi yükleme stratejiniz olsun
Tipografi, iyi bir tasarımın temelidir. Web yazı tipleri kullanıyorsanız metninizin oluşturulmasını engellemek istemezsiniz ve görünmez metin göstermek kesinlikle istemezsiniz.
Lighthouse'ta artık web yazı tipleri yüklenirken görünmez metinlerden kaçınma denetimiyle bu sorunu vurguluyoruz.
Web yazı tiplerinizi bir yazı tipi yüzü bloğu kullanarak yüklerseniz web yazı tipinin getirilmesi uzun sürdüğünde ne yapılacağına tarayıcının karar vermesine izin vermiş olursunuz. Bazı tarayıcılar, sistem yazı tipine geri dönmeden önce üç saniyeye kadar bekler ve indirildikten sonra yazı tipini değiştirir.
Bu görünmez metinden kaçınmaya çalışıyoruz. Bu nedenle, web yazı tipinin yüklenmesi çok uzun sürseydi bu haftanın klasik doodle'larını göremezdik. Neyse ki font-display adlı yeni özellik sayesinde bu süreç üzerinde çok daha fazla kontrol sahibi olabilirsiniz.
@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 ne kadar sürede değiştirileceğine bağlı olarak nasıl oluşturulacağına veya yedekleneceğine karar vermenize yardımcı olur.
Bu durumda, font-display: swap kullanıyoruz. Swap, yazı tipi için sıfır saniyelik bir engelleme süresi ve sonsuz bir değiştirme süresi sağlar. Bu, yazı tipinin yüklenmesi biraz zaman alırsa tarayıcının metninizi yedek bir yazı tipiyle hemen çizeceği anlamına gelir. Yazı tipi kullanılabilir olduğunda bu yazı tipini değiştirecektir.
Uygulamamızda bu yaklaşım, çok erken bir aşamada anlamlı bir metin göstermemize ve hazır olduğunda web yazı tipine geçmemize olanak tanıdığı için çok işe yaradı.
Genel olarak, web'in büyük bir kısmında olduğu gibi web yazı tipleri kullanıyorsanız iyi bir web yazı tipi yükleme stratejiniz olmalıdır.
Yazı tiplerinin yükleme deneyimini optimize etmek için kullanabileceğiniz birçok web platformu özelliği vardır. Ancak Zach Leatherman'ın Web Font Recipes deposuna da göz atmanızı öneririz. Bu depo gerçekten harika.
Oluşturmayı engelleyen komut dosyalarını azaltma
Uygulamamızın, indirme zincirinde daha önceye alabileceğimiz başka bölümleri de var. Böylece en azından bazı temel kullanıcı deneyimlerini biraz daha erken sunabiliriz.
Lighthouse zaman çizelgesi şeridinde, tüm kaynakların yüklendiği bu ilk birkaç saniye boyunca kullanıcının hiçbir içeriği göremediğini görebilirsiniz.
Harici stil sayfalarının indirilmesi ve işlenmesi, oluşturma sürecimizin ilerlemesini engelliyor.
Stillerden bazılarını biraz daha erken sunarak kritik oluşturma yolumuzu optimize etmeye çalışabiliriz.
Bu ilk oluşturma işleminden sorumlu stilleri çıkarıp HTML'mize satır içi olarak eklersek tarayıcı, harici stil sayfalarının gelmesini beklemeden bunları hemen oluşturabilir.
Bizim örneğimizde, derleme adımında kritik içeriğimizi index.html dosyasına satır içi olarak eklemek için Critical adlı bir NPM modülü kullandık.
Bu modül, işin büyük kısmını bizim için halletse de farklı rotalarda sorunsuz çalışmasını sağlamak biraz zor oldu.
Dikkatli olmazsanız veya sitenizin yapısı çok karmaşıksa, uygulama kabuğu mimarisini en baştan planlamadıysanız bu tür bir kalıbı uygulamak çok zor olabilir.
Bu nedenle, performansla ilgili konuları erkenden ele almak çok önemlidir. En baştan performans odaklı tasarım yapmazsanız daha sonra bunu yaparken sorun yaşama olasılığınız yüksektir.
Sonuçta aldığımız riskin karşılığını aldık, bunu başardık ve uygulama içeriği çok daha erken sunmaya başladı. Bu da ilk anlamlı boyama süremizi önemli ölçüde iyileştirdi.
Sonuç
Sitemize uyguladığımız performans optimizasyonlarının uzun bir listesiydi. Şimdi sonuca bakalım. Uygulamamızın, optimizasyondan önce ve sonra 3G ağındaki orta seviye bir mobil cihazda yüklenme şekli bu şekildedir.
Lighthouse performans puanı 23'ten 91'e yükseldi. Hız açısından oldukça iyi bir ilerleme. Tüm değişiklikler, Lighthouse raporunu sürekli olarak kontrol edip takip etmemiz sayesinde yapıldı. Tüm iyileştirmeleri teknik olarak nasıl uyguladığımızı görmek isterseniz depomuza, özellikle de oradaki PR'lere göz atabilirsiniz.
Tahmine dayalı performans: Veriye dayalı kullanıcı deneyimleri
Makine öğreniminin birçok alanda gelecek için heyecan verici bir fırsat sunduğuna inanıyoruz. Gelecekte daha fazla deneme yapılmasına ilham vereceğini umduğumuz bir fikir, gerçek verilerin oluşturduğumuz kullanıcı deneyimlerine gerçekten rehberlik edebileceğidir.
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 veriyoruz. Doğru tahmin edersek az miktarda kaynağa öncelik verebiliriz ancak bunu tüm web sitesine ölçeklendirmek gerçekten zordur.
Optimizasyonlarımızı daha iyi bilgilendirmek için kullanabileceğimiz verilerimiz var. Google Analytics Reporting API'yi kullanarak sitemizdeki herhangi bir URL için bir sonraki en popüler sayfaya ve çıkış yüzdelerine göz atabilir, böylece hangi kaynaklara öncelik vermemiz gerektiği konusunda sonuçlar çıkarabiliriz.
Bunu iyi bir olasılık modeliyle birleştirirsek agresif bir şekilde aşırı önceden getirme yaparak kullanıcımızın verilerini boşa harcamaktan kaçınırız. Bu Google Analytics verilerinden yararlanabilir, makine öğrenimi ve Markov zincirleri veya nöral ağ gibi modelleri kullanarak bu modelleri uygulayabiliriz.
Bu denemeleri kolaylaştırmak için Guess.js adını verdiğimiz yeni bir girişimi duyurmaktan mutluluk duyuyoruz.
Guess.js, web için veriye dayalı kullanıcı deneyimlerine odaklanan bir projedir. Bu çalışmanın, web performansını iyileştirmek için verilerin kullanılması ve daha fazlası konusunda keşiflere ilham vereceğini umuyoruz. Tümü açık kaynaklıdır ve GitHub'da kullanıma sunulmuştur. Bu araç, Minko Gechev, Gatsby'den Kyle Matthews, Katie Hempenius ve diğer birçok kişi tarafından açık kaynak topluluğuyla işbirliği içinde geliştirildi.
Guess.js'yi inceleyin ve ne düşündüğünüzü bize bildirin.
Özet
Puanlar ve metrikler, web'in hızını artırmada faydalıdır ancak bunlar yalnızca araçtır, hedefin kendisi değildir.
Hepimiz mobil cihazlarda yavaş sayfa yüklemeleriyle karşılaşmışızdır. Ancak artık kullanıcılarımıza çok hızlı yüklenen daha keyifli deneyimler sunma fırsatına sahibiz.
Performansı artırmak bir süreçtir. Çok sayıda 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.
Ward Peeters, Minko Gechev, Kyle Mathews, Katie Hempenius, Dom Farolino, Yoav Weiss, Susie Lu, Yusuke Utsunomiya, Tom Ankers, Lighthouse ve Google Doodle'larına özel teşekkürler.