Show HN: Jampack - Statik web sitesi optimizasyonu için son işleme adımı

 (github.com/divriots)
4 puan yazan GN⁺ 2024-03-26 | 1 yorum | WhatsApp'ta paylaş
  • Jampack, Static Site Generator çıktısını alıp kullanıcı deneyimini ve Core Web Vitals puanlarını optimize eden bir son işleme aracıdır; bir bundler ya da framework değildir
  • HTML’deki <img> ve <picture> öğelerini duyarlı görsellere dönüştürür; WebP·AVIF gibi formatları, srcset, sizes, width, height, loading="lazy", decoding="async" gibi özellikleri otomatik olarak ekler
  • CDN görselleri, URL parametrelerine dayalı srcset ile duyarlı hale getirilebilir; harici görseller ise _jampack altına indirilip optimize edilmiş yerel görsellere dönüştürülebilir
  • Above-the-fold varlıklar yüksek öncelikle işlenir, küçük görseller HTML içine satır içi yerleştirilir; below-the-fold görseller ve iframe’ler lazy loading ile yüklenir
  • Statik site build çıktısı klasöründe npx @divriots/jampack./dist çalıştırılarak uygulanır; CSS·JS·HTML·SVG·görsel sıkıştırması da ikinci geçişte yapılır

Jampack’in rolü

  • Jampack, Static Site Generator, yani SSG tarafından üretilen çıktıyı girdi olarak alıp statik web sitesini optimize eder
  • Amaç, kullanıcı deneyimini ve Core Web Vitals puanlarını iyileştirmektir
  • README, Jampack’i “ne bir bundler ne de bir framework” olarak ayırır
  • Tanıtım yazısı Read the introduction blog post üzerinden sunulmaktadır

Görsel optimizasyonu

  • Normal <img> öğeleri duyarlı görsellere dönüştürülür
    • Orijinal src için WebP dosyası oluşturulur ve srcset eklenir
    • sizes="100vw", loading="lazy", decoding="async", width, height gibi özellikler eklenir
  • <picture> öğesi, birden fazla görsel formatı içeren duyarlı bir yapıya dönüştürülür
    • AVIF için <source type="image/avif"> eklenir
    • WebP için <source type="image/webp"> eklenir
    • Orijinal <img> öğesine de srcset, sizes, loading, decoding, width, height eklenir
  • Görsel optimizasyonu özelliği optimize-images belgesine yönlendirir, ancak README’deki ilgili bağlantı göreli yoldur

CDN ve harici görsellerin işlenmesi

  • CDN görselleri, uzak URL korunurken duyarlı srcset eklenerek kullanılabilir
    • Örnekte Unsplash görsel URL’sine w, fit=min, auto=format parametreleri eklenerek farklı genişliklerde adaylar oluşturulur
    • Orijinal görsele de loading="lazy", decoding="async", sizes="100vw" eklenir
  • Harici görseller, indirildikten sonra optimize edilmiş yerel dosyalara dönüştürülebilir
    • Örnek, harici bir Unsplash görselini _jampack/ab99b9d280ce4cf7cfc810b59f3a7739.jpg.webp gibi bir yola dönüştürür
    • Dönüştürülen görselde width, height, srcset, sizes, loading, decoding bulunur

Above-the-fold ve CSS·bağlantı optimizasyonu

  • Jampack, above-the-fold varlıkları ayrıca optimize eder
    • Görseller daha yüksek öncelikle yüklenir
    • Küçük görseller HTML içine gömülür
  • below-the-fold varlıklar gecikmeli yüklenir
    • Görseller ve iframe’ler lazy load kapsamındadır
  • Critical CSS HTML içine satır içi eklenir
    • Amaç, stil sayfası indirme ve ayrıştırma sırasında oluşabilecek FOUC durumunu önlemektir
    • Kalan CSS gecikmeli yüklenir
  • Bağlantı prefetch’i, gelecekteki sayfa geçişlerini hızlandırmaya yönelik bir özelliktir
    • quicklink kullanılarak bağlantı viewport’a girdiğinde dinamik olarak işlenebilir

Varlık sıkıştırma ve çalıştırma yöntemi

  • Jampack, ikinci geçişte dokunulmamış tüm varlıkları sıkıştırır; aynı adı ve aynı formatı korur
  • Uzantıya göre sıkıştırma araçları şöyledir
  • Statik web sitesi dist klasöründeyken şu komutla çalıştırılır
npx @divriots/jampack ./dist

