Gerçekten Dönüşüm Sağlayan Yüksek Performanslı Web Sitesi Nasıl İnşa Edilir

Yüksek performanslı bir web sitesi inşa etmek, bitmiş bir projenin üstüne bir önbellekleme eklentisi serpiştirmek ve en iyisini ummakla ilgili değil. İlk kod satırı yazılmadan önce gerçekleşmesi gereken mimari bir karar. Yine de çoğu ekip hızı daha sonra düzeltilecek bir şey olarak ele alıyor — tasarım kilitlendikten sonra, içerik yüklendikten sonra, müşteri hemen çıkma oranlarından şikâyet etmeye başladıktan sonra.

Gerçek şu: sayfa yüklemesindeki bir saniyelik gecikme dönüşümleri %20'ye kadar düşürebilir. Bir saniyede yüklenen siteler, beş saniyede yüklenen sitelere kıyasla 3 kat daha yüksek dönüşüm oranına sahip. Bunlar varsayımsal rakamlar değil — Cloudflare ve Portent'in gerçek dünya çalışmalarından geliyor. Performans gelirdir. Ve web geliştirme ortağınız bunu projenin her aşamasına dahil etmiyorsa, parayı masada bırakıyorsunuz demektir.

Rakamlarla başlayalım çünkü görmezden gelmesi zor bir hikâye anlatıyorlar. Kötü UX'in SEO ve dönüşümleri nasıl yok ettiğine dair rehberimizde incelediğimiz gibi, performans sorunları çoğu zaman kılık değiştirmiş UX sorunlarıdır — ve Google ikisini de ölçüyor.

Google, 2010'dan bu yana sayfa hızını bir sıralama sinyali olarak kullanıyor, ancak 2021'de Core Web Vitals'ın tanıtımı bunu açık hale getirdi: siteniz yavaşsa, daha düşük sıralanacaksınız. Nokta. 2026'da, INP (Interaction to Next Paint) temel metrik olarak FID'in tamamen yerini aldıkça, çıta yalnızca yükseldi.

Ancak SEO sıralamaları resmin sadece bir parçası. Kullanıcı tarafında neler olduğunu düşünün:

• Mobil ziyaretçilerin %53'ü ayrılıyor sayfanın yüklenmesi 3 saniyeden uzun sürerse.
• 2 saniyelik gecikme hemen çıkma oranlarını %103 artırıyor.
• Çevrimiçi alışveriş yapanların %79'u kötü performans yaşadıklarında o siteye geri dönmeyeceklerini söylüyor.
• 1 saniyede yüklenen B2B siteleri, 10 saniyede yüklenen sitelerden 5 kat daha yüksek dönüşüm sağlıyor.

Örüntü açık. Hız teknik bir incelik değil — bir iş metriği. Yükleme sürenizden kırptığınız her yüz milisaniye doğrudan etkileşime, müşteri adaylarına ve satışa dönüşüyor.

Geliştirici olarak beni hayal kırıklığına uğratan şu: müşteri sitelerinde gördüğüm performans sorunlarının çoğu tamamen önlenebilir nitelikte. Çözülemez teknik kısıtlamalardan değil, projenin başında yapılan kötü mimari seçimlerden kaynaklanıyorlar.

Hızlı bir web sitesi inşa edecekseniz, performans ölçümünün dilini konuşmanız gerekiyor. Google'ın Core Web Vitals bize üç spesifik, ölçülebilir hedef sunuyor:

Largest Contentful Paint (LCP) — Hedef: 2,5 saniyenin altında

LCP, sayfadaki en büyük görünür öğenin render edilmesinin ne kadar sürdüğünü ölçüyor. Genellikle bu bir hero görseli, başlık bloğu veya video küçük resmidir. Kullanıcıların "sayfa yüklendi" olarak algıladığı şey budur. Yavaş bir LCP çoğunlukla optimize edilmemiş görsellere, yavaş sunucu yanıtlarına veya render'ı engelleyen kaynaklara işaret ediyor.

Interaction to Next Paint (INP) — Hedef: 200 milisaniyenin altında

