Web sitenizin kötü performansının sorumlusu kim?

Web siteniz üzerinden elde ettiğiniz dönüşüm, lead ya da aksiyonların, başarısını etkilediği bir işiniz varsa ve özellikle de teknik bir background’a sahip biri değilseniz, eminim web sitenizin teknik performansının yeteri kadar iyi olup olmadığı sorusu aklınızı kurcalıyordur. Peki bu konuda sağlıklı bilgiye nasıl erişebilirsiniz?

Bu soru ile yola çıktığınızda, karşınıza ilk önce internette bulabileceğiniz pek çok online performans testi çıkacak. Bu testleri yaptığınızda göreceksiniz ki, her biri birbiri ile pek de ilişkili görünmeyen bir sürü şey söylüyor. Bir tanesi verdiği puanla çok iyi olduğunuzu söylerken, bir diğeri durumunuzu vahim olarak tanımlayabiliyor. Aslında bu testlerin çoğu da doğru söylüyor ama problem şu ki odaklandıkları yerler birbirinden farklı. Biz yine ilk sorumuz ile başbaşayız. “Web sitemin performansı yeteri kadar iyi mi, değilse bunun sorumlusu kim?” Gelin bu yazıda tane tane bu soruya nasıl cevap bulabileceğimizi konuşalım.

Öncelikle olağan şüphelileri birbirinden ayırıp tanıyarak başlayalım. Birincisi web sitenizin üzerinden çalıştığı sunucu. Bu bir paylaşımlı hosting, sanal ya da fiziksel bir sunucu olabilir. Bu sunucunun işi sitenizin yazılımına ait kodları çalıştırarak ziyaretçilere, isteklerine göre ürettiği sonuçları tarayıcının görüntüleyebileceği şekilde göndermek. Bu sunucunun bu işlemleri yaparken ne kadar hızlı çalıştığı, ne kadar yüksek hızlı ve geniş bir bağlantıya sahip olduğu, isteği gönderen ziyaretçiye ne kadar yakın olduğu web sitenizin performansını doğrudan etkileyecektir.

Ancak tek şüphelimiz o değil. İkinci adayımız web sitenize ait backend kodları. Sunucu performansı ne kadar iyi olursa olsun, kodlarınızın yaptığı bir iş ve o işin aldığı bir zaman var. Çok basit bir örnekle bir milyon tane sayfanın olduğu sitenizde ziyaretçinin istediği sayfayı bulmak için her birine tek tek bakan bir kodunuz varsa sunucunun pek de yapabileceği bir şey yok. Ancak problemin bu ikisinden hangisinde olduğunu ayırt edebilmek de çok kolay değil. Çünkü kötü kodu çalıştırmaya çalışan sunucunun performansı kötüleşecek, benzer şekilde kötü sunucu üzerinde çalışan kodların işlem süresi de uzayacaktır. Bunları birbirinden nasıl ayırt edeceğimize yazının devamında geleceğiz.

Üçüncü potansiyel problem noktası tarayıcı yani ziyaretçinin bilgisayarı. Her ne kadar ilk anda bu sizin kontrolünüz dışında gibi görünse de, o bilgisayara görüntüleyeceği kodları sizin sunucunuz gönderiyor. Dolayısıyla web sitenizin sağlıklı çalışması için tarayıcıdan ne kadar yüksek beklentilerinizin olduğunu kontrol etmek de yine sizin sorumluluğunuz. Tarayıcı sizden kodları aldıktan sonra sayfayı görüntüleyebilmek için başka kaç farklı yerle daha konuşmak zorunda kalacak, bu da yine sizin kontrolünüzde.

Bu üçlünün yanına eklenmesi muhtemelen farklı birkaç aday daha bulmak mümkün. Ancak ortalama bir web sitesi için %95’in üzerinde sorumlu bu üçlünün arasından çıkacaktır. Bu yazıyı da mümkün olduğunca basit tutabilmek için onları şimdilik atlayabiliriz.

Sunucu Performansı

Şüphelileri karşımıza dizdiğimize göre şimdi sıra suçluyu bulmakta. Bunun için ziyaretçinin sitenizin adresini tarayıcısına yazdığı ilk andan başlayalım. İlk önce ziyaretçinin bilgisayarının sunucunuz ile buluşup konuşmaya başlaması gerekiyor. Bu noktada izlemeniz gereken kritik bir metrik var; TTFB (Time to first byte). TTFB ziyaretçinin talebinin sunucuya gönderilmesi ile sunucunun ilk yanıtının tekrar ziyaretçiye ulaştığı an arasında geçen süreyi belirtir. Bu süre bağlantının sağlanması için geçen süreler ile request’in sunucuda işlenmesi için geçen sürenin birleşimidir. Şu anda odaklandığımız sunucunun performansı olduğu için, kodumuzun bu süredeki etkisini minimuma indirmemiz gerekiyor. Bunu da statik dosyalar üzerinden TTFB değerini ölçerek yapabiliriz. Web sunucunuzdaki basit bir .html ya da .css dosyasının TTFB değeri, bu dosyalar sunucuda işlenmeden doğrudan sunuldukları için sunucunuzun yanıt süresi hakkında önemli bir fikir verecektir.

