Web sitesi hızlandırma hizmeti: gerçek ziyaretçide ölçülen, görünümü bozmayan hız.

Bu rehberi, sitesinin yavaş açıldığını hisseden ya da PageSpeed Insights’ta kırmızı bir sonuç gören ama yavaşlığın nereden geldiğini ve neyin önce düzeltileceğini göremeyen işletme sahipleri, pazarlama ekipleri ve geliştiriciler için yazdık. Anlattığımız eşikler ve mekanizmalar web.dev, Chrome for Developers, Google Search Central ve MDN’in İngilizce belgelerine dayanıyor; kaynaklar sık sorulan soruların altında numaralı olarak listeleniyor. Tanımları ve eşikleri Eylül 2026 itibarıyla kaynaktan doğruladık. Kendi saha gözlemlerimizi ise “Uzman notu” başlığıyla ayrı işaretledik.

Site hızlandırmada işimiz üç katmanda ilerler: ölçüm; yükleme; etkileşim ve kararlılık. Aşağıdaki on bir başlık bu katmanları ve kurulumda neye baktığımızı sırasıyla anlatır.

Site hızı hangi ölçütlerle değerlendirilir?

Google site hızını Core Web Vitals (Önemli Web Verileri) adlı üç ölçütle değerlendirir: LCP yüklemeyi, INP etkileşimi, CLS görsel kararlılığı ölçer.¹ Her ölçütün “iyi”, “iyileştirilmeli” ve “zayıf” olmak üzere üç aralığı vardır; PageSpeed Insights’ın kullandığı sınırlar şöyledir:²

Eşik tek bir ölçümle değil, dağılımla okunur: web.dev, ziyaretçilerin çoğunda hedefin tutturulduğunu görmek için sayfa yüklemelerinin 75. yüzdeliğine, mobil ve masaüstünü ayrı ele alarak bakmayı öneriyor.¹ 75. yüzdelik, yüklemelerin dörtte üçünün bu değerde ya da daha iyisinde kaldığı noktadır; yavaş bağlantıdaki ve eski telefondaki ziyaretçi bu yüzden ortalamanın içinde kaybolmaz.

“Geçti” kararı da bu değere göre verilir. PageSpeed Insights, üç ölçütün 75. yüzdeliği de “iyi” ise Core Web Vitals değerlendirmesini geçmiş sayar; INP için yeterli veri yoksa LCP ve CLS’nin “iyi” olması yeterlidir.² Search Console’daki Core Web Vitals raporu ise benzer deneyimdeki URL’leri gruplar ve grubun durumunu en zayıf ölçütüne göre belirler; INP’si iyi ama CLS’si zayıf olan bir grup raporda zayıf görünür.³

Saha verisi nereden gelir, hangi sayfalarda görünür?

Saha verisi, gerçek Chrome kullanıcılarının deneyiminden oluşan Chrome UX Report (CrUX: Chrome kullanıcı deneyimi raporu) veri kümesinden gelir ve yalnız herkese açık, yeterince ziyaret alan sayfalarda oluşur.⁴ Bir kullanıcının deneyimi CrUX’e ancak kullanım istatistiği raporlamasını açmışsa, tarama geçmişini senkronize ediyorsa, senkronizasyon parolası koymamışsa ve desteklenen bir platform kullanıyorsa girer.⁴ iOS’taki Chrome, WebView kullanan Android uygulamaları ve Microsoft Edge gibi öteki Chromium tarayıcıları veri kümesine katkı vermez.⁴

Sayfa tarafında iki koşul vardır. Sayfa herkese açık olarak keşfedilebilir olmalıdır: yönlendirmelerden sonra 200 dışında bir HTTP durum koduyla ya da noindex işaretiyle sunulan sayfa bu koşulu karşılamaz.⁴ Sayfa ayrıca yeterince ziyaret almalıdır; eşiği geçemeyen sayfalar ve kaynaklar (origin, yani sitenin tamamı) veri kümesine alınmaz.⁴ PageSpeed Insights gerçek kullanıcıların son 28 günlük deneyimini raporlar; sitenin geneline ait veri de yetersizse hiç saha verisi gösteremez.²

PageSpeed puanı ile saha verisi neden farklıdır?

