Web Uygulaması Performans Rehberi ile Hız Kazanın

Bir kullanıcı teklif ekranınızın açılmasını üç saniye beklediğinde, yalnızca birkaç saniye kaybetmezsiniz. Satış ekibinin oluşturduğu talep, pazarlama bütçesi ve ürün geliştirme emeği aynı anda risk altına girer. Bu web uygulaması performans rehberi, hızı salt teknik bir skor olarak değil; dönüşüm, operasyonel verimlilik ve ölçeklenme kapasitesi olarak ele alır.

Performans sorunu çoğu zaman tek bir nedene bağlı değildir. Ağır bir arayüz paketi, verimsiz SQL sorgusu, seri çalışan servis çağrıları veya yoğun saatlerde yetersiz kuyruk yönetimi tek başına tolere edilebilir görünür. Birlikte çalıştıklarında ise kullanıcıya yavaş, güven vermeyen ve hata üretmeye yatkın bir ürün deneyimi sunarlar. Doğru yaklaşım, önce ölçmek, sonra en yüksek ticari etkisi olan darboğazı çözmektir.

Önce Hedefi Tanımlayın

Her uygulama için “hızlı” aynı anlama gelmez. Bir e-ticaret akışında ürün listeleme ve ödeme adımlarındaki gecikme doğrudan geliri etkiler. Bir B2B operasyon panelinde ise yüzlerce kaydın filtrelenmesi, dışa aktarım işlemleri ve yetkilendirme kontrolleri daha kritik olabilir. Rapor üreten bir ekranda kullanıcı sonucun birkaç saniye sürmesini kabul edebilir; ancak ilerleme durumunu görememeyi kabul etmez.

Bu nedenle çalışmaya teknik hedeflerle değil, iş açısından kritik kullanıcı yolculuklarıyla başlayın. Örneğin bir ziyaretçinin demo talebi oluşturması, saha ekibinin müşteri kaydına ulaşması ya da finans ekibinin günlük raporu üretmesi. Her yolculuk için kabul edilebilir yanıt süresini, hata oranını ve yoğun trafik altındaki davranışı belirleyin.

Tek bir ortalama yanıt süresi yeterli değildir. Ortalama, birkaç çok yavaş isteği saklayabilir. P95 ve P99 gibi yüzdelik değerler, kullanıcıların en kötü deneyimlerinin nerede oluştuğunu daha gerçekçi biçimde gösterir. Başlangıç ölçümünün nasıl yapılacağını Eski Web Sitesini Yenileme ile Büyümeyi Hızlandırın yazımızda, yavaş bir sayfanın nasıl sessiz bir iş kaybına dönüştüğünü ise Görünmeyen Kayıp yazımızda anlattık. Yönetim için hedef basit olmalıdır: Kritik işlemler öngörülebilir sürede tamamlanmalı, trafik arttığında maliyet ve gecikme kontrol dışına çıkmamalıdır.

İzlenecek Temel Göstergeler

Performans panosunda onlarca grafik bulunabilir, ancak karar vermeyi kolaylaştıran birkaç gösterge vardır.

Largest Contentful Paint. İlk anlamlı ekran içeriğinin kullanıcıya ne zaman ulaştığını gösterir.

Interaction to Next Paint. Tıklama ve giriş gibi etkileşimlere arayüzün ne kadar hızlı tepki verdiğini ölçer.

API gecikmesinin P95 ve P99 değerleri. Nadir ama maliyetli yavaşlamaları görünür kılar.

Hata oranı, zaman aşımı ve başarısız arka plan işi sayısı. Performansın güvenilirlikle ilişkisini ortaya koyar.

Bu göstergeleri müşteri segmenti, ülke, cihaz türü ve uygulama sürümüne göre ayırmak gerekir. DACH bölgesindeki bir kullanıcının deneyimi ile Türkiye'deki mobil ağ üzerinden bağlanan bir kullanıcının deneyimi aynı olmayabilir. Coğrafi farkı yalnızca CDN ayarıyla açıklamak da yanıltıcıdır; üçüncü taraf servislerin bölgesel yanıt süreleri ve veri işleme mimarisi de sonucu etkiler.

Tarayıcıda Hissedilen Hız: Ön Yüz Bütçesi Oluşturun

Kullanıcının algıladığı hız, sunucunun yanıt süresinden daha geniş bir konudur. Tarayıcı JavaScript paketlerini indirmeli, ayrıştırmalı, arayüzü çizmelidir. Büyük görseller, gereksiz yazı tipleri ve ilk ekranda ihtiyaç duyulmayan bileşenler, güçlü bir backend'e rağmen deneyimi yavaşlatabilir.

