Web Sitenizi Neyin Yavaşlattığını Nasıl Tespit Edersiniz?

Bir web sitesinin yavaş olması bir belirtidir, teşhis değil. Gereğinden büyük görseller, geciken sunucu yanıtları, üçüncü taraf betikleri ve yoğun JavaScript işlemleri benzer sorunlara yol açabilir; ancak her biri farklı bir çözüm gerektirir.

Web sitenizi neyin yavaşlattığını bulmak için gerçek kullanıcı performans verilerini, sorun yaşanan bir sayfanın tarayıcıdaki performans kaydıyla birlikte değerlendirin. Ardından gecikmenin kaynağını belirli bir isteğe, betiğe, oluşturma görevine veya arka uç işlemine kadar takip edin. Bu yaklaşım, optimizasyon araçları kurup puanınızın yükselmesini beklemekten daha yararlıdır.

1. Web Sitesinin Nerede ve Ne Zaman Yavaşladığını Belirleyin

Önce sorunu net biçimde tanımlayın. “Web sitesi yavaş geliyor” ifadesi, verimli bir inceleme yapmak için fazla geneldir.

Sitenizi temsil eden birkaç sayfa seçin: ana sayfanız, önemli bir açılış sayfası, bir içerik sayfası ve varsa bir ürün veya ödeme sayfası. Hangi cihazların, konumların ve kullanıcı işlemlerinin etkilendiğini kaydedin.

İncelemenin kapsamını daraltmak için şu soruları kullanın:

• Sorun yalnızca mobil cihazlarda mı yaşanıyor?
• Her sayfa mı yavaş, yoksa yalnızca belirli bir şablonu kullanan sayfalar mı?
• Gecikme, içerik görünmeden önce mi yoksa kullanıcı bir yere tıkladıktan sonra mı oluşuyor?
• Oturum açmış kullanıcılar, oturum açmamış ziyaretçilerden daha fazla mı etkileniyor?
• Trafik aniden arttığında performans düşüyor mu?
• Sorun bir sürümün yayına alınmasından, eklenti güncellemesinden veya pazarlama entegrasyonundan sonra mı başladı?

Örneğin, ana sayfanın hızlı ancak ürün aramasının yavaş olması, tüm sayfaların yanıtlarının gecikmesinden farklı bir soruna işaret eder. İlk durumda arama sorguları veya uygulama kodu etkili olabilir; ikinci durumda ise barındırma hizmeti, önbellekleme ya da ortak altyapı incelenmelidir.

URL, tarih, cihaz, bağlantı koşulları ve gözlenen gecikmeyi içeren basit bir başlangıç kaydı tutun. Her testi birkaç kez çalıştırın; olağan dışı derecede iyi veya kötü tek bir sonuca güvenmek yerine tipik sonuçları karşılaştırın. Tarayıcının durumunu testler arasında tutarlı tutun ve önbelleğin boş olduğu ilk ziyaretle tekrar ziyareti birbirinden ayırın.

2. Sorunun Türünü Belirlemek için PageSpeed Insights Kullanın

Sorun yaşanan URL’leri Google PageSpeed Insights ile test edin. Araç birbirini tamamlayan iki görünüm sunar: mevcut olduğunda saha verileri ve kontrollü bir Lighthouse laboratuvar testi.

Saha verileri, sürekli güncellenen bir raporlama dönemi boyunca gerçek Chrome kullanıcılarının deneyimlerini yansıtır. Laboratuvar verileri ise belirli koşullarda simüle edilen bir ziyareti kaydeder. Biri diğerinin yerini tutmaz: saha verileri kullanıcıların sorun yaşayıp yaşamadığını gösterirken laboratuvar testleri tekrarlanabilir nedenleri araştırmaya yardımcı olur.

Saha sonuçlarının tam olarak test ettiğiniz URL’ye mi yoksa daha geniş kapsamlı site kaynağına mı ait olduğunu kontrol edin. Site genelini kapsayan bir özet, yavaş bir sayfa şablonunu gizleyebilir. Ayrıca bazı sayfalarda URL düzeyinde raporlama için yeterli trafik bulunmayabilir.

Metrikleri Birer İpucu Olarak Okuyun

Core Web Vitals, kullanıcı deneyiminin hangi yönünde sorun olduğunu belirlemeye yardımcı olur:

Bu eşikler, sayfa ziyaretlerinin 75. yüzdelik dilimindeki değere göre değerlendirilir; mobil ve masaüstü ayrı ayrı ele alınır.

İlk Bayta Kadar Geçen Süre, yani TTFB, bir Core Web Vitals metriği değildir; ancak HTML belgesi gelmeden önceki gecikmeleri açıklamaya yardımcı olur. Yüksek bir değer yalnızca yetersiz bir barındırma paketinden değil; yönlendirmelerden, ağ gecikmesinden, sunucudaki işlemlerden veya içeriğin önbellekte bulunmamasından da kaynaklanabilir.

