Web Sitenizi Gerçekten Hızlı Hale Getirme Yolları

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

Herkes hızlı bir web sitesi ister, ancak farklı web siteleri farklı yolculuklar yaşar. Bu bizim deneyimimiz, mantığımız, yolculuğumuz ve sonuçlarımız. 2026'da web sitemizi daha hızlı hale getirmek için yaptıklarımız burada.

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

Bu gönderinin bir versiyonu, büyük bir planımız olduğunu, kusursuz bir şekilde uyguladığımızı ve mükemmel bir şekilde optimize edilmiş bir site sunduğumuzu anlatıyor. Ama olan bu değil.

Gerçekte olan, büyüyen bir kod tabanını devralmamız, bir süredir ilk Lighthouse denetimimizi yapmamız, mobilde 34 puan görmemiz ve oraya nasıl geldiğimiz hakkında uzun, rahatsız edici bir konuşma yapmamızdı.

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

Laravel'den Next.js'e geçmek ilk içgüdümüz değildi, ancak bariz bir seçim haline geldi. Pazarlama sitemiz bir Laravel uygulaması olarak başladı. Blade şablonları, sunucu tarafından işlenen HTML, biraz jQuery. O anki ölçek için mükemmel derecede makuldü. Ancak ürün büyüdükçe, birden fazla dil, canlı veri çeken fiyatlandırma sayfaları, gerçek trafik alan bir blog, karmaşık kimlik doğrulama akışları ile; bir zamanlar "mükemmel derecede makul" olan şey "sessizce pahalı" hale geldi.

Asıl sorun performans değildi. Hızdı. Her ön uç değişikliği PHP'ye dokunuyordu. Bir kopya düzenlemesi bir arka uç dağıtımı anlamına geliyordu. Yeni bir sayfa bölümü eklemek, verilerin denetleyicilerden, görünüm bestecilerinden, Blade dosyalarına akması anlamına geliyordu. Ön uca sahip olması gereken kişiler (tasarımcılar, pazarlamacılar, prodüksiyon) bir mühendis olmadan ona dokunamıyordu.

Next.js 15'e App Router ile geçtik. En kolay yol olduğu için değil, sunucu tarafı işleme, statik üretim, artımlı yeniden doğrulama ve uygun bir bileşen modeli sunduğu için. Karar doğruydu. Uygulama, hala düzeltmeye çalıştığımız pürüzlü kenarlara sahipti.

Next.js Üzerindeki İlk Lighthouse Denetimimiz Mütevazıydı

Yeni Next.js sitesindeki ilk Lighthouse denetimimiz beklediğimiz iyileşmeyi sağlamadı. Yeni siteyi kurup ilk kez çalıştırdığımızda, Laravel'e göre bir iyileşme bekliyorduk. Hemen bir iyileşme elde edemedik.

Bazı kategorilerde skor 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 verir. Bu araçları doğru kullanmak ayrı bir problemdir.

Sitemizi yavaşlatan ilk şeyin render engelleyici kaynaklar olduğunu fark ettik. JavaScript değil, bu konuda dikkatli olmuştuk. Sorun daha inceydi: tarayıcı ipuçları olmayan harici alan adlarından veri çekiyorduk. Görsellerimiz "$static.plusclouds.com$" üzerinde yaşıyordu. API'miz "$apiv4.plusclouds.com$" idi. Hiçbiri belge başlığında bir preconnect ipucuna sahip değildi. Bu yüzden her sayfa yüklemesinde, tarayıcı HTML'yi ayrıştırıyor, harici bir alan adına bir istekle karşılaşıyor ve ardından DNS çözümlemesi ve TCP el sıkışmasını sıfırdan başlatıyordu.

Ana düzenle iki satır bunu düzeltti:

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

Bu neredeyse çok basit geliyor. Ancak preconnect ipuçları, her sayfa yüklemesinde, her ziyaretçi için, onları bulundurmanın maliyetinin birikmesiyle ilgili bir şeydir. Tarayıcı artık ilk görsel veya API çağrısıyla karşılaşmadan önce bu bağlantıları kurmaya başlar. Bu yüzden, web sitenizi daha hızlı hale getirmek istiyorsanız preconnect ipuçlarına dikkat etmek önemlidir.

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