INP, Mart 2024'te First Input Delay'in yerini aldı ve sayfanızın tüm oturum boyunca kullanıcı etkileşimlerine — yalnızca ilk tıklama değil — yanıt verme hızını ölçüyor. Biri bir butona dokunduğunda veya bir açılır liste açtığında siteniz hantal hissettiriyorsa, INP sorununuz var demektir. Ağır JavaScript ve büyük DOM ağaçları olağan suçlulardır.

Cumulative Layout Shift (CLS) — Hedef: 0,1'in altında

CLS, sayfadaki beklenmedik görsel hareketi izliyor. Mobilde bir bağlantıya dokunmaya çalışmış, ardından bir reklamın yüklenerek içeriği aşağı itmesini yaşadınız mı? Düzen kayması bu. Boyutları olmayan görseller, dinamik olarak eklenen içerik ve ilk render'dan sonra değişen web yazı tipleri bu duruma neden oluyor.

Bu üç metrik size somut bir çerçeve sunuyor. "Hızlı bir site" hedeflemenin ötesinde, Google'ın sayfalarınızı değerlendirmek için kullandığı spesifik, ölçülebilir rakamları hedefliyorsunuz. Her mimari ve optimizasyon kararı bu metrikler aracılığıyla süzülmeli. Bu puanları daha geniş bir UX ölçüm pratiğinin parçası olarak nasıl izleyeceğinizi ve yorumlayacağınızı anlamak istiyorsanız, gerçekten iş sonuçlarını etkileyen UX metrikleri rehberimiz Core Web Vitals'ı izlemeye değer tam göstergelerle birlikte ele alıyor.

Çoğu projenin yanlış gittiği yer burası. Ekip, popüler veya tanıdık olan şeye dayanarak bir teknoloji yığını seçiyor, sayfa oluşturucu veya ağır bir CMS ekliyor, eklentiler ve üçüncü taraf komut dosyaları yığıyor, ardından PageSpeed Insights'ın neden 47 puan gösterdiğini merak ediyor.

Performans mimari düzeyde başlar. Render stratejisi, barındırma altyapısı ve kod organizasyonu hakkında yaptığınız seçimler performans tavanınızı belirliyor — sitenizin daha sonra ne kadar optimizasyon yaparsanız yapın ulaşabileceği maksimum hız.

Geliştirme başlamadan önce sormaya değer birkaç soru:

• Sayfalar nasıl render edilecek? İstemci tarafı render, sunucu tarafı render, statik üretim veya hibrit bir yaklaşım? Her birinin farklı performans profilleri var.
• Barındırma ortamı nedir? Paylaşımlı barındırma, VPS, sunucusuz işlevler veya edge bilişim? Sunucu yanıt süreniz (İlk Bayta Süre) diğer her şeyin temelini oluşturuyor.
• Çerçeve varsayılan olarak ne kadar JavaScript gönderiyor? Bazı çerçeveler tek bir bileşen yazmadan önce 200KB+ JavaScript gönderiyor.
• Site statik varlıkları bir CDN'den sunabilir mi? Edge önbellekleme, çoğu sayfa yüklemesinde sunucu gidiş dönüşlerini tamamen ortadan kaldırabilir.

Doğru yanıtlar projenizin özel gereksinimlerine bağlı. Çoğunlukla statik içeriğe sahip bir kurumsal web sitesinin gereksinimleri gerçek zamanlı verilerle dinamik bir web portalından çok farklı. Ama ilke aynı: performansı son dakika onay kutusuna değil, birinci sınıf tasarım kısıtına dönüştürün.

2026'da web geliştirme dünyası render tartışmasını büyük ölçüde kapattı. Sunucu öncelikli varsayılan, ve bunun iyi nedeni var.

Sunucu tarafı render (SSR) ile sunucu, tarayıcıya tamamen oluşturulmuş bir HTML sayfası gönderiyor. Kullanıcı, JavaScript'in indirilmesini, ayrıştırılmasını ve çalıştırılmasını beklemeden neredeyse anında içeriği görüyor. Bu, LCP için büyük bir kazanım — en büyük içerik öğesi, sayfa geldiğinde zaten HTML'de mevcut.

