Web Sitesi Performansı Optimizasyonu Rehberi

Bir ziyaretçi sitenize tıkladığında, ona ilk izleniminizi verdirecek kaç saniyeniz var? Araştırmalar, kullanıcıların yarısından fazlasının bir sayfanın yüklenmesini üç saniyeden uzun süre beklemeyeceğini gösteriyor. Yani performans, bugün artık teknik bir detay değil; markanızın müşteriyle ilk tanıştığı andır, verdiği sözün tutulup tutulmadığının ölçüldüğü yerdir.

Bir e-ticaret sitesi düşünün: Kullanıcı ürünü sepete eklemek için butona basıyor ama hiçbir şey olmuyor. Sayfanın yavaş çalıştığı, dolayısıyla markanın da o kadar güvenilir olmadığı düşüncesi bir saniyeden daha kısa sürede oluşuyor. Bu düşünce kalıcıdır ve kazanılması pahalıdır.

Bu makalede, bir web sitesini hızlandırmanın tüm hatlarını uçtan uca ele alıyoruz: kullanıcı tarafından algılanan hızdan, sunucunun milisaniyeler seviyesindeki yanıt sürelerine; görsel boyutlarını küçültmekten, tarayıcının kodu nasıl işlediğini anlamaya kadar. Teknik bilgisi orta düzeyde olan bir okuyucu, bu makalenin sonunda hangi sorunun neden önemli olduğunu, gerçek dünyada nasıl karşımıza çıktığını ve pratikte ne yapılması gerektiğini bilecek.

noves.digital'da bir web projesine başlarken en çok üzerinde durduğumuz konulardan biri de tam olarak budur: Tasarımın güzelliği, hızın güvencesi olmadığında anlamını yitirir. Bu makaledeki perspektifi de benzer şekilde, performansı bir "sonradan eklenen özellik" değil, projenin ilk günden itibaren içine işlenen bir disiplin olarak ele aldık.

1. Performans Neden Bir Özellik Değil, Temel Gereksinim?

Sorunun ne olduğu

Birçok kurumsal sitede performans, projenin son aşamasında "site biraz yavaş, hızlandıralım" cümlesiyle ele alınır. Bu yaklaşımın temel hatası, performansın eklenebilen bir aparat değil, mimarinin kendisi olduğunu görmemektir. Altyapı, tasarım ve içerik kararları verildikten sonra yapılan hızlandırma çalışmaları genellikle yüzeysel iyileştirmelerle sınırlı kalır.

Neden önemli

Hızlı bir site üç ayrı kapıyı aynı anda açar: Kullanıcı memnuniyeti, arama motoru görünürlüğü ve dönüşüm oranları. Bu üçü birbirinden bağımsız çalışmaz; hız iyileştikçe üçü de birlikte yükselir. Tam tersi de geçerlidir: Yavaşlık, tek başına yapılmış her doğru kararı götürebilecek bir risk unsuru olarak her an oradadır.

Gerçek dünyadan örnek

Dünyanın en büyük e-ticaret platformlarından biri, sayfa yükleme süresini 100 milisaniye kısalttığında satışlarında ölçülebilir bir artış gözlemlediğini açıkladı. 100 milisaniye, insanın fark edemeyeceği kadar kısa bir süredir; ama milyonlarca ziyaretçi söz konusu olduğunda ortaya çıkan fark devasa olur. Bu örnek, performansın "kullanıcı göremeyecek kadar küçük iyileştirmelerle" bile değer yarattığını gösterir.

Pratik çözüm önerisi

Performans hedeflerini projelendirme aşamasında tanımlayın. "Site hızlı olacak" yerine, "Sayfa yükleme süresi 2 saniyenin altında, mobilde en yüksek skor kategorisinde olacak" gibi ölçülebilir hedefler koyun. Her proje kararını bu hedeflerle test edin.

2. Core Web Vitals: Google'ın Kullanıcıya Sorduğu Gerçek Sorular

Sorunun ne olduğu

Google, bir web sitesinin kalitesini ölçerken artık kendi laboratuvar testlerinden çok, gerçek kullanıcıların yaşadığı deneyime bakıyor. Core Web Vitals, bu deneyimi üç temel soruya indirgemiş bir metrik setidir: İçerik ne kadar hızlı göründü? Site etkileşime ne kadar çabuk yanıt verdi? Sayfa kararlı mı kaldı?

Neden önemli

Bu metrikler sadece teknik raporlar için değil, doğrudan arama sıralamaları için kullanılıyor. Google, açık şekilde Core Web Vitals değerlerini sıralama sinyalleri arasına aldı. Yani performans artık "iyi olursa hoş olur" değil, "kötü olursa cezası var" bir konu.

Gerçek dünyadan örnek

Bir seyahat sitesi, yalnızca sayfa kaymalarını (layout shift) düzelterek mobil dönüşüm oranını gözle görülür biçimde artırdığını rapor etti. Sorun, görselin yüklendikten sonra butonu aşağı itmesi ve kullanıcının yanlış yere tıklamasıydı. Tek bir kararlılık sorunu bile doğrudan gelir kaybı demekti.