TTFB değeri ne olmalı? Hangi süreler iyi ya da kötüdür?

Peki gelelim bu süreyi öğrendikten sonra yorumlamaya; Eğer paylaşımlı bir hosting kullanıyorsanız 400ms-600ms arası süreler iyi kabul edilebilir. Güçlü ve ziyaretçiye yakın bir sunucuda hedeflemeniz gereken ideal değerler 200ms civarı olabilir. 800ms’e kadar Google Pagespeed’in testini geçmiş olursunuz. Ancak 1 saniye ve üzerindeki TTFB değerleri sunucunuzun yanıt süresinde bir problem olduğuna işaret edebilir.

TTFB süresi nasıl kısaltılabilir.

TTFB duruma ve siteye göre daha az değişken bir veri olduğu için formülü ve iyileştirmek için yapılması gerekenler de oldukça net;

1. Daha yüksek performanslı bir sunucuya geçmek ve CDN kullanımı: Sunucunuzun yükünü azaltarak ya da kapasitesini arttırarak bu süreyi iyileştirebilirsiniz. CDN kullanımı sunucudaki yükü azaltarak ziyaretçilere en uygun lokasyondan dosyalarınızı sunacağı için TTFB süreniz için faydalı olabilir.

2. Ziyaretçilerinizin büyük çoğunluğuna yakın bir konumda web sitenizi barındırmak: Her şeyin kusursuz olduğu bir dünyada bile ışık hızından daha hızlı veri alıp veremezsiniz. Ziyaretçiler sitenize ulaşmak istediklerinde onlara cevap verecek bilgisayarın dünyanın uzak bir köşesinde olması uzun bekleme sürelerine yol açar. Elbette dünyanın her yerinden ziyaretçiniz olabilir fakat bunların toplandıkları lokasyonlara göre sunucu konumunuzu seçmek ortalama yanıt sürelerinizi düşürecektir.

3. Cache kullanımı: Aynı istekler için sunucunuzun aynı işi tekrar tekrar yapması yerine standart hazır yanıtlar biriktirmesi hem iş yükünü hem de TTFB süresini azaltmanıza yardımcı olabilir.

Backend kod performansı

Gelelim backend kod performansımızı sorgulamaya. Kodlarınızda bir sorun olduğunun ilk göstergesi statik sayfalarımızla dinamik sayfalarımız arasındaki TTFB süresi farkının açılması olabilir. Elbette backend kodunun yaptığı işin gerektirdiği süre her sayfa için çok farklı olabilir. Bu performans web sunucunuzun cevap verdiği toplam trafiğe, üzerinde çalıştığı datanın boyutuna bağlı olarak da ciddi oranlarda değişebilir. Dolayısıyla size web sitenizin kötü performansını açıklamaya çalışan birinin kullanabileceği onlarca bahanesi olacaktır.

Fakat gerekçeler arasında boğulmadan sizin için konuyu şu kadar basitleştirebilirim; backend kodunuzun yaptığı iş her ne ise, onu milisaniyeler seviyesinde bir sürede tamamlayamıyorsa yapısal bir probleminiz var demektir. Eğer mevcut kod için bu süre geliştirilemiyorsa mutlaka daha temelde mimari bir probleminiz var demektir.

Backend kodunuzun performansı ile ilgili bir probleminiz var ve mevcut teknik ekibiniz ile bu performansı iyileştirmekte sorun yaşıyorsanız, mutlaka kodunuzu inceleyecek ikinci yetkin bir kişi ya da ekipten görüş almanızı tavsiye ederim.

Site arayüzünün performansı

Artık backend kodunuz da işini tamamladı ve sitenizi görüntüleyebilmesi için kodlarınızı kullanıcının tarayıcısına gönderdi. Fakat işimiz bitmedi. Hatta en alengirli kısmı şimdi başlıyor. Gelin şimdi de site arayüzünün görüntülenmesindeki olası problemlere ve bunların çözüm yollarına bakalım.

Ziyaretçinin açmak istediği sayfa için ona ilk anda düz metin olarak sayfamızın html kodlarını gönderiyoruz. Bu döküman sayfamızın nasıl görüntüleneceğini tarayıcıya tarif ediyor. Fakat tüm kaynaklarımız bu dökümandan ibaret değil. Sayfamızın içinde yer alan tüm görseller, stil, script, font dosyaları gibi pek çok başka dosyanın adresi bu ilk dökümanın içinde. Tarayıcı ilk dökümanı alıp içeriğini okuduktan sonra da diğer kaynakları sırasıyla yüklemeye başlıyor.

Burada da izlememiz gereken 2 farklı kritik metrikten söz edeceğiz. Bunlar sayfamız yüklenirken hangi aşamaya hangi sürede geldiğini ölçtüğümüz metrikler ve problemin tespiti için bize ciddi ipuçları verecekler.

FCP (First Contentful Paint)