Statik site üretimi (SSG) bunu daha da ileriye taşıyor. Sayfalar dağıtım zamanında önceden oluşturuluyor ve bir CDN'den düz HTML dosyaları olarak sunuluyor. Sunucu işlemi yok, veritabanı sorguları yok, istek anında API çağrısı yok. Sonuç? İki haneli milisaniyelerle ölçülen İlk Bayta Süre.

Next.js, Astro ve Nuxt gibi çerçeveler burada ayrıntılı kontrol sunuyor. Pazarlama sayfalarınızı statik olarak oluşturabilir, dinamik kontrol panelinizi sunucu tarafında render edebilir ve yalnızca gerçekten ihtiyaç duyan interaktif widget'ları istemci tarafında render edebilirsiniz. Bazen "adaları mimarisi" olarak da adlandırılan bu hibrit yaklaşım, her render stratejisinin en iyisini ödün vermeden elde etmenin yolu.

Temel içgörü: sunucuda render edebileceğinizi istemcide render etmeyin. Görüntülemeye hazır HTML olarak gelen her içerik parçası, kullanıcının cihaz gücü veya ağ hızından bağımsız olarak anında yükleniyor.

Görseller çoğu web sayfasının toplam ağırlığının yaklaşık %50'sini oluşturuyor. Yalnızca bir performans optimizasyonu yapacaksanız, bu olsun.

Vezert'te her projede takip ettiğimiz kontrol listesi:

Modern formatlar kullanın. WebP, eşdeğer kalitede JPEG'den %25-35 daha küçük dosyalar sunuyor. AVIF bunu %50'ye kadar çıkarabiliyor. Her ikisi de 2026'da mükemmel tarayıcı desteğine sahip.

Duyarlı görseller sunun. 390 piksel ekranlı bir telefona 2400 piksel hero görseli göndermeyin. Her cihaz için doğru çözünürlüğü sunmak için srcset ve sizes özelliklerini (veya çerçevenizin görsel bileşenini) kullanın.

Ekranın altındaki görselleri tembel yükleyin. loading="lazy" özelliği, tarayıcıya henüz görünmeyen görsellerin yüklenmesini ertelemesini söylüyor. Bu, kullanıcının gerçekten önce ne gördüğüne öncelik vererek LCP'yi doğrudan iyileştiriyor.

Açık genişlik ve yükseklik ayarlayın. Boyutlar olmadan tarayıcı bir görsel için ne kadar alan ayıracağını bilmiyor. Görsel yüklendiğinde altındaki her şey kayıyor — ve CLS puanınız düşüyor.

LCP görselinizi önceden yükleyin. Hero görseliniz en büyük içeriksel boyama öğesiyse, tarayıcının CSS'i ayrıştırmadan önce anında getirmeye başlaması için bir <link rel="preload"> etiketi ekleyin.

Otomatik optimizasyon sağlayan bir CDN kullanın. Cloudflare, Vercel veya Imgix gibi hizmetler, isteyen cihaza göre görselleri otomatik olarak yeniden boyutlandırabilir, sıkıştırabilir ve dönüştürebilir. Tek yükleme, sonsuz optimize sürüm.

Görselleri düzgün yönetmek suretiyle toplam sayfa ağırlığını %60-70 azaltan siteler gördüm. Bu marjinal bir iyileştirme değil — bir dönüşüm.

JavaScript, bayt başına web'in en pahalı kaynağıdır. Yalnızca kodu çözülmesi ve boyatılması gereken bir görüntünün aksine, JavaScript'in indirilmesi, ayrıştırılması, derlenmesi ve çalıştırılması gerekiyor. Orta seviye bir Android telefonda (gerçek kullanıcılarınızın çoğunun sahip olduğu şey), 200KB JavaScript'i ayrıştırmak bir saniyeden uzun sürebilir.

JavaScript'i kontrol altında tutma yöntemimiz:

Kod bölme. Yalnızca mevcut sayfa için gereken JavaScript'i gönderin. Modern paketleyiciler (Webpack, Turbopack, Vite), kodunuzu otomatik olarak talep üzerine yüklenen daha küçük parçalara bölebilir.

Ağaç sallama. Paketleyicinizin kullanılmayan kodu kaldırdığından emin olun. Bir yardımcı kütüphaneden tek bir işlev içe aktarıyorsanız, tüm kütüphaneyi göndermeniz gerekmemeli.