İlk adım, her kritik sayfa için bir performans bütçesi belirlemektir. Bu bütçe ilk yüklemede indirilen JavaScript miktarı, görsel boyutu, istek sayısı ve hedef yükleme süresi gibi sınırlar içerir. Bütçe ihlali, kod inceleme sürecinde kalite sorunu olarak değerlendirilmelidir. Böylece performans, lansman öncesindeki acele testlere bırakılmaz.

Kod bölme ve gecikmeli yükleme burada etkili araçlardır. Yönetim panelindeki gelişmiş raporlama modülünü, kullanıcı giriş yaptığı anda yüklemek zorunda değilsiniz. Ancak her bileşeni gecikmeli yüklemek de çözüm değildir. Kullanıcının hemen tıklayacağı bir alan sonradan yüklenirse, teknik olarak daha küçük paket elde ederken algılanan hızı düşürebilirsiniz. Karar, gerçek kullanım verisine göre verilmelidir.

Görsellerde doğru format, boyutlandırma ve önceliklendirme önem taşır. Arayüzdeki en büyük görsel öğeyi erken yüklemek faydalıdır; ekranın altındaki medya içeriğini ise ertelemek çoğu senaryoda daha doğrudur. Dinamik tablolar ve uzun listelerde sanallaştırma kullanmak da tarayıcının binlerce satırı aynı anda çizmesini önler.

API Katmanında Gereksiz Beklemeyi Kaldırın

Bir kullanıcı ekranı açtığında uygulamanın beş farklı servisi sırayla çağırması, sık görülen bir mimari borçtur. Kimlik doğrulama, müşteri verisi, izinler, bildirimler ve öneriler birbirini gereksiz biçimde bekliyorsa toplam gecikme büyür. Bağımsız çağrılar mümkün olduğunda paralel yürütülmeli, kritik olmayan bilgi ise ekran etkileşime hazır olduktan sonra yüklenmelidir.

API tasarımı, istemcinin ihtiyacı kadar veri döndürmelidir. Sık kullanılan bir liste ekranına tüm ilişkili nesneleri göndermek hem ağ maliyetini hem de veritabanı yükünü artırır. Alan seçimi, sayfalama, filtreleme ve sunucu tarafı sıralama bu nedenle yalnızca teknik ayrıntılar değildir. Bunlar, büyüyen veri hacminde uygulamanın öngörülebilir kalmasını sağlar.

Önbellekleme de güçlü fakat dikkat isteyen bir araçtır. Değişme sıklığı düşük ürün katalogları, referans veriler ve yetki tanımları için önbellek gecikmeyi ciddi biçimde azaltabilir. Buna karşılık bakiye, stok veya anlık fiyat gibi verilerde eski bilgi göstermek ticari zarara yol açabilir. Önbellek stratejisi için her veri türünün tazelik beklentisi açıkça tanımlanmalıdır.

Dış servis bağımlılıkları için zaman aşımı, tekrar deneme ve devre kesici politikaları uygulanmalıdır. Sonsuz bekleyen bir ödeme, e-posta veya harita sağlayıcısı çağrısı, uygulamanın kendi kaynaklarını tüketebilir. Tekrar denemeler de kontrollü yapılmalıdır; aynı başarısız isteği anında yüzlerce kez göndermek sorunu büyütür. Servisler arası entegrasyonun planlanmasını İşletmeler için API Entegrasyonu Nasıl Planlanır? yazımızda ele aldık.

Veritabanı Performansı: Sorguyu Değil, Erişim Biçimini İnceleyin

Veritabanı sorunlarının önemli bölümü işlemci gücü eksikliğinden değil, yanlış erişim desenlerinden kaynaklanır. İndekssiz filtreler, her satır için tekrar çalışan sorgular ve gereğinden geniş sonuç kümeleri, veri büyüdükçe maliyeti katlar. Geliştirme ortamındaki birkaç bin kayıt üzerinde hızlı görünen ekran, üretimde yüz binlerce kayda ulaştığında beklenmedik biçimde yavaşlayabilir.

Sorgu planlarını incelemek, optimizasyonun başlangıç noktasıdır. Hangi filtrelerin kullanıldığı, tam tablo taramasının nerede gerçekleştiği ve birleştirmelerin maliyeti görünmeden yapılan indeks eklemeleri tahmine dönüşür. Her indeksi eklemek de doğru değildir; indeksler okuma işlemlerini hızlandırırken yazma maliyetini ve depolama ihtiyacını artırabilir.

