Yeni başlayanlar için sayfa yükleme süresini gerçekten iyileştirenler: görseller, önbellekleme, barındırma, kod ve Core Web Vitals—ve hızlı uygulanabilecek kazanımlar.
İnsanlar “sitem yavaş” dediğinde genellikle iki şeyden birini kasteder:
“Yükleme süresi” tek bir kronometre sayısı değildir. Bir sayfa aşamalar halinde yüklenir: tarayıcınız dosyaları (HTML, görseller, fontlar, scriptler) ister, indirir ve sonra bunları kullanılabilir bir sayfaya çevirir. Bunu bir dükkanı açmaya benzetebilirsiniz: kapıyı açmak, ışıkları yakmak, rafları doldurmak ve nihayet müşterileri ağırlamaya hazır olmak.
Hız etkiler:
50 mikro-optimizasyona ihtiyacınız yok. Çoğu yeni başlayan site için en büyük gelişmeler kısa bir listeden gelir: görseller, fazla JavaScript/CSS, üçüncü taraf widget'lar ve sunucu/barındırma yanıt süresi.
Bu rehber, gerçek dünyada sayfa yükleme süresini iyileştiren pratik, düşük riskli adımlara odaklanır; özellikle mobilde. Uygulama mimarisini baştan yazmak, özel önbellek katmanları oluşturmak veya büyük mühendislik ekipleri için performans bütçelemeye derinlemesine girmeyecektir. Amaç, gerçekten bitirebileceğiniz—ve doğrulayabileceğiniz—değişiklikler yapmanıza yardımcı olmak, siteyi bozmak değil.
İnsanlar “sitem yavaş” dediğinde genellikle üç şeyden birini kasteder: ana içerik geç görünüyor, sayfa etkileşimde gecikiyor veya layout sürekli kayıyor. Google’ın Core Web Vitals bu şikayetlerle güzelce eşleşir.
LCP (Largest Contentful Paint): genellikle bir hero görseli veya başlık bloğu gibi en büyük “ana” şeyin ne kadar sürede göründüğü. LCP yüksekse kullanıcılar çoğunlukla boş bir sayfaya bakar.
INP (Interaction to Next Paint): kullanıcı etkileşiminden (dokunma, tıklama, yazma) sonra sayfanın ne kadar çabuk yanıt verdiği. INP yüksekse site yapışkan hisseder—butonlar geç tepki verir, menüler gecikir.
CLS (Cumulative Layout Shift): yükleme sırasında sayfanın ne kadar kaydığı. Metin kayar ve yanlışlıkla bir butona basarsanız, bu CLS'dir.
TTFB (Time to First Byte), sunucunuzun (ve aradaki her şeyin) herhangi bir şey göndermeye başlaması için ne kadar sürdüğüdür. Yavaş TTFB her şeyi geciktirir: görseller inemez, fontlar yüklenemez ve genellikle LCP kötüleşir. TTFB sorunları genellikle barındırma, ağır backend işleri veya eksik önbellekleme işaret eder.
Laboratuvar testleri (Lighthouse gibi) belirli koşullar altında bir sayfa yüklemesini simüle eder. Hata ayıklama ve öncesi/sonrası karşılaştırmalar için harikadır.
Gerçek kullanıcı verisi (genellikle alan verisi olarak anılır, ör. PageSpeed Insights içindeki CrUX), ziyaretçilerin cihazları ve ağları üzerinde gerçekte ne deneyimlediğini yansıtır. “Gerçek insanlar için hızlı mı?” sorusu açısından bu daha önemlidir.
Bir temel almadan “optimize etmeye” başlarsanız zaman kaybetmek veya yanlışlıkla siteyi daha da yavaşlatmak kolaydır. Önce 20 dakika ölçüm yapın, sonra hangi değişikliklerin işe yaradığını bilirsiniz.
PageSpeed Insights gibi araçları kullanın: PageSpeed Insights size hızlı bir anlık görüntü verir. Hem alan verisi (kullanıcı deneyimi) hem de laboratuvar verisi (simüle test) raporlar. Dikkat edin:
Daha derin laboratuvar testi için Chrome'da Lighthouse çalıştırın:
Hangi şeyin sayfayı geciktirdiğini görmek gerektiğinde, WebPageTest en net araçlardan biridir. Waterfall görünümü her dosyanın yüklenmesini sırayla gösterir—HTML, görseller, fontlar, scriptler ve üçüncü taraf etiketler—ve tarayıcının nerede beklediğini gösterir.
Bir ana sayfayla başlayın (ana sayfa veya öne çıkan açılış sayfası) ve test edin:
Her test için şunları not alın:
Küçük bir günlük oluşturun (bir tablo yeterli): tarih, kullanılan araç, URL, sonuçlar ve yapılan değişiklik. Her seferinde bir veya iki şey değiştirin, sonra aynı koşullarda yeniden test edin.
Bir uygulama üzerinde iterasyon yapıyorsanız (sadece statik site değilse), performans deneylerini göndermek ve geri almak için güvenli bir yol olması yardımcı olur. Örneğin Koder.ai gibi platformlar (sohbet iş akışından React/Go uygulamaları oluşturup barındırabilir) burada kullanışlıdır çünkü anlık görüntüler (snapshots) alabilir, değişiklikleri test edebilir ve bir “hız düzeltmesi” UX'i bozar ise hızlıca geri alabilirsiniz.
Yavaş sayfalar genellikle tek bir gizemli sorundan kaynaklanmaz. Mobilde üst üste binen birkaç yaygın “ağırlık ve gecikme” sorununun sonucudur.
Görseller genellikle sayfanın en ağır kısmıdır. Yanlış boyutta dışa aktarılmış tek bir hero görseli megabaytlar ve saniyeler ekleyebilir.
Yaygın sebepler:
JavaScript, bir sayfanın kullanılabilir hale gelmesini geciktirebilir. Sayfa “görünse” bile scriptler yüklenip çalışırken site yavaş hissedebilir.
Üçüncü taraf scriptler sık sık suçludur: sohbet widget'ları, açılır pencereler, ısı haritaları, A/B test araçları, reklam etiketleri ve sosyal gömüler. Her biri ekstra ağ çağrısı ekleyebilir ve tarayıcının kritik işleri yapmasını geciktirebilir.
Bazen tarayıcı sayfanın yüklenmesine başlamadan önce sunucunuzu bekler. Bu genellikle yavaş ilk yanıt (TTFB) olarak hissedilir. Sebepler: yetersiz barındırma, yoğun veritabanı, optimize edilmemiş tema/eklentiler veya her ziyaret için dinamik olarak oluşturulan sayfalar.
Site her ziyareti sıfırdan başlatıyorsa, tekrar gelen ziyaretçiler cezalandırılır. Önbellek yoksa sunucu sayfaları tekrar tekrar yeniden oluşturur ve tarayıcı nadiren değişen dosyaları yeniden indirir.
Ayrıca çok sayıda küçük dosya (fontlar, scriptler, stiller, izleyiciler) “istek yükü” yaratır. Her dosya küçük olsa bile birleşik bekleme süresi toplanır.
İyi haber: bu nedenler düzeltilebilir—ve genellikle en büyük kazançları bu sırayla alırsınız.
Tek bir performans iyileştirmesi yapacaksanız, görseller olsun. Birçok yeni başlayan sitede görseller sayfanın indirilen “ağırlığının” çoğunu oluşturur—özellikle mobilde. İyi haber: görsel düzeltmeleri genellikle güvenlidir, hızlıdır ve tasarımınızı değiştirmenizi gerektirmez.
Yaygın hata, devasa bir fotoğraf (ör. 4000px genişlik) yükleyip bunu 800px olarak göstermektir. Tarayıcı hâlâ büyük dosyayı indirmek zorunda kalır.
Görselleri sitenizde gerçek maksimum görünecek boyuta yakın dışa aktarın. Örneğin, blog içerik alanınız 800px ise 3000–4000px görseller yüklemeyin “ihtimal” için.
JPEG ve PNG hâlâ çalışır, ancak modern formatlar aynı görsel kalitede çok daha küçük dosya sunar.
CMS veya görsel eklentiniz otomatik olarak WebP/AVIF sunabiliyorsa fallback (yedek) ile bu idealdir.
Sıkıştırma çoğu hemen elde edilen kazancın olduğu yerdir. Görselin “görsel olarak aynı” kalmasını sağlayarak genellikle %30–70 boyut azaltımı mümkündür.
Ayrıca gereksiz metadata'yı (kamera bilgisi, konum verisi) kaldırın. Görselin görünüşünü değiştirmez ama byte ekler.
Pratik kural: kalite belirgin düşene kadar sıkıştırın, sonra bir adım geri gidin.
Mobil kullanıcılar masaüstü boyutlu görselleri indirmemeli. Responsive görseller tarayıcının ekran genişliğine göre uygun boyutu seçmesini sağlar.
Siteniz birden fazla görsel boyutu otomatik üretiyorsa, temanızın bunları doğru kullandığından emin olun. Aradığınız şey HTML'de tek bir devasa dosya yerine srcset gibi bir şey olsun.
Kodu küçültme gibi daha ileri ayarlamalara geçmeden önce yalnızca en büyük görsellerinizi denetleyin:
Bulundukları yerde uygun boyutta mı?
Mümkünse WebP/AVIF olarak sunuluyor mu?
Makul şekilde sıkıştırılmışlar mı?
Mobil cihazlar daha küçük sürümler alıyor mu?
Bu dört şeyi tutarlı şekilde yapın; web sitesi hızınız ve sayfa yükleme süreniz genellikle hemen iyileşir—çoğu zaman Core Web Vitals'ı olumlu etkiler.
Lazy loading, sayfanızın bazı görselleri (ve bazen iframe'leri) ekranına yakın olana kadar indirmeyi geciktirmesi anlamına gelir. Bu, özellikle uzun içerikli sayfalarda başlangıçta tarayıcının her şeyi aynı anda almaması nedeniyle ilk yüklemeyi kısaltır.
Lazy loading en çok şu durumlarda faydalıdır:
Doğru kullanıldığında “önceki yükleme işi” azalır ve sayfa daha hızlı hissedilir.
En büyük üst ekran görseli genellikle hero görselidir. Eğer bunu lazy-load yaparsanız, tarayıcı onu istemekte gecikebilir ve bu Largest Contentful Paint (LCP)'i olumsuz etkileyebilir.
Kural: ana hero görselini veya ilk ekranda kritik olan öğeleri asla lazy-load yapmayın (başlık görseli, birincil ürün fotoğrafı, üst afiş).
Lazy loading, görseller görünürken “atlama”ya neden olabilir. Layout shift (CLS)'yi önlemek için alan ayırın:
width ve height verin, veyaBöylece görseller yüklenirken sayfa düzeni stabil kalır.
Eğer üst ekranda çok önemli bir görsel veya font varsa, tarayıcının onu erken alması için preload düşünün. Bunu tutarlı şekilde kullanın—çok fazla preload bant genişliği için yarışarak geri tepme yapabilir.
Kontrol listesi yaklaşımını isterseniz, bunu ölçüm adımınızla eşleştirin ve blog/how-to-measure-site-speed-before-you-change-anything adlı referansı not alın.
Web sitesi hızı genellikle iki şeyi ifade eder:
Bir sayfa “yüklü görünse” bile JavaScript meşgulse veya layout kaymaları oluyorsa hâlâ yavaş hissedilebilir.
Core Web Vitals, yaygın kullanıcı şikayetlerine karşılık gelen ölçümlerdir:
Bunları iyileştirmek genellikle gerçek algılanan hızı artırır, sadece puanı değil.
Pratik hedefler olarak şunları kullanın:
Bunları yön gösterici hedefler olarak ele alın—önce en kötü metriği düzeltmeye odaklanın.
Tahmin yürütmemek için önce bir temel alın:
Cihaz, ağ, konum ve tam URL'yi kaydedin; her seferinde sadece 1–2 şey değiştirin ve yeniden test edin.
En büyük nedenler genellikle şunlardır:
Bu sırayla düzeltilmeleri genellikle en hızlı kazanımları verir.
Çünkü görseller genellikle sayfadaki en büyük dosyalar ve hem indirme süresini hem de LCP'yi etkiler. Dört ana noktaya odaklanın:
Lazy loading, ilk yüklemede ekran dışındaki içeriğin indirilmesini erteleyerek başlangıç işini azaltır.
Pratik kurallar:
width/height veya sabit en-boy oranı kullanarak yer ayırın.Önbellekleme esasen tekrar ziyaretleri hızlandırır (ikinci sayfa tıklaması, geri dönüşler):
app.3f2a1c.js) kullanın.Doğru yapıldığında önbellek, yeniden indirmeleri ve sunucu işini azaltır, güncellemeleri engellemez.
CDN, ziyaretçiye daha yakın bir sunucudan dosya sunarak gecikmeyi azaltır; en çok şu durumlarda fayda sağlar:
CDN en iyi statik varlıklar için (görseller, CSS, JS, fontlar). Dikkat edilecekler:
CDN tek başına ağır görselleri veya şişkin betikleri düzeltmez; önce temelleri halledin, sonra CDN ekleyin.
Basit bir sırayla yapın ve her şeyi doğrulayın:
Her adım sonrası aynı koşullarda yeniden test edin ve siteyi normal kullanıcı gibi tıklayıp kullanım bozulması olup olmadığını kontrol edin.
srcset) kullanın ki mobil cihazlar daha küçük dosyalar indirsin.Bu değişiklikler genellikle düşük risklidir ve hemen ölçülebilir etkiler verir.
Kritik olan ilk ekran içeriği gerekiyorsa, dikkatli kullanın ve gerektiğinde preload düşünün.