Ozellikle 2018 ’in Temmuz ayında tum siteler icin sayfa hızının mobilde bir sıralama faktoru olduğu duyurulduktan sonra tum gozler sitemi nasıl optimize edeceğim sorusunun cevabını aramaya başladı.
Ancak site hızı optimizasyonu ile ilgili araştırma yaptığımızda genelde iceriklerin daha yuzeysel ve neyi neden yaptığını acıklayan bir yaklaşımdan uzak olduğunu goruyoruz.
Bu yazımızda sayfa yuklenme adımlarını acıklayarak, bir sayfanın gec acılmasına ne sebep olur, hangi aşamada sayfa uzun sure yuklenmez, bunu nasıl kontrol edersiniz ve bu adımları nasıl optimize edersiniz bunlardan bahsedeceğiz.
Yani saniyelik hatta bazen saliselik adımlarda gercekleşen hareketleri detaylı anlatmaya calışacağız. Sayfa yuklenme hızı optimizasyonu icin hazırsak başlayalım.
OPTİMİZASYON ONCESİ TEKNİK KISIMLAR
1.Critical Rendering Path
Critical Rendering Path, yani kısaca CRP, tarayıcınız uzerinden bir sayfaya tıkladığınız anda başlayan ve sayfanın tamamen yuklenmesine kadar gecen suredeki adımların butunudur.
Sayfa hızı optimizasyonu aslında CRP ’nin optimizasyon surecidir.
CRP ’deki adımları gozlemleyerek sayfanızın yuklenirken nerelerde uzun sure kaldığını, nerelerde optimizasyon yapabileceğinizi anlayabilirsiniz. Optimizasyon kısmında bundan bahsedeceğim, şimdilik devam ediyorum. CRP adımlarını bir bir detaylı bir şekilde inceleyelim.
Yukarıdaki grafik biraz karışık gelebilir, gelmesin! CRP dediğimiz aslında tam olarak bu ve bu kadar karışık değil.
Bir kullanıcı bir siteye girmek icin sayfaya tıkladığı anda tarayıcı oncelikle DNS sunucusunda ip adresini arar. Ve bir yanıt alır. Sonraki adımda tarayıcı sunucuya istekte bulunur ve ‘ ’BANA HTML ’i VER! ’ ’ der.
Tarayıcı HTML kaynağını yukarıdan aşağıya doğru cozumlemeye başlar ve DOM (Document Object Model) ağacı dediğimiz HTML ’in icindeki nesnelerin (title, body, image, p, gibi) iskeletini cıkartır.
Yukarıdan aşağıya doğru HTML kaynağını tararken CSS ile karşılaştı, neler olacak?
DOM ağacını oluştururken CSS ile karşılaşan tarayıcınız DOM surecini durdurur. Bu sebeple CSS icin ‘ ’render blocking ’ ’ diyoruz. Yani işleme surecini durdurmaktadır. Burada tarayıcınızı bir işi bitirmeden başka işe gecen, plansız bir calışan olarak duşunebilirsiniz. Ama bunun da bir sebebi var, acıklayacağım.
BU ARADA HENUZ EKRANDA BİR ŞEY YOK!
HTML ’in DOM ’u varsa CSS ’inde CSSOM ’u var!
CSS ile karşılaşan tarayıcı bu sefer de CSSOM olarak tabir ettiği stil hiyerarşisini belirlemeye başlıyor. CSSOM ’u oluşturduktan sonra HTML ’deki title, head, paragraf iceriklerini CSS ’teki komutlar ile birleştirerek ‘ ’render tree ’ ’ dediğimiz hangi iceriği hangi stilde goruntuleyeceğini belirlediği bir surece giriyor. Eşleştirme sureci olarak duşunebilirsiniz. Orneğin, HTML kodundan title iceriğini alıyor, CSS kodundan bu title iceriğini hangi stilde gostereceğini buluyor ve bunları eşleştirerek render tree surecini tamamlamaya calışıyor.
Yukarıdaki ornekte ise DOM ’dan ‘ ’p ’ ’ altındaki icerikleri alıp, CSSOM ’dan font buyukluğunu ve stilini alarak render tree de bunları birleştiriyor. Span altındaki icerik icin CSSOM ’da display:none yani goruntuleME komutu verildiği icin HTML kodunda ‘ ’web performance ’ ’ iceriği bulunsa da bir anlam ifade etmiyor ve bunu render tree de gostermiyor.
Eğer bu işlem olmasaydı yani tarayıcı CSS ’i beklemeden sayfayı yukleseydi aşağıda sağdaki goruntu ile karşılaşacaktık ve kullanıcı deneyimi acısından negatif etkisi yuksek olan bir surec bizi bekliyor olacaktı. Bu sebeple render blocking olması kacınılmaz oluyor.
Bitti mi? Hayır. Cunku Şimdi JavaScript Sahneye Cıkıyor!
Peki buraya kadar ekranda bir şey gorduk mu? Yalnızca ‘ ’first paint ’ ’ dediğimiz tarayıcınız bir siteye istekte bulunduğu an ekranda oluşan değişikliği goruyoruz hala. Daha iyi anlamak adına aşağıdaki gorselde ikinci resim first paint ’i temsil etmekte.
Tum DOM sureci tamamlanmadan, Layout işlemi gercekleşmeden ekranda bir şey goremeyeceksiniz.
JavaScript Diyorduk…
Barry Adams, LearnInbound ’daki ‘ ’Technical SEO in the Real World ’ ’ isimli sunumunda JavaScript ’ten şeytan diye bahsediyor. JavaScript ’in Google tarafından farklı konularda bir cok problem doğurması bir kenara, biz şimdilik sayfa yuklenme esnasında JavaScript ’in neler yaptığından bahsedelim ve Barry ’nin savını burada da haklı cıkartalım!
Bir JavaScript ’in calıştırılması icin oncelikli olarak CSSOM ’un tamamlanmış olması gerekiyor. Bu surecler hep birbirini durduran surecler. Şu an DOM sureci yarım kalmış bir şekilde bekliyor ve diğerlerinin tamamlanması ile tekrar ağacı oluşturmaya devam edecek.
Javascript CSSOM ’un tamamlanması ile başlıyor. CSS nasıl ki render blocking olarak geciyordu, JavaScript de parser blocking olarak geciyor.
Kısaca CSS de JavaScript de DOM surecini engellemekte.
Javascript ’i de calıştırdık, DOM surecini de sonlandırdık. Oldu mu?
HALA EKRANDA BİR ŞEY YOK!
2. Layout
Artık kaynaklar hazır, tarayıcı neyi, ne şekilde sayfaya yukleyeceğini biliyor. Ancak neyi, nereye, hangi boyutta yerleştireceğini henuz bilmiyor. Son olarak Layout kısmı devreye giriyor.
Layout kısmında ise tum bileşenleri sayfanın neresine ve hangi boyutta yerleştireceğine karar veriyor ve taa daaa! Sonunda sayfa yukleniyor.
Bu arada bir coğunuz bilse de tam konusu olduğu icin sayfa yuklenme adımlarını manuel nasıl kontrol edersiniz ondan da kısaca bahsedelim.
Chrome ’un DevTools ’unda ‘ ’performans ’ ’ panelini acın ve aşağıda işaretlenmiş, sayfayı tekrar yukle butonuna basın.
DevTools otomatik olarak en cok aktivitenin olduğu kısımları buyutecek.
Screenshots kısmını aktiflerseniz kayıt esnasında sayfanın goruntulerini de cekmeye başlayacak.
Capture Settings kısmında ise dilediğiniz ayarları yapabilirsiniz. Orneğin network kısmında bağlantıyı 3G secip sayfanın yuklenme hızındaki değişimi gozlemleyebilirsiniz.
Summary ’de bu surelerin ne kadar surduğunu gozlemleyebilir, optimize edilebilir alanları saptayabilirsiniz.
Ben ‘ ’network ’ ’ panelindeki waterfall kısmını daha cok seviyorum.
Dilerseniz orada da hangi adımın ne kadar surduğunu gorebilirsiniz.
Bu kısımda daha detaylı bilgi almak icin Google ’ın rehberlerine goz atmakta fayda var.
https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference
Optimizasyon Oncesi…
Optimizasyona gecmeden once neden bunları oğrendik ve neden hız optimizasyonu yapacaktık kısmında bir iki hatırlatma yapalım;
Kullanıcıların %53 ’u 3 saniyeden sonra sayfayı terk ediyor. Mobil kullanıcıların %70 ’i ise hala 2G ve 3G ile internete bağlanıyor. Şimdi bu iki verinin birbiriyle butunleştirilmesi biraz zor, kabul ediyorum.
Ancak en azından road runner olmayı hedefleyip onu kovalayan cakal olmak bile strateji yolunda farklı fikirler bulmamıza sebep olabilir. Cakal dediysek yanlış anlaşılmasın lutfen, kapasite değil strateji mesele!
OPTİMİZASYON SURECİ
Dedik ki sayfa yuklenme hızı optimizasyonu aslında Critical Rendering Path optimizasyonudur.
Şimdi bu adımlarda neler yapılabilir bakalım.
1.Kucult (Minify), Sıkıştır (Compress) ve On Belleğe Al (Cache) Ucgeni
Minify yani kucultme işlemi HTML,CSS ve JavaScript ’e uygulanabilir. Bunun compress yani sıkıştırma işlemi ile karıştırılmaması gerekir. Kucultme işlemi gereksiz boşlukları, yorumları kodunuzdan kaldırarak aslında tarayıcının bunlarda vakit kaybetmesini engellemeye yardımcı olur.
Ornek verecek olursak;
CSS kucultme işleminden once:
CSS kucultme işleminden sonra:
Sıkıştır işlemi ise gzip veya brotli gibi bir sıkıştırma şeması ile dosyanın boyutunu azaltmaya yonelik yapılan bir işlemdir.
Sıkıştırma ve on belleğe alma işlemi sunucu tarafında ayarlanır. Yalnızca kucultme işlemi sunucuya aktarılmadan gercekleştirilmelidir.
On belleğe alma işleminde surec şu şekilde ilerliyor: Bir sayfaya ilk kez girdiğinizde ‘ ’eğer o site sunucu tarafında on belleğe alma işlemini tanımlamışsa ’ ’ tarayıcınız o iceriği indiriyor ve bir sonraki girişinizde o sayfayı sunucudan değil kendi on belleğinden getiriyor. Bunu sitenin sahibi HTTP header kısmında komutlarla belirliyor. Aşağıdaki orneği inceleyelim:
Tarayıcı siteye girdiğinde sunucudan ‘ ’GET‘ ’ isteği yapıyor demiştik. O esnada on bellek ile ilgili verileri de topluyor. Orneğin yukarıdaki ornekte max-age ile on bellek suresini 120 saniye olarak belirlemiş ve hemen altında bir ‘ ’token ’ ’ kodu vermiş. Yani tarayıcı site icerisindeki iceriğin guncellenip guncellenmediğini aynı zamanda bu ‘ ’token ’ ’ ın değişip değişmediğinden de anlayabilir.
On belleğe alma işlemi sitenin yapısına gore değişebilir. Orneğin bir haber sitesi, surekli yenilenen bir iceriğe sahip olduğu icin HTTP header kısmında ‘ ’No-Cache ’ ’ ile sayfalarının on belleğe alınmasını engelleyebilir ve kullanıcı her seferinde siteye girmek istediğinde tarayıcı veriyi sunucudan cağırır.
Ancak bunun gibi ornekler dışında cache sayfa hızı icin onemli bir parametredir ve uygulanmalıdır.
Yani ozetle kucult, sıkıştır ve on belleğe al ucgenini uygulayarak işe koyulabiliriz.
Minify işlemi icin bu siteyi kullanabilirsiniz!
2. Inline CSS & Media
Diğer yandan CRP adımlarını anlatırken CSS ’in tamamlanmadan DOM ’u da JavaScript ’i de beklettiğini biliyoruz. Dolayısıyla CSS surecini kısaltmak onemli. Bunun icinde CSS ’i dışarıdan bir kaynaktan yuklemek yerine ‘ ’inline ’ ’ yaparak yani HTML kaynağı icinde acık vererek sureyi bir nebze olsun kısaltabiliriz.
Ancak bu cozum her zaman tutmayacaktır. Eğer CSS iceriğin coksa ters etki de edebilir. Bu durumda ‘ ’media ’ ’ seceneği duşunulebilir.
İlk linke bakalım. Bir media acıklaması yok. Dolayısıyla ilk kısım hala render blocking yani sureci durdurucu ozelliktedir. CSS işlemi bitmeden DOM devam etmeyecektir.
İkinci linke baktığımızda media=print işaretlemesi ile karşılaşıyoruz. Bu kısım render blocking surecini kaldırıyor. Diyor ki yalnızca icerik basılı ise CSS ’i uygula. Yani icerik gelmeden herhangi bir işlem yapmayacak, sureci de durdurmayacak. Ertelemek gibi duşunebiliriz.
Dolayısıyla secim CSS iceriğinizin yoğunluğuna gore değişecektir.
Yani yapabiliyorsan CSS ’i inline yap, eğer CSS iceriğin yoğunsa ‘ ’media ’ ’ işaretlemeleri uygulayabilir misin kontrol et.
3. JavaScript Async ve Defer İşaretlemesi
JavaScript ’in DOM surecini durdurduğunu soylemiştik. Ancak bunun da cozumu var.
JavaScript herhangi bir şekilde aksi belirtilmediyse senkronize calışır. Async olarak işaretlendiğinde ise senkronize calışmayı bırakır. Aşağıdaki gorsel durumu iyi ozetliyor aslında.
Asenkronize olması icin işaretlendiğinde 25 saniye daha az surede calıştığını goruyoruz.
Dolayısıyla DOM surecini bekletmiyor. Ancak burada onemli bir ipucu verelim, inline JavaScript yaparsanız async calışmaz. JavaScript dosyasının dışarıdan yuklenmesi ve async olarak işaretlenmesi gerekiyor.
Async dışında daha az bilinen ama benzer işlevi goren ‘ ’Defer ’ ’ işaretlemesinden bahsedelim.
Defer de async gibi işaretleniyor ancak herşey bittikten sonra JavaScript ’i calıştır demek oluyor.
Aralarındaki farkı anlamanız icin aşağıdaki gorsel sorusunu cevaplamaya calışmanızı oneriyorum.
Cevaplayalım mı?
Uc sutundaki rendering işlemini incelediğimizde ikinci sutunda .js uzantılı bir dosyanın olmadığını goruyorsunuz. Bu demek oluyor ki JavaScript inline bir şekilde HTML icinde oluşturulmuş. İlk sutunda ise .js dosyaları aralarda indirilmiş, surekliliği yok. Parse HTML ’den bunu anlayabiliyoruz. Yani bu da demek oluyor ki async olarak işaretlenmiş. Blocking yani herhangi bir işaretleme yapılmayan JavaScript ’de ise .js dosyaları arka arkaya calıştırılıyor ve o işlem bittikten sonra diğer işlemlere devam ediliyor. Yani son sutun da blocking.
Peki defer işaretlemesi ile yapılmış olsaydı nasıl gorunecekti?
Defer olsaydı .js dosyalarını yalnızca en sonda gorecektik. Cunku tum sureci bitirdikten sonra calıştır komutu vermiş olacaktık.
JavaScript ’i her durumda asenkronize calıştıramazsın. Orneğin calışmak icin jquery ’ye ihtiyac duyan bir script asenkronize calışıp jquery ’den once yuklenirse hata alabilirsin. Bu durumda sayfa işleyişini bozmadan ne kadar cok script async ve defer olarak işaretlenebilirse o kadar sayfanı hızlandırabilirsin. Dolayısıyla neleri async olarak işaretleyebileceğin onemli.
4. CRP Kaynaklarını ve Uzunluğunu Azalt!
Sayfa hızı optimizasyonunun aslında CRP optimizasyonu olduğunu belirtmiştik. CRP de kritik kaynakların cokluğu (HTML,CSS ve JavaScript) ve bu yolculuğun uzun olması tarayıcının işleme suresini uzatacak ve dolayısıyla sayfanızın hızını etkileyecektir.
Kaynakları azaltabildiğinizde ve CRP yolculuğunu kısalttığınızda sayfanızın hızını da artırmış olacaksınız.
‘ ’render blocking ’ ’ ve ‘ ’parser blocking ’ ’ olan herşey kritik kaynaktır. Zaten en cok sure burada kaybediliyor genelde. Dolayısıyla kritik kaynaklarınızı tekrar gozden gecirmenizde fayda var.
Kritik kaynakların sayısını azalt, CRP yolunu kısaltabiliyor musun araştır.
Ayrıca son olarak JavaScript calışmadan once tum HTML kaynağının indirildiğinden emin olun. Bunun icin JavaScript ’i body kısmında sona taşıyabilirsiniz. Bu da sizin sayfa yuklenme hızınızı etkileyecektir.
JavaScript şeytandır! Onunla en son yuzleşmek adına body kısmının sonuna taşı, HTML sureci JavaScript calışmadan once sonlansın.
5. Resim Optimizasyonu
Sayfa hızını etkileyen en onemli parametrelerden birisi de yuksek kalitedeki resimler.
Burada hem kullanıcıyı hem SEO ’yu aynı anda duşunmelisiniz.
Aşağıdaki gibi bir kucultme işlemi belki SEO performansını artıracaktır ancak kullanıcıya sunduğunuz bu fotoğrafın amacına hizmet etmesi mumkun olmayacak.
Oncelikle dosya formatlarından bahsedelim:
.jpg formatını fotoğraflar ve ekran goruntuleri, .png formatını ise yuksek kaliteli gorseller ve transparan ogeler icin tercih edebilirsiniz.
GIF ise animasyon ozelliğinden illa ki faydalanacağım dediğiniz zamanlarda tercih etmelisiniz cunku boyutu yuksek olacaktır.
Resim boyutunu optimize ederken iki madde ustunde odaklanacağız. Scaling yani boyutlandırma dediğimiz işlem ve compress yani fotoğrafın boyutunu sıkıştırma işlemi. Burada biraz Turkce ’nin azizliğine uğruyoruz, bu iki işlemi aynı şeymiş gibi konuşuyoruz genelde ama değil.
Yeniden Boyutlandırma İşlemi
Scaling işlemi resmin boyutlarını değiştirme işlemidir. Sayfanızda resmin kendi boyutundan bağımsız goruntulendiği alanın da bir pixel genişliği vardır. Ornekle gosterecek olursak;
Kaynak kodunun uzerinde acılan resmin altında iki boyut goruyoruz; natural size yani doğal boyutu ve ilk başta yazan display size yani goruntulenen boyutu. Natural boyut resmin kendi genişliği ve yuksekliğidir. Display boyut ise sayfa uzerinde goruntulendiği boyuttur. Sayfa uzerinde goruntulenen alan ile resmin boyutu birbirine ne kadar yakın olursa o kadar kullanıcı deneyimi ve SEO acısından uygun bir resim elde etmiş olacaksınız. Yani diyelim ki resminizin genişliği 2000 pixel ve siz onu 300 pixellik bir alanda gosteriyorsunuz. Boşu boşuna tarayıcı o 2000 pixeli indirmiş olacak, ayrıca doğru kod yazılmadıysa resminiz duzgun bile gorunmeyecektir.
Dolayısıyla boyutlandırma işlemi yaparken resmin geleceği alanın genişliğine gore boyutlandırma yapmak en doğru cozum olacaktır. Responsive dizaynda işler biraz karışıyor ancak ona Vol.2 yazımızda yani ‘ ’Responsive Dizayn, AMP ve PWA ’ ’ konularına değindiğimizde detaylıca inceleyip yine bu kısıma atıfta bulunarak aradaki farkı anlatacağım.
Wordpress kullanıyorsanız bunun icin plug in ’ler mevcut. Resimlerinizi yuklediğinizde display alanına gore yeniden boyutlandırıyor. Bir iki resim kucultecekseniz de doğrudan paint uzerinden bile bu işlemi gercekleştirebilirsiniz.
Sıkıştırma İşlemi
Compress yani sıkıştırma işlemi ise dosya boyutunun kucultulmesi işlemidir. Burada kayıplı (lossly) ve kayıpsız (lossless) kucultme karşımıza cıkıyor. Kayıpsız kucultmede fotoğrafın kalitesinden odun vermeden gereksiz meta verileri vs kaldırılarak bir kucultme soz konusudur. Tabi ki kayıpsız sıkıştırma kayıplı sıkıştırmaya gore daha az bir kucultme sağlar. Ancak kayıplı sıkıştırmada da fotoğrafın kalitesi bozulmakta, sıkıştırma oranına gore değişen blur goruntu oluşmaktadır.
Sıkıştırma işlemi icin kraken.io, imagify.io, compressjpeg.com sitelerini kullanabilirsiniz.
6. Lazy Load Metodu
Lazy load gorsellerin fazla ve sayfanın uzun olduğu yerlerde sayfaların daha hızlı acılmasını sağlayacak bir javascript dosyasının kullanılmasıdır. Bu metotla kullanıcının henuz goruntulemediği ‘ ’kritik olmayan ’ ’ kaynakların yuklenmesini erteleyebilirsiniz. Yani kullanıcı sayfanızı actığında ilk gorduğu kısımdaki resim, video gibi icerikler yuklenirken, sayfada aşağıya indikce altta kalan kaynaklar yuklenmeye başlar. Dolayısıyla sayfanın yuklenmeden once ağırlığı hafifletilmiş olur.
HTML icin ornek lazy loading kodu;
Lazy loading her ne kadar mukemmel cozum gibi gorunse de performans problemleri yaratabilen bir yaklaşımdır.
Orneğin tek sayfa olan ve navigasyonla sayfanın en altına link veren bir site duşunelim. (one page template) Kullanıcı navigasyonla sayfanın aşağısına indiğinde lazy load kullanılmışsa orada var olan fotoğrafı hemen goremeyecektir. Kulağa hic kullanıcı dostu gibi gelmiyor! Ancak yuzlerce fotoğrafın olmadığı ve sayfanın hızını daha da iyileştirmek adına bir şeyler yapmak istediğinizde kullanabileceğiniz bir yontem yine de.
Ayrıca Google bot her zaman lazy load ile gelen kaynakları taramayabiliyor. Search Console uzerinde fetch and render testi yaparken bu hata ile karşılabilirsiniz.
7. CDN (Content Delivery Network)
İcerik dağıtım ağı yani kısaca CDN sitenizdeki statik icerikleri farklı lokasyonlardaki sunuculara yukleyerek kullanıcıya en yakın lokasyondan sayfanın yuklenmesine olanak tanır.
Cıkış sebebi anlaşılacağı uzere gozden ırak olanın tarayıcının gonlunden de uzak olmasıdır. Eğer kilometrelerce otede barındırılan (hosting) bir sayfayı ziyaret ediyorsanız sayfa goruntulemede gecikme yaşanması kacınılmaz olacaktır.
Kucuk bir işletme iseniz, yuzlerce videoyu ve medya iceriğini sitenizde barındırmıyorsanız ve trafiğiniz cok da yuksek değilse, hepsinden ote coğrafik olarak farklı bolgelerden ziyaretcileriniz yoksa CDN sizin icin gerekli olmayacaktır. Ancak aksi durumda site hızı icin ciddi bir artısı olacaktır.
AmazonCloudFront, Cachefly ve MaxCDN bu hizmeti sağlayan şirketlerden yalnızca birkacıdır.
Daha yapılabilecek onlarca optimizasyon adımı sayılabilir site hızı geliştirmeleri icin. Ancak en kritik olanları sizin icin derlemeye calıştık. Meşakatli ve bazen sitenin yapısı gereği yapılması zor oneriler olabilir. Yine de ust sıraya yerleşmek adına yarıştığımız platform gereği bu dili anlamamız ve ona uygun konuşmamız kacınılmaz olacaktır.
8. Site Hızı Test Aracları
PageSpeed Insights
Web sitenizin hem mobilde hem desktopta hız konusunda nasıl olduğunu merak ediyorsanız Google ’ın ucretsiz sunduğu bu aracı kullanabilirsiniz.
Bu aracın en onemli ozelliği Google Chrome aracından gercek zamanlı veriler sunması. Topladığı verilerin ortalamasını alarak size kendi verileri icinden bir sonuc cıkartıyor.
Ancak hızı test etmek konusunda yuzde yuz guvenip bu aracı baz almamalısınız. PageSpeed Insights sayfanın yuklenme zamanını vermiyor orneğin. Size fikirler verebilecek ve optimizasyon onerileri sunabilecek bir arac. Muhakkak test edin ancak bununla yetinmeyin!
Google Lighthouse
Bir diğer Google urunu olan Lighthouse Chrome modulu olarak karşımıza cıkıyor.
Network ’un yanındaki oklara tıkladığınızda acılan menuden ‘ ’Audits ’ ’e tıklayın.
Acılan pencerede secimlerinizi yaparak sayfanızı test edebilirsiniz. Test bittiğinde lighthouse aracı da size optimizasyon onerileri sunacaktır.
Onemli: Google yeni bir guncelleme ile PageSpeed Insights aracında Lighthouse verilerini vermeye başladı.
Dolayısıyla artık PageSpeed Insights uzerinden de lighthouse aracının sunduğu optimizasyon onerilerini gorebileceksiniz.
GTMetrix
GTMetrix verilerini Pagespeed Insights ve YSlow uzerinden ceken hem ucretsiz kullanım sunan hem de ucretli seceneği bulunan bir arac.
Mobil verilerini almak isterseniz aracı satın almanız gerekiyor.
Pingdom
Bir diğer arac, site hızı dışında başka ozellikler de sunan Pingdom aracı. Kullanışlı ara yuzu ve veri gorselleştirmesi ile on plana cıkıyor. Ancak ucretli bir arac.
Varvy
Son olarak da site hızı test aracı olarak varvy.com var. Hem ucretsiz bir arac hem de blog kısmında detaylı ve teknik yazıları ile gonlumuzu celiyor.
Bu yazımızı detaylı okuduktan sonra aracların sunduğu her bir optimizasyon onerisini sizler icin daha anlaşılır kılmayı umduk. Umarız keyifli bir okuma olmuştur!
Serinin 2. yazısı Gercek Kullanıcı Metrikleri ile Site Hızı Olcumu ve 3. yazısı AMP nedir yazılarına devam edebilirsiniz!
Kaynaklar:
https://www.udacity.com/course/websi...ization--ud884
https://developers.google.com/web/to...rome-devtools/
https://varvy.com/
kaynak : https://zeo.org/tr/blog/sayfa-yuklen...optimizasyonu/