Web Siteniz Neden Yavaşlıyor?

Kupa elinde, ekranın ışığı yüzüne vuruyor. Tıklıyorsun.
Bekliyorsun.
Sonra yine… bekliyorsun.

O sırada aklın başka yerlere kayıyor; belki de aynı anda potansiyel ziyaretçi çoktan başka bir siteye yöneldi bile. Web Siteniz Neden Yavaşlıyor? sorusu, zihninin içinde yankılanıyor.

Hız, kalabalık bir yolda yeşil ışığı beklerken yanındaki bisikletlinin senden önce geçmesi gibi; küçük bir ayrıntı ama hissi ağır. TÜİK verilerine göre kullanıcıların yüzde 53’ü, üç saniyeden uzun sürede açılan sayfaları terk ediyor. Üç saniye… bir nefes alıp vermek kadar kısa. Fakat işte o kısacık anda, hikâyen eksik kalıyor.

Bazen sorun, ufukta duran dev bir dağ gibi açıkça görülür; bazen ise ayağındaki küçücük bir taşın farkına bile varmazsın. Belki yanıt vermekte ağır kalan sunucu, belki de sayfa boyunca dolaşan ağır görseller… Sebep her ne olursa olsun, cevap aradığın soru aynı: Web Siteniz Neden Yavaşlıyor?

Ve bu cevabın, düşündüğünden çok daha fazla katmanı var. Hem teknik hem insani hem gözle görülür hem görünmeyen. Hazırsan, adım adım bu izleri birlikte takip edelim…

Web Sitenizin Hızını Anlamanın İlk Adımı: Ölçmek

Bazen bir şeyin neden ağırdan aldığını anlamak için önce ona ayna tutmak gerekir.
Tıpkı sabah uyandığında yüzündeki ifadeyi fark etmen gibi; belki göz altındaki yorgunluk, belki saçının başının dağınıklığı sana dünün izlerini gösterir. Web siteleri de öyle. Önce ölçersin, sonra sorunun izini sürersin.

Hızınızı ölçün: PageSpeed / CrUX / WebPageTest kısa rehberi

Google’ın PageSpeed Insights’ı, sana sadece rakamlar vermez; o rakamların ardında, ziyaretçilerin deneyimini fısıldayan ipuçları vardır. CrUX (Chrome User Experience Report), gerçek kullanıcıların tarayıcılarından gelen verilerle, sitenin kalabalık bir cadde mi yoksa tenha bir patika mı olduğunu gösterir. WebPageTest ise işin dedektifidir; her sayfanın yüklenme anını kare kare yakalayan, perde arkasındaki bütün sahneleri kayda alan bir kameraman gibi.

• PageSpeed ile mobil ve masaüstü hızını ayrı ayrı gör.
• CrUX ile gerçek kullanıcı verilerini incele.
• WebPageTest ile yüklenme sürecini kare kare izle.

Bu araçların hepsi sana “nerede” sorusunun cevabını verir. “Neden?” kısmı ise bir sonraki adımda saklıdır.

En büyük yavaşlatıcıyı bulun: LCP / TTFB / JS ağırlığı

Bir ormanda yürürken ayağına takılan dalı bulmak için önce etrafına bakarsın. Sitede de en büyük yavaşlatıcıyı bulmak için LCP (Largest Contentful Paint), TTFB (Time To First Byte) ve JavaScript yükünü incelemek gerekir.

• LCP, ziyaretçinin gördüğü en büyük içeriğin ekrana ne zaman geldiğini söyler. Geç kalıyorsa, ilk izlenim çoktan bozulmuştur.
• TTFB, sunucunun ilk yanıtı vermek için ne kadar beklettiğini gösterir. Burada uzayan her milisaniye, merakın yerini sabırsızlığa bırakır.
• JavaScript ağırlığı, sayfanın omuzlarına binen yükün ta kendisidir. Fazla yük, en çevik koşucuyu bile yavaşlatır.

Belki de asıl mesele bu üçünden biridir; belki de hepsinin sessizce üst üste binmiş etkisidir.
Önemli olan, hikâyenin nerede tökezlediğini görmek…
Çünkü gördüğün an, çözüm için ilk adımı zaten atmış olursun.