Pratik çözüm önerisi

Google Search Console'daki Core Web Vitals raporunu düzenli olarak inceleyin. "İyi" durumda olmayan URL gruplarını tespit edip önceliklendirin. Herhangi bir teknik ölçüm yapmadan önce, bu rapor size "kullanıcıya göre" durumu gösterecektir.

3. LCP (Largest Contentful Paint): İlk İzlenimin Ölçümü

Sorunun ne olduğu

LCP, sayfadaki en büyük içeriğin (genellikle ana görsel veya başlık) ekrana ne kadar sürede çizildiğini ölçer. Kullanıcı için bu, "site açıldı" hissinin oluştuğu andır. Google'ın beklentisi 2.5 saniyenin altı; üstü iyileştirme gerektiren alan demektir.

Neden önemli

Kullanıcı zihnindeki ilk kalite kararını LCP süresi boyunca verir. Ekranda uzun süre boşluk veya dönen bir yükleme göstergesi kalırsa, ziyaretçi çoğunlukla geri tuşuna basar. Yanı sıra Google, bu süreyi sıralama faktörü olarak kullandığı için yavaş LCP hem kullanıcıyı hem arama görünürlüğünü aynı anda etkiler.

Gerçek dünyadan örnek

Bir haber sitesi, ana sayfadaki devasa kapak fotoğrafını sıkıştırıp boyutlandırdığında LCP süresini üç saniyenin altına indirdi ve hemen çıkma oranında belirgin düşüş yaşadı. Sorun o kadar basitti ki: 5 megapiksellik bir fotoğraf, düşünülmeden yüklenmişti.

Pratik çözüm önerisi

Ana görseli küçültün: Boyut, site genişliğinden büyük olmamalı.

Bu görsele öncelik verin: Tarayıcıya, diğer her şeyden önce bu dosyayı getirmesini söyleyin.

Sunucu yanıtını kısaltın: LCP'nin kötü olmasının sık nedeni, sunucunun ilk baytı geç göndermesidir.

4. INP (Interaction to Next Paint): Site Hızlı Görünmek Yeterli Değil

Sorunun ne olduğu

INP, kullanıcının tıkladığı, yazdığı, kaydırdığı her anın ardından sitenin görsel olarak ne kadar sürede tepki verdiğini ölçer. Bir butona basıp hiçbir değişiklik görememek, LCP'nin kusursuz olmasını anlamsız kılar. Kullanıcı için "site açıldı ama çalışmıyor" hissi, "site açılmadı" hissi kadar hayal kırıklığı yaratır.

Neden önemli

Modern sitelerde etkileşim giderek artıyor: Filtreleme menüleri, canlı arama, sepet işlemleri, form doğrulamaları. Hepsi anında yanıt bekliyor. INP, 2024'ten itibaren Google'ın eski "İlk Giriş Gecikmesi" (FID) metriğinin yerini aldı ve etkileşim kalitesini çok daha kapsamlı ölçüyor.

Gerçek dünyadan örnek

Bir restoran rezervasyon sitesi, menüde gezinirken her kategoriye geçişte yarım saniyelik donmalar yaşıyordu. Kullanıcılar menüyü incelemekten vazgeçip arama motoruna geri dönüyordu. Sorun, her kategori değişiminde çalıştırılan ağır JavaScript hesaplamalarıydı.

Pratik çözüm önerisi

Gereksiz JavaScript'i kaldırın: Kullanılmayan eklenti ve kütüphaneler ana iş parçacığını meşgul eder.

Uzun işlemleri bölmün: Büyük hesaplamaları küçük parçalara ayırın ki tarayıcı arada kullanıcıya yanıt verebilsin.

Üçüncü parti script'leri denetleyin: Analitik, sohbet balonları ve reklam kodları çoğu zaman INP suçlusudur.

5. CLS (Cumulative Layout Shift): Kullanıcının Güvenini Kaybettiren Kaymalar

Sorunun ne olduğu

Sayfa yüklenirken içeriklerin aniden aşağı veya yukarı kaymasıdır. Reklam alanı yüklenince metnin zıplaması, görsel belirince butonun yerinden oynaması tipik örneklerdir. CLS bu kaymaların toplamını puanlar; düşük puan, kararsız bir sayfa demektir.

Neden önemli

Kayma, kullanıcıyı iki şekilde kaybettirir: Yanlış yere tıklama (örneğin "satın al" yerine "iptal") ve sayfaya güven duymama. İkincisi daha ağırdır; ziyaretçi siteye "kontrolsüz" gözüyle bakmaya başladığında satın alma ihtimali hızla erir.

Gerçek dünyadan örnek

Büyük bir e-ticaret markası, ürün listeleme sayfalarına reklam banner'ları ekledikten sonra mobil iade oranlarında artış fark etti. İncelemede, banner yüklendiğinde "sepete ekle" butonunun kayması ve yanlış ürünlerin satın alınması olduğu ortaya çıktı.