Toplam Engelleme Süresi’ni (TBT) INP ile karıştırmayın. Lighthouse, TBT’yi ana iş parçacığındaki engellemeleri incelemek için bir laboratuvar metriği olarak kullanır; bu metrik gerçek kullanıcıların gerçekleştirdiği tüm etkileşimleri ölçmez.

Her öneriyi aynı derecede acil görmek yerine raporu, “ana görselin indirilmesi çok geç başlıyor” gibi bir hipotez oluşturmak için kullanın.

3. Chrome DevTools ile Yükleme Gecikmelerinin Kaynağını İzleyin

Chrome DevTools’u açın, Network panelini seçin ve sayfayı yeniden yükleyin. İlk ziyareti incelemek için DevTools açıkken Disable cache seçeneğini etkinleştirin. Testleri karşılaştırırken ağ hızını sınırlandırma ayarlarını tutarlı tutun.

Ağ şelalesi, isteklerin ne zaman başladığını, ne kadar sürdüğünü ve hangi isteklerin diğerlerine bağlı olduğunu gösterir. İstekleri süreye ve aktarılan veri boyutuna göre sıralayın; beklenmedik şekilde geç başlayan kaynakları da inceleyin.

Ana HTML Belgesini Kontrol Edin

İlk belge isteğini seçin ve Timing sekmesini inceleyin. Gecikmenin büyük bölümü yanıt beklenirken oluşuyorsa isteğin izlediği yolu ve arka ucu araştırın.

Sonraki adımda şu noktaları kontrol etmek yararlı olur:

• Son sayfa yüklenmeden önceki yönlendirme zincirleri.
• Yanıtın önbellekten sunulup sunulmadığı.
• Uygulama hataları, kaynakların kapasite sınırına ulaşması veya ani trafik artışları.
• Yavaş veritabanı sorguları veya harici API çağrıları.
• Kullanıcılar ile yanıt veren sunucu arasındaki coğrafi uzaklık.

Tarayıcıdaki zamanlama bilgisi tek başına belirli bir veritabanı sorgusunu ortaya çıkaramaz. Gerçek arka uç işlemini bulmak için yavaş isteği uygulama günlükleri, sunucu metrikleri veya işlem izleme verileriyle ilişkilendirin.

Büyük ve Geç Yüklenmeye Başlayan Kaynakları Bulun

Büyük görselleri, video dosyalarını, yazı tipi indirmelerini, JavaScript paketlerini ve tekrarlanan üçüncü taraf isteklerini arayın. Hem dosya boyutunu hem de zamanlamayı dikkate alın: geç keşfedilen orta boyutlu bir görsel, hemen istenen daha büyük bir görselden daha fazla gecikmeye neden olabilir.

Web sitesinin yavaş yüklenmesini incelerken en yararlı soru çoğu zaman “En büyük dosya hangisi?” değil, “Önemli içeriğin görünmesini ne engelliyor?” sorusudur.

Örneğin, yalnızca bir stil sayfası üzerinden tanımlanan ana görsel, ilk HTML içinde yer alan bir görselden daha geç keşfedilebilir. İlk ekranda görünen bu görsele gecikmeli yükleme uygulamak, yüklenmesini daha da geciktirebilir. Ekran dışında kalan görseller, gecikmeli yükleme için daha uygun adaylardır.

Bir isteği neyin başlattığını görmek için Initiator bilgisini kontrol edin. Böylece tanımadığınız bir kaynağın bir etiket yöneticisi, eklenti, stil sayfası veya başka bir betik tarafından çağrıldığını görebilirsiniz.

4. Sayfa Yavaş Tepki Verdiğinde Olanları Kaydedin

Bir sayfanın indirilmesi tamamlanmış olsa bile etkileşimlere verdiği yanıt yavaş olabilir. Chrome DevTools içindeki Performance panelini açın ve yavaş hissettiren işlemi kaydedin: gezinme menüsünü açmak, ürünleri filtrelemek, çerezleri kabul etmek veya sepete ürün eklemek.

Bu etkileşimin gerçekleştiği sırada ana iş parçacığını inceleyin. 50 milisaniyeden uzun süren uzun görevler, tarayıcının kullanıcı girdilerini işlemesini veya ekranı zamanında güncellemesini engelleyebilir.

Yaygın nedenler arasında yoğun JavaScript çalıştırılması, yüksek işlem maliyetli olay işleyicileri, tekrarlanan yerleşim hesaplamaları ve aynı anda çok fazla arayüz öğesinin oluşturulması bulunur. Yoğun işlem yükü kendi uygulamanızdan kaynaklanabileceği gibi analiz, sohbet, reklam ve kişiselleştirme araçlarından da gelebilir.

Hangi işlevin veya betiğin zaman tükettiğini belirlemek için performans kaydını kullanın. Coverage paneli de kayıt sırasında kullanılmayan kodu gösterebilir; ancak kullanılmayan kodu kaldırmak her zaman güvenli değildir. Bu kod, başka bir sayfa yolunda veya etkileşimde gerekli olabilir.