Üçüncü taraf komut dosyalarını erteleyin. Analizler, sohbet widget'ları, ısı haritaları, etiket yöneticileri — bu komut dosyaları çoğu zaman 300-500KB JavaScript ekliyor. Ana içerik etkileşimli hale geldikten sonra yükleyin, öncesinde değil.

Bağımlılıklarınızı denetleyin. Tek bir hover efekti için eklediğiniz animasyon kütüphanesi? Paketinize 80KB ekliyor olabilir. Neredeyse her zaman daha hafif bir alternatif vardır veya animasyonu CSS'te yazabilirsiniz.

async ve defer özelliklerini akıllıca kullanın. Bu özellikler olmadan <head>'deki komut dosyaları render'ı tamamen engelliyor. Bunları doğru etiketleyin veya body'nin sonuna taşıyın.

Pratik bir hedef: kritik render yolunuz için toplam JavaScript'i 150KB'ın altında tutun (sıkıştırılmış). Bu, INP puanınızı düşürmeden bir çerçeve, yönlendirme ve temel etkileşim için yeterli.

Sunucunuz Virginia'da olabilir. Kullanıcınız Tokyo'da olabilir. Bu fiziksel mesafe, sunucu sayfayı işlemeye başlamadan önce her isteğe 150-300ms gecikme ekliyor.

Bir İçerik Dağıtım Ağı (CDN) bu sorunu, içeriğinizi dünya genelinde dağılmış sunucularda önbelleğe alarak çözüyor. Tokyo'daki bir kullanıcı sayfanızı talep ettiğinde, Virginia değil Tokyo'daki bir sunucudan alıyor. Gecikme tek haneli milisaniyelere düşüyor.

Ama CDN'ler yalnızca önbellekleme stratejiniz kadar iyidir. Tavsiyelerimiz:

Statik varlıkları agresif biçimde önbelleğe alın. CSS, JavaScript, görseller ve yazı tipleri dağıtımlar arasında değişmiyor. Cache-Control: max-age=31536000, immutable ayarlayın ve dosyalar değiştiğinde önbelleğin otomatik olarak geçersiz kılınması için içerik karma dosya adları kullanın.

Mümkün olduğunda HTML sayfalarını edge'de önbelleğe alın. İstekler arasında değişmeyen sayfalar için (pazarlama sayfaları, blog gönderileri, ürün listeleri), edge önbellekleme sunucuyu tamamen ortadan kaldırıyor. Vercel, Netlify ve Cloudflare Pages bu işlemi statik içerik için varsayılan olarak yapıyor.

Yarı dinamik içerik için stale-while-revalidate kullanın. Bu örüntü, arka planda taze bir kopya alırken önbelleğe alınmış sürümü anında sunuyor. Kullanıcılar anlık yanıtlar alıyor, içerik makul ölçüde güncel kalıyor.

Önbelleğe ALMAYACAĞINIZ şeyler konusunda bilinçli olun. Kişiselleştirilmiş içerik, kimliği doğrulanmış sayfalar ve gerçek zamanlı veriler edge'de önbelleğe alınmamalıdır. Bu isteklerin kaynak sunucunuza veya sunucusuz işlevlere gitmesine izin verin.

Edge bilişim bunu daha da ileri taşıyor — sunucu mantığını merkezi bir sunucu yerine CDN konumlarında çalıştırıyor. Konuma veya A/B testi varyantlarına dayalı farklı içerik sunması gereken bir açılış sayfası için edge işlevleri hem kişiselleştirme hem de hız sağlıyor.

Özel web yazı tipleri en sinsi performans sorunlarından biri. Birden fazla ağırlığa sahip tek bir yazı tipi ailesi sayfanıza 200-400KB ekleyebilir. Daha da kötüsü, yazı tiplerinin yüklenme şekli düzen kaymaları ve görünmez metne neden olabilir — her ikisi de Core Web Vitals'ınıza zarar verir.

İşe yarayan yaklaşım:

Yazı tipi ailelerini ve ağırlıklarını sınırlayın. Her biri iki ağırlıkla iki yazı tipi ailesi genellikle yeterli. Her ek ağırlık başka bir HTTP isteği ve 20-50KB veri ekliyor.

