Hızlı Web Sitesi Geliştirme

Hız, modern bir web sitesinin en görünür ama çoğu zaman en geç fark edilen özelliğidir. Ziyaretçi daha tek bir paragraf okumadan sitenin nasıl hissettirdiğini anlar. Sayfa geç açılıyorsa, görseller sonradan zıplıyorsa, menüye tıklayınca tepki gecikiyorsa ya da form alanları yavaş yükleniyorsa güven duygusu zayıflar. Kullanıcı bunu “teknik performans problemi” diye adlandırmaz; yalnızca sitenin ağır, eski veya bakımsız olduğunu hisseder.

Aynı durum Google için de geçerlidir. Google bir siteyi yalnızca içerik kalitesiyle değerlendirmez; o içeriğe ne kadar hızlı, kararlı ve sorunsuz ulaşıldığına da bakar. İyi yazılmış bir sayfa, kötü bir teknik deneyimin içinde değerini kaybedebilir. Bu yüzden performans, tasarımın ya da yayına alma sürecinin sonunda kontrol edilecek küçük bir madde değil, sitenin temel mimarisine en baştan işlenmesi gereken bir konudur.

Bu sayfa, web geliştirme hizmetimin performans tarafını anlatır. Yani “siteyi yaptım, yayına aldım” anlayışının ötesine geçer. Bir sitenin nasıl daha hafif, daha hızlı, daha kararlı ve uzun vadede daha sürdürülebilir kurulabileceğini açıklar. Benim için hız, sonradan eklenecek bir hızlandırma paketi değil; doğru teknoloji seçimi, sade mimari, kontrollü kaynak kullanımı ve ölçülebilir geliştirme sürecinin doğal sonucudur.

Hız aynı zamanda SEO’nun temelidir. Çünkü hızlı bir site daha rahat taranır, kullanıcıyı daha az bekletir, sayfalar arasında geçişi kolaylaştırır ve dönüşüm ihtimalini artırır. Buradaki hedef yalnızca PageSpeed skorunu yeşile çevirmek değildir. Asıl mesele, gerçek kullanıcıların siteyi gerçekten hızlı hissetmesidir. Arama motorları da giderek bu gerçek deneyime daha fazla önem verir.

Neden çoğu site yavaşlar?

Yavaş sitelerde genellikle tek bir suçlu yoktur. Sorun çoğu zaman küçük kararların üst üste birikmesiyle oluşur. İlk başta zararsız görünen eklentiler, gereksiz kütüphaneler, büyük görseller, ölçülmeden eklenen üçüncü parti script’ler ve kontrolsüz tasarım tercihleri zamanla siteyi ağırlaştırır. Sayfa açılır ama zor açılır. İçerik gelir ama geç gelir. Kullanıcı tıklamak ister ama tarayıcı hâlâ arka planda kod çalıştırıyordur.

En sık karşılaştığım nedenler şunlardır:

• Aşırı JavaScript — Ağır framework kullanımı, gereksiz kütüphaneler ve her sayfada çalışan üçüncü parti script’ler performansı ciddi biçimde düşürür. Chat araçları, analytics etiketleri, reklam kodları, ısı haritası script’leri ve tag manager içinde unutulmuş eski izleme kodları buna örnektir. Tek başlarına küçük görünebilirler; birlikte tarayıcıyı yorar, özellikle mobil cihazlarda sayfanın etkileşime hazır hâle gelmesini geciktirirler.

• Optimize edilmemiş görseller — Bir görselin ekranda küçük görünmesi, dosya olarak da küçük olduğu anlamına gelmez. Mobilde küçük bir kart içinde kullanılan fotoğrafın aslında çok büyük bir JPG ya da PNG olarak yüklenmesi sık görülen bir hatadır. Kullanıcı görselin küçük hâlini görür ama arka planda gereksiz büyüklükte dosya indirir. Doğru boyutlandırma yapılmadığında, AVIF ve WebP gibi modern formatlar kullanılmadığında sayfanın yükü gereksiz yere artar.

