Web Sitenizi Gerçekten Nasıl Hızlandırırsınız

• Neden Laravel'den Next.js'e Geçtik?
• Next.js'teki İlk Lighthouse Denetimimiz Bize Ders Oldu
• Daha İyi Script Yönetimiyle JavaScript Paket Boyutunu Nasıl Azalttık?
• Next.js Görsel Optimizasyonu: WebP, CDN ve Priority Özelliği
• Next.js Render Stratejisi: Statik Üretim, ISR ve Dinamik Render
• SEO Yapılandırılmış Veri, hreflang ve OpenGraph Next.js'te
• Sonuçlar: Lighthouse Skoru 90'ın Üzerinde, LCP 2.5sn Altında, TTFB 100ms Altında

Herkes hızlı bir web sitesi ister, ancak farklı sitelerin farklı yolculukları vardır. Bu bizim deneyimimiz, mantığımız, yolculuğumuz ve sonuçlarımız. 2026'da sitemizi hızlandırmak için yaptıklarımız burada.

Web siteniz için daha kişiselleştirilmiş tavsiyeler almak isterseniz topluluğumuza katılın.

Bu yazının bir versiyonu, büyük bir planımız olduğunu, kusursuzca uyguladığımızı ve mükemmel şekilde optimize edilmiş bir site yayına aldığımızı anlatıyor. Gerçekte olan bu değildi.

Aslında olan şey, büyüyen bir kod tabanını devralmamız, uzun zamandır ilk kez bir Lighthouse denetimi yapmamız, mobilde 34 puan görmemiz ve oraya nasıl geldiğimiz hakkında uzun ve rahatsız edici bir konuşma yapmamız oldu.

Neden Laravel'den Next.js'e Geçtik?

Laravel'dan Next.js'e geçiş yapmak ilk içgüdümüz değildi, ancak zamanla en bariz tercih haline geldi. Pazarlama sitemiz bir Laravel uygulaması olarak başladı. Blade şablonları, sunucu tarafında oluşturulan HTML, biraz jQuery. O zamanki ölçeğimiz için gayet makuldü. Ancak ürün büyüdükçe; birden fazla dil desteği, canlı veri çeken fiyatlandırma sayfaları, gerçek trafik alan bir blog, karmaşık kimlik doğrulama akışları gibi ihtiyaçlar ortaya çıktıkça, bir zamanlar "gayet makul" olan çözüm "sessizce pahalıya mal olan bir yapıya" dönüştü.

Asıl sorun performans değildi. Sorun hızdı. Her ön yüz değişikliği PHP'ye dokunuyordu. Bir metin düzenlemesi bile arka uç dağıtımı gerektiriyordu. Yeni bir sayfa bölümü eklemek, verilerin denetleyicilerden, görünüm bestecilerinden geçip Blade dosyalarına kadar akması anlamına geliyordu. Ön yüze sahip olması gereken kişiler (tasarımcılar, pazarlamacılar, prodüksiyon ekibi) mühendisin devreye girmesi olmadan dokunamıyordu.

Next.js 15'e App Router ile geçiş yaptık. En kolay yol olduğu için değil, bize sunucu tarafı render, statik üretim, artımlı yeniden doğrulama ve düzgün bir bileşen modeli gibi her şeyi tek bir çatı altında sunduğu için. Karar doğruydu. Uygulamanın ise hâlâ düzeltmeye çalıştığımız pürüzleri oldu.

Next.js'te İlk Lighthouse Denetimimiz Bize Ders Oldu

Yeni Next.js sitemizde yaptığımız ilk Lighthouse denetimi beklediğimiz iyileşmeyi getirmedi. Yeni siteyi ayağa kaldırıp ilk kez çalıştırdığımızda, Laravel'e göre bir iyileşme bekliyorduk. Hemen olmadı, en azından hemen değil.

Bazı kategorilerde puan daha kötüydü. Bu, nedenini anlayana kadar kafa karıştırıcıydı: modern bir çerçeveye geçmek sitenizi otomatik olarak hızlı yapmaz. Size daha iyi araçlar sunar. Bu araçları doğru kullanmak ise ayrı bir sorundur.