Pratik çözüm önerisi

Her görsele ve videoya genişlik-yükseklik değeri verin. Tarayıcı, dosya yüklenmeden önce yerini bilsin.

Reklam ve yerleşim alanlarına sabit boyut atayın.

Yazı tiplerini dikkatli yükleyin: Font değişimi metnin boyutunu değiştirmemeli; mümkünse metni geçici olarak görünmez yapmayın.

6. Görsel Optimizasyonu: Sayfa Boyutunun En Büyük Suçlusu

Sorunun ne olduğu

Ortalama bir web sayfasının veri hacminin yarısından fazlası görsellerden oluşur. Yüksek çözünürlüklü kameralar ve stok fotoğraf siteleri, çoğu zaman gereğinden on kat büyük dosyalar üretir. Bu dosyalar, özellikle mobil bağlantılarda yükleme süresini katbekat uzatır.

Neden önemli

Görsel optimizasyonu, en yüksek getirili performans çalışmasıdır. Diğer tekniklerde uzmanlık gerektiren konulara girmeden, doğru format seçimi ve boyutlandırma ile sayfa hızını dramatik biçimde iyileştirmek mümkündür.

Gerçek dünyadan örnek

Bir butik otelin sitesi, oda fotoğraflarını sıkıştırmadan yükleyip toplam sayfa boyutunu 15 MB'a çıkarmıştı. Mobilde site yaklaşık 10 saniyede açılıyordu. Fotoğraflar uygun boyuta getirilip modern formata dönüştürülünce sayfa 1.8 MB'a indi ve açılış süresi üçte bire düştü.

Pratik çözüm önerisi

Yayına almadan önce görselleri boyutlandırın: Sitede 1200 piksel genişlikte görünen bir alana 4000 piksellik dosya koymayın.

Sıkıştırma aracı kullanın: İnsan gözünün fark etmeyeceği kayıpla dosya boyutunu yarı yarıya düşürmek mümkündür.

Görselleri bir klasör yönetimi içinde düzenleyin: Kaynak dosyayı saklayın, web için optimize edilmiş kopyayı üretin.

7. WebP ve AVIF: Görsel Formatlarının Yeni Nesli

Sorunun ne olduğu

Yıllardır standart olan JPEG ve PNG formatları, verimlilik açısından artık geride kaldı. Google'ın geliştirdiği WebP ve Alliance for Open Media'nın çıkardığı AVIF, aynı görsel kalitesini çok daha küçük dosyalarla sunabiliyor.

Neden önemli

Format değişikliği, ekstra iş gerektirmeyen en kolay kazanımdır. WebP ortalama %30, AVIF ise kalite ayarına bağlı olarak %50'ye varan boyut tasarrufu sağlar. Destekleyen tüm modern tarayıcılarda bu formatlara geçmek, neredeyse bedava hız demektir.

Gerçek dünyadan örnek

Bir moda markası, ürün görsellerini AVIF'e dönüştürdükten sonra mobil veri kullanımını yüzde 40 azalttığını ve kategori sayfalarının açılış süresini iki kat hızlandırdığını ölçtü. Özellikle görsel ağırlıklı sektörlerde bu dönüşüm rekabet avantajı yaratır.

Pratik çözüm önerisi

Dönüşümü toplu olarak yapın: Tek tek elle dönüştürmek yerine, görsel yükleme sürecinize otomatik dönüştürme adımı ekleyin.

Geriye dönük uyumluluk için yedek plan tanımlayın: Eski tarayıcılar için JPEG versiyonunu hazır bulundurun.

Şeffaf görsellerde dikkatli olun: PNG'nin şeffaflık özelliğini taşıyan formatları ve doğru kalite ayarlarını seçin.

8. Responsive Görseller: Her Ekrana Uygun Boyutta Teslimat

Sorunun ne olduğu

Masaüstünde 2000 piksel genişliğinde görünen bir görseli, 375 piksellik telefon ekranına da aynı dosya boyutuyla göndermek yaygın bir israftır. Telefon hem gereksiz veri indirir hem de görseli indirdikten sonra yeniden boyutlandırmak zorunda kalır.

Neden önemli

Mobil trafiğin toplam web trafiğinin çoğunluğunu oluşturduğu gerçeğini düşünürsek, responsive görsel stratejisi artık lüks değil zorunluluk. Aynı görselin dört-beş farklı boyutunu hazırlamak, veri maliyetini ve yükleme süresini doğru orantılı olarak düşürür.

Gerçek dünyadan örnek

Bir haber portalı, görsellerin yalnızca ekran boyutuna uygun versiyonlarını sunmaya başladığında aylık bant genişliği maliyetinde ciddi tasarruf sağladı ve sayfa hızı puanları yükseldi. Tasarruf, yalnızca sunucu maliyetinde değil, kullanıcıların mobil veri paketlerinde de oluştu.

Pratik çözüm önerisi

Görselleri en az üç boyutta üretin: Küçük (mobil), orta (tablet) ve büyük (masaüstü).