font-display: swap kullanın. Bu, tarayıcıya metni anında yedek bir yazı tipinde göstermesini, ardından hazır olduğunda özel yazı tipine geçmesini söylüyor. Kısa bir tipografi değişimi olsa bile kullanıcılar daha hızlı içerik görüyor.

Birincil yazı tipinizi önceden yükleyin. Hero bölümünüzde ve ana başlıklarınızda kullanılan yazı tipi dosyası için <link rel="preload" as="font" crossorigin> ekleyin. Bu, tarayıcıya CSS'i işlemeden önce erken getirmesini söylüyor.

Yazı tiplerini kendiniz barındırın. Google Fonts'tan yazı tipi yüklemek bir DNS araması, fonts.googleapis.com'a bağlantı ve ardından fonts.gstatic.com'a bağlantı gerektiriyor. Kendiniz barındırmak bu ekstra gidiş dönüşleri ortadan kaldırıyor.

Mümkün olduğunda değişken yazı tipleri kullanın. Tek bir değişken yazı tipi dosyası birden fazla ağırlık dosyasının yerini alabilir; istek sayısını ve toplam dosya boyutunu %50-70 azaltıyor.

CSS için aynı ilkeler geçerli: daha az gönderin, daha hızlı gönderin. Kritik CSS'inizi (ekranın üst kısmındaki içerik için gereken stiller) doğrudan <head>'e dahil edin ve geri kalanını erteleyin. Modern çerçeveler bunu otomatik olarak yapıyor, ama üretim yapılarınızda doğrulamaya değer.

Hızlı bir site inşa etmek bir şey. Onu hızlı tutmak başka bir şey.

Performans kademeli olarak bozuluyor. Burada yeni bir izleme komut dosyası, orada daha ağır bir görsel, kod incelemesinden geçen kötü optimize edilmiş bir bileşen. Aktif izleme olmadan, dikkatle optimize edilmiş siteniz aylar içinde 20-30 PageSpeed puanı kaybedebilir.

Performans bütçeleri temel metriklere sert sınırlar koyuyor:

• Toplam sayfa ağırlığı: 1,5MB'ın altında
• JavaScript paketi: 150KB'ın altında (sıkıştırılmış)
• LCP: 2,5 saniyenin altında
• INP: 200ms'nin altında
• CLS: 0,1'in altında
• İlk Bayta Süre: 200ms'nin altında

Bu bütçeler otomatik olarak uygulanmalıdır. Her çekme isteğinin performans puanı alması için Lighthouse CI'yi dağıtım hattınıza entegre edin. Puan eşiğin altına düşerse, dağıtım engellenir.

Gerçek kullanıcı izleme (RUM) için, Vercel Analytics, Sentry Performance veya Google'ın Chrome Kullanıcı Deneyimi Raporu (CrUX) gibi araçlar sitenizin gerçek ziyaretçiler için nasıl performans gösterdiğini gösteriyor — yalnızca laboratuvar koşullarında değil. Laboratuvar testleri hızlı donanım ve hızlı bağlantıyla çalışıyor. Kullanıcılarınız kırsal alanda 4G telefonla. RUM verisi gerçeği gösteriyor.

Core Web Vitals gerilediğinde uyarılar kurulumu yapın. Performans sorununu ne kadar erken yakalarsanız, düzeltmesi o kadar kolay oluyor.

Birçok ekibin yanlış yaptığı şey şu: gigabit bağlantılı bir MacBook Pro'da performansı test ediyor ve işi bitti sayıyor. Ancak web trafiğinin %60'ından fazlası mobil cihazlardan geliyor ve mobil performans temelden farklı bir sorun.

Mobil cihazların daha yavaş CPU'ları, daha az belleği var ve çoğu zaman kesintili 4G veya hatta 3G bağlantılarla çalışıyor. Geliştirme makinenizde 200ms'de ayrıştırılan bir JavaScript paketi, orta seviye Samsung telefonda 1,5 saniye alabilir.

Mobil öncelikli performans gerçekte nasıl görünüyor?