JavaScript paket boyutunu daha iyi script yönetimi ile azaltmak, geçişimizdeki daha sessiz ama en etkili kazanımlardan biriydi. Laravel döneminde, scriptler organik olarak birikmişti. Burada bir analiz, orada bir sohbet widget'ı, bir pazarlama kampanyası sırasında eklenen ve asla kaldırılmayan üçüncü taraf bir piksel. Her biri senkron veya ertelenmiş bir script etiketi idi ve eklenme sıraları, sayfanın gerçekten neye ihtiyaç duyduğuna dair herhangi bir düşünceli değerlendirme yerine, özelliklerin gönderildiği sırayı yansıtıyordu.

Next.js'e geçtiğimizde, bu alışkanlıkların bazılarını daha iyi script yönetimi ile taşıdık. İki simge kullandıklarında tüm simge kütüphanelerini içe aktaran bileşenlerimiz vardı. Sadece belirli bir dalda ihtiyaç duyulan yardımcı fonksiyonlar dosyaların üst kısmında içe aktarılmıştı. Hiçbir etkileşimi olmayan, sadece birinin emin olmadığı bir zamanda yazıldığı için 'use client' olarak işaretlenmiş istemci bileşenlerimiz vardı.

Bunların her biri küçük unsurlardı. Toplu olarak, anlamlı derecede daha büyük bir JavaScript paketi oluştururlar. Kod tabanını metodik olarak gözden geçirdik: her üçüncü taraf script, < head > içinde olması gerekip gerekmediği veya ertelenip ertelenemeyeceği değerlendirildi. Her büyük ithalat, gerçek kullanıma karşı kontrol edildi.

Tarayıcı API'lerine ihtiyaç duymayan bileşenler tekrar sunucu bileşenlerine dönüştürüldü. Paket boyutu düştü ve bununla birlikte, sayfanın etkileşimli hale gelmesi için geçen süre de azaldı.

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

Hızlı web siteniz için daha fazla potansiyel müşteri yönlendirmek 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 teslimatı ve priority özelliği dahil, herhangi bir sayfadaki en pahalı kalemdi ve bunu birden fazla kez yanlış yaptık. Herkes görsel optimizasyonuna başını sallar ve sonra Figma'dan doğrudan 3.7MB'lık bir JPEG yüklemeye geri döner. Biz de tam olarak bunu yaptık. Birkaç kez.

Oluşturduğumuz özel görsel yükleyici, tüm üretim trafiğini CDN'mizdeki imgproxy üzerinden yönlendirir. Her görsel, gerçekten ihtiyaç duyulan boyutlara yeniden boyutlandırılır, talep eden tarayıcı için doğru formatta sunulur ve kenarda önbelleğe alınır. 390px ekranlı bir mobil ziyaretçi artık aynı görselin 1600px versiyonunu indirmez. Yükleyici bunların hepsini şeffaf bir şekilde halleder; geliştirici normal bir < Image > etiketi yazar ve CDN gerisini halleder.

Ancak format dönüşümü, teslimattan ayrı bir problemdir. Hızlı bir CDN'den sunulan bir JPEG hala bir JPEG'dir. Kahraman 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ır. Ana sayfamızdaki kahraman görselinde 1.3MB'lık bir PNG vardı ve bunu dördüncü ardışık denetimde Lighthouse işaretleyene kadar fark etmedik. O görselin WebP'de yaklaşık 200KB ağırlığında olması gerekir. CDN bunu düzeltemez; yalnızca kaynak dosyayı dönüştürmek bunu yapabilir.

Daha uzun süre yanlış yaptığımız diğer şey: Next.js görsellerindeki priority özelliği. Çerçeve varsayılan olarak görselleri tembel yükler, bu da katlanma altındaki görseller için doğru davranıştır. Ancak En Büyük İçerik Dolu Boya elemanı (neredeyse her zaman kahraman görseli) asla tembel yüklenmemelidir. priority eklemek, Next.js'e o görseli önceden yüklemesini ve isteğe bağlı içerik gibi davranmayı bırakmasını söyler. Bu bir özellik. LCP iyileştirmesi hemen ve ölçülebilir.

Next.js İşleme Stratejisi: Statik Üretim, ISR ve Dinamik İşleme

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

Her istekte sunucu tarafından işlenen, derleme zamanında statik olarak üretilen, periyodik yeniden doğrulama ile statik olarak üretilen: bunlar farklı sorunlar için farklı araçlardır ve yanlış olanı kullanmak gerçek performans sonuçlarına sahiptir.