Tarayıcıya seçim imkanı tanıyın: Tarayıcı, cihazın ekranına ve ağ koşullarına en uygun versiyonu kendisi seçebilir.

Kart tasarımlarında dikkat edin: Liste sayfalarında düzinelerce küçük görsel vardır; hepsine büyük dosya vermek toplamı felakete götürür.

9. Lazy Loading: Gerektiğinde Yükleme Disiplini

Sorunun ne olduğu

Kullanıcının henüz görmediği içeriklerin, sayfanın en başında yüklenmesi gereksizdir. Uzun bir sayfada onlarca görsel, video ve yorum varsa; bunların hepsinin ilk saniyede inmesi, görünür alanın açılmasını yavaşlatır. Lazy loading, içerik ekrana yaklaştığında yüklemeyi erteler.

Neden önemli

Doğru uygulandığında ilk yükleme süresi belirgin biçimde kısalır. Ancak yanlış uygulandığında da ters etki yapar: Sayfanın en üstündeki ana görsel tembel yükleme alırsa, LCP felaketleşir. Yani bu teknik, nerede kullanılacağını bilmeyi gerektirir.

Gerçek dünyadan örnek

Bir forum sitesi, konu sayfalarındaki tüm avatar görsellerine tembel yükleme eklediğinde sayfa başına indirilen veri miktarını yarıya indirdi. Buna karşılık bir başka site, ana vitrin görseline de aynı işlemi uygulayınca Google'ın raporlarında "en büyük içerik geç yüklendi" uyarısı aldı.

Pratik çözüm önerisi

Kural basit: Ekranın ilk görünen bölgesindeki (above-the-fold) hiçbir içeriğe tembel yükleme uygulamayın.

Uzun listelerde uygulayın: Blog arşivleri, ürün listeleri, yorum bölümleri ideal adaylardır.

Video ve iframe'leri de kapsayın: Çoğu site bunları unutur; oysa üçüncü parti gömüntüler ciddi yük bindirir.

10. JavaScript Yükünü Hafifletmek

Sorunun ne olduğu

Modern web siteleri, çoğu zaman gereğinden fazla JavaScript taşır. Her buton animasyonu, her kaydırma efekti ve her analitik aracı ek kod demektir. Tarayıcı, bu kodun tamamını indirmeli, ayrıştırmalı ve çalıştırmalıdır; tümü bitmeden sayfa tam etkileşimli olmaz.

Neden önemli

JavaScript, INP metriğinin de ana belirleyicisidir. Ana iş parçacığını meşgul eden her kod, kullanıcının tıklamasına yanıt süresini uzatır. Ayrıca mobil cihazların işlemcileri masaüstüne göre zayıf olduğundan, aynı kod yükü mobilde çok daha ağır hissedilir.

Gerçek dünyadan örnek

Bir SaaS girişimi, landing page'inden kullanılmayan üç kütüphaneyi kaldırıp kalan kodu yeniden düzenlediğinde, sayfanın tam etkileşimli hale gelme süresi 4 saniyeden 1.5 saniyeye indi. Demo talebi formuna ulaşan ziyaretçi oranı da buna paralel yükseldi.

Pratik çözüm önerisi

Eklenti envanterini çıkarın: Sitede kaç üçüncü parti araç çalışıyor, hangileri gerçekten kullanılıyor?

Ağır kütüphaneleri sorgulayın: Küçük bir işlem için dev bir kütüphane dahil etmek yaygın bir hatadır.

Kullanıcı etkileşimine bağlayın: Sayfa açılır açılmaz değil, kullanıcı ilgili bölüme geldiğinde çalışan kodlar tercih edin.

11. CSS Optimizasyonu: Görünür Olmanın Hızı

Sorunun ne olduğu

CSS dosyaları çoğu zaman yıllar içinde büyüyen, kullanılmayan kurallarla dolu organizmalara dönüşür. Bir tema güncellemesi, bir eklenti eklemesi... Her biri stil dosyasına bir şeyler bırakır. Tarayıcı, sayfanın hiçbir yerinde kullanılmayan binlerce satır kuralı yine de indirir ve işler.

Neden önemli

Özellikle "kritik CSS" yaklaşımı, kullanıcı deneyimini doğrudan etkiler. Ekranın ilk görünen bölümünün stilleri dışarıdan gelen büyük bir dosyayı bekliyorsa, kullanıcı stilsiz (boş veya dağınık) bir sayfa görür. İlk izlenim saniyeler içinde zedelenir.

Gerçek dünyadan örnek

Bir ajans sitesi, tasarım yenilemesinde eski temanın tüm stil dosyasını bırakıp üzerine yenilerini eklemişti. Sayfa, 1.2 MB'lık CSS indiriyordu. Kullanılmayan kurallar temizlendikten sonra bu boyut 180 KB'a indi ve ilk görünen bölümün stilleri HTML içine gömülerek sayfa "aniden ve şık" açılmaya başladı.

Pratik çözüm önerisi