Laboratuvar testi sayfayı tek bir cihazda ve sabit ağ koşullarında yükler; saha verisi ise gerçek kullanıcıların farklı cihaz ve bağlantılardaki geçmiş deneyimidir, bu yüzden ikisi farklı değer verir.² PageSpeed Insights’taki laboratuvar sonucu Lighthouse’tan gelir; mobil testte orta segment bir cihaz ve mobil ağ, masaüstünde kablolu bağlantı taklit edilir.²

Farkın en önemli sonucu INP’dedir. Lighthouse gibi sayfayı kullanıcısız, benzetilmiş bir ortamda yükleyen araçlar INP’yi ölçemez, çünkü ortada kullanıcı girdisi yoktur; laboratuvarda ölçülebilen Total Blocking Time (TBT) INP için vekil ölçüttür.¹

Core Web Vitals Google sıralamasını etkiler mi?

Etkiler, ama tek başına belirleyici değildir: Google, Core Web Vitals’ın sıralama sistemlerinde kullanıldığını ve sayfa deneyimi için tek bir sinyal olmadığını yazıyor.⁵ Aynı belgeye göre Google Arama, sayfa deneyimi zayıf olsa bile en alakalı içeriği göstermeye çalışır.⁵ Search Console’daki Core Web Vitals raporunda ya da üçüncü taraf araçlarda iyi sonuç almak da sayfanın Google’da en üst sırada çıkacağı anlamına gelmez.⁵

Bu yüzden hız çalışmasını sıralama vaadiyle değil, ziyaretçinin gördüğü deneyimle gerekçelendiriyoruz. Arama görünürlüğü hedefleniyorsa içerik, tarama ve dizine ekleme de birlikte ele alınır; bu tarafı SEO danışmanlığı sayfamızda anlatıyoruz.

LCP hangi parçalardan oluşur?

LCP, kullanıcının sayfayı açmaya başladığı andan görüntü alanındaki en büyük görsel ya da metin bloğunun çizildiği ana kadar geçen süredir ve dört alt parçaya ayrılır.⁶ web.dev bu parçalar için bir pay dağılımı da öneriyor:⁶

İlk parça olan TTFB; yönlendirme süresini, varsa service worker başlatmayı, DNS sorgusunu, bağlantı ve TLS kurulumunu ve isteği, yanıtın ilk baytı gelene kadar kapsar.⁷ TTFB bir Core Web Vitals ölçütü değildir, ama FCP (ilk içerikli çizim) ve LCP’den önce gelir; sunucuda kaybedilen süre bu yüzden iki ölçüte de yansır.⁷ web.dev çoğu site için 0,8 saniye ya da altını hedef gösteriyor, 1,8 saniyenin üstünü zayıf sayıyor.⁷ Bu yüzden TTFB’yi tek başına değil, LCP’nin içindeki payıyla okuyoruz.

Sunucu yanıtı, önbellek ve CDN nasıl düzenlenir?

HTML her kullanımda doğrulanan bir önbellekle, sürüm numaralı statik dosyalar uzun süreli önbellekle ve mümkünse ziyaretçiye yakın bir CDN (içerik dağıtım ağı) üzerinden sunulur. web.dev, sunucuyu kullanıcıya coğrafi olarak yaklaştırmak için CDN kullanmayı öneriyor.⁶ Kaynaklar verimli bir cache-control (önbellek denetimi) politikasıyla sunulduğunda, aynı kaynağı ikinci kez isteyen ziyaretçiye dosya önbellekten gelir.⁶

Önbellek kuralını dosya türüne göre ayırıyoruz. MDN’in anlattığı cache busting (önbellek kırma) yönteminde içerik değiştiğinde dosyanın adresi de değişir; böylece dosya uzun süre önbellekte tutulabilir.⁸ Sürüm numaralı CSS, JavaScript ve görseller için MDN’in örneği bir yıllık max-age ve immutable yönergesidir; adresi sabit kalan HTML ise no-cache ile her kullanımda sunucuya doğrulatılır.⁸ MDN, yanıtı hiç saklamayan no-store’un gereksiz kullanımının tarayıcının geri/ileri önbelleği (bfcache) gibi avantajları kaybettirdiğini de yazıyor.⁸

Görseller ve yazı tipleri nasıl hazırlanır?