FCP sayfanız yüklenirken, tarayıcıda ilk görüntünün oluştuğu zamanı ölçer. Bu noktadan itibaren tüm süreleri bir önceki aşamanın üzerine ekleyeceğiz. Dolayısıyla FCP süremize TTFB aşamasında beklediğimiz süre de dahildir.

FCP için en kritik nokta, sayfanın görüntülenebilmesi için mutlaka beklememiz gereken dış kaynaklardır (Render-Blocking Resources) Örneğin sayfanız görüntülenmek için mutlaka font dosyalarının yüklenmesini beklemeli mi yoksa bunları opsiyonel olarak hazır olduklarında devreye girecek şekilde mi düzenlediniz. FCP’nin temel amacı ziyaretçinin en kısa sürede bir şeyler görmeye başlamasını sağlamak.

Google yönergelerine göre FCP aşamasının tamamlanması için beklenen süre en fazla 1.8 saniye. 3 saniye üzeri ise “kötü performans” olarak tarif ediliyor.

Eğer FCP süreniz problemli görünüyorsa sayfanın görüntülenebilmesi için önden yüklenmesi gereken dosyaların adedini azaltmayı deneyebilirsiniz. Ayrıca tarayıcının ulaşması gereken hem kaynak hem de bunların bulunduğu konum adedini azaltmak iyi bir fikir olabilir. Imajlarınızı sayfa açılışı yerine lazy-loading biçiminde sayfa açılışından sonra yüklemek de bu açıdan çok verimli bir tercih olacaktır.

LCP (Largest Contentful Paint)

İkinci aşama LCP. Bu süre ise sayfanızdaki ana içeriğin (bu genelde sayfada görünür alandaki ilk içerik olur) görünür olduğu süreyi gösterir. Ziyaretçinin artık sayfa ile ilgilenmeye başlayabileceği zaman olduğu için de ayrıca önemli bir andır.

Google için LCP aşamasının tamamlanması için beklenen süre en fazla 2.5 saniye. 4 saniye üzeri ise “kötü performans” olarak tarif ediliyor.

Sayfanızdaki ya da kaynaklarınızdaki kod kalabalıkları LCP sürenizi kötü etkileyebilir. Öncelikle sayfanızdaki LCP bölgesini tespit etmek işinize yarayacaktır. O bölgedeki stil kodlarını inline olarak yazmak, diğer bölgelerdeki yüklemeleri ertelemek de LCP sürenize katkı sağlayabilir.

Sayfa açılırken ana doküman için bir istek göndermiştik hatırlıyorsanız. Sayfa açılışı sırasında da tüm diğer kaynaklar için ayrı ayrı yeni istekler gönderiyoruz. Dolayısıyla bu isteklerin her birinin de kendine ait TTFB süreleri olduğunu unutmayın.

Arayüzün işlem maliyeti

Şimdiye kadar daha çok bağlantı ve yüklenme sürelerinin üzerinde durduk. Ancak tüm kaynaklar yüklendikten sonra bunları ekranda görüntülemek de yine tarayıcının işi olacak. Burada da onu ne kadar yorduğumuz önemli. Örneğin parallax imajlar, degrade ve hareketli zemin renkleri ya da standartlar harici çok sayıda tıklama, scroll izlemek tarayıcının üzerine fazla gitmenize ve isyanına sebep olabilir. Dolayısıyla sayfalarımızı kurgularken öncelikli amacı doğru tespit etmek ve tasarım aşamasında bu öncelikleri göz önünde bulurdurmak önemli. Ayrıca çalıştığınız tasarım ekibinin arayüz performansı konusunda bilgi sahibi olması da işinizi kolaylaştıracaktır.

Sitenizin performansını takip etmek ve değişikliklerden haberdar olmak için Bekçi

Bu yazıda web sitenizin performansı konusunda izlemeniz gereken başlıca kritik metrikleri, bunları nasıl yorumlayabileceğinizi ve bunlara dayanarak problemli bölgeleri tespit edebilmenize bir parça yardımcı olmaya çalıştık. Umarım sizin için faydalı olmuştur. Elbette tüm metrikler bu yazıda söz ettiklerimiz ile sınırlı değil. Ancak adım adım ilerlemek önemli ve bu çerçevenin iyi bir başlangıç noktası olacağını umuyorum.

Web sitesi performansınızı iyileştirmek için yola çıktığınızda elbette bu performansı takip etmek ve buradaki değişikliklerden haberdar olmak kritik önemde. Bu konuda size rehberlik etmesi amacı ile Bekçi’yi geliştirdik. Bekçi web sitenizi sürekli takip ederek performansını analiz eden, bu analiz sonucunda geliştirme önerileri sunan, bunları teknik ekiplerle kolay iletişim kurup sonuçlarını izleyebileceğiniz şekilde sizin için açıklayan, ayrıca değişiklik durumunda size anında haber veren bir web uygulaması.

Siz de bekci.site adresinden hemen kayıt olup Bekçi’yi 7 gün ücretsiz deneyebilir, ayrıca dilerseniz sonrasında “MERHABA” kodu ile 3 ay %50 indirimle kullanabilirsiniz.

Hemen Kayıt ol