Kullanılmayan CSS'i temizleyin: Denetim araçlarıyla sayfada hiç eşleşmeyen kuralları tespit edin.

Kritik stilleri önceliklendirin: İlk ekranın stilleri hızlıca ulaşmalı; geri kalanı arka planda yüklenebilir.

Fontları kontrollü yükleyin: Her font ağırlığı ayrı bir dosyadır; gerçekten kullandıklarınızı tutun.

12. Sunucu Yanıt Süresi (TTFB): Hızın Sıfır Noktası

Sorunun ne olduğu

Tarayıcı bir istek gönderir ve sunucunun ilk baytı göndermesini bekler. Bu süreye TTFB (Time to First Byte) denir. İçerik ne kadar optimize edilirse edilsin, sunucu geç yanıt veriyorsa tüm zincir gecikir. LCP sorunlarının önemli bir bölümü aslında TTFB sorunudur.

Neden önemli

Kullanıcının sabrı, sunucu yanıtını bekleme süresinden başlar. 600 milisaniyenin üzerindeki TTFB değerleri, ardındaki tüm optimizasyon çabalarını baltalar. Google da bu metriği dolaylı olarak değerlendirir; çünkü yavaş TTFB, genelde kötü altyapının işaretidir.

Gerçek dünyadan örnek

Bir etkinlik biletleme sitesi, kampanya dönemlerinde trafik patlaması yaşadığında sunucuları göçüyordu. Yanıt süreleri 3-4 saniyelere çıkıyor ve kullanıcılar ödeme adımından atıyordu. Altyapı güçlendirilip önbellekleme katmanı eklenince aynı trafik rahatlıkla kaldırılabildi.

Pratik çözüm önerisi

Barındırma (hosting) kalitesini gözden geçirin: Ucuz paylaşımlı sunucular, yoğun saatlerde yanıt sürelerini katlar.

Önbellek katmanı ekleyin: Sık istenen sayfaların hazır kopyalarını saklayın.

Zamanlanmış görevleri dengeleyin: Yedekleme, raporlama gibi ağır işleri ziyaretçi saatlerinden uzakta çalıştırın.

13. Önbellekleme Stratejileri: Tekrar Tekrar Hesaplamamak

Sorunun ne olduğu

Her ziyarette aynı sayfanın veritabanından yeniden üretilmesi gereksizdir. Bir blog yazısı haftalarca değişmeden kalıyorsa, her ziyaretçi için sıfırdan sorgulanmamalıdır. Önbellekleme, üretilmiş sonucu saklayıp sonraki isteklere hazır sunma tekniğidir.

Neden önemli

Doğru kurgulanmış bir önbellek sistemi, sunucu yükünü ve TTFB değerini dramatik biçimde düşürür. Trafik arttığında sunucunun çökmemesini sağlayan ilk savunma hattıdır. Ayrıca sabit bir hız deneyimi sunar; ziyaretçi sayısı artsa bile site yavaşlamaz.

Gerçek dünyadan örnek

Bir içerik sitesi, anasayfa ve kategori sayfalarını 15 dakikalık önbellekle servis etmeye başladığında, ziyaretçi sayısı üç katına çıkmasına rağmen sunucu maliyeti sabit kaldı. Aynı dönemde sayfa açılış süreleri de düzenli hale geldi; dalgalanmalar ortadan kalktı.

Pratik çözüm önerisi

Katmanlı düşünün: Tarayıcı önbelleği, sunucu önbelleği ve veritabanı önbelleği birlikte çalışmalı.

Geçerlilik sürelerini akıllı ayarlayın: Statik içerik uzun süre, sepet gibi dinamik bölümler hiç önbelleğe alınmamalı.

Temizleme kuralları tanımlayın: İçerik güncellendiğinde ilgili önbellek kendiliğinden yenilenmeli.

14. CDN Kullanımı: İçeriği Kullanıcıya Yaklaştırmak

Sorunun ne olduğu

Sunucunuz İstanbul'da ama ziyaretçiniz Sydney'deyse, veri binlerce kilometrelik kablolarla seyahat eder. Bu fiziksel mesafe, ping sürelerini ve yükleme sürelerini uzatır. CDN (Content Delivery Network), sitenizin kopyalarını dünya genelindeki noktalara dağıtıp ziyaretçiyi en yakın noktaya yönlendirir.

Neden önemli

CDN kullanımı, küresel kitlelere ulaşan her site için hız farkı yaratır. Aynı zamanda DDoS saldırılarına karşı koruma ve ana sunucu yükünün azaltılması gibi yan faydalar sağlar. Modern CDN'ler artık sadece dosya saklamıyor; ağın kenarında (edge) kod çalıştırabiliyor.

Gerçek dünyadan örnek

Bir online eğitim platformu, video ve dokümanları CDN üzerinden sunmaya geçtiğinde yurt dışı trafiğinin yüzde 60'ını ana sunucusuna hiç uğratmadan yanıtladı. Orta Doğu ve Avrupa'dan gelen ziyaretçilerin sayfa yükleme süreleri yarı yarıya kısaldı.

