Google Lighthouse, PageSpeed Insights ve Web Performansı üzerine
Lighthouse, web sayfalarının kalitesini artırmak amaçlı açık kaynak kodlu bir araçtır. Performans, erişilebilirlik, Progressive Web App, SEO gibi konularda web sayfalarını değerlendirmektedir.
Bu yazıda Google Lighthouse aracının nasıl çalıştığını, Lighthouse Metriklerini ve Hepsiburada’da bu performans metriklerini nasıl iyileştirdiğimizi ve iyileştireceğimizi anlatıyor olacağım.
PageSpeed Insights ve Lighthouse
Google PageSpeed Insights, hem Chrome Kullanıcı Deneyimi raporunda bulunan gerçek dünya verilerini(direkt web sayfanızı ziyaret eden kullanıcılardan topluyor) hem de laboratuvar verilerini kullanmaktadır.
Kısacası web sayfalarınızın performansını analiz ederek, web sitenizin genel hızının raporunu oluşturan bir araçtır. Ve bu puanı nasıl yükseltebileceğiniz konusunda bizlere bazı tavsiyeler veriyor.
Lighthouse ise, bir web sitesinin diğer yönlerini de denetlemektedir. (SEO, Erişilebilirlik, PWA.)
PageSpeed Insights ise yalnızca performans metriğini ölçer.
Lighthouse ise rapor oluşturmak için yalnızca laboratuvar verilerini kullanmaktadır.
Google PageSpeed Insights, Lighthouse tarafından oluşturulan bilgileri gerçek dünya verileriyle zenginleştirip performans puanı üretirken, Lighthouse bizlere bundan ötede farklı kriterler sunmaktadır.
Web Performansı?
Öncelikle web performansı dediğimizde insanların aklına ilk olarak Google’ın oluşturduğu araçlar geliyor. En çok kullanılan browser ve search engine olmasından dolayı buradaki standartlarda, Pazarlama ve Seo tarafında bu işin takibini yapan arkadaşlarımız daha çok Google’ı baz alıyor.
Tabi bunun yanında bir sürü farklı araç daha bulunmakta benzer metrikleri ölçüp takip edebileceğimiz. Aynı zamanda bu konuda browser api’ları size yardımcı olacaktır.
Web Performansı ile ilgili standartları belirleyen, Web Performance Working Group sayfasına göz atabilirsiniz.
Browser’ın bizlere sunduğu bu metriklerin nasıl hesaplandığı, neden hesaplandığı ile ilgili çok daha geniş bir bilgiye sahip olacaksınızdır.
Google, düzenlediği yazılım etkinliklerinde devreye girecek özellikleri önceden duyuruyor. Chrome Dev Summit etkinlik serisini takip etmenizi şiddetle tavsiye ederim. Google bu konuda yine mobile-first yaklaşımıyla ilerliyor.
Webpagetest, Gtmetrix gibi kalitesini kanıtlamış servislerde, sayfalarınızın eksik olduğu noktalarda sizi uyarıyor ve çok detaylı raporlar sunuyor.
Geçmişe dönecek olursak, web performansı ile ilgili dikkate aldığımız ilk araç, benim hatırladığım kadarıyla 2000'li yılların ortasında/sonlarında, arkasında Yahoo’nun olduğu YSlow’du. Bu yazıda Google üzerinden yürüyeceğimiz için, Yahoo’ya güzelleme yapmamak haksızlık olurdu.
Google’ın yaptığı, bana göre işin içine kullanıcı deneyimini katıp, oluşturduğu aracı daha iyi bir şekilde pazarlamak.
Geçmişe döndük çünkü bu kavramlar genel kanının aksına, Google ile ortaya çıkmış değil. Ama şu an da hızlı web sayfaları ve daha iyi bir kullanıcı deneyimi için arayüz mühendislerini çok güzel yönlendiriyorlar.
Lighthouse Metrikleri
Google, bir web sayfasına puan verirken, görselde bulunan maddelere göre ortalama bir puan oluşturmakta. Bu görsel Google’ın ifade ettiği şekilde laboratuvar testinden alınmış bir rapor.
Bizlere 3G gibi düşük bağlantılı ve bunun yanında zayıf işlemciye sahip cihazları önem derecesinde en öne oturtmamız gerektiğini söylüyor.
Bu puanı doğru ölçümleyebilmek için, Chrome Developer Tools’ta bir Lighthouse simülasyonu çalıştırmadan önce, ayarlarından Simulated Throttling özelliğini aktif etmeniz gerekmektedir.
Bu özelliğin açık olması durumunda, tarayıcınızı 3G slow network ve 4x slowdown CPU gücünde çalıştıracaktır.
Bu ilgili alanların sayfanız yüklenirken nereye denk geldiğini merak ediyorsanız, Chrome Developer Tools’ta bulunan, Performance tab’ini kullanıp kayıt oluşturarak nereye işaret ettiğini ve bu esnada çalışan tüm task’leri görüp inceleme yapabilirsiniz.
Peki Google bu ortalama puanı nasıl belirliyor? Bu noktada hızlı adım atmak istiyorsanız, Google’ın en çok önem verdiği (her kriterin ortalama puan) metriklerinizi iyileştirmek en doğru yol olacaktır. Zaten X metriği için yaptığınız geliştirmeden, diğer metriklerde büyük çoğunlukla olumlu etkilenecektir eğer yanlış bir şey yapmıyorsanız.
Nasıl Arttırdık?
Her ne kadar kişisel web sitesi üzerinden ilerleyip başarılı senaryoları anlatan blog içerikleri var olsa da, bu yazılarda anlatılan best practices’leri zaten uygulamıştık. Ama skorumuz yeterince iyi değildi.
Sorunlarımız…
İnternete dolaşan yazılarda veya Web Vitals yönergelerinde bulunan örnekler genellikle küçük bir web sayfasında işe yararken, sadece Marketing ekiplerinin 2MB boyutunda 3.party JavaScript yükletmek zorunda olduğu, Micro Frontends mimarisine geçiş ile birlikte, JavaScript dosyalarının havada uçuştuğu, görselliğin ve içeriğin kalabalık olduğu, seo sebebiyle server’da tüm içeriği direkt sunmak zorunda olduğunuz, sunucudan ortalamaya göre olağanüstü büyük bir html yüklettiğiniz bir ortamda çok işe yaramıyor desek yalan olmaz.
Bunların yanında hala Legacy çalışan sayfalarımız var. Ve bunların üstüne her yeni geliştirilen feature’da, micro frontend ile yük bindirip daha fazla dosya yüklenmesine istemeden de olsa sebep olabiliyoruz.
Hepsiburada içerik olarak kalabalık/zengin olan, 3.party scriptlerin başka departmanlarca(marketing) sıklıkla kullanılabildiği bir uygulama.
Arka tarafta bağlandığınız onlarca servisten bir tanesinin, response time’ının anlık olarak yükselmesi ile birlikte ilk isteğin yavaşlaması bile puanınıza etki edebiliyor. Ve bunun takibini yapabilmek birazcık zor.
Kısacası anlatmak istediğim şey, içerik olarak minimalist bir web uygulamamız yok. Ve böyle büyük bir web uygulamasını performans olarak iyileştirmek oldukça zor bir challange.
Bunlara istinaden HTML, CSS, JavaScript dosyalarının boyutları çok yüksek olduğu için, Lighthouse testlerinden yüksek puan almamız oldukça zorlaşıyordu.
Nasıl bir iyileştirme yaptık?
Bu yazının varoluş amacı da birazcık burada edindiğimiz know-how’ı paylaşabilmek. Kritik noktalarda yaptığımız bazı geliştirmeler sonrası mobil anasayfada 9–14 arasında seyreden puanımızı, önce 35–45 seviyelerine ardından da 60–70+ seviyelerine çıkarttık.
Aslında yapmamız gereken çok şey bulunuyor fakat yine de bugüne kadar edindiğimiz deneyimi aktarmaya çalışacağım.
Peki bu metriklerin detaylarına ve optimizasyonlarına girmeden önce temel olarak hangi felsefeye sahip olmalıyız? Ve neler yapmalıyız?
- Blocking çalışan JavaScript, CSS, Font, Video vs. tüm kaynakları asenkron olarak yükletmeliyiz.
- Google Chrome Developer Tools aracılığı ile, Long Task olarak işaretlenmiş olan JavaScript kaynaklarını optimize etmeliyiz.
- Above the fold alanında görüntülenen içeriği direkt kullanıcıya sunmak için, bu alanda lazy-load kullanmamalı ve Critical CSS tekniği ile bu alandaki ilk içeriği olabildiğince hızlı sunmalıyız.
- Halk dili ile konuşacak olursak, kafadan 20–30 puan kaybettiren 3.party pazarlama tool’larının kaynaklarını (hotjar, analytics, optimizely, criteo vs) lazy-load veya alternatif yöntemler ile yükletmeliyiz. Buradaki kazancımız ilk yükleme süresi azaltmak oluyor. Örneğin kullanıcı scroll yaptıktan belli bir süre sonra yükletebiliriz.
- İlk yükleme hızı için sayfayı server’da render ettirmeliyiz.
- Web sayfamız yüklenirken sayfada görsel olarak hiç bir oynama olmamalı. (Header’ın sayfa yüklenirken, 3px aşağıya kayması, blocking bir javascript kodunun çalışmayı bitirince pop’up açması vs.)
Ortalama Puan Nasıl Hesaplanıyor?
Google Lighthouse ana skor puanınızı hesaplarken, bu 6 kriterden aldığınız saniye cinsinde değerini, oranlarına göre hesaplayıp ortalama bir puan üretmektedir. LCP ve TBT bu puanı etkileyen iki önemli kritik olarak görünüyor. Siz bu puanı okurken bu standartlar değişmiş olabilir. Çünkü her güncellemede ortalama puanın hesabıyla ilgili değişiklikler olabiliyor. Veya bu maddelerden herhangi birinin hesaplanma mantığı değişmiş olabiliyor.
Şimdi adım adım bu maddelerin neler olduğunu ve bu maddeleri iyileştirmek için neler yapabileceğimizi öğrenelim.
FCP (First Contentful Paint)
İlk Zengin İçerikli Boyama (FCP) kuralı, sayfa yüklenmeye başladığı andan itibaren, sayfaya çizilen ilk içeriğin ne zaman çizildiğine işaret etmektedir.
FCP Nasıl İyileştirilebilir?
- Olabildiğince küçük bir html ve hızlı bir response time verin. TTFB skorunuzu olabildiğince hızlı tutmaya çalışın.
- Sayfanızda FCP olan alanı, performance tab’inde bulduğunuzda, onun öncesinde çalışan bütün task’leri yok etmeye çalışın. FCP öncesi yüklenen içeriklerin hepsini öteleyin. (bknz)
- Html’i olabildiğince küçültün. Server Side Rendering yapıyorsanız bunu yapmanız SEO açısından pek mümkün olmayabilir bizim gibi, fakat önemsiz alanları ekranda görünür olduğunda client’ta yükletebilirsiniz. (bknz)
- Eğer custom font kullanıyorsanız, bunların tarayıcıyı bloklamadığına emin olun. CSS bu konuda sizlere yardımcı olacaktır. (bknz)
- İlk yüklemede, Above The Fold olarak adlandırdığımız yani sayfanın kullanıcıya görünen ilk alanın css resource’larını yükletin. Bunun haricinde bir CSS yükletmeyin. Ve bu CSS’i inline olarak html’de gönderin. (bknz)
SI (Speed Index)
Speed Index (SI), bir sayfanın içeriğinin ne kadar hızlı bir şekilde doldurulduğunu gösteren bir sayfa yükleme performansı metriğidir.
Sayfanın görünen bölümlerinin görüntülendiği ortalama süredir. Milisaniye cinsinden ifade edilir ve görüntü alanının boyutuna bağlı olarak puan ne kadar düşükse o kadar iyidir.
Hesaplama, sayfa görsel olarak tamamlanana kadar her 100 ms aralıkta sayfanın yüzde kaçının görsel olarak yüklendiğini hesaplar.
Lighthouse bu puanı, oluşturmak için Speedline Node.js modülünü kullanmaktadır.
Bu metriği iyileştirmek için aslında özel bir yöntem yok. Yine diğer maddelerde bahsedilen optimizasyon önerilerini gerçekleştirdiğinizde bu puanınız hızlanacaktır.
JavaScript çalışma süresini azaltmak, JavaScript kodunu küçülterek ve Code-Splitting yaparak bu metrik için iyileştirmede bulunabilirsiniz.
LCP (Large Contentful Paint)
En Büyük İçerikli Boyama (LCP) kuralı , sayfanın ilk yüklenmeye başladığı zamana göre, kullanıcıya görünen alanda oluşan en büyük görüntü veya metin bloğunun oluşturma süresini temsil ediyor.
Özet geçecek olursak LCP, Carousel kullanmayı çok seven ülkemiz için, hero görselimiz oluyor.
LCP Nasıl İyileştirilebilir?
- Tarayıcıyı bloklamakta olan tüm işlemleri erteleyin. (bknz)
- Eğer LCP metriğiniz bir imaj ile ölçülüyor ise, bu imajı preload olarak yükletin. Eğer LCP olarak hesaplanan alan bir html elemanı ise bu elemanın css’lerini inline olarak verin.
- Above The Fold alanında bulunan görselleri Lazy Load yükletmeyin. JavaScript bu aşamalarda çalışmamalı.
- Server Response Time’ı 70ms altında olmalı. TTFB değeri de oldukça önemli.
- Critical CSS kavramını duymadıysanız kesinlikle sayfalarınıza uygulayın. Ve bunu sayfalarınıza özel yapmalısınız. Biz ekipçe sorumlu olduğumuz tüm sayfalar için ayrı ayrı uyguluyoruz. Bu geliştirmeyi yaparken puppeteer kullanmıştım. Critical CSS uygulamasından çok güzel verim aldık.(bknz)
- JavaScript dosyalarını yüklerken, async ve defer kullanmak yerine JavaScript kaynaklarını client’ta asenkron bir şekilde yüklettik. Benzer işleri yapsalarda, ilginç bir şekilde puanlarımızda yükselme gördük.
Bunun en büyük sebebi ise Micro Frontend uyguladığımız sayfalarda eskiden vendor bundle’mızın sync olarak yüklenmesi ve sayfayı bloklamasıydı elbette. Aslında asıl kazanıcımız buradan oldu.
Aşağıdaki basit bir fonksiyon örneğinde görmüş olduğunuz üzere bu vendor dosyasını asnyc yükletip, callback’inde diğer Micro Frontend fragmentlarını ve Layer Engine scriptlerini yükleterek büyük bir puan artışı kazandık. Özetle sizi bloklayan herşeyi yok ederek puanınızı çok iyi seviyeye getirmeniz mümkün.
- Kullanılmayan CSS’leri kaldırma imkanınız varsa kaldırın. Coverage sekmesinden de hangi kaynakların kullanılmadığını öğrenebilirsiniz. Örneğin search input’una focus olduğunda açılan autocomplete bir tab var olduğunu düşünelim. Bu autocomplete alanın css kaynaklarına ilk yüklemede ihtiyacınız yok.
Veya bir popup’a ilk yüklemede ihtiyacınız yok. Olabildiğince az kaynak yükletmeliyiz. Bu her performans kriteri için geçerlidir aynı zamanda.
TTI (Time To Interactive)
TTI, sayfanın tam etkileşimli hale gelmesinin ne kadar sürdüğünü ölçmektedir.
Özellikle bizim gibi yüksek boyutta JavaScript kaynağı yükleten sayfalar için bu metriği optimize etmek çok zor.
TTI Nasıl İyileştirilebilir?
- Code Splitting: Webpack aracılığıyla bir çok popüler kütüphanede, Code Splitting yapabilirsiniz. Biz Loadable Components kullanıyoruz çünkü maalesef React.lazy ve Suspense henüz server side rendering için support vermiyor. Fakat yeni versiyonunda gelecek.
Ayrıca React resmi dökümantasyonunda Loadable Components’i önermekte. - Modern browser’lar için, JavaScript kodunuzu ES5'e çevirmeden serve edebilirsiniz. Bu sayede kodunuzun boyutu küçülecektir. bknz
- Yine çalışmayan veya çalışma önemi olmayan JavaScript’leri yok etmeniz gerek. Örneğin Hotjar kullanıcılardan geri bildirim almak veya ısı haritası oluşturmak için UX ekiplerinin sıklıkla kullandığı bir tool. Biz bu tarz araçları bir süredir ilk yükleme yerine, kullanıcı sayfayı scroll ettikten bir süre sonra yükletiyoruz.
- Third party kaynakların response time’ları yüksek ise(ki genelde böyle olur) bu kaynakları içeri almak bir çözüm olabiliyor. Ama bunun business maliyeti çok yüksek. İlgili tool’u kullanan pazarlama ekibiyle ve tool’u kullanan şirket ile iletişime geçmeniz gerekiyor. Çünkü yüklediğiniz script’in değişme ihtimali çok fazla. Başka bir negatif durum ise karşı taraftan yüklediğinizde bu kaynakların cache süreleri çok düşük oluyor.
- Bu madde için aynı zamanda PRPL pattern’i önerilmekte. Bize uygun olmadığı için uygulamadık fakat araştırmanızı önerebilirim.
TBT (Total Blocking Time)
Total Blocking Time (TBT), uzun olarak işaretlendirilen taskların (50 ms’den uzun tüm taskları kapsamaktadır) ana iş parçacığını engellediği ve bir sayfanın kullanılabilirliğini etkilediği süredir.
FCP ve TTI arasında gerçekleşen her uzun görevde gerçekleşen, engelleme süresinin toplamıdır .
TBT Nasıl İyileştirilebilir?
- Performans tabini açarak long task görünen tüm kodlarınızı tespit ederek üstünden geçmeniz gerekiyor.
(Özellikle Dom Update yapılan yerler genelde long olarak işaretleniyor) - Code-Splitting yaparak, sayfanızın ihtiyacı olmayan kodları yükletmeyin.
- Unused olarak görüntülenmekte olan kodlarınızı kaldırın.
- Webpack Bundle Analyzer kullanarak gereksiz yüklediğiniz kütüphanelerden kurtulmaya çalışın.
CLS (Cumulative Layout Shift)
Cumulative Layout Shift, web sayfamızdaki “kaymaları” ölçen bir metrik.
Bu metriğin hesaplanmasındaki amaç sayfada ki görsel kararlılığı test etmek aslında. bknz: visual stability
Görselde görüldüğü üzere, sayfa yüklenmeye başladığı zaman ve ile lifecycle state’in gizli olarak değiştiği zaman arasında, kullanıcı herhangi bir event tetiklemediği sürece, sayfada bulunan elemanların oynamaması gerekiyor.
Örneğin haber siteleri ve blog sayfalarında çokça gördüğümüz önerilen yazılar kısmı vardır. Genelde bu içerik 3.party bir servis aracılığıyla sayfaya yüklenir. Sayfa ilk yüklendiğinde öyle bir içerik yokken “pıt” diye sayfaya 200px yüksekliğinde bir içerik gelir. CLS kuralı, bize bunu yapmamız gerektiğini dikte etmekte. Daha iyi bir kullanıcı deneyimi sunabilmemiz için.
Annie Sullivan ve Steve Kobes isimli iki arkadaşın Cumulative Layout Shift ile ilgili sunumunu izlemelisiniz.
CLS Nasıl İyileştirilebilir?
- Her zaman resimlerinize ve video öğelerinize boyutlarını eklemelisiniz. width ve height değerlerinden bahsetmekteyim. Aynı zamanda browser bu görselleri bu sayede daha hızlı render edecektir.
Not: Biz bu konuda bir performans artışı göremesek bile böyle önerilmekte. - Kullanıcı bir etkileşime girmediği sürece, asla mevcut içeriğin üzerine bir içerik eklemeyin.
- Eğer sayfa üzerinde reklam gösterimi bulunuyorsa, min-width ve min-height değerlerini kullanın.
- Yeniden boyutlandırma yapmak zorunda kalacağınız durumlarda ilgili elemanın,
heightvewidthözelliklerini değiştirmek yerine,transform: scale()kullanın. - CSS, aspect-ratio özelliğinden faydalanın.
Geri bildirim 📬
Tavsiye, eleştiri ve geri bildirimleriniz için iletişime geçebilirsiniz.