Sunucu & Barındırma (TTFB, konum, kapasite)

Bir şehirde yaşıyorsun, evin şehrin ucunda; işe gitmek için önce dar bir sokaktan, sonra yarım yamalak asfaltlı bir yoldan geçiyorsun. Her viraj, her çukur seni birkaç saniye daha oyalar. İşte sunucu da siten için böyle bir mahalle olabilir: adresin var, kapın açık ama oraya ulaşmak bir sabır testi.

TTFB (Time To First Byte) dediğimiz şey, kapının tokmağına dokunduktan sonra içeriden “kim o?” sesinin gelme süresi gibidir. Kimi evlerde hemen açılır kapı, kiminde önce terlikler giyilir, televizyon sesi kısılır… O aradaki fark, ziyaretçini ya güler yüzle karşılar ya da kapı önünde üşütür.

Paylaşımlı → VPS → Bulut: ne zaman yükseltmeli?

Paylaşımlı hosting, apartman dairesi gibidir; maliyeti düşüktür ama komşuların gürültüsü, sıcak suyun birden kesilmesi, asansörün arada bozulması olağandır.
VPS, kendi dairenin kapısını kilitleyebildiğin ama hâlâ ortak koridorları kullandığın bir modeldir; biraz daha konfor, biraz daha özgürlük.
Bulut ise, istediğinde genişleyebilen bir ev gibidir; misafir geldiğinde salon büyür, kışın küçük bir odaya çekilirsin.

• Trafiğin artıyorsa, sayfaların sık sık yavaşlıyorsa veya TTFB ölçümünde süre 600 ms’yi aşıyorsa yükseltme zamanın gelmiş olabilir.
• Bir de kampanya ya da özel günlerde site trafiğin ani sıçramalar yapıyorsa, bulutun esnek yapısı seni yarı yolda bırakmaz.

Edge / CDN ve coğrafi gecikme

Bazen sorun evin içinde değil, yolun uzunluğundadır. Ziyaretçin Avustralya’dan bağlanıyor ama senin sunucun Frankfurt’ta… Her paket, okyanusu iki kere geçmek zorunda kalıyor. İşte Content Delivery Network (CDN) bu noktada devreye girer; dünyanın dört bir yanında ufak “evcikler” kurarak, ziyaretçine en yakın noktadan cevap verir.

• Edge sunucular, tıpkı köşe başındaki bakkal gibi, ihtiyacını anında karşılar.
• Coğrafi gecikmeyi azaltmak, ziyaretçine fiziksel olarak yaklaşmaktır; bazen bir kıtanın yükünü yalnızca birkaç milisaniyeye indirir.

Sunucu seçimi, yalnızca teknik bir karar olmaz; biraz da evini hangi semtte kurduğun, misafirini kapıda ne kadar bekletmeyi tercih ettiğinle ilgilidir. Ve bazen, doğru mahalle, tüm hikâyenin akışını değiştirir.

Ön uç ağırlığı (görseller, CSS/JS, fontlar)

Bir market poşeti düşün: eve girerken “hepsini tek seferde taşıyacağım” inadıyla parmaklarını ince plastikle kesersin ya… Ön uç da bazen öyle şişer; görseller, fontlar, CSS ve JS dosyaları birikince, sayfa kapıda nefes nefese kalır. Oysa mesele, poşetleri akıllıca bölüştürmekte. Hangisi hemen içeri, hangisi sonra? Hangisi hafifletilebilir? Küçük kararlar, büyük ferahlık…

WebP + lazy-load + aspect-ratio

Görsel, hikâyenin vitrini. Fakat vitrin camını kalınlaştırdıkça içerisi geç görünür.
“Az olan yeterlidir,” der gibi Italo Calvino, kulağa fısıldar.

1. WebP seçimi:
   • Aynı sahneyi daha küçük dosyayla anlatır; kalite hissini korur, ağırlığı azaltır.
   • Fotoğraf ağırlıklı alanlarda JPEG → WebP, grafik/ikon tarafında PNG/SVG → WebP/SVG dönüşümleri sihirli bir %20–40 rahatlama sağlayabilir.