• Render-blocking kaynaklar — Tarayıcı sayfayı çizebilmek için bazı CSS ve JavaScript dosyalarını bekler. Bu kaynaklar gereksiz büyükse, yanlış sırada yükleniyorsa ya da ilk ekranda ihtiyaç duyulmayan kodlar başlangıcı engelliyorsa kullanıcı boş ekranla karşılaşır. Hız algısını bozan en kritik noktalardan biri budur: İçerik vardır ama kullanıcı henüz göremez.

• Geç yüklenen fontlar — Font yönetimi çoğu projede önemsenmez. Oysa metnin görünmesi için font dosyasının indirilmesini beklemek, özellikle mobil bağlantılarda rahatsız edici olabilir. Bazen kullanıcı birkaç saniye boş alan görür, bazen sistem fontuyla gelen metin sonradan değişir. Bu da hem görsel kararlılığı hem de profesyonellik hissini etkiler.

• Yavaş sunucu ve önbellek eksikliği — Sayfa daha tarayıcıya ulaşmadan sunucuda bekliyorsa, ön yüzde yapılan iyileştirmelerin etkisi sınırlı kalır. Yüksek TTFB, zayıf hosting, yanlış yapılandırılmış önbellek ve CDN kullanılmaması sitenin her istekte gereksiz yere yeniden çalışmasına neden olabilir.

• Her sayfaya her şeyi yükleme alışkanlığı — Yalnızca iletişim sayfasında gereken harita script’inin tüm sayfalarda yüklenmesi, sadece bir blog yazısında kullanılan galeri kütüphanesinin ana sayfaya da gelmesi çok yaygındır. Bu yaklaşım geliştirme sırasında kolay görünebilir ama performans için pahalıdır. İyi yapılandırılmış bir sitede her sayfa yalnızca gerçekten ihtiyaç duyduğu kaynakları yüklemelidir.

Bu sorunların ortak noktası şudur: Site bir anda yavaşlamaz; zamanla ağırlaşır. “Bir eklenti daha”, “bir script daha”, “bir font daha” derken kullanıcıya gönderilen yük büyür. Bu yüzden performansı proje başında ele alırım. Sonradan hızlandırmak mümkündür, ama en temiz ve kalıcı sonuç genellikle doğru mimariyle baştan kurulan sitelerde alınır.

Hafif, içerik öncelikli mimari

Pazarlama siteleri, kurumsal sayfalar, hizmet sayfaları, bloglar ve içerik odaklı yapılar için çoğu zaman ağır bir istemci tarafı uygulamaya gerek yoktur. Kullanıcı sayfayı okumak, hizmeti anlamak, form doldurmak veya başka bir sayfaya geçmek ister. Bunun için tarayıcıya büyük bir JavaScript paketi göndermek çoğu senaryoda gereksizdir.

Bu nedenle pazarlama ve içerik sitelerini, hafif ve içerik öncelikli bir altyapıyla kurarım. Buradaki temel fikir, sayfayı sunucuda veya build aşamasında HTML olarak üretmek ve tarayıcıya varsayılan olarak neredeyse hiç JavaScript göndermemektir. Sadece gerçekten etkileşim gereken alanlarda küçük “ada”lar kullanılır. Örneğin mobil menü, tema değiştirici, küçük bir filtreleme bileşeni veya form etkileşimi script alabilir. Geri kalan sayfa düz, hızlı ve okunabilir HTML olarak gelir.

Bu yaklaşımın pratik sonucu nettir: Tarayıcı daha az dosya indirir, daha az kod ayrıştırır, daha az kod çalıştırır. Bu fark özellikle mobil cihazlarda hissedilir. Çünkü performans yalnızca internet hızına bağlı değildir; cihazın işlem gücü de önemlidir. Eski veya orta seviye bir telefonda gereksiz JavaScript, sayfa görünse bile tıklamaların gecikmesine yol açabilir.

Bu yaklaşımla kurulan bir sayfada içerik önce gelir; stiller gömülü tutulur ve JavaScript en aza iner. Okunabilirlik, erişilebilirlik ve hız önceliklidir. Etkileşim gerekiyorsa eklenir; ama sadece gerektiği kadar. Bu sadelik yalnızca hızı artırmaz, bakım kolaylığı da sağlar. Site ne kadar kontrollü olursa, ileride geliştirmek ve korumak o kadar kolay olur.