Sitemizi yavaşlatan ilk şeyin render-blocking kaynaklar olduğunu fark ettik. JavaScript değil, bu konuda dikkatliydik. Sorun daha inceydi: veri çektiğimiz harici alan adlarında tarayıcı ipucu yoktu. Görsellerimiz "$static.plusclouds.com$" üzerinde yaşıyordu. API'miz "$apiv4.plusclouds.com$" idi. Hiçbirinin belge başlığında preconnect ipucu yoktu. Yani her sayfa yüklemesinde, tarayıcı HTML'yi ayrıştırıyor, harici bir alan adına yapılan isteği görüyor, ardından DNS çözümlemesi ve TCP el sıkışmasını sıfırdan başlatıyordu.

Kök yerleşime eklediğimiz iki satır bunu düzeltti:

<link rel="preconnect" href="https://static.plusclouds.com" />
<link rel="preconnect" href="https://apiv4.plusclouds.com" />

Neredeyse fazla basit gibi geliyor. Ancak preconnect ipuçları, sahip olmamanın maliyetinin her sayfa yüklemesinde, her ziyaretçi için katlanarak arttığı şeylerden biridir. Tarayıcı artık ilk görseli veya API çağrısını karşılamadan önce bu bağlantıları kurmaya başlar. Yani, sitenizi hızlandırmak istiyorsanız dikkat etmeniz gereken şeylerden biri de preconnect ipuçlarıdır.

Daha İyi Script Yönetimiyle JavaScript Paket Boyutunu Nasıl Azalttık

Daha iyi script yönetimiyle JavaScript paket boyutunu azaltmak, geçişimizde sessiz ama en etkili kazanımlardan biriydi. Laravel döneminde, scriptler organik olarak birikmişti. Burada bir analiz aracı, orada bir sohbet widget’ı, bir pazarlama kampanyası sırasında eklenip hiç kaldırılmayan üçüncü parti bir pixel. Her biri senkron veya ertelenmiş bir script etiketi olarak eklenmişti ve eklenme sıraları, özelliklerin yayına alınma sırasını yansıtıyordu; sayfanın gerçekten neye ihtiyacı olduğu ise pek düşünülmemişti.

Next.js’e geçtiğimizde, bu alışkanlıkların bir kısmını daha iyi script yönetimiyle beraber taşıdık. İki ikon kullanan bir bileşen, tüm ikon kütüphanesini import ediyordu. Sadece belirli bir dalda ihtiyaç duyulan yardımcı fonksiyonlar dosyanın en üstünde import ediliyordu. Hiçbir etkileşimi olmayan, sadece biri emin olmadığı için o şekilde yazılmış 'use client' olarak işaretlenmiş istemci bileşenlerimiz vardı.

Bunların her biri küçük unsurlar. Toplamda ise anlamlı şekilde daha büyük bir JavaScript paketi oluşturuyorlar. Kod tabanını sistematik olarak gözden geçirdik: Her üçüncü parti script, < head > içinde mi olması gerektiği yoksa ertelenip ertelenemeyeceği açısından değerlendirildi. Her büyük import, gerçek kullanımına göre kontrol edildi.

Tarayıcı API'lerine ihtiyaç duymayan bileşenler tekrar sunucu bileşenlerine dönüştürüldü. Paket boyutu azaldı ve bununla birlikte, sayfanın etkileşimli hale gelme süresi de kısaldı.

Siteyi daha hızlı hale getirmek için benimsediğimiz script paketi kuralı şu: Hiçbir şey ihtiyaç duyulana kadar içe aktarılmaz, sunucuda çalışabilecek hiçbir şey tarayıcıda çalışmaz ve görünür bir render'ı engellemediği sürece < head > içinde hiçbir şey yüklenmez.

Daha fazla potansiyel müşterinin hızlı web sitenize yönlendirilmesini istiyorsanız, satış sürecini otomatikleştiren yapay zeka aracımıza göz atın.