Kullanım örnekleri ve adının anlamı

İlgili okumalar

1 yorum

 
GN⁺ 2024-03-26
Hacker News yorumları

  • Tam aradığım araç. Böyle görsel optimizasyonu yapmak için Sharp tabanlı kendi betiğimi yazıyordum; Jampack onu tamamen ikame ediyor ve çok daha iyi çalışıyor.
    Quarto statik sitesini derledikten sonra Jampack’i çalıştırınca klasör boyutu %32 azaldı ve şimdilik göze çarpan bir dezavantaj yok.
    PageSpeed Insights’a göre Jampack’ten önce mobilde performans 52, erişilebilirlik 73, en iyi uygulamalar 100, SEO 85; masaüstünde performans 90, erişilebilirlik 75, en iyi uygulamalar 100, SEO 82 idi.
    Uyguladıktan sonra mobilde performans 49, erişilebilirlik 80, en iyi uygulamalar 100, SEO 92; masaüstünde performans 85, erişilebilirlik 82, en iyi uygulamalar 100, SEO 91 çıktı.

    • Lighthouse ve PageSpeed Insights puanları dalgalanabilir. Böyle performans karşılaştırmaları yaparken birkaç kez çalıştırıp medyana bakmak daha iyi olur.
      “5 Lighthouse çalıştırmasının medyan puanı, tek çalıştırmadan iki kat daha kararlı” diyen bir kaynak da var: https://developers.google.com/web/tools/lighthouse/variabili...
    • Beğenmene sevindim. Yine de performans metriklerinin daha iyiye gitmesini beklerdim. Sakıncası yoksa Jampack uygulanmadan önceki statik site çıktısını paylaşırsan incelemek isterim.
      georges [at] divriots [dot] com

  • Apache ve Nginx için PageSpeed modülü aklıma geldi: https://developers.google.com/speed/pagespeed/module

  • Vay, bunu epey beğendim. Deneyeceğim.
    Kötü bulan biri varsa kusurlarını belirtmesini isterim. Bana C’yi aşırı optimize edilmiş assembly’ye derlemeye benziyor; insanın kendi yapmak istemeyeceği işleri kesin biçimde üstlenen bir araç gibi görünüyor.

    • HTML ve CSS’te aşırı optimize edilmiş assembly gibi bir şey dağıtmamız gerekiyorsa doğru yönde ilerleyip ilerlemediğimizden emin değilim.
      Bence en basit ve sezgisel HTML ile CSS’i yazdığımızda, tüm cihazlardaki tarayıcılar bunu sorunsuzca render edebilmeliydi.
      Gerçekten bu düzeyde optimize edilmiş çıktılar dağıtmamız gerekiyorsa HTML ve CSS’i tamamen atlayıp, yüksek düzeyde optimize edilmiş WebAssembly dağıtmaya izin vermek ve geliştiricinin istediği dili kullanmasını sağlamak daha iyi olurdu.

  • SSG çıktısının Unicode aralığına göre fontları alt kümelere ayırmanın ve CSS’te tanımlı font-feature-settings’e dayanarak OpenType eksenlerini sabitlemenin bir yolu olsa güzel olurdu.

    • Evet, font tarafında yapılabilecek pek çok güzel şey var. TODO listesinde, doğru metriklere sahip sistem fontu yedeğini otomatik ekleyerek CLS’yi otomatik iyileştirmek var.
      Söylediğin “font-feature-settings tabanlı OpenType ekseni sabitleme” bu mu, yoksa başka bir şey mi merak ettim.
      Font alt küme optimizasyonu da yapmak istiyorum ama iyileşme payının ne kadar olacağından henüz emin değilim. Bunu elle yapıp yapmadığını merak ediyorum.
    • Tarayıcı/sistem fontları kullanırsan font boyutunu 0 olarak optimize edebilirsin; buna gerek var mı emin değilim.

  • Ayrı bir stil sayfasında tutmak yerine inline edilmesi gereken kritik CSS’i belirleme fikri ilginç.
    Kritik CSS ile kritik olmayan CSS’i ilkesel olarak ayırmanın bir yolu olmasını ummuştum. Örneğin :hover gibi kullanıcı etkileşimi efektlerini her zaman kritik olmayan saymak gibi.
    Ama kullanılan kütüphane sayfayı render edip hangi kuralların kritik sayılabileceğine dair en iyi tahmini yapıyor; bu biraz hayal kırıklığı: https://github.com/GoogleChromeLabs/critters

    • CSS 50 KB’nin altındaysa doğrudan inline etmek yeterli. 50 KB’den büyük CSS’in varsa muhtemelen bir şeyleri yanlış yapıyorsundur.
      Elbette fontları da inline ediyorsan bunu anlayabilirim; ama onun dışındaki stiller 50 KB’yi aşıyorsa genelde yanlış yoldasın demektir.
      Ciddi konuşmak gerekirse inline etmek, sıcak önbellekle karşılaştırıldığında bile performans açısından çok iyi; harici stil sayfası veya betiklerin daha iyi hâle geldiği eşik sanıldığından yüksek, yaygın piyasa ölçütlerinde yüzlerce KB’ye kadar çıkabiliyor.
      Kritik CSS kavramı, temel sorunu düzeltmektense boşa harcanan performansın birazını geri kazanmaya çalışan yenilgici bir yaklaşım gibi geliyor.
      Yine de bu sistematik bir teknik değil; hafif deneyim ve gözlemlere dayalı bir yargı. Birinin bu kavramı daha düzgün ölçmesini isterdim ama bunu ben yapacak gibi değilim.

  • Bu, insanların en başta SSG ve eklenti seçmesinin çeşitli kullanım amaçlarını kapsıyor gibi görünüyor. Özellikle Astro ya da Eleventy seçiliyorsa daha da öyle.
    Bunu ayrı bir derleme sonrası adımı olarak tutmayı tercih etmek için bir sebep var mı? Geliştirme sırasında yeniden derlemeler hızlanır ama görsel width bildirimleri gibi şeyler eklenirken ortaya çıkan ince hataları kaçırma riskiyle bir ödünleşim gibi görünüyor.

  • Web sayfası yerleşimiyle uğraşmayı sevmeyen ve öğrenmeyi de reddeden ama ara sıra yapmak zorunda kalan biri olarak bu araç çok iyi görünüyor.

  • İyi görünüyor. Yine de kişisel olarak sayfayı ilk ekranın altına kaydırdığımda görselleri beklemekten hoşlanmıyorum.
    Varsayılan davranış olarak, ilk ekrandaki içerik bittikten sonra alttaki geri kalan içerik arka planda yükleniyor mu?

    • Hayır. Tarayıcının yerleşik lazy loading özelliğini kullanıyor. Başlıca tarayıcılar loading="lazy" özniteliğini “bu görseli/iframe’i neredeyse görünür olana kadar yükleme” anlamında ele alıyor: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
      Ancak en-boy oranı inline olarak eklendiği için yükleme bittikten sonra yerleşim değişmiyor. Böylece lazy loading’in en büyük günahından kaçınılmış oluyor.
    • @lelandfe’nin belirttiği gibi Jampack tarayıcının yerleşik loading="lazy" özelliğini kullanıyor.
      Şu anda bu davranışı değiştirmenin bir yolu yok; ama sayfanın tamamı yüklendikten sonra ilk ekranın altındaki görselleri arka planda önceden yükleyen bir seçenek eklenebilir. Oldukça iyi bir fikir.
      Yine de sayfanın altındaki gereksiz görsellerin de yüklenmesinden endişe ederim. Seçenek olursa herkes açıp kapatabileceği için sorun olmaz gibi.

  • Üretim ortamında kullanılan statik site oluşturucuları olarak neler var? Bu araçla çıktıyı daha da optimize etmek mümkün olabilir.
    Örneğin dün Divjoy React web sitesini sade HTML’ye çevirip S3 bucket’tan sunmak için örneği takip ederek bütün günümü harcadım. Bu kadar zor olacağını bilmiyordum ve hâlâ bocalıyorum.
    İdeal olarak S3 bucket’a otomatik dağıtım yapan ve alan adını da bağlayan bir şey olsa güzel olurdu. Para bile ödedim ama geliştirici ortadan kayboldu, Discord da terk edilmiş durumda; bu acı veriyor. Bu yüzden her zaman FOSS’u daha çok tercih ediyorum.

    • Hugo, Zola, Jekyll sayılabilir.
      Bunların bir kısmında bu özelliklerin bazıları zaten var.

  • Benim projelerimden birinde büyük bir değişiklik olmadı. Örneğin toplam bundle boyutu azaldı ama gzip boyutu arttı; pratikte benim için net zarardı.
    Yine de CSS iyileştirmeleri gerçekten yardımcı olmuş gibi.
    Fikir harika görünüyor; projede görsel olsaydı muhtemelen faydası olurdu.