N+1 sorgu problemi özellikle ORM kullanılan uygulamalarda yaygındır. Bir müşteri listesi çekilir, ardından her müşteri için sipariş veya iletişim kaydı ayrı ayrı sorgulanır. Çözüm, ilişkileri bilinçli biçimde önceden yüklemek, gerekli veriyi toplu getirmek veya ekranın ihtiyaç duyduğu özet veriyi ayrı bir sorguda üretmektir.

Ağır raporlar ile operasyonel işlemleri aynı kaynaklar üzerinde çalıştırmak da risklidir. Gün sonu analizi, dosya üretimi veya toplu belge işleme gibi işler kuyruklara alınabilir. Kullanıcıya işin alındığı bilgisi hemen verilir, sonuç hazır olduğunda bildirim yapılır. Bu model hem ekranı bloklamaz hem de kaynak kullanımını yoğun saatlerin dışına yayma olanağı sağlar.

Ölçeklenme, Yalnızca Daha Fazla Sunucu Eklemek Değildir

Yatay ölçekleme, doğru tasarlanmış uygulamalarda değerli bir seçenektir; ancak durum bilgisinin sunucu belleğinde tutulduğu, dosyaların yerel diskte saklandığı veya arka plan işlerinin izlenmediği yapılarda yeni sunucu eklemek yeni hatalar yaratabilir. Oturum yönetimi, paylaşımlı önbellek, dosya depolama ve kuyruk altyapısı birlikte düşünülmelidir. Mimari düzeydeki tercihleri Mikroservis Monolit Mimari Karşılaştırması yazımızda ele aldık.

Yoğun kampanya, aylık raporlama dönemi veya yeni ürün lansmanı öncesinde yük testi yapmak gerekir. Test, yalnızca kaç eşzamanlı kullanıcıya ulaşıldığını ölçmemelidir. Gerçekçi kullanıcı davranışları, giriş, arama, kayıt oluşturma, dosya yükleme ve rapor alma gibi karışık senaryolar içermelidir. Ayrıca sistem sınırı aşıldığında nasıl davrandığı da test edilmelidir: Hızlı ve anlaşılır hata mı veriyor, yoksa tüm uygulamayı mı kilitliyor?

Maliyet tarafı da performans kararının parçasıdır. Her sorgu için çok agresif önbellek, her sayfa için yüksek kapasiteli altyapı veya nadir kullanılan raporlar için sürekli çalışan kaynaklar bütçeyi şişirebilir. En iyi mimari, en yüksek teknik kapasiteyi değil; hedeflenen kullanıcı deneyimini makul ve ölçülebilir birim maliyetle sağlayan mimaridir.

Performansı Sürekli Bir Ürün Disiplini Haline Getirin

Lansman günü yapılan tek seferlik optimizasyon zamanla etkisini kaybeder: Yeni özellikler, analitik etiketleri, üçüncü taraf bileşenler ve büyüyen veri hacmi uygulamayı yeniden yavaşlatır. Sürüm öncesi performans kontrollerini, gerçek kullanıcı izlemeyi ve düzenli kapasite değerlendirmesini teslimat sürecinin parçası yapın; bu işletme disiplinini Canlıya Alındıktan Sonra: Yapay Zeka Sistemleri Neden Sessizce Değer Kaybeder? yazımızda ayrıntılı ele aldık; ilkeler yalnızca yapay zeka sistemleri için değil, her canlı uygulama için geçerlidir.

İçerik ağırlıklı sitelerde performansın en sık kaybolduğu yer eklenti ve tema yüküdür. Hazır sistem ile özel çözüm arasındaki dengeyi WordPress mi, Özel Geliştirilmiş Web Sitesi mi? Kurumsal Karar Rehberi yazımızda ele aldık.

Bir sonraki iyileştirme toplantısında ekibinize yalnızca “Uygulama yavaş mı?” diye sormayın. “Hangi kullanıcı, hangi kritik işlemi, hangi koşulda bekliyor ve bunun iş maliyeti nedir?” sorusuyla başlayın. Doğru cevap, yatırım önceliğinizi teknik varsayımlardan değil, ölçülebilir etkiden kuracaktır.

Uygulamanızın hangi noktada yavaşladığını ve bunun size neye mal olduğunu birlikte ölçmek isterseniz, projenizi bize anlatın.