Bak şimdi, Geçen ay, İstanbul’da küçük bir SaaS ekibiyle konuşurken aynı cümleyi üç farklı kişiden duydum: “Arayüzü toparladık, özellikleri de ekledik ama kullanıcı yine kaçıyor.” Açık konuşayım, çoğu zaman sorun tasarımda değil. Sorun, sayfanın daha kendini göstermeden insanı sinirlendirmesi. Bir saniye bile uzun geliyor. Hatta bazen yarım saniye… E peki, sonuç ne oldu? evet, o kadar ince bir çizgi.
Bhavin Sheth’in anlattığı mesele tam da buraya dokunuyor: insanlar ürününüzün ne kadar iyi olduğuna bakmadan önce onun ne kadar hızlı açıldığına bakıyor. Ben bunu ilk kez 2023’te kendi blog tarafında test ederken fark ettim; Ankara’daki bir kampanya sayfasında yükleme süresini 2,4 saniyeden 1,1 saniyeye çekince, içerik aynı kalmasına rağmen tıklama sonrası çıkışlar gözle görülür biçimde azaldı. İçerik değişmedi. Sadece hız değişti. Garip ama gerçek.
İlk İzlenim: Tasarım Değil, Tepki Süresi Kazanıyor
Bak şimdi, bir ürünün iyi görünmesi başka şey — hızlı hissettirmesi bambaşka (inanın bana). Çoğu kullanıcı “güzel ama biraz bekleyeyim” demiyor, hani öyle bir sabır yok artık. Onun yerine sessizce sekmeyi kapatıyorlar. İşin aslı şu: internet kullanıcısı sadece sabırsız değil; alternatifleri o kadar fazla ki seçici de olmak zorunda kalıyor. Yani sizin uygulamanız yavaşsa karşı tarafta başka bir sekme zaten hazır bekliyor (evet, doğru duydunuz)
Şahsen, Editör masasında bu haberi okuduğumda aklıma geçen sene test ettiğim bir iç araç geldi (bu beni çok şaşırttı). Ekim 2024’te Kadıköy’deki bir startup ofisinde dashboard’un ilk yüklenme süresi neredeyse 3 saniyeydi ve ekip “ama içerik çok zengin” diyordu. Haklılardı açıkçası; veri boldu, grafikler güzeldi, emek verilmişti — gel gelelim kullanıcı ilk grafiği görmeden çıkıyordu zaten. Kimse beklemiyordu.
Ve işler burada ilginçleşiyor.
Bunu yaşayan biri olarak söyleyeyim, Bana göre burada en can sıkıcı nokta şu: yavaşlık bazen gözle görünmüyor. Arka planda ağır kütüphaneler dönüyor olabilir, gereksiz script’ler zincir gibi uzuyor olabilir… ama kullanıcı bunların hiçbirini bilmez. O sadece bekler ve gider. Bu kadar.
Nerede Çuvallıyoruz? Ağır Sayfaların Klasik Günahları
Bu tip problemleri ben genelde dört başlıkta görüyorum: şişmiş JavaScript paketleri, geciken render, fazla üçüncü taraf servis. Aynı anda yüklenen çok sayıda varlık. Bilhassa küçük ekiplerde “bir eklenti daha ne olacak ki?” yaklaşımı bayağı yaygın oluyor, bunu çok gördüm. Sonra sayfa açılıyor gibi yapıp aslında sürünüyor.
Bir de şu var: performans sorunları tek başına büyük görünmeyebilir ama üst üste binince gerçekten can sıkıyor. Mesela hero görseli geç geliyor, buton aktifleşmesi gecikiyor ve üstüne bir de analitik script’i ana thread’i kilitliyorsa — işte orada kullanıcıyı tutmak neredeyse imkansızlaşıyor. Hepsi bir araya gelince tablo berbat.
Evet, doğru duydunuz.
Aşağıdaki tabloyu ben kendi projelerimde sık kullanıyorum; hangi sorunun neye yol açtığını görmek bazen on satırlık koddan çok daha öğretici oluyor çünkü:
| Sorun | Kullanıcıda Hissettirdiği Şey | Tipik Çözüm |
|---|---|---|
| Ağır JS bundle | “Site dondu mu?” | Kod bölme, lazy load |
| Çok fazla üçüncü taraf script | “Neden bu kadar şey yükleniyor?” | Önceliklendirme, temizleme |
| Geciken render | “Boş ekranla mı uğraşacağım?” | SSR, skeleton ekranlar |
// Basit mantık:
// Kritik olmayan her şeyi sonra yükle
// İlk ekranda sadece gerekli parçalar kalsın
// Kullanıcıya "bir şey oldu" hissini hemen ver
if (!critical) {
deferLoad(resource);
} else {
renderImmediately(resource);
}Şunu özellikle söyleyeyim: küçük startup ile enterprise ortamında problem aynı görünse de çözüm öncelikleri epey farklı oluyor. Küçük ekipte amaç çoğu zaman “ilk değer anını” hızlandırmakken kurumsal tarafta güvenlik kontrolleri. Entegrasyonlar işi ağırlaştırabiliyor (şaşırtıcı ama gerçek). Ama dürüst olayım — kurumsal projelerde bile bazen gereksiz şişkinlik öyle bir noktaya geliyor ki insan şaşırıyor, “bunu kim koydu buraya” diye soruyorsun.
Ben Olsam Ne Yapardım? Önce Gösterir, Sonra Zenginleştirirdim
Şöyle ki, Açık konuşayım, yeni özellik eklemek heyecan veriyor. İnsan ister istemez parlıyor; daha fazla buton, daha fazla kart, daha fazla otomasyon… Fakat hız konusu ertelenirse bütün o parlaklık boşa gidiyor. Kimse açılmayan aracı kullanmak istemez. Kimse.
Önce hayati yolu sadeleştirin
Kritik yol dediğimiz şey biraz evin kapısı gibi — misafir önce oradan giriyor. Eğer giriş koridorunda ayakkabı kutuları yığılmışsa kimse salona ulaşamıyor bile. Ben performans iyileştirmelerinde önce bu kısmı temizliyorum, çünkü burası açılmadan geri kalanın önemi yok: Railway İçin Internal Tool Güvenilir mi? 2026’da Cevap Bu yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
- Kullanılmayan script’leri kaldırmak
- İlk ekran için gereken CSS’i öne almak
- Büyük görselleri uygun formatta sunmak
- Ana thread’i bloklayan işleri azaltmak
- Üçüncü taraf araçları tek tek sorgulamak — ciddi fark yaratıyor
Bir arkadaşımın Berlin’deki ürünü üzerinde yaptığımız denemede yalnızca kullanılmayan iki analitik paketi kaldırarak LCP değerini ciddi biçimde düşürdük. Ürün değişmedi, tek satır yeni kod yazmadık — ama algı değişti. Kullanıcı “bu uygulama çalışıyor” demeye başladı. Bazen bu kadar basit.
Kullanıcıya erken temas verin
Bence en önemli numara şu ya da bu framework değil; kullanıcıya hemen etkileşim hissi vermek. Tüm ekran kusursuz dolmasa bile ilk aksiyon yapılabiliyorsa işler değişiyor — bunu deneyimledim. Mesela arama kutusu hazır olsun, temel liste — en azından ben öyle düşünüyorum — gelsin ya da iskelet ekranlar boşluğu doldursun. Bunlar küçük detay gibi duruyor ama etkisi gerçekten büyük. Daha fazla bilgi için Flutter 3.x Mülakatı: Yeni Özellikler ve Hızlı Sorular yazımıza bakabilirsiniz.
Hız bir özellik değil; ürünün size verdiği ilk söz.
Ve o söz tutulmazsa geri dönüş yok denecek kadar az.
Küçük Ekipte Başka Çare Yok, Büyük Yapıda İse Bahane Çok
Küçük startup’larda genelde iki kişi hem frontend’i hem analitiği hem de landing page optimize etmeunu taşıyor — haliyle performans borcu kolay büyüyor, farkında bile olmadan. Burada yapılacak en akıllıca şey her yeni özelliğin maliyetini peşinen sormak bence. “Bu gerçekten gerekli mi?” sorusu bazen sprint planlamasından çok daha değerli oluyor. Ciddiyim.
Küçük startup için pratik yaklaşım
Eğer ürününüz yeni çıkıyorsa hız doğrudan büyümeye bağlıdır diyebilirim. İlk gelen kullanıcıların sabrı kısa; onlar hata bulmaya değil çözüm bulmaya geliyorlar. Şans yok.
- MVP’de yalnızca ana akışı tutun; — ciddi fark yaratıyor
- Gereksiz animasyonları erteleyin; — ciddi fark yaratıyor
- Tema paketlerini ve ikon setlerini hafif tutun;
- Ölçmeden hiçbir şeyi “iyi” sanmayın.
Enterprise seviyede durum neden karışıyor?
Büyük yapılarda ise hikaye biraz farklı; onay süreçleri uzun olduğu için her değişiklik kolayca uygulanamıyor ve herkes sorumluluğu başkasına atıyor. Tanıdık geldi mi? Bana çok tanıdık geldi.
- Sahiplik net olmalı;
- Performans bütçesi belirlenmeli;
- Her ekip kendi yüklediği bağımlılıktan sorumlu olmalı;
- Dış servislerin etkisi düzenli ölçülmeli.
Açıkçası, Neyse uzatmayalım; benim gördüğüm en sağlam yaklaşım hep şu oldu — önce ölçmek, sonra budamak, sonra tekrar ölçmek (ben de ilk duyduğumda şaşırmıştım). Çünkü tahmin ederek iyileştirme yapmak bir düşüneyim… çoğu zaman kumar oynamak gibi. Ve genelde kaybediyorsunuz.
Neyi Feda Ettim? Ve Neyi Kazandım?
Şöyle ki, Bazen hayal kırıklığı da gerekiyor açıkçası. Her şeyi koruyarak hızlanamazsınız, bu mümkün değil (ben de ilk duyduğumda şaşırmıştım). Bir proje üzerinde bunu acı şekilde yaşadım; — en azından ben öyle düşünüyorum — Mart 2024’te İzmir’de yaptığım bir demo sırasında video arka planını kaldırınca tasarımcı arkadaş pek mutlu olmadı — anlıyorum, emek vermişti —. Dönüşüm oranı yükseldi. Görsel gösteriş biraz azaldı. Kullanım arttı. İşte ikilem tam burada başlıyor: estetik mi, akış mı? Çoğu durumda ikisi birlikte yürüyebilir ama bazen biri diğerine alan açmak zorunda kalıyor, bu gerçeği kabullenmek lazım. Bu konuyla ilgili Rockstar Games gerçekten hacklendi mi? İşin aslı biraz daha karmaşık yazımıza da göz atmanızı tavsiye ederim. Rate Limiting Deep Dive: Token Bucket, Leaky Bucket ve Sliding Window yazımızda da bu konuya değinmiştik. HTTP Durum Kodları: 36 Kodu Tek Ekranda Topladım yazımızda da bu konuya değinmiştik.
Kendi deneyimimden konuşuyorum, Bir de şunu söyleyeyim: performans iyileştirmeu yalnızca teknik borcu azaltmıyor. Ekibin karar alma şeklini de düzeltiyor — daha az bağımlılık, daha az karmaşa, daha az sürpriz. Bir süre sonra toplantılar bile kısalıyor. İnanması zor ama oluyor, ben yaşadım.
Dengeyi nasıl kurarsınız?
- Kritik olmayan öğeleri sonradan yükleyin;
- Hero alanını hafif tutun;
- A/B testlerinde hız metriğini ayrı izleyin;
- Kampanya dönemlerinde üçüncü taraf script listesini gözden geçirin.
Aslında, Bazı günler gerçekten durup düşünüyorum: “Bu widget’a ihtiyaç var mı?” Cevap hayırsa — sil gitsin. Hani böyle sert söyleyince kaba duruyor ama pratikte kurtarıcı oluyor. Gerçekten.
Saatlerce Tasarlayıp Bir Saniyeyi Kaçırmayın
Bazıları ürünü “tamamlanmış” sanıyor. Renkler güzel olmuş, animasyonlar pürüzsüz çalışıyor, her piksel yerli yerinde duruyor (ki bu çoğu kişinin gözünden kaçıyor). Hmm. Ben sahada şunu gördüm: yükleme süresi kötü olan uygulama, iyi fikir olsa bile ikinci plana düşüyor. Kullanıcı size kredi vermiyor; önce kanıt istiyor. Sonra belki sever.
Bu yüzden performansı son adım gibi görmek bana hep yanlış geldi. Aslında başlangıç noktası olmalıydı. Bence bugün bir ürün geliştiriyorsanız şu soruyu masanın ortasına koymanız lazım: “İnsan bu sayfayı beklemeden kullanabilir mi?” Eğer cevap net değilse — orası hala eksiktir.
Bir de şöyle düşünün: hızlı çalışan ürünler güven veriyor. Yavaş olanlar ise sanki sürekli özür diliyor gibi hissettiriyor kullanıcıya. Ve özür dileyen yazılımın ömrü pek uzun olmuyor. Maalesef.
Sıkça Sorulan Sorular
Kullanıcılar kaç saniye içinde siteyi terk eder?
Buna tek sayı vermek zor çünkü sektör ve beklenti değişiyor ama pratikte ilk saniyeler çok can alıcı oluyor.
Sayfa boş kalıyorsa veya etkileşim gecikiyorsa kullanıcı hızlıca çıkabiliyor.
LCP ve CLS gerçekten bu kadar önemli mi?
Evet, çünkü bunlar kullanıcının gördüğü deneyimi doğrudan anlatıyor.
Kağıt üstünde güzel görünen bir site kötü LCP ile hantallaşabiliyor.
Küçük ekiplerde hız optimizasyonuna nereden başlanır?
Şöyle ki, En kolay kazanç genelde gereksiz script’leri temizlemekten gelir.
Sonra görselleri hafifletmek ve kritik CSS’i öne almak iyi çalışır.
Sadece frontend iyileştirmesi yeter mi?
Çoğu zaman yetmez.
Backend yanıt süresi de kötüyse frontend ne kadar cilalı olsa da etki sınırlı kalır.
Kaynaklar ve İleri Okuma
Web.dev — Why speed matters for user experience
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