Pratik çözüm önerisi

Statik varlıkları CDN'e taşıyın: Görseller, CSS, JavaScript ve fontlar ilk adaydır.

Önbellek sürelerini doğru ayarlayın: Adı değişen dosyalar uzun süre önbelleğe alınabilir.

Edge yeteneklerini değerlendirin: Kullanıcıya özel olmayan bazı işlemleri merkezi sunucu yerine ağın kenarında yapmak mümkündür.

15. Mobil Performans: Asıl Sınavın Yeri

Sorunun ne olduğu

Siteler masaüstünde pürüzsüz görünürken mobilde takılır. Bunun nedeni, mobil cihazların daha zayıf işlemcileri, daha değişken ağ bağlantıları ve daha küçük ekranlarıdır. Masaüstünde 2 saniyede açılan site, aynı koşullarda orta segment bir telefonda 5 saniye sürebilir.

Neden önemli

Mobil trafik çoğu sektörde toplam trafiğin yarısından fazlasını oluşturuyor. Google da sıralamaları mobil deneyime göre belirliyor. Yani mobil performansınız, sitenizin gerçek performansıdır; masaüstü skorlarınız sadece bir referans noktasıdır.

Gerçek dünyadan örnek

Bir sigorta şirketinin sitesi, masaüstünde 90 üzeri puan alıyordu ancak mobilde 40'lı puanlardaydı. Kullanıcıların yüzde 70'i mobilden geldiği için asıl deneyim felaket ölçekteydi. Mobil öncelikli iyileştirme sonrası form doldurma oranı yüzde 35 arttı.

Pratik çözüm önerisi

Testleri mobil öncelikli yapın: Değerlendirmeleri düşük donanımlı bir Android telefon senaryosuyla koşun.

Dokunma hedeflerini büyük tutun: 44 pikselin altındaki tıklanabilir alanlar hem hata hem hayal kırıklığı demektir.

Karanlık modu ve kontrastı destekleyin: Mobil kullanım çoğunlukla dış mekanda ve değişken ışıkta olur.

16. Üçüncü Parti Script'lerin Gizli Maliyeti

Sorunun ne olduğu

Sohbet balonları, analitik araçlar, reklam ağları, sosyal medya butonları, A/B test platformları... Her biri sitenize bir JavaScript dosyası ekler. Tek tek bakıldığında hafif görünen bu araçlar, biriktikçe sayfanın kontrolünü ele geçirir. Kullanıcı verisi ise dış servislere akar.

Neden önemli

Üçüncü parti script'ler INP'yi düşürmenin, veri sızıntısının ve güvenlik risklerinin baş kaynağıdır. Ayrıca bunlardan biri yavaşlarsa veya çökerse, sizin siteniz de etkilenir. Kontrolünüz dışındaki kod, sizin performansınızın rehini demektir.

Gerçek dünyadan örnek

Bir e-ticaret sitesi, beş farklı analitik ve pazarlama aracını aynı anda kullanıyordu. Her biri sayfa yüklenmeden önce çalışmak istediği için, kullanıcı etkileşimine yanıt süresi 1.8 saniyeyi buluyordu. Araç sayısı ikiye indirilip kalanlar asenkron çalıştırılınca bu süre 0.3 saniyeye düştü.

Pratik çözüm önerisi

Düzenli envanter yapın: Kaç üçüncü parti script çalışıyor, hangileri son kullanım tarihi geçmiş?

Yükleme stratejisini değiştirin: Kritik olmayan script'ler, kullanıcı etkileşiminden sonra veya arka planda yüklenmeli.

Sözleşmeleri gözden geçirin: Veri işleme şartları ve performans taahhütleri, araç seçiminin parçası olmalı.

17. Performans Ölçüm Araçları ve Doğru Metodoloji

Sorunun ne olduğu

"Site yavaş" söylemi, ölçülmeden ele alınan bir duygudur. Performans çalışması, doğru araçlarla doğru metriklerin ölçülmesiyle başlar. Ancak her araç farklı bir perspektif sunar; laboratuvar verisi ile gerçek kullanıcı verisi (field data) aynı şeyi söylemez.

Neden önemli

Yanlış araçla yanlış metrik ölçmek, iyileştirme çabalarının boşa gitmesine yol açar. Örneğin laboratuvar testinde harika skor alan bir site, gerçek kullanıcıların yavaş bağlantılarında felaket olabilir. Doğru metodoloji, her iki dünyayı da birlikte okumaktır.

Gerçek dünyadan örnek

Bir blog sitesi, geliştiricisinin bilgisayarında mükemmel ölçümler aldığı için "sitemiz hızlı" diyordu. Google Search Console'un gerçek kullanıcı verilerini inceleyince, mobil kullanıcıların yüzde 60'ının yavaş deneyim yaşadığı ortaya çıktı. Laboratuvar koşulları, gerçek dünyayı gizlemişti.

Pratik çözüm önerisi