2. Lazy-load pratiği:
   • Ekranda görünmeyen görselleri beklemeye al; ziyaretçi aşağı kaydıkça çağır.
   • İlk anda görünen kahraman kareleri hemen, geri kalanını yeri gelince… Tıpkı çay demlemek gibi: önce suyu ısıt, çayı yavaşça bırak.
3. Aspect-ratio ile yer tutucu:
   • Görüntünün kaplayacağı alanı önceden ayarla ki metinler hop oturup hop kalkmasın; sayfa dans ederken okurun gözü sabit bir ritim bulsun.
   • Yan yana kartlar, blog kapakları, ürün fotoğrafları… Hepsi için “yer ayırtma” sakinlik getirir.

Kısa bir kontrol listesi:

• Görsel sayısını azalt: Aynı hikâyeyi daha az kareyle anlatabilir misin?
• Boyutlandır: 1200 px gösterdiğin şeyi 4000 px taşımak… hani kamyonla manava gitmek gibi.
• Sıkıştır: Görsel optimizasyon araçlarıyla son bir tur.
• Critical görselleri önceliklendir: preload ile kahramanı sahneye erken al.

“Sadelik karmaşıklıktan daha zordur.” Leonardo da Vinci

Render-blocking JS/CSS’yi azaltma

Bir tiyatro düşün: sahne hazır, perde kalkacak… ama sahne amiri perde ipini tutmuş, “bir dakika” diyor; kostüm ayrıntıları, dekorun son cilası, sahne arkasında minik bir keşmekeş. Render-blocking kaynaklar tam olarak bu “bir dakika”dır; perdeyi gereksiz yere tutan, giriş sahnesinin parıltısını geciktiren dosyalar.

Peki perde nasıl kalkar, izleyici ilk sahneyi hızlıca nasıl görür?

• • Kritik CSS’yi öne al:
    Katman 1: görünür alan için küçük, “kritik” bir CSS demeti.
    Katman 2: geri kalan stilleri media veya preload + onload ile sonradan akıt.
  • JS’yi terbiye et:
    • defer ile betikleri DOM hazır olunca çalıştır;
    • async ile dış kaynakları bağımsız koştur;
    • İlk ekranda işe yaramayan kodları sayfanın altına gönder.
  • Ağır paketleri parçalara böl:
    Modüler düşün; “alışveriş sepeti” sayfasında gereken kodu ana sayfaya yüklemeye ne gerek var?
  • Üçüncü taraf (3P) script diyeti:
    Analitik, sohbet balonu, reklam etiketi… Hepsi misafir. Misafiri seversin ama evin koridorunu kaplamasına izin vermezsin.
  • Öncelik ipuçları:
    rel=preconnect, dns-prefetch, preload… Tarayıcıya nazikçe “şuraya bir göz at” demenin yolları.

Site mimarisi (eklentiler, yönlendirmeler, 3P scriptler)

Bir bina düşün; temeli sağlam ama yıllar içinde balkonlara, çatının altına, merdiven boşluğuna türlü ekler yapılmış. Kimisi lazım olmuş, kimisi “dursun, belki işe yarar” denmiş. Sonra bir bakmışsın, binanın içinde dolaşmak bir labirente dönmüş. Site mimarisi de böyle; eklediğin her eklenti, yönlendirme ya da dış kaynak, yapının nefesini biraz daha kısar.

Ve bazen yavaşlık, görkemli bir sorundan değil, bu küçük ama çok sayıdaki “ek”lerden gelir.

Eklenti diyeti: ölç, kaldır, izole et

Eklentiler, sitenin mutfağındaki baharat kavanozları gibidir. Hepsi ayrı tat katar ama fazlası yemeğin özünü gölgeler.

• Ölç: Hangi eklentiler en çok yük bindiriyor? Basit bir performans raporu bile hangilerinin “ağır misafir” olduğunu ortaya çıkarır.
• Kaldır: Ayda bir bile kullanmadığın, hatta varlığını unuttuğun eklentiler varsa vedalaş. Kod, kullanılmadığında romantik bir hatıra değil, hantallık yaratır.
• İzole et: Mecbur olduğun ağır eklentileri, sadece gerektiği sayfalarda çalışacak şekilde sınırla. Bir yemek sosu, tatlıya bulaşmaz; kod da bulaşmamalı.

