- Laravel'dan Next.js'e Neden Geçtik
- Next.js Üzerindeki İlk Lighthouse Denetimimiz Mütevazıydı
- Daha İyi Script Yönetimi ile JavaScript Paket Boyutunu Nasıl Azalttık
- Next.js Görüntü Optimizasyonu: WebP, CDN ve Öncelik Özelliği
- Next.js İşleme Stratejisi: Statik Üretim, ISR ve Dinamik İşleme
- SEO Yapılandırılmış Veriler, hreflang ve Next.js'de OpenGraph
- Sonuçlar: Lighthouse Skoru 90'ın Üzerinde, LCP 2.5s'nin Altında, TTFB 100ms'nin Altında
Herkes hızlı bir web sitesi ister, ancak farklı web siteleri farklı yolculuklar yaşar. Bu bizim deneyimimiz, nedenlerimiz, yolculuğumuz ve sonuçlarımız. 2026 yılında 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.
Community
Further questions? Ask our team
Bu gönderinin bir versiyonu var ki, size büyük bir planımız olduğunu, kusursuz bir şekilde uyguladığımızı ve mükemmel bir şekilde optimize edilmiş bir site yayınladığımızı söyleriz. Ancak bu olmadı.
Aslında olan şey, 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 ve rahatsız edici bir konuşma yapmamızdı.
Laravel'dan Next.js'e Neden Geçtik
Laravel'dan 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 zamanlar bulunduğumuz ölçek için tamamen makuldü. Ancak ürün birden fazla dil, canlı veri çeken fiyatlandırma sayfaları, gerçek trafik alan bir blog, karmaşık kimlik doğrulama akışları ile büyüdükçe, bir zamanlar "tamamen 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 bileşenlerinden, 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.
App Router ile Next.js 15'e 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 pürüzlerini giderdiğimiz zorluklarla doluydu.
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. En azından 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 sunar. Bu araçları doğru kullanmak ayrı bir sorundur.
Sitemizi yavaşlatan ilk şey, render-engelleyici kaynaklardı. JavaScript değil, bu konuda dikkatli olmuştuk. Sorun daha inceydi: tarayıcı ipuçları olmayan dış alanlardan 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 nedenle her sayfa yüklemesinde, tarayıcı HTML'yi analiz eder, bir dış alan isteğiyle karşılaşır ve ardından DNS çözümlemesi ve TCP el sıkışmasını sıfırdan başlatırdı.
Kök düzenine iki satır eklemek bunu düzeltti:
<link rel="preconnect" href="https://static.plusclouds.com" />
<link rel="preconnect" href="https://apiv4.plusclouds.com" />
Bu neredeyse çok basit görünüyor. Ancak preconnect ipuçları, her sayfa yüklemesi için, her ziyaretçi için maliyeti biriken şeylerden biridir. Tarayıcı artık ilk görüntü veya API çağrısıyla karşılaşmadan önce bu bağlantıları kurmaya başlar. Dolayısıyla, web sitenizi daha hızlı hale getirmek istiyorsanız preconnect ipuçlarına dikkat etmek önemlidir.
Daha İyi Script Yönetimi ile JavaScript Paket Boyutunu Nasıl Azalttık
Daha iyi script yönetimi ile JavaScript paket boyutunu azaltmak, görece 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ırası, sayfanın gerçekten neye ihtiyaç duyduğuna dair düşünceli bir değerlendirme değil, ö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 beraber taşıdık. İki simge kullanan bileşenler tüm simge kütüphanelerini içe aktarıyordu. Sadece belirli bir dalda ihtiyaç duyulan yardımcı fonksiyonlar dosyaların en üstünde içe aktarılıyordu. Hiçbir etkileşimi olmayan, sadece birisi emin olmadığında o şekilde yazılmış olan 'use client' işaretli istemci bileşenlerimiz vardı.
Bunların her biri küçük unsurlar. Birlikte, anlamlı bir şekilde 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 içe aktarma, gerçek kullanımına karşı kontrol edildi.
Tarayıcı API'larına ihtiyaç duymayan bileşenler sunucu bileşenlerine geri dönüştürüldü. Paket boyutu düştü ve bununla birlikte, sayfanın etkileşimli hale gelme süresi 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 görünür bir render'ı engelleyebilecek hiçbir şey < head > içinde yüklenmez.
Hızlı web sitenize daha fazla potansiyel müşteri çekmek istiyorsanız, satış sürecini otomatikleştiren yapay zeka aracımızı inceleyin.
LeadOcean
Start generating leads free
Next.js Görüntü Optimizasyonu: WebP, CDN ve Öncelik Özelliği
Next.js görüntü optimizasyonu — format dönüştürme, CDN teslimi ve öncelik özelliği dahil, herhangi bir sayfadaki en pahalı kalemdi ve bunu birden fazla kez yanlış yaptık. Herkes görüntü optimizasyonuna başını sallar ve sonra Figma'dan doğrudan 3.7MB bir JPEG yüklemeye geri döner. Biz de tam olarak bunu yaptık. Birkaç kez.
Oluşturduğumuz özel görüntü yükleyici, tüm üretim trafiğini CDN üzerindeki imgproxy üzerinden yönlendirir. Her görüntü, gerçekten ihtiyaç duyulan boyutlara yeniden boyutlandırılır, talep eden tarayıcı için doğru formatta sunulur ve uçta önbelleğe alınır. 390px ekrana sahip bir mobil ziyaretçi artık aynı görüntünün 1600px versiyonunu indirmez. Yükleyici tüm bunları şeffaf bir şekilde halleder; geliştirici normal bir < Image > etiketi yazar ve CDN gerisini halleder.
Ancak format dönüştürme, teslimattan ayrı bir sorundur. 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. Anasayfa kahramanımızda 1.3MB bir PNG vardı ve bunu ancak Lighthouse dördüncü ardışık denetiminde işaretleyene kadar fark etmedik. O görüntü WebP'de yaklaşık 200KB ağırlığında olmalıdır. 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örüntülerinde öncelik özelliği. Çerçeve, varsayılan olarak görüntüleri tembel yükler, bu alt kısımda bulunan görüntüler için doğru davranıştır. Ancak En Büyük İçerik Boyama öğesi (neredeyse her zaman kahraman görüntüsü) asla tembel yüklenmemelidir. öncelik eklemek, Next.js'e o görüntüyü önceden yüklemesini ve isteğe bağlı içerik gibi davranmayı bırakmasını söyler. Bu bir özelliktir. LCP iyileştirmesi hemen ve ölçülebilirdir.
Next.js İşleme Stratejisi: Statik Üretim, ISR ve Dinamik İşleme
Doğru Next.js işleme stratejisini (statik üretim, ISR veya dinamik işleme) seçmek, çerçevede 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) dakikada değişmez. Artık generateStaticParams ile ISR ve bir saatlik yeniden doğrulama penceresi ile birlikte kullanılıyorlar. Derleme zamanında, her yerel kombinasyon statik HTML olarak önceden işlenir. Bir kullanıcı bir ürün sayfasına ulaştığında, CDN kenarından 100ms'nin altında bir sürede sunulan bir önbellek dosyası alır. Sunucu yok, veritabanı sorgusu yok, Node.js süreci uyanmıyor.
Taze veriye ihtiyaç duyan sayfalar (blog dizini, canlı fiyatlandırma, kullanıcıya özel herhangi bir şey) kısa yeniden doğrulama pencereleri veya bileşen düzeyinde önbellekleme ile dinamik işleme kullanır. Sonuç olarak, trafiğimizin büyük ç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 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ı bir kararın sonucudur.
SEO yapılandırılmış veriler, hreflang etiketleri ve OpenGraph meta verileri kullanıcılar için görünmezdir ancak diğer her şey için önemlidir ve geçiş yaptığımızda neredeyse hiçbiri yoktu. Google's generative AI özellikleri için optimize etmek, doğru şema işaretlemeleri ile 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üzenine Organization şeması. Bunlar arama tarayıcıları ve giderek artan bir şekilde içeriğinizi oluşturulan özetlere ve yanıt kutularına dahil edip etmeyeceğine 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 bir buildAlternates() fonksiyonu oluşturduk. Yanlış veya eksik hreflang etiketlerinin uluslararası arama performansınıza aktif olarak zarar verdiğ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örüntü 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 yapmaya başlamamız anlamına geldi.
Sonuçlar: Lighthouse Skoru 90'ın Üzerinde, LCP 2.5s'nin Altında, TTFB 100ms'nin Altında
Geçişten sonra, mobildeki Lighthouse skorlarımız tutarlı bir şekilde 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 bitmedik. WebP olması gereken ama olmayan hala görüntüler var, statik olarak üretilebilecek ama dinamik işlemeye varsayılan sayfalar var ve daha spesifik olabilecek yapılandırılmış veriler 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örüntüsünde PR birleştirilmeden önce öncelik. Yeni bir dış alan tanıtıldığında aynı gün preconnect eklenir. Sayfa içeriğiyle birlikte yazılmış yapılandırılmış veriler, geriye dönük olarak eklenmez. İçe aktarmalar, paket ağırlığı haline gelmeden önce denetlenir.
Bu şeyler alışkanlık haline geldiğinde, kontrol listeleri yerine, birikmiş kararlardan kurtulmak 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ş tavsiyeler almak istiyorsanız topluluğumuza katılın.
Community
Further questions? Ask our team
Hızlı, akıllı altyapıyı tek bir panelden açığa çıkarmak için sunucularımıza göz atın. Otomatik yedekleme ve geri yükleme, planlanmış sağlık kontrolleri ve anında ölçeklendirme gibi ücretsiz özelliklerimiz, web sitenizin daha iyi çalışmasına yardımcı olur. Onları incelemekten çekinmeyin.
PlusClouds Cloud
Deploy your first server today