LCP görseli HTML’de erken keşfedilir, öncelikli, doğru boyutta ve modern bir biçimde indirilir; ikonlar SVG’de, yazı tipleri yalnız gereken ağırlıklarla yüklenir. web.dev, LCP görselinin asla tembel yüklenmemesi gerektiğini, bunun her zaman gereksiz bir yükleme gecikmesine yol açıp LCP’yi kötüleştirdiğini yazıyor.⁶ LCP öğesi olması muhtemel bir görsel için fetchpriority=”high” (getirme önceliği) niteliğini, inme süresini kısaltmak için de görseli doğru boyutta sunmayı, modern biçim kullanmayı ve sıkıştırmayı öneriyor.⁶ Görsel inmiş olsa da çizim gecikebilir: <head> içinde hâlâ yüklenen stil dosyaları ya da eşzamanlı betikler bütün sayfanın çizimini engelleyebilir.⁶

Biçim tarafında MDN, raster (piksel tabanlı) görseller için PNG, JPEG ve GIF’e göre genelde daha iyi sıkıştırma sağlayan WebP ya da AVIF’i öneriyor.⁹ Kayıplı WebP dosyaları, gözle benzer sıkıştırma düzeyindeki JPEG’lerden ortalama %25–35 daha küçüktür.⁹ AVIF kullanırken tarayıcı desteği daha geniş biçimlere <picture> öğesiyle yedek verilmesi gerekir.⁹ İkonlar ve logolar ise vektör kalır: MDN, simgelerin çoğunun vektör sürümü olduğunu ve mümkün olduğunda SVG sürümüne öncelik verilmesini yazıyor.⁹

1. LCP görseli: şablonda hangi öğenin LCP olduğunu mobil ve masaüstünde ayrı buluyor; o görseli HTML’de doğrudan görünür kılıyor, tembel yüklemeden çıkarıyor ve fetchpriority=”high” veriyoruz.
2. Biçim ve boyut: fotoğrafları WebP ya da AVIF’e çevirip ekrandaki boyuta göre srcset ile sunuyor; ikon, logo ve çizimleri SVG’de tutuyoruz.
3. Ekran dışı görseller: ilk ekranın altındaki görselleri ve iframe’leri tembel yüklüyor, hepsine width ve height veriyoruz.
4. Yazı tipleri: yalnız kullanılan ağırlıkları yüklüyor, ilk ekrandaki yazı tipini önceden yüklüyor, font-display değerini düzen kaymasını ölçerek seçiyoruz.

INP neyi ölçer, etkileşim nasıl hızlanır?

INP, sayfanın ziyaret boyunca kullanıcı etkileşimlerine genel olarak ne kadar çabuk yanıt verdiğini ölçer; ölçülen etkileşimler fareyle tıklama, dokunmatik ekranda dokunma ve fiziksel ya da ekran klavyesinde tuşa basmadır.¹⁰ Üzerine gelme, yakınlaştırma ve kaydırma sayılmaz.¹⁰ Chrome kullanım verisine göre kullanıcının sayfada geçirdiği sürenin %90’ı sayfa yüklendikten sonra geçer; yükleme sonrasındaki yanıt bu yüzden yükleme hızı kadar önemlidir.¹⁰ Çoğu sitede en yavaş etkileşim INP olarak raporlanır; çok etkileşimli sayfalarda her 50 etkileşimde en yüksek bir tanesi göz ardı edilir.¹⁰

INP, FID’in (First Input Delay: ilk girdi gecikmesi) halefidir ve 12 Mart 2024’te onun yerine Core Web Vitals ölçütü oldu; Google, FID’in o gün Search Console’dan kaldırılacağını, öteki araçlara altı aylık geçiş süresi tanınacağını duyurmuştu.¹⁰¹¹

Bir etkileşimin süresi üç evreden oluşur: ilk geri çağırma işlenene kadar geçen giriş gecikmesi, bütün geri çağırmaların çalıştığı işleme süresi ve geri çağırmalar bittikten sonra yeni karenin ekrana gelmesine kadar geçen sunum gecikmesi.¹⁰ Sahada bu üç evreyi uzatan şeyin çoğu zaman ana iş parçacığını (main thread) uzun süre meşgul eden JavaScript olduğunu görüyoruz.

