Güzel bir web sitesi teslim ettiniz. Tasarım sade, içerik net ve özellik seti tam olarak müşterinin istediği gibi. İki ay sonra Google Search Console’de organik trafiğin neden yerinde saydığını kontrol ettiğinizde, genellikle suçlu anahtar kelimeler değil — yükleme süresidir.
Site hızının önemi “isteğe bağlı” bir özellikten zorunlu bir sıralama sinyaline dönüştü. Ancak nüans önemlidir: ne kadar önemlidir, nerede en çok zarar verir ve hangi spesifik şeyleri düzeltmelisiniz? Bu makale gerçek ölçütleri, etki arkasındaki verileri ve geliştiricilerin bugün uygulayabileceği somut çözümleri analiz ediyor.
Neden Hız, Sıralama Sinyalidir (Sadece UX Ölçütü Değil)
Neden Hız, Sıralama Sinyalidir (Sadece UX Ölçütü Değil)
Google, sayfa deneyimi sinyallerini — Core Web Vitals dahil olmak üzere — sıralama algoritmasına 2021 yılında resmi olarak entegre etti. Ancak hız ve sıralamalar arasındaki ilişki bu güncellemeden çok öncesine dayanıyor. Google, Yükleme Süresini (Time to First Byte – TTFB) yıllardır tarama bütçesi hesaba katma kriteri olarak kullanıyor ve yavaş sayfalar daha az sıklıkla taranıyor.
Daha etkileyici veriler sektördeki çalışmalardan geliyor:
- Portent 1 saniyede yüklenen bir sitenin, 5 saniyede yüklenen birine göre 3 kat daha yüksek dönüşüm oranına sahip olduğunu bulmuştur.
- Google’ın kendi araştırması, mobil kullanıcıların %53’ünün 3 saniyeden uzun sürede yüklenen bir sayfayı terk ettiğini gösteriyor.
- Backlinko’nun 11.8 milyon arama sonucunu analiz etmesi, ilk 10 sonucun ortalama sayfa hızının, 2. sayfadakilerin hızından önemli ölçüde daha yüksek olduğunu buldu.
Bu mekanizma kısmen doğrudan (Google hızı ölçer) ve kısmen dolaylı (yavaş sitelerin daha yüksek sıçrama oranları, daha düşük süre, daha az sayfa görüntüleme gibi davranışsal sinyalleri) tarafından etkiler.
Gerçekten Hedef Almanız Gereken Ölçütler
Gerçekten Hedef Almanız Gereken Ölçütler
“3 saniyeden az” gibi keyfi eşiği unutun. Google’ın alan verisi araçları (CrUX — Chrome Kullanıcı Deneyim Raporu aracılığıyla), performansı Core Web Vitals kullanarak sınıflandırıyor:
| Ölçüt | İyi | Geliştirme Gerektiriyor | Kötü |
|---|---|---|---|
| LCP (En Büyük İçerik Boyutu) | ≤ 2.5s | 2.5s – 4.0s | > 4.0s |
| INP (Etkileşim için Sonraki Boyut) | ≤ 200ms | 200ms – 500ms | > 500ms |
| CLS (Cumulative Layout Shift – Kümülatif Düzen Kayması) | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
| TTFB (İlk Bayt İçin Süre) | ≤ 800ms | 800ms – 1800ms | > 1800ms |
Geliştiricilerin en çok gözden kaçırdığı nokta: Google, laboratuvar verilerini değil, alan verilerini (gerçek kullanıcı ölçümleri) kullanır. Lighthouse’u yerel olarak çalıştırıp 95 puan almak, kullanıcılarınızın gerçek dünyada hızlı bir site deneyimi yaşamasıyla aynı şey değildir. Her zaman PageSpeed Insights ile çapraz kontrol yapın; bu, gerçek CrUX verilerini çeker, ayrıca daha derin su şelalesi analizi için WebPageTest gibi araçları kullanın.
Darboğazlar Nerede Gerçekten Bulunur
Darboğazlar Nerede Gerçekten Bulunur
1. Optimizasyona Uygun Olmayan Görseller
1. Optimizasyona Uygun Olmayan Görseller
Görseller, düşük LCP puanlarının sürekli birincil sebebidir. 2MB JPEG olarak sunulan bir hero görselinin, 180KB WebP olarak düzgün srcset nitelikleriyle sunulması, yaygın ve düzeltilebilir sorunlardan biridir.
src="/images/hero.webp"
srcset="/images/hero-480.webp 480w, /images/hero-1024.webp 1024w"
sizes="(max-width: 600px) 480px, 1024px"
alt="Hero image"
loading="eager"
fetchpriority="high"
/>fetchpriority="high" niteliğine dikkat edin — bu, tarayıcıya LCP görselini yükleme şelalesinde erken almasını önceliklendirmesi için bir talimat verir ve doğrudan LCP puanınızı artırır.
2. Render-Blocking Kaynaklar
2. Render-Blocking Kaynaklar
Render’ı engelleyen JavaScript ve CSS, TTFB ve FCP (İlk İçerik Boyutu) üzerinde büyük bir etkendir. Laravel + Vite yapılandırmasında, doğru varlık parçalaması ve kritik olmayan scriptlerin askıya alınmasını sağlamak gerekir:
// vite.config.js
import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
export default defineConfig({
plugins: [
laravel({
input: ['resources/css/app.css', 'resources/js/app.js'],
refresh: true,
}),
],
build: {
rollupOptions: {
output: {
manualChunks: vendor: ['alpinejs'],
},
},
},
},
});Kritik olmayan JavaScript’i defer ile veya varsayılan olarak askıya alan type="module" ile yükleyin ve kritik fontlar ve CSS için kullanın.
3. Sunucu Yanıt Süresi (TTFB)
3. Sunucu Yanıt Süresi (TTFB)
Düşük TTFB genellikle üç şeyden birine işaret eder: yavaş hosting, eksik önbellekleme veya optimizasyonu yapılmamış veritabanı sorguları. Laravel’de TTFB’yi önemli ölçüde iyileştirmek için önbellek stratejinizi katmanlayabilirsiniz:
// Öncelikli sorguları etiketli önbellek ile önbelleğe al
$products = Cache::tags(['products'])->remember('featured_products', now()->addHours(6), function () {
return Product::with('category')
->where('is_featured', true)
->orderBy('created_at', 'desc')
->limit(12)
->get();
});Pazarlama sayfalarında tam sayfa önbelleklemesi yapmak için, spatie/laravel-responsecache gibi paketler, önbelleğe alınmış yanıtların TTFB sürelerini 400 ms’den 50 ms’nin altına çekebilir; bu, önemli bir fark yaratır.
4. Üçüncü Taraf Scriptleri
4. Üçüncü Taraf Scriptleri
Bu genellikle göz ardı ediliyor. Analiz, sohbet widgetleri, reklam pikselleri ve sosyal paylaşım butonları, yükleme süresine genellikle 200–800ms ekleyebilir. Üçüncü taraf scriptlerinizi WebPageTest’teki “Üçüncü Taraf” sekmesiyle denetleyin. İlk render için kritik olmayan scriptler için bunları tembel yükleyin:
// Kritik olmayan üçüncü taraf scriptleri sayfa yüklemesi sonrası yükleyin
window.addEventListener('load', () => {
const script = document.createElement('script');
script.src = 'https://cdn.example.com/widget.js';
script.async = true;
document.body.appendChild(script);
});
Test ve İzleme Uygulamaları
Test ve İzleme Uygulamaları
Bir kez düzeltin, izlemiyorsanız yavaş yavaş gerileyin. Dağıtım hattınızda otomatik Lighthouse CI ayarlayın:
# .github/workflows/lighthouse.yml
- name: Lighthouse CI'yi Çalıştır
uses: treosh/lighthouse-ci-action@v10
with:
urls: |
https://yourdomain.com/
https://yourdomain.com/about
budgetPath: ./budget.json
uploadArtifacts: true
Bunu, performans eşiklerinizi zorlayıcı bir sınır olarak belirleyen bir budget.json ile eşleştirin — eğer bir PR LCP’yi 2.5 saniyeden fazla artırıyorsa, derleme başarısız olur. Bu, performansı öncelik olarak elde tutmanın ve yıllık bir yangın söndürme işine dönüşmesini engellemenin bir yoludur.
Hosting ve CDN Hakkında Not
Hosting ve CDN Hakkında Not
Dünyadaki tüm kod optimizasyonları kötü altyapıyı aşamaz. Paylaşımlı hostingdeyseniz, önbellek kullansanız bile muhtemelen TTFB tavanınız 800ms civarındadır. VPS (DigitalOcean, Hetzner veya bölgesel bir bulut sağlayıcısı) ile CDN katmanı (Cloudflare ücretsiz ve mükemmel) kullanmak, genellikle TTFB’yi yarıya düşürür ve coğrafi performans tutarlılığını önemli ölçüde artırır.
Sonuç
Sonuç
Site hızı tek seferlik bir optimizasyon görevi değildir — bu, geliştirme iş akışınıza yerleştirilmesi gereken bir disiplindir. PageSpeed Insights’tan gerçek alan verileri ile başlayın, LCP’yi düzeltmeye (genellikle görseller ve sunucu yanıtı) öncelik verin, render’ı engelleyen kaynakları ortadan kaldırın ve üçüncü taraf scriptlerinizi acımasızca denetleyin. Ardından izlemeyi otomatikleştirin, böylelikle gerilemeler üretime ulaşmadan önce yakalanır.
Organik arama sonuçlarında kazanan geliştiriciler, mutlaka en teknik olarak üstün kodu yazanlar değildir. Performansı ilk günden itibaren birinci sınıf bir konu olarak ele alanlardır.
Kaynak: Orijinal Makale
- Neden Hız, Sıralama Sinyalidir (Sadece UX Ölçütü Değil)
- Gerçekten Hedef Almanız Gereken Ölçütler
- Darboğazlar Nerede Gerçekten Bulunur
- 1. Optimizasyona Uygun Olmayan Görseller
- 2. Render-Blocking Kaynaklar
- 3. Sunucu Yanıt Süresi (TTFB)
- 4. Üçüncü Taraf Scriptleri
- Test ve İzleme Uygulamaları
- Hosting ve CDN Hakkında Not
- Sonuç