Üçüncü Taraf Betiklerini Ayrı Ayrı Test Edin

Bir test ortamında, her seferinde tek bir entegrasyonu geçici olarak devre dışı bırakıp aynı kaydı tekrarlayın. Yalnızca genel puanı değil, etkileşim gecikmesini ve ana iş parçacığındaki etkinliği de karşılaştırın.

Bu yöntem, belirli bir eklentinin yavaş olduğunu varsaymaktan daha güçlü kanıt sağlar. Hangi betiklerin yüklendiğini etkileyebileceği için kullanıcı onayı durumunu testler arasında aynı tutun. Sırf bir test sonucunu iyileştirmek amacıyla canlı sitedeki onay mekanizmalarını devre dışı bırakmayın.

Sonuç olarak bir entegrasyonu kaldırmak, yalnızca gerektiği yerde yüklemek, zorunlu olmayan çalışmasını ertelemek veya uygulanma biçimini değiştirmek gerekebilir. Doğru seçim, hem performans maliyetine hem de işletmeye sağladığı değere bağlıdır.

5. Bulgulara Uygun Çözümü Seçin

Olası bir darboğaz belirlediğinizde hedefe yönelik bir müdahale seçin. Barındırma hizmetini, önbelleklemeyi, görselleri ve betikleri aynı anda değiştirmekten kaçının; aksi hâlde neyin fayda sağladığını veya neyin bozulduğunu anlamak zorlaşır.

Önbellekleme, kullanıcı işlemlerinin yapıldığı sitelerde özellikle dikkat gerektirir. Herkese açık içerik ortak önbelleklemeden yararlanabilir; ancak hesap sayfaları, sepetler ve kişiselleştirilmiş yanıtlar uygun biçimde kapsam dışında tutulmalıdır. Daha hızlı bir sayfa, başka bir müşterinin bilgilerini açığa çıkarıyorsa bu bir iyileştirme değildir.

Benzer şekilde, bir içerik dağıtım ağı içeriğin iletimini hızlandırabilir; ancak verimsiz bir veritabanı sorgusunu veya aşırı yük altındaki bir tarayıcıyı düzeltmez. Çözümü, ölçümle belirlediğiniz kısıta göre seçin.

Önceliklendirmeyi kullanıcıya etki, etkilenen kitlenin büyüklüğü, bulguya duyulan güven ve uygulama çabasına göre yapın. Yüksek trafik alan mobil ürün sayfası şablonunda doğrulanmış bir gecikme, genellikle az ziyaret edilen bir sayfadaki küçük bir uyarıdan daha önemlidir.

6. İyileştirmeleri Doğrulayın ve Performans Gerilemelerini İzleyin

Her önemli değişiklikten sonra aynı testi benzer koşullarda tekrarlayın. Yalnızca Lighthouse puanını değil; yüklemeyi, etkileşimleri, görsel kararlılığı ve iş açısından temel işlevleri de kontrol edin.

Pratik bir doğrulama kontrol listesi şöyle olabilir:

1. Aynı URL’leri, cihaz profilini ve ağ koşullarını kullanarak yeniden test edin.
2. Tek bir sonuç yerine birkaç testin sonuçlarını karşılaştırın.
3. Hedeflenen isteğin veya görevin iyileştiğini doğrulayın.
4. Gezinmeyi, formları, onay mekanizmalarını, aramayı ve varsa ödeme sürecini test edin.
5. Değişiklik yayına alındıktan sonra gerçek kullanıcı sonuçlarını cihaz ve sayfa türüne göre ayrı ayrı izleyin.
6. Önemli sayfalar ve yeni yayına alınan sürümler için düzenli kontroller ekleyin.

İyileştirmeler laboratuvar testlerine hemen yansıyabilir; ancak sürekli güncellenen saha raporlarının yeni sürümü yansıtması daha uzun sürer. Canlı ortamdan daha hızlı geri bildirim almak için gizliliği gözeten gerçek kullanıcı izleme yöntemlerini değerlendirin. Veri toplama ve onay gerekliliklerini faaliyet gösterdiğiniz pazarlar açısından inceleyin.

Etkili bir web sitesi performans optimizasyonu, sürekli bir teşhis sürecidir: gözlemleyin, sorunu ayrıştırın, değiştirin ve doğrulayın. Amaç, işletmenin ihtiyaçlarından kopuk kusursuz bir puan değil, sitenizi gerçekten kullanan kişilere tutarlı biçimde daha hızlı bir deneyim sunmaktır.

Tarayıcıdaki bulguları arka uç davranışıyla ilişkilendirmek için yardıma ihtiyacınız varsa Global Web Page, performans sorunlarının teşhisi ve hedefe yönelik yazılım iyileştirmeleri konusunda destek sağlayabilir. Odaklı bir incelemeyi görüşmek için sorun yaşanan sayfaları ve belirtileri Global Web Page müşteri paneli üzerinden paylaşın.