İki dünyayı da takip edin: PageSpeed Insights gibi laboratuvar araçları + Search Console gibi gerçek kullanıcı verileri.

Şelale (waterfall) analizi yapın: Hangi dosya, hangi sırada, ne kadar sürede iniyor; darboğazı görün.

Tarihsel kayıt tutun: Ölçümleri arşivleyin; iyileştirmelerin etkisini kanıtlamanız gerekecek.

18. Performans ile SEO Arasındaki Doğrudan Bağ

Sorunun ne olduğu

Google, hızlı ve kararlı siteleri sıralamada ödüllendirir. Bu, Core Web Vitals güncellemesiyle resmileşti. Ancak etki yalnızca metriklerle sınırlı değildir: Hızlı siteler daha iyi taranır, daha hızlı indekslenir ve kullanıcı sinyalleri (tıklama, kalma süresi) açısından avantajlıdır.

Neden önemli

SEO yatırımı yapan bir site, performansını ihmal ediyorsa bütçesinin önemli bir bölümünü çöpe atıyor demektir. İyi içerik + kötü performans kombinasyonu, kötü içerik + iyi performans kombinasyonunu dahi yenemez. Arama sonuçları sayfasında, hız görünmez bir eleme kriteridir.

Gerçek dünyadan örnek

Bir hukuk bürosu sitesi, teknik SEO çalışmalarına rağmen sıralamalarda istediği yeri alamıyordu. Performans denetiminde LCP'nin 4.9 saniye olduğu tespit edildi; kötü barındırma ve optimize edilmemiş görseller suçluydu. Altyapı değişimi sonrası üç ay içinde hedef anahtar kelimelerde ilk sayfaya çıktı.

Pratik çözüm önerisi

Teknik SEO denetimlerine performansı mutlaka dahil edin.

Sayfa bazında değil, site genelinde bakın: Tek bir yavaş şablon tüm SEO çabasını zedeleyebilir.

İçerik takvimini hız kontrolleriyle eşleştirin: Yeni içerik eklerken performans gerilemesi yaşanmamalı.

19. Performansın Dönüşüm Oranlarına ve Gelire Etkisi

Sorunun ne olduğu

Dönüşüm oranı, ziyaretçinin sitenizde istediğiniz eylemi yapma olasılığıdır: Satın alma, form doldurma, arama yapma, telefon etme. Performans, bu olasılığın en doğrudan belirleyicilerinden biridir. Yavaşlık, pazarlama hunisinin her aşamasında sızıntı yaratır.

Neden önemli

Reklam bütçesiyle gelen ziyaretçiyi yavaş bir sayfa yüzünden kaybetmek, doğrudan para kaybıdır. Tıklama başına maliyetiniz sabitken, dönüşüm oranı düştükçe edinme maliyetiniz (CAC) artar. Performans iyileştirmesi, pazarlama bütçenizin verimini yükseltmenin en ucuz yoludur.

Gerçek dünyadan örnek

Bir online kurs platformu, ödeme sayfasının yüklenme süresini 1.2 saniye kısalttığında ödeme tamamlama oranında yüzde 7'lik artış kaydetti. Bu oran, aynı reklam bütçesiyle çok daha fazla satış anlamına geliyordu; ek pazarlama harcaması olmadan gerçekleşen bir büyüme.

Pratik çözüm önerisi

Dönüşüm hunisinin her adımını ölçün: Ana sayfa, ürün sayfası, sepet, ödeme; hangi adımda ne kadar zaman geçiyor?

A/B testlerinde performansı kontrol edin: Bir tasarım varyantı daha iyi dönüşüm sağlıyor ama siteyi yavaşlatıyorsa uzun vadede kaybettirir.

Hız hedefini gelir hedefiyle ilişkilendirin: Yönetim raporlarında performans skorunu, dönüşüm metrikleriyle birlikte sunun.

20. Performans Kültürü: Sürdürülebilirliğin Anahtarı

Sorunun ne olduğu

Bir siteyi bir kez hızlandırmak kolaydır; asıl zorluk hızı korumaktır. Her yeni içerik, her eklenti, her tasarım değişikliği performansı yavaş yavaş aşındırır. Sürdürülebilirlik, performansın bir proje kültürüne dönüşmesiyle mümkün olur.

Neden önemli

Performansı kimse sahiplenmediğinde, site bir yıl içinde başlangıç noktasına döner. "Birileri ilgilenecek" varsayımı, ilgilenilmediğinin en yaygın ifadesidir. Hız, tıpkı güvenlik gibi, sürekli bakım isteyen bir canlı varlıktır.

Gerçek dünyadan örnek

Bir teknoloji şirketi, her yayın öncesi otomatik performans kontrolü koşan bir süreç kurdu. Belirlenen eşiğin altına düşen değişiklikler yayına alınmadı önce iyileştiriliyordu. Bu basit kural sayesinde site iki yıl boyunca ilk günkü hızını korudu.

Pratik çözüm önerisi