Küçük bir not: Her yeni eklenti hem satır sayısını hem de potansiyel çakışmaları artırır. Fazlalıkları atmak, bazen bir diyetten daha hızlı sonuç verir.

Yönlendirme zincirlerini kesmek

Bir adres sorarsın, “Şu köşeden dön, oradan şu sokağa sap, sonra bir daha sorarsın” derler. Her yönlendirme de böyle; bir ziyaretçi geldiğinde, “Asıl yer şurada” demek için onu birkaç duraktan geçirirsen, sabır testini başlatmış olursun.

• Harita çıkar: Site içindeki tüm yönlendirmeleri tarayan bir araçla zincirleri gör.
• Kısalt: Gereksiz yönlendirmeleri sil, kalanları en kısa yoldan hedefe ulaştır.
• Tek adım kuralı: Bir içerikten diğerine geçiş en fazla bir adım olmalı.

Google’ın botları da ziyaretçilerin sabrı da uzun yolları sevmez.
Yönlendirme zincirlerini kestikçe, site içindeki yollar düzleşir; tıpkı şehirde tek bir köprüyle iki yakayı birleştirmek gibi.

Belki de hız, büyük sıçramalardan çok, bu küçük kestirmelerden doğar… Ve en sonunda, site kendi nefesini yeniden bulur.

Önbellekleme & CDN stratejisi

Bazı hikâyeler bir kez dinlendiğinde zihne kazınır; bir dahaki gelişinde baştan anlatmaya gerek kalmaz. Önbellekleme de böyledir: tarayıcıya ya da ağın kenarındaki sunucuya, “Bak, bunu zaten biliyorsun” demenin teknik versiyonu. Böylece aynı sahne tekrar tekrar kurulmaz, sayfa gereksiz yere taşınmaz.

Tarayıcı / edge cache politikaları

Tarayıcı önbelleği, ziyaretçinle aranda kurulan küçük bir anlaşmadır: “Gördüğün şu görseli, şu CSS’i, şu fontu bir süre sakla, ben de sana tekrar göndermeyeyim.”

• Cache-Control başlıkları: max-age, s-maxage ve immutable parametreleriyle dosyaların “raf ömrünü” belirle.
• ETag & Last-Modified: Tarayıcıya, dosyanın değişip değişmediğini soran zarif bir protokol. Değişmediyse, yeni yükleme yapılmaz.
• Edge cache: CDN üzerindeki kenar sunucular, içerikleri ziyaretçiye en yakın noktada saklar. Bir marketin en taze meyvesini en öndeki rafa koyması gibi; ne kadar yakın, o kadar hızlı.

Buradaki amaç, her ziyaretçiye baştan taş taşımak yerine, yolu kısaltmak ve yükü hafifletmek.

Dinamik sayfalarda cache taktikleri (ESI, varyantlar)

Statik bir sayfayı saklamak kolaydır; dinamik sayfalar ise, her seferinde yeniden pişen taze yemek gibidir. Ama akıllı taktiklerle burada da hız kazanılır.

• Edge Side Includes (ESI): Sayfayı küçük parçalar hâlinde cache’leyip sadece değişen kısımları taze çekmek. Bir romanı baştan yazmak yerine sadece yeni eklenen paragrafı eklemek gibi.
• Varyant cache: Kullanıcının cihaz tipine, diline ya da konumuna göre farklı versiyonları saklamak. Böylece her profile en uygun ve en hızlı sayfa sunulur.
• Fragment caching: Dinamik sayfanın sadece “statikleşebilecek” kısımlarını saklamak; örneğin header, footer, menü gibi bölümler.

Bir cache stratejisi, sitenin belleğini düzenlemek gibidir. Gereksiz hatıraları atmazsın, ama her şeyi baştan hatırlamaya da çalışmazsın.
Sonunda, ziyaretçi geldiğinde hikâye kaldığı yerden, hiç ara vermemiş gibi devam eder.