Performans mühendisliği: katman katman

Hızlı site yapmak tek bir ayarla olmaz. “Bir eklenti kuralım, hızlansın” yaklaşımı kalıcı çözüm değildir. Performans; görselden fonta, CSS’ten JavaScript’e, sunucudan önbelleğe kadar birçok katmanın birlikte doğru çalışmasıyla oluşur. Ben bu süreci parça parça ele alırım.

• Görsel optimizasyonu — Görseller çoğu sitede en büyük yüklerden biridir. Her görsel kullanım yerine göre doğru boyutta hazırlanmalıdır. Masaüstü için gereken boyutla mobil için gereken boyut aynı değildir. AVIF ve WebP gibi modern formatlar tercih edilir. Görselin kaplayacağı alan width/height ile önceden belirtilir. Böylece sayfa yüklenirken içerik aşağı yukarı kaymaz ve CLS sorunu azalır. Kritik olmayan görseller lazy load ile ihtiyaç duyuldukça yüklenir.

• Font yönetimi — Fontlar kullanıcı deneyimini güçlendirebilir ama yanlış kullanıldığında performansı bozar. Fontları mümkün olduğunda self-host ederim. Böylece üçüncü parti font servislerine ekstra istek gitmez. font-display ayarıyla metnin görünürlüğü kontrol edilir. Kritik font gerekiyorsa preload ile erkenden yüklenmesi sağlanır. Ancak her fontu preload etmek çözüm değil, yeni bir yük olabilir; burada ölçülü davranmak gerekir.

• CSS mimarisi — Sayfanın ilk görünümü için gereken stiller önceliklidir. Kritik CSS inline kullanıldığında tarayıcı ekstra dosya beklemeden sayfayı çizmeye başlayabilir; küçük içerik sayfalarında tüm CSS’i HTML içine gömmek render-blocking isteği tamamen ortadan kaldırır. Daha büyük projelerde CSS parçalanır, kullanılmayan stiller temizlenir ve her sayfaya yalnızca gerekli olan stil gönderilir.

• JavaScript kontrolü — JavaScript gerektiğinde kullanılır, alışkanlık gereği değil. Gereksiz hydration’dan kaçınırım. Bir bileşen yalnızca statik içerik gösteriyorsa tarayıcıda yeniden canlandırılmasına gerek yoktur. Etkileşim gereken kodlar bölünür, ertelenir ve küçük tutulur. Sadece menü açıp kapatmak için büyük bir framework yüklemek yerine basit ve hafif bir çözüm tercih edilir.

• Önbellek ve CDN — Hız yalnızca ön yüzde bitmez. Statik HTML’in hızlı servis edilmesi, asset’lerin doğru cache politikasıyla sunulması ve içeriğin kullanıcıya yakın bir edge noktadan verilmesi önemlidir. Cloudflare edge üzerinden dağıtım, hash’li asset’ler için uzun cache süreleri ve statik HTML’in hızlı servis edilmesi bu yüzden değerlidir. Kullanıcı aynı dosyaları tekrar tekrar indirmek zorunda kalmaz.

• Sayfa yapısı ve içerik önceliği — İlk ekranda neyin görüneceği önemlidir. Kullanıcının önce ihtiyaç duyduğu başlık, açıklama, ana görsel ve temel gezinme alanları hızlı gelmelidir. Alt kısımda kalan içerikler daha sonra yüklenebilir. Böylece kullanıcı sayfanın hazır olduğunu daha erken hisseder.

• Üçüncü parti script disiplini — Analytics, reklam, chat, CRM ve benzeri araçlar bazen gereklidir. Ama her biri ölçülerek eklenmelidir. Kullanılmayan araçlar kaldırılır. Gerekli olanlar mümkünse ertelenir, sadece ilgili sayfalarda çalıştırılır veya daha hafif alternatiflerle değiştirilir.