• Gerçek cihazlarda test edin. Chrome DevTools kısıtlaması yararlı bir yaklaşım, ama gerçek 200 dolarlık Android telefonda test etmenin yerini hiçbir şey tutmaz. Fark göz açıcı.
• Dokunmatik hedefler önemlidir. Google'ın WCAG 2.2 standartları minimum 24x24 piksel dokunmatik hedef öneriyor. Dar butonlar yalnızca kullanılabilirliği değil — gereksiz yeniden render'ları tetikleyen yanlış dokunuşlara neden olarak INP'ye de zarar veriyor.
• Mobilde JavaScript'i agresif biçimde azaltın. Mobil kullanıcılara basitleştirilmiş etkileşimli bileşen sürümleri sunmayı veya kritik olmayan etkileşimi tamamen ertelemeyi düşünün.
• Değişken ağ koşulları için optimize edin. Service worker'lar çevrimdışı veya zayıf bağlantı senaryoları için kritik varlıkları önbelleğe alabilir. Bant genişliği sınırlıyken duyarlı görseller daha da kritik hale geliyor.

Google'ın performans değerlendirmesi mobil öncelikli. PageSpeed puanınız, arama sıralamanız, Core Web Vitals değerlendirmeniz — bunların hepsi mobil deneyime dayanıyor. Masaüstü siteniz 95 puan alıyorsa ama mobil siteniz 60 puan alıyorsa, Google 60'ı görüyor.

Sürekli hızlı web siteleri sunan ekipler, performansı ayrı bir iş akışı olarak ele almıyor. Projenin her aşamasına dokuma gibi işliyor.

Keşif ve planlama sırasında:

• Rakip kıyaslamaları ve iş hedeflerine dayalı performans bütçeleri tanımlayın.
• Gereksinimlerinizle eşleşen performans özelliklerine sahip bir teknoloji yığını seçin.
• Ana açılış sayfalarınız için kritik render yolunu haritalayın.

Tasarım sırasında:

• Benzersiz yazı tipi ağırlıklarının ve özel animasyonların sayısını sınırlayın.
• Görsellerin başından itibaren doğru boyutlandırılması için gerçek içerik boyutlarıyla tasarım yapın.
• Aşamalı yükleme için plan yapın — kullanıcılar önce ne görmeli, sonra ne, ondan sonra ne?

Geliştirme sırasında:

• Her çekme isteğinde Lighthouse çalıştırın.
• Üçüncü taraf komut dosyalarını ayrı, denetlenebilir bir listede tutun.
• Çerçeveye özgü performans özelliklerini kullanın (Next.js Image, otomatik kod bölme vb.).

Lansmanın ardından:

• Gerçek kullanıcı performans verilerini haftalık izleyin.
• Bütçelerinize karşı üç aylık performans denetimleri yapın.
• Performans gerilemeyi hata olarak ele alın — hemen düzeltin.

Vezert'te her projeye bu şekilde yaklaşıyoruz; bir UX/UI tasarım yenilemesi olsun, tam yeniden inşa olsun. Performans bir aşama değil — bir disiplin.

Yüksek performanslı bir web sitesi lüks bir özellik değil. Çevrimiçi varlığını ciddiye alan her işletme için temel beklenti.

Teknikler sır değil: hızlı ilk yüklemeler için sunucu tarafı render, daha hafif sayfalar için görsel optimizasyonu, keskin etkileşimler için disiplinli JavaScript yönetimi, küresel hız için edge dağıtımı ve her şeyin geriye doğru kaymasını önlemek için sürekli izleme.

95+ puan alan siteleri diğerlerinden ayıran tek bir numara yok. Performansı baştan itibaren — mimaride, tasarımda, her çekme isteğinde ve süregelen bakımda — temel bir gereksinim olarak ele alma taahhüdü.

Mevcut siteniz Core Web Vitals'ı geçmekte zorlanıyorsa ya da yeni bir yapı planlıyorsanız ve performansın temele dahil edildiğinden emin olmak istiyorsanız, ekibimize ulaşın. Darboğazların tam olarak nerede olduğunu ve nasıl düzeltileceğini göstereceğiz — ya da başından itibaren doğru şekilde inşa edeceğiz.