Kurulumda INP’si zayıf sayfa tiplerini saha verisinden buluyor, en sık yapılan etkileşimleri (menü, filtre, sepete ekleme, form) laboratuvarda yeniden üretiyor, performans kaydında uzun görevleri çıkarıyoruz. Etiket yöneticisinde kullanılmayan ve yinelenen etiketleri kaldırıyor, zorunlu olmayanları sayfa yüklendikten sonra çalıştırıyoruz. Çözüm çoğu zaman bir betiği silmek değil, işini bölmek ve çalışma zamanını değiştirmektir.

Düzen kayması (CLS) nasıl önlenir?

CLS, sonradan yüklenen her öğenin yeri ilk düzende ayrılarak önlenir; web.dev zayıf CLS’nin en yaygın nedenlerini boyutsuz görseller, boyutsuz reklam, gömülü içerik ve iframe’ler, sonradan eklenen içerik ve web yazı tipleri olarak sıralıyor.¹² Modern tarayıcılar görselin varsayılan en-boy oranını width ve height niteliklerinden hesapladığı için bu iki niteliği vermek kaymayı önler.¹² Geç yüklenen içerik için ilk düzende yer ayırmak da aynı işi görür.¹²

Yazı tiplerinde font-display: optional, web yazı tipini yalnız ilk düzen anında hazırsa kullandığı için yeniden düzeni önleyebilir; kritik yazı tiplerinin <link rel=preload> ile olabildiğince erken yüklenmesi de önerilir.¹² Animasyonlarda translate gibi birleştirilmiş (composited) dönüşümler öteki öğeleri etkilemediği için CLS’ye sayılmaz.¹² Kullanıcı girdisinden sonraki 500 milisaniye içinde olan kaymalar da CLS’ye eklenmez; düğmeye basınca açılan panel bu yüzden sorun değildir, kendiliğinden itilen içerik sorundur.¹²

Bir hız analizi neyi gösterir, ne kazandırır?

İşe yarayan bir hız analizi tek bir puan değil, puanı düşüren öğenin adını ve sayfadaki yerini verir: en büyük içerik öğesinin çizimini (LCP) hangi öğe geciktiriyor, sayfayı hangi blok kaydırıyor (CLS), hangi düzeltme ne kadar süre kazandırır. Sitelerin hızını izlediğimiz markention app’teki Hız ekranı bu soruları aynı görünümde yanıtlar; aşağıdaki görüntü panelden, örnek veriyle alındı.

Solda laboratuvar ölçümünün metrikleri durur: ilk içerikli çizim (FCP), en büyük içerik öğesinin çizimi (LCP), toplam engelleme süresi (TBT), kümülatif düzen kayması (CLS) ve hız indeksi. Bu değerler benzetilmiş bir cihazda ve kısıtlı ağda yapılan tek bir testten gelir, yani teşhis içindir.² Sağda Google ölçümünde çekilen tam sayfa görüntüsü telefon çerçevesinde açılır. Mavi çerçeve LCP öğesini ve çizildiği anı, turuncu çerçeve kayan bloğu ve kayma puanını gösterir; LCP ya da CLS çipine basınca yalnız o metriğin işaretleri kalır ve altta yalnız onunla ilgili denetimler listelenir. Fırsatlar tahmini kazançla sıralanır, yükleme sırası şeridi de sayfanın saniye saniye nasıl dolduğunu gösterir.

Bu görünümün işe kattığı şeyler şunlar:

• Doğru hedef: “site yavaş” yerine “ana sayfadaki kapak görseli 4,1 saniyede çiziliyor” denir; düzeltilecek öğe adıyla ve yeriyle bellidir.
• Sıra: fırsatlar tahmini kazançla sıralandığı için önce en çok süre kazandıran ve görünümü riske atmayan iş yapılır.
• Şablon düzeyinde düzeltme: ana sayfa, hizmet, blog, ürün, kategori ve kampanya sayfalarından birer örnek ayrı ölçülür; bir şablondaki sorun bir kez düzeltilip o şablonu kullanan bütün sayfalarda doğrulanır.
• Kanıtlı izleme: ölçüm haftada bir kendiliğinden tekrarlanır; ölçüm geçmişi laboratuvar sonucunu gerçek kullanıcı verisinin 75. yüzdeliğiyle yan yana gösterir.¹ Sonradan eklenen bir etiket ya da eklenti hızı düşürürse bu bir sonraki ölçümde görünür.