Bu katmanlar birlikte ele alındığında site yalnızca testlerde iyi görünmez; günlük kullanımda da rahat, kararlı ve hızlı çalışır. Asıl hedef budur.

Ölçüm: laboratuvar testi ve gerçek kullanıcı verisi

Performans ölçmeden yönetilemez. Ancak tek bir araca bakmak da yanıltıcıdır. Lighthouse ve PageSpeed gibi araçlar sentetik testlerdir. Belirli bir cihaz, bağlantı ve koşul simülasyonu üzerinden sonuç üretirler. Sorunları görmek, darboğazları tespit etmek ve teknik iyileştirmeleri takip etmek için çok faydalıdırlar; ama tek başlarına yeterli değildirler.

Asıl önemli olan gerçek kullanıcı verisidir. CrUX verileri ve Search Console’daki Core Web Vitals raporu bu yüzden değerlidir. Çünkü gerçek insanların, gerçek cihazlarla, gerçek bağlantılar üzerinden yaşadığı deneyimi gösterir. Laboratuvar testinde yeşil görünen bir site, sahada kırmızı olabilir. Bunun nedeni kullanıcı kitlesinin ağırlıklı olarak mobil cihazlardan gelmesi, bağlantı koşullarının değişmesi veya bazı sayfa türlerinin test edilenden daha ağır olması olabilir.

Özellikle üç metriğe bakarım:

• LCP — Sayfanın ana içeriğinin ne kadar hızlı göründüğünü anlatır. Büyük hero görseller, yavaş sunucu yanıtı veya render-blocking kaynaklar LCP’yi etkileyebilir.

• CLS — Sayfa yüklenirken içeriklerin ne kadar kaydığını gösterir. Görsellere boyut verilmemesi, geç gelen reklam alanları veya sonradan yüklenen fontlar bu değeri bozabilir.

• INP — Kullanıcının tıklama, dokunma veya klavye etkileşimine sitenin ne kadar hızlı yanıt verdiğini ölçer. Aşırı JavaScript ve uzun süren ana iş parçacığı işlemleri burada sorun yaratır.

Bu metriklere yalnızca skor olarak bakmam. Sorunun kaynağını incelerim. LCP kötüyse sadece görseli sıkıştırmak yeterli olmayabilir; sunucu yanıtı, CSS yükleme sırası ve font stratejisi de etkili olabilir. INP zayıfsa problem çoğu zaman kullanıcı tıkladığı anda çalışan ağır JavaScript’tedir. CLS sorunu varsa sayfa iskeleti, görsel boyutları ve geç yüklenen öğeler birlikte değerlendirilmelidir.

Yeni site ya da mevcut site hızlandırma

Performans çalışması iki şekilde yapılabilir. Yeni bir site kurulacaksa hız en baştan mimarinin içine yerleştirilir. Kullanılacak teknoloji, sayfa yapısı, görsel stratejisi, font seçimi, içerik modellemesi ve dağıtım altyapısı buna göre planlanır. Bu en temiz yoldur; çünkü sonradan tamir etmek yerine baştan hafif, ölçülebilir ve sürdürülebilir bir yapı kurulur.

Mevcut bir site hızlandırılacaksa önce ölçüm yapılır. Hangi sayfalar yavaş, hangi kaynaklar ağır, hangi script’ler gerçekten gerekli, hangi görseller yanlış boyutta, sunucu nerede bekletiyor; bunlar tek tek incelenir. Sonra etkisi yüksek adımlardan başlanır. Bazen birkaç gereksiz script’in kaldırılması bile ciddi fark yaratır. Bazen asıl sorun görsellerdedir. Bazen de altyapı, önbellek veya CDN tarafında çözülmesi gereken daha temel bir darboğaz vardır.

Amaç yalnızca raporda daha iyi puan almak değil; kullanıcıya daha hızlı açılan, daha kararlı çalışan ve daha güven veren bir site sunmaktır. Yeni bir siteyi performans odaklı kurmak ya da mevcut sitendeki yavaşlıkları temizlemek istiyorsan, detayları konuşmak için bana yaz.