Hızlı ve Etkili Bir Web Sitesi İçin İlk Adımınızı Atın

Dijital dünyada hız, doğru strateji ve güçlü bir marka dili her zamankinden daha kritik. Bu yazıda paylaştığımız bilgiler, umuyoruz ki size faydalı olmuştur. Eğer web performansınızı artırmaya yönelik adımları derinleştirmek isterseniz, “Hızlı Web Siteleri İçin Optimizasyon İpuçları” ve “Hosting Seçiminde Dikkat Edilecek 7 Kritik Faktör” başlıklı içeriklerimizi mutlaka inceleyin; her ikisi de rekabette öne geçmenizi sağlayacak pratik ve uygulanabilir bilgiler sunuyor.

İşinizi bir adım öteye taşımak için şimdi harekete geçin.

Sıkça Sorulan Sorular

Web sitesi hızımı artırmak SEO sıralamamı ne kadar etkiler?

Arama motorları, özellikle Google, sayfa hızını sıralama faktörlerinden biri olarak kullanır. Hızlı yüklenen sayfalar, hem tarayıcı botları tarafından daha kolay taranır hem de kullanıcıların sitede daha uzun süre kalmasını sağlar. Örneğin, bir e-ticaret sitesinde saniyelik bir hız artışı bile dönüşüm oranlarını doğrudan yükseltebilir. SEO’da teknik optimizasyon ile kullanıcı deneyimini birlikte ele almak, uzun vadede daha istikrarlı bir görünürlük sağlar.

Hız optimizasyonu için üçüncü taraf hizmet sağlayıcılarla çalışmak gerekli midir?

Küçük ölçekli iyileştirmeler temel bilgi ve araçlarla yapılabilir; ancak kapsamlı optimizasyon için deneyimli bir ekiple çalışmak süreci hızlandırır ve daha kalıcı sonuçlar getirir. Profesyonel hizmet sağlayıcılar, yalnızca hız ölçümü yapmaz; kod optimizasyonu, sunucu yapılandırması ve kullanıcı davranış analizini de bütüncül olarak ele alır. Bu sayede “deneme-yanılma” sürecinden tasarruf edilir ve bütçe daha verimli kullanılır.

Mobil cihazlar için hız optimizasyonu neden ayrı bir önem taşır?

TÜİK verilerine göre internet kullanıcılarının büyük kısmı mobil cihazlar üzerinden erişim sağlıyor. Mobilde yavaş açılan bir site, masaüstünde iyi performans verse bile kullanıcı kaybına yol açabilir. Mobil optimizasyon, hızın yanı sıra dokunmatik ekran uyumu, görsel ölçekleme ve veri tüketimi gibi ek faktörleri de kapsar. Mobil dostu hız stratejileri, özellikle saha çalışanları, perakende müşterileri ve hareket halindeki kullanıcılar için kritik avantaj sağlar.

Web sitesi hızını düzenli olarak takip etmek için hangi aralıklarla test yapılmalı?

Genellikle ayda en az bir kez hız testi yapmak iyi bir başlangıçtır; ancak kampanya dönemleri, büyük içerik güncellemeleri veya altyapı değişikliklerinden sonra ek testler yapılmalıdır. Düzenli takip, olası yavaşlamaların erken fark edilmesini sağlar ve ani trafik artışlarında bile performansın korunmasına yardımcı olur. Süreklilik, hız optimizasyonunun tek seferlik değil, dinamik bir süreç olduğunu hatırlatır.

Hız optimizasyonunun kullanıcı dönüşüm oranları üzerindeki etkisi nasıl ölçülür?

Google Analytics veya benzeri analiz araçları, hız değişiklikleri öncesi ve sonrası dönüşüm oranlarını karşılaştırma imkânı sunar. Örneğin, bir ürün sayfasının yüklenme süresini 4 saniyeden 2 saniyeye düşürdüğünüzde, sepet tamamlama oranında artış olup olmadığını doğrudan görebilirsiniz. Bu ölçümler, teknik çalışmaların ticari sonuçlara yansımasını net şekilde ortaya koyar ve yatırımın geri dönüşünü hesaplamada önemli bir veridir.