Örnekteki değerler temsilîdir; gerçek bir çalışmada aynı ekranı sizin sayfa tiplerinizle kuruyor, düzeltmenin saha verisine yansımasını 28 günlük pencere doldukça izliyoruz.⁴

Web sitesi hızlandırma hizmeti ilk 30 günde nasıl işler?

İlk 30 günün işi bütün sayfaları aynı anda değiştirmek değil; en çok ziyaretçiyi etkileyen şablondaki darboğazı görünümü bozmadan gidermek ve etkisini ölçmeye başlamaktır. Şu sırayla ilerliyoruz.

1. 1. hafta · Ölçüm: sayfa tiplerinin mobil ve masaüstü saha verisi okunur; verisi olmayan sayfalar için laboratuvar ölçümü ve gerekirse kendi ölçüm betiğimiz kurulur.
2. 2. hafta · Teşhis: her sayfa tipinde LCP öğesi, alt parçaların payı, uzun görevler, etiketler ve kayan öğeler çıkarılır; bulgular etki ve risk sırasıyla yazılı raporlanır.
3. 3. hafta · Düzeltme: sunucu, önbellek, görsel, yazı tipi ve etiket düzeltmeleri test ortamında yapılır, ekran görüntüleriyle karşılaştırılıp yayına alınır.
4. 4. hafta · İlk okuma: laboratuvar sonuçları hemen, saha verisi 28 günlük pencere doldukça izlenir; sonraki ayın planı çıkar.

Search Console’da bir düzeltmeyi doğrulatmak için başlatılan izleme 28 gün sürer; ilk ayın sonunda saha verisindeki değişimin tamamını değil başlangıcını görürsünüz.³ Hızın dönüşüme etkisini deneyle ölçmek isterseniz bu tarafı CRO danışmanlığı sayfamızda anlatıyoruz.

Hız eklentisi, sunucu yükseltmesi ve hızlandırma hizmeti: fark ne?

“Site hızı nasıl artırılır?” sorusuna üç yaygın yanıt verilir. Üçü de işe yarayabilir; fark, darboğazı bulup bulmadıklarındadır.

Site hızlandırma hizmeti alırken nelere dikkat edilmeli?

Hız teklifleri çoğu zaman bir PageSpeed puanıyla gelir. Karşılaştırırken puandan önce şunlara bakın:

1. Ölçüm kaynağı: raporda her rakamın laboratuvardan mı, gerçek ziyaretçilerin saha verisinden mi geldiği ayrı yazılıyor mu?
2. Görünüm güvencesi: tasarımın ve ikonların aynı kaldığı, değişiklik öncesi ve sonrası ekran görüntüleriyle nasıl doğrulanıyor?
3. Geri alma: her değişiklik belgeleniyor ve gerektiğinde geri alınabiliyor mu?
4. Ölçüm ve izin: etiketler düzenlenirken dönüşüm ölçümü ve çerez izni nasıl korunuyor?
5. Erişim: hangi erişimler isteniyor ve çalışma bitince kaldırılıyor mu?
6. Puan vaadi: “PageSpeed’de 100 puan” ya da sıralama sözü, laboratuvar puanının testten teste oynadığını ve sıralamanın tek bir sinyale bağlı olmadığını atlar.

Web sitesi hızlandırma fiyatları neye göre belirlenir?

Hızlandırma çalışmasının bedelini sitenin büyüklüğünden çok darboğazların nerede olduğu ve işin ne kadar süre izleneceği belirler:

Kapsamı ilk görüşmede birlikte çıkarıyor, ardından yazılı teklif veriyoruz. Barındırma, CDN ya da görsel dönüştürme hizmeti gibi üçüncü taraf ücretleri hizmet bedelinden ayrıdır.

Web sitesi hızlandırma fiyatları: tahmini aralıklar

Tahmini aralık, KDV hariç; “/ ay” yazan satırlar aylık, diğerleri tek seferliktir. Kapsam ilk görüşmeden sonra yazılı teklifle kesinleşir. Ekim 2026 itibarıyla.

Sitenizin bugün nerede durduğunu birlikte okumak isterseniz aşağıdan size uygun bir görüşme günü seçebilirsiniz; ilk görüşmede hangi sayfa tipinden başlayacağımızı birlikte netleştiriyoruz.