Performans bütçesi tanımlayın: "Sayfa 2 MB'ı, LCP 2.5 saniyeyi geçemez" gibi sınırlar koyun ve her değişikliği bu bütçeye göre değerlendirin.

Sorumluluk atayın: Performansın bir sahibi olmalı; düzenli denetim takvimi olmalı.

Ekip içinde farkındalık yaratın: Tasarımcıdan içerik editörüne, herkesin kararlarının hıza etkisini anlaması gerekir.

21. Yaygın Performans Hataları ve Hızlı Teşhis Yolları

Sorunun ne olduğu

Deneyimli ekiplerin bile düştüğü tekrarlayan hatalar vardır: Otomatik oynayan videolar, boyutu belirsiz görseller, her sayfada çalışan gereksiz kod, ağır slider eklentileri. Bu hataların ortak özelliği, "öylece gelişen" detaylar olmalarıdır; bilinçli tercih değildirler.

Neden önemli

Teşhis edilmeden çözülemeyen sorunlar, enerjiyi boşa harcar. Doğru teşhis yöntemi, saatler süren kör denemeler yerine dakikalar içinde sorunun kaynağına inmenizi sağlar. Aşağıdaki tablo, en sık karşılaşılan hataları ve ilk bakılacak yerleri özetler.

Gerçek dünyadan örnek

Bir hastane sitesi, "site çok yavaş" şikayeti üzerine tüm görselleri yeniden optimize etti ama bir şey değişmedi. Şelale analizi, asıl darboğazın hasta portalına yönlendiren üçüncü parti bir doğrulama script'inin 6 saniyede yanıt vermesi olduğunu gösterdi. Sorun, hiç bakılmayan bir yerdeydi.

Pratik çözüm önerisi

22. Performans Yol Haritası: Nereden Başlamalı?

Sorunun ne olduğu

Tüm bu başlıklar karşısında "nereden başlayacağım?" sorusu doğal. Her şeyi aynı anda yapmak hem mümkün değil hem gereksiz. Doğru yol haritası, etki-gayret dengesine göre sıralama yapmayı gerektirir. Bazı iyileştirmeler 15 dakikada hayat değiştirir; bazıları projelendirme ister.

Neden önemli

Önceliklendirme yapmadan yapılan performans çalışması, kaynakları düşük getirili alanlara bağlar. En acı verici senaryo, haftalarca uğraşılan bir optimizasyonun sonunda ölçülebilir hiçbir iyileşme çıkarmamasıdır. Yol haritası, bu riski ortadan kaldırır.

Gerçek dünyadan örnek

Bir girişim, teknik borç listesini önem sırasına koyup ilk iki haftayı yalnızca görsel optimizasyonuna ve önbelleğe ayırdı. Bu iki başlık, toplam iyileşmenin yüzde 70'ini tek başına getirdi. Daha sonra yapılan kapsamlı altyapı çalışmaları ise kalan yüzde 30'u tamamladı.

Pratik çözüm önerisi

Ölçün: Search Console ve hız test araçlarıyla mevcut durumu haritalayın.

Sıralayın: Etkisi yüksek, maliyeti düşük olanları öne alın (görseller, önbellek, gereksiz script'ler).

Projelendirin: Altyapı ve mimari işlerini planlı takvime yayın.

Oturtun: Performans bütçesi ve yayın öncesi kontrollerini sürece yerleştirin.

Sonuç: Hız, Bir Sitenin Karakteri

Bu makalede web performansını uçtan uca ele aldık: Kullanıcının gördüğü ilk andan, sunucunun milisaniyeler seviyesindeki yanıtına; tek bir görselin boyutundan, tüm sitenin mimari kararlarına. Görünen o ki, hızlı bir site tesadüfen ortaya çıkmıyor. Hız, her aşamada bilinçli kararlar veren, ölçen ve koruyan bir yaklaşımın ürünü.

noves.digital olarak bir web projesine başlarken ilk günden itibaren sorduğumuz soru şudur: "Bu tasarım, bu altyapı, bu içerik; kullanıcıya ulaşırken ne kadar hızlı olacak?" Cevap tatmin edici değilse, o karar daha masadayken revize edilir. Çünkü biliyoruz ki estetik bir arayüz, yavaş bir deneyimle buluştuğunda anlamını kaybeder; ama hızlı bir altyapı üzerine kurulan her tasarım, markaya değer katar.

Web sitenizin performansı hakkında konuşmak, genellikle dijital varlığınızın genel sağlık durumunu konuşmaktır. Eğer bu makaledeki başlıklar size tanıdık geliyorsa ve "bizde de durumlar böyle" diyorsanız, doğru soruyu sormaya başlamışsınız demektir. Doğru sorunun cevabı ise hep aynı yerden geçer: Ölçmek, önceliklendirmek ve disiplinli bir şekilde iyileştirmek.

İsterseniz bu makaleyi Notion'a doğrudan yapıştırabileceğiniz düz metin formatında bir dosya olarak da hazırlayabilirim, ya da belirli bölümleri genişletip kısaltabilirim.