Geliştirici, Next.js yerine Hono'ya geçerek Lighthouse'ta tam 100 puan aldı

Ne oldu

Bir geliştirici, blogunu her Lighthouse kategorisinde tam 100 puana taşıma sürecini ilk elden anlattı ve belirleyici adım, en çok kullandığı framework olan Next.js'i çıkarmak oldu. Hacker News'in ana sayfasına çıkan yazı, cache çalışmasını, puanı sınırlayan şeyin teşhisini ve sonundaki Hono ile yeniden yazım sürecini adım adım anlatıyor.

Proje, barındırılan platformlara daha hafif bir alternatif kurma girişimi olarak başladı. Yazara göre Medium ve Blogger şişkin ve yavaştı, WordPress eklenti bakımı demekti, Ghost kendi sunucunda barındırma ya da pahalı bir plan gerektiriyordu ve yükseltmelerde bozuluyordu, Hugo ise yetenekliydi ama kurulumu zahmetliydi. Bear Blog en yakın alternatifti ama aşırı minimalizmi, kısıtlı editörü ve ücretsiz görsel yüklememesi eliyordu. Hedef, Bear Blog kadar hızlı ama biraz daha fazla işlevli bir blog oldu.

Önce cache ve görseller

16.1.6 sürümü üzerinde kurulu Next.js sürümü zaten standart performans uygulamalarını izliyordu. Sayfalar ISR ile önceden render ediliyordu ve yazar, Next.js'in cache özelliklerinin tek başına performans açısından uzun bir yol kat ettirdiğini belirtiyor. Küresel erişim için site bir CDN arkasındaydı ve görseller Cloudflare'in Image Transformations özelliğiyle işleniyordu; yazar, ücretsiz plana 5.000 görselin dahil olduğunu söylüyor.

Yazar ayrıca Vercel ve Next.js ikilisinin neden cazibesini yitirdiğini de açıklıyor: Pro plan baştan pahalı, serverless cold starts hâlâ bir sorun ve Vercel ekosistemine bağımlılık göz ardı edilemeyecek kadar belirgin. CDN ağırlığı kaldırdığında, Next.js'in kendi cache'i her yayında geçersiz kılmanız gereken ikinci bir cache'e dönüşüyor. Yazarın vardığı sonuca göre statik bir site için tek başına bir CDN yeterli.

Bu çalışma yüksek ama mükemmel olmayan puanlar üretti.

Next.js'in altına inemediği runtime tabanı

Lighthouse, pakette yazarın yazmadığı çok miktarda eski JavaScript işaretledi; bunlar Next.js'in gönderdiği framework runtime'ından geliyordu ve hiçbir etkileşimi olmayan sayfalarda bile bulunuyordu. Bir deneme olarak yazar, tüm client component'leri kaldırıp yalnızca server component'leri bıraktı. Puan değişmedi.

Yazarın tarif ettiği kök neden şu: next/link ve next/image'ın kendileri client component olarak işaretleniyor, yani ikisinden birini kullanmak bile client runtime'ı çekmek ve hydration'ı tetiklemek için yeterli. Onları da kaldırdığınızda App Router'ın kendi runtime'ı, router ve error boundary'ler dahil, hâlâ kalıyor. Bunu sıfıra indirmenin resmi bir yolu yok; tek seçenek, render edilen HTML'den script'leri soyup atan bir hack'ti. Yazarın muhakemesine göre o noktada framework artık yerini hak etmiyordu.

Sadece kullanılmayan JavaScript 230.460 bayta ulaşıyordu.

Hono ile yeniden yazım

Yerine geçecek teknoloji olarak yazar, hafif tasarımına ve JSX desteğine çekildiği Hono'yu seçti; geçiş maliyeti yönetilebilir görünüyordu. Tamamen vanilla'a geçmek de düşünüldü ama framework düzeyindeki üretkenliği korumak tercih edildi. pagespeed.web.dev ile ölçülen sonuçlar:

• Her Lighthouse kategorisinde tam 100 puan.

• Kullanılmayan JavaScript 230.460 bayttan 407 bayta düştü.

• Herhangi bir şey render edilmeden önce çalışan uzun task 309,3ms'den 68,01ms'ye düştü; yazar bunu yaklaşık %78'lik bir iyileşme olarak değerlendiriyor.

• Build süresi yaklaşık %40 düştü.

Ekran görüntülerinden birinde SEO puanı 69 görünüyor; yazar, söz konusu sitenin bilinçli olarak arama indekslemesini engellediğini açıklıyor. Ve Next.js tamamen terk edilmiş değil; blog'un yönetim uygulaması onunla kurulu. Yazarın görüşüne göre Next.js, etkileşim yoğun uygulamalar için hâlâ iyi bir framework.

Neden önemli

Bu, tekrar tekrar süren framework'e karşı statik site tartışmasına somut bir veri noktası. React meta-framework'leri, router ve hydration mekanizmaları dahil bir client runtime'ı, hiçbir etkileşimi olmayan sayfalara bile gönderiyor ve bu anlatımın gösterdiği gibi, framework içinde kalıp bunu sıfıra indirmenin desteklenen bir yolu yok. Her Lighthouse puanının önemli olduğu içerik siteleri için bu runtime, altında inşa edemeyeceğiniz bir taban. Alternatifin elle yazılmış HTML olması gerekmiyor: JSX destekli küçük bir sunucu tarafı framework, tarayıcıya neredeyse hiçbir şey göndermezken yazarın ergonomisini korudu. Sonuç bilinçli olarak dar kapsamlı ve işe yarayan da bu. Sorun genel olarak Next.js değil, baştan beri client tarafı mekanizmasına hiç ihtiyaç duymayan statik bir sayfaya uygulanmış Next.js'ti.