Ürün sayfalarımız (sunucu özellikleri, fiyatlandırma katmanları, özellik belgeleri) dakika başı değişmez. Artık generateStaticParams ile ISR ve bir saatlik yeniden doğrulama penceresi ile kullanıyorlar. Derleme zamanında, her yerel kombinasyon statik HTML'ye önceden işlenir. Bir kullanıcı bir ürün sayfasına tıkladığında, CDN kenarından 100ms altında bir sürede önbelleğe alınmış bir dosya sunulur. Sunucu yok, veritabanı sorgusu yok, Node.js süreci uyanmıyor.

Taze veriye ihtiyaç duyan sayfalar (blog indeksi, canlı fiyatlandırma, kullanıcıya özel herhangi bir şey) kısa yeniden doğrulama pencereleri veya bileşen seviyesinde önbelleğe alma ile dinamik işleme kullanır. Sonuç olarak, trafiğimizin ezici çoğunluğu statik HTML'den sunulur ve sunucu yalnızca içerik gerçekten değiştiğinde gerçek iş yapar.

Çoğu sayfada TTFB artık sürekli olarak 100ms'nin altında. Eski Laravel kurulumunda nadiren 400ms'nin altındaydı. Bu, çerçevenin sihir yapması değil, her sayfa için hangi işleme stratejisinin mantıklı olduğuna dair kasıtlı kararlar vermenin bir sonucudur.

SEO yapılandırılmış veriler, hreflang etiketleri ve OpenGraph meta verileri kullanıcılar için görünmezdir ancak her şey için önemlidir ve taşındığımızda bunların neredeyse hiçbiri yoktu. Google's generative AI özellikleri için optimize etmek, doğru şema işaretlemeleriyle iyi yapılandırılmış, taranabilir içerik gerektirir.

Ürün ve özellik sayfalarına FAQPage JSON-LD ekledik. Araçlarımız için SoftwareApplication şeması. Navigasyon hiyerarşisi için BreadcrumbList. Kök düzeninde Organization şeması. Bunlar arama tarayıcıları ve giderek artan bir şekilde içeriğinizi oluşturulan özetlere ve cevap kutularına dahil edip etmeyeceklerine karar veren AI sistemleri tarafından okunur.

Hreflang durumu daha karmaşıktı. Dört yerel dili destekliyoruz ve alternatif bağlantılarımız 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 paylaşılan bir buildAlternates() fonksiyonu oluşturduk. Yanlış veya eksik hreflang etiketlerinin uluslararası arama performansınızı aktif olarak zedelediğini fark edene kadar bu tür şeyler ev işi gibi gelir.

OpenGraph meta verileri benzerdi, bazı sayfalarda vardı, bazılarında yoktu, görsel boyutları tutarsızdı. Next.js'nin generateMetadata API'si aracılığıyla merkezi hale getirmek ve kök düzenine metadataBase eklemek, sayfa başına düşünmeyi bırakmamız ve her yerde varsayılan olarak doğru yapmamız anlamına geldi.

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

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

Henüz bitirmedik. WebP olması gereken ama olmayan görseller, dinamik işleme varsayılan olan ancak statik olarak üretilebilecek sayfalar ve daha spesifik olabilecek yapılandırılmış veriler hala var. Liste eskisinden daha kısa, ancak asla sıfıra ulaşmıyor.

Tüm bunlardan alınan dürüst ders, performansın bitirdiğiniz bir proje değil, oluşturduğunuz bir dizi varsayılan olduğudur. Her kahraman görselinde PR birleştirilmeden önce priority. Yeni bir harici alan adı tanıtıldığında aynı gün eklenen preconnect. Sayfa içeriğiyle birlikte yazılan yapılandırılmış veriler, geriye dönük olarak eklenmez. İthalatlar, paket ağırlığı haline gelmeden önce denetlenir.

Bu şeyler alışkanlıklar yerine kontrol listeleri olduğunda, birikmiş kararlardan kurtulmak için sprint 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ş tavsiyeler almak istiyorsanız topluluğumuza katılın.

Tek bir panelden hızlı, akıllı altyapıyı açmak için sunucularımıza göz atın. Otomatik yedeklemeler 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. Onlara göz atın.