Parçalı parçalama ile geliştirilmiş Next.js ve Gatsby sayfa yükleme performansı

Chrome, JavaScript açık kaynak ekosistemindeki araçlar ve çerçevelerle işbirliği yapıyor. Yükleme performansını iyileştirmek için yakın zamanda bir dizi yeni optimizasyon eklendi. Sonraki.js Ve Gatsby. Bu makale, artık her iki çerçevede de varsayılan olarak gönderilen gelişmiş bir parçalı parçalama stratejisini ele almaktadır.

giriiş #

Birçok web çerçevesi gibi, Next.js ve Gatsby de web paketi çekirdek paketleyicileri olarak. webpack v3 tanıtıldı CommonsChunkPlugin tek bir (veya birkaç) “ortak” yığında (veya yığınlarda) farklı giriş noktaları arasında paylaşılan modüllerin çıktısını almayı mümkün kılmak için. Paylaşılan kod ayrı olarak indirilebilir ve daha erken bir zamanda tarayıcı önbelleğinde saklanabilir, bu da daha iyi bir yükleme performansıyla sonuçlanabilir.

Bu model, şuna benzeyen bir giriş noktası ve paket yapılandırmasını benimseyen birçok tek sayfalık uygulama çerçevesinde popüler hale geldi:

Pratik olmasına rağmen, tüm paylaşılan modül kodunu tek bir öbek halinde birleştirme kavramının sınırlamaları vardır. Her giriş noktasında paylaşılmayan modüller, onu kullanmayan rotalar için indirilebilir ve bu da gereğinden fazla kodun indirilmesine neden olur. Örneğin, ne zaman page1 yükler common yığın, için kodu yükler moduleC rağmen page1 kullanmaz moduleC. Bu nedenle, diğer birkaç eklentiyle birlikte webpack v4, eklentiyi yeni bir eklenti lehine kaldırdı: SplitChunksPlugin.

Geliştirilmiş Parçalama #

için varsayılan ayarlar SplitChunksPlugin çoğu kullanıcı için iyi çalışır. Sayısına bağlı olarak birden çok bölünmüş parça oluşturulur. koşullar birden çok rotada yinelenen kodun alınmasını önlemek için.

Bununla birlikte, bu eklentiyi kullanan birçok web çerçevesi, yığın bölme için hala bir “tek ortak nokta” yaklaşımını izlemektedir. Örneğin, Next.js bir commons sayfaların %50’sinden fazlasında kullanılan herhangi bir modülü ve tüm çerçeve bağımlılıklarını içeren paket (react, react-domve benzeri).

const splitChunksConfigs = {
  …
  prod: {
    chunks: 'all',
    cacheGroups: {
      default: false,
      vendors: false,
      commons: {
        name: 'commons',
        chunks: 'all',
        minChunks: totalPages > 2 ? totalPages * 0.5 : 2,
      },
      react: {
        name: 'commons',
        chunks: 'all',
        test: /[\\/]node_modules[\\/](react|react-dom|scheduler|use-subscription)[\\/]/,
      },
    },
  },

Çerçeveye bağımlı kodu paylaşılan bir yığına dahil etmek, herhangi bir giriş noktası için indirilebileceği ve önbelleğe alınabileceği anlamına gelse de, kullanıma dayalı ortak modülleri dahil etme buluşsal yöntemi birden fazla yerde kullanılır. sayfaların yarısı çok etkili değil Bu oranı değiştirmek yalnızca iki sonuçtan biriyle sonuçlanır:

• Oranı düşürürseniz, daha fazla gereksiz kod indirilir.
• Oranı artırırsanız, birden çok yol boyunca daha fazla kod çoğaltılır.

Bu sorunu çözmek için Next.js bir farklı konfigürasyon içinSplitChunksPlugin bu, herhangi bir rota için gereksiz kodu azaltır.

• Yeterince büyük olan herhangi bir üçüncü taraf modülü (160 KB’den büyük) kendi ayrı öbeğine bölünür
• ayrı bir frameworks yığın, çerçeve bağımlılıkları için oluşturulur (react, react-domve benzeri)
• Gerektiği kadar paylaşılan parça oluşturulur (en fazla 25)
• Oluşturulacak bir yığın için minimum boyut 20 KB olarak değiştirildi

Bu ayrıntılı parçalama stratejisi aşağıdaki faydaları sağlar:

• Sayfa yükleme süreleri iyileştirildi. Tek bir parça yerine birden fazla paylaşılan parça yayınlamak, herhangi bir giriş noktası için gereksiz (veya yinelenen) kod miktarını en aza indirir.
• Navigasyonlar sırasında iyileştirilmiş önbelleğe alma. Büyük kitaplıkları ve çerçeve bağımlılıklarını ayrı parçalara bölmek, bir yükseltme yapılana kadar her ikisinin de değişme olasılığı düşük olduğundan, önbellek geçersiz kılma olasılığını azaltır.

Next.js’nin benimsediği yapılandırmanın tamamını görebilirsiniz. webpack-config.ts.

Daha fazla HTTP isteği #

SplitChunksPlugin ayrıntılı parçalamanın temelini tanımladı ve bu yaklaşımı Next.js gibi bir çerçeveye uygulamak tamamen yeni bir kavram değildi. Bununla birlikte, birçok çerçeve, birkaç nedenden ötürü tek bir sezgisel ve “ortak” paket stratejisini kullanmaya devam etti. Buna, daha birçok HTTP isteğinin site performansını olumsuz yönde etkileyebileceği endişesi de dahildir.

Tarayıcılar, tek bir kaynağa (Chrome için 6) yalnızca sınırlı sayıda TCP bağlantısı açabilir, bu nedenle bir paket oluşturucu tarafından çıkarılan parça sayısını en aza indirmek, toplam istek sayısının bu eşiğin altında kalmasını sağlayabilir. Ancak bu yalnızca HTTP/1.1 için geçerlidir. HTTP/2’de çoklama, birden çok isteğin tek bir kaynak üzerinden tek bir bağlantı kullanılarak paralel olarak yayınlanmasına olanak tanır. Başka bir deyişle, genellikle paketleyicimiz tarafından yayılan parça sayısını sınırlama konusunda endişelenmemize gerek yoktur.