Next.js Görsel Optimizasyonu: WebP, CDN ve Priority Özelliği

Next.js görsel optimizasyonu — format dönüşümü, CDN üzerinden teslimat ve priority özelliği dahil — herhangi bir sayfadaki en maliyetli kalemdi ve bunu birden fazla kez yanlış yaptık. Herkes görsel optimizasyonuna başını sallar ama sonra gidip Figma’dan direkt olarak 3,7MB’lık bir JPEG yükler. Biz de tam olarak bunu yaptık. Hem de birkaç kez.

Oluşturduğumuz özel görsel yükleyici, tüm üretim trafiğini CDN’imizdeki imgproxy üzerinden yönlendiriyor. Her görsel, gerçekten ihtiyaç duyulan boyutlara yeniden boyutlandırılıyor, talep eden tarayıcıya uygun formatta sunuluyor ve uçta önbelleğe alınıyor. 390px ekranlı bir mobil ziyaretçi artık aynı görselin 1600px’lik versiyonunu indirmiyor. Yükleyici bunların hepsini şeffaf bir şekilde hallediyor; geliştirici normal bir < Image > etiketi yazıyor ve CDN gerisini hallediyor.

Ama format dönüşümü, teslimattan ayrı bir problem. Hızlı bir CDN’den sunulan bir JPEG hâlâ JPEG’dir. Hero arka planlarını ve büyük pazarlama görsellerini WebP’ye dönüştürmek dosya boyutlarını %60 ila %80 oranında azaltıyor. Ana sayfa hero’muzda 1,3MB’lık bir PNG vardı ve Lighthouse bunu üst üste dört denetimde işaretleyene kadar fark etmedik. O görsel WebP’de yaklaşık 200KB olmalıydı. CDN bunu düzeltemez; yalnızca kaynak dosyayı dönüştürmek bunu sağlayabilir.

Daha uzun süre yanlış yaptığımız bir diğer şey: Next.js görsellerinde priority özelliği. Framework, görselleri varsayılan olarak tembel yüklüyor; bu, sayfanın altındaki görseller için doğru davranış. Ancak En Büyük İçerikli Boya (genellikle hero görseli) asla tembel yüklenmemeli. priority eklemek, Next.js’e o görseli önceden yüklemesini ve isteğe bağlı içerik gibi davranmamasını söylüyor. Sadece bir özellik. LCP iyileşmesi anında ve ölçülebilir şekilde gerçekleşiyor.

Next.js Render Stratejisi: Statik Üretim, ISR ve Dinamik Render

Doğru Next.js render stratejisini seçmek (statik üretim, ISR veya dinamik render) frameworkteki en önemli mimari kararlardan biridir ve gerçek performans sonuçları vardır.

Her istekte sunucuda render edilen, derleme zamanında statik olarak üretilen, periyodik yeniden doğrulama ile statik olarak üretilen: bunlar farklı problemler için farklı araçlardır ve yanlış olanı kullanmak gerçek performans sorunlarına yol açar.

Ürün sayfalarımız (sunucu özellikleri, fiyatlandırma katmanları, özellik dokümantasyonu) dakikada bir değişmiyor. Artık generateStaticParams ile ISR'ı ve bir saatlik yeniden doğrulama penceresini birlikte kullanıyoruz. Derleme zamanında, her dil kombinasyonu için statik HTML olarak önceden render ediliyor. Bir kullanıcı bir ürün sayfasına girdiğinde, CDN edge'den 100 ms'nin altında önbelleğe alınmış bir dosya sunuluyor. Sunucu yok, veritabanı sorgusu yok, Node.js süreci uyanmıyor.

Taze veri gerektiren sayfalar (blog ana sayfası, canlı fiyatlandırma, kullanıcıya özel her şey) kısa yeniden doğrulama pencereleri veya bileşen seviyesinde önbellekleme ile dinamik render kullanıyor. Sonuç olarak, trafiğimizin ezici çoğunluğu statik HTML'den sunuluyor ve sunucu yalnızca içerik gerçekten değiştiğinde gerçek iş yapıyor.

Çoğu sayfada TTFB artık tutarlı bir şekilde 100 ms'nin altında. Eski Laravel kurulumunda nadiren 400 ms'nin altına iniyordu. Bu, frameworkün sihir yapması değil; her sayfa için hangi render stratejisinin mantıklı olduğuna bilinçli olarak karar vermenin bir sonucudur.

SEO yapılandırılmış veriler, hreflang etiketleri ve OpenGraph meta verileri kullanıcılar için görünmezdir ama her şey için önemlidir ve taşındığımızda neredeyse hiç yoktu. Google'ın üretken yapay zeka özellikleri için optimize etmek, uygun şema işaretlemesine sahip, iyi yapılandırılmış ve taranabilir içerik gerektirir.

Ürün ve özellik sayfalarına FAQPage JSON-LD ekledik. Araçlarımız için SoftwareApplication şeması kullandık. Navigasyon hiyerarşisi için BreadcrumbList ekledik. Ana düzen dosyasında Organization şeması bulunuyor. Bunlar, arama tarayıcıları ve içeriğinizi oluşturulan özetlerde ve yanıt kutularında gösterip göstermemeye karar veren yapay zeka sistemleri tarafından okunuyor.

Hreflang durumu daha da karışıktı. Dört yerel dil destekliyoruz ve alternatif linklerimiz en iyi ihtimalle tutarsız, en kötü ihtimalle eksikti. Tek bir yol argümanından doğru hreflang etiketleri üreten ve her sayfada çalışan ortak bir buildAlternates() fonksiyonu oluşturduk. Bu, ev işleri gibi hissettiren ama yanlış veya eksik hreflang etiketlerinin uluslararası arama performansınıza aktif olarak zarar verdiğini fark edene kadar önemini anlamadığınız türden bir şey.

OpenGraph meta verileri de benzerdi, bazı sayfalarda vardı, bazılarında yoktu, görsel boyutları tutarsızdı. Bunu Next.js'in generateMetadata API'si üzerinden merkezileştirip kök yerleşime metadataBase eklemek, sayfa bazında düşünmeyi bırakıp her yerde varsayılan olarak doğru yapmamızı sağladı.

Sonuçlar: Lighthouse Skoru 90'ın Üzerinde, LCP 2.5sn Altında, TTFB 100ms Altında

Geçişten sonra, mobilde Lighthouse puanımız sürekli olarak 90'ın üzerinde. CLS 0.05'in altında. LCP çoğu sayfada 2.5 saniyenin altında. Statik olarak sunulan içerik için TTFB 100ms'nin altında.

Henüz bitmedi. Hâlâ WebP olması gereken ama olmayan görseller, statik olarak üretilebilecekken dinamik render edilen sayfalar ve daha spesifik olabilecek yapılandırılmış veriler var. Liste eskisinden daha kısa, ama asla sıfıra inmiyor.

Tüm bunlardan çıkarılan dürüst ders şu: performans bitirdiğiniz bir proje değil, kurduğunuz varsayılanlar bütünüdür. Her hero görselinde PR birleşmeden önce priority. Yeni bir dış alan adı eklendiği gün preconnect. Yapılandırılmış veri, sayfa içeriğiyle birlikte yazılır, sonradan eklenmez. İçe aktarmalar, bundle ağırlığı olmadan önce denetlenir.

Bunlar alışkanlık haline geldiğinde, biriken kararları düzeltmek için sprintler harcamayı bırakır ve varsayılan olarak hızlı gönderim yapmaya başlarsınız.

Web siteniz için daha kişiselleştirilmiş tavsiye almak isterseniz topluluğumuza katılın.

Sunucularımıza göz atarak hızlı ve akıllı altyapıyı tek bir panelden kullanmaya başlayın. Otomatik yedekleme ve geri yükleme, zamanlanmış sağlık kontrolleri ve anında ölçeklendirme gibi ücretsiz özelliklerimiz, web sitenizin daha iyi çalışmasına yardımcı olur. Buradan inceleyebilirsiniz.

::cta:altyapı::