Show HN: Jampack - tahap pascapemrosesan untuk optimasi situs web statis

 (github.com/divriots)
4 poin oleh GN⁺ 2024-03-26 | 1 komentar | Bagikan ke WhatsApp
  • Jampack adalah alat pascapemrosesan yang menerima output Static Site Generator untuk mengoptimalkan pengalaman pengguna dan skor Core Web Vitals, dan bukan bundler maupun framework
  • Mengubah <img> dan <picture> di HTML menjadi gambar responsif, serta secara otomatis menambahkan format seperti WebP dan AVIF, srcset, sizes, width, height, loading="lazy", decoding="async", dan lainnya
  • Gambar CDN dapat diproses secara responsif dengan srcset berbasis parameter URL, dan gambar eksternal dapat diunduh ke bawah _jampack lalu diubah menjadi gambar lokal yang telah dioptimalkan
  • Aset above-the-fold diproses dengan prioritas tinggi dan gambar kecil di-inline ke HTML, sementara gambar dan iframe below-the-fold dimuat secara lazy
  • Diterapkan dengan menjalankan npx @divriots/jampack ./dist pada folder hasil build situs statis, dan pada pass kedua juga melakukan kompresi CSS, JS, HTML, SVG, hingga gambar

Peran Jampack

  • Jampack mengoptimalkan situs web statis dengan menerima hasil keluaran dari Static Site Generator, yaitu SSG
  • Tujuannya adalah meningkatkan pengalaman pengguna dan skor Core Web Vitals
  • README membedakan Jampack sebagai “bukan bundler dan bukan framework”
  • Tulisan pengantar tersedia di Read the introduction blog post

Optimasi gambar

  • <img> biasa diubah menjadi gambar responsif
    • Membuat file WebP untuk src asli dan menambahkan srcset
    • Menambahkan atribut seperti sizes="100vw", loading="lazy", decoding="async", width, dan height
  • Elemen <picture> diubah menjadi struktur responsif yang mencakup beberapa format gambar
    • Menambahkan <source type="image/avif"> untuk AVIF
    • Menambahkan <source type="image/webp"> untuk WebP
    • Pada <img> asli juga ditambahkan srcset, sizes, loading, decoding, width, dan height
  • Fitur optimasi gambar berlanjut ke dokumentasi optimize-images, tetapi tautan terkait di README berupa path relatif

Penanganan CDN dan gambar eksternal

  • Gambar CDN dapat mempertahankan URL jarak jauh sambil menambahkan srcset responsif
    • Contohnya membuat beberapa kandidat lebar pada URL gambar Unsplash dengan menambahkan parameter w, fit=min, dan auto=format
    • Pada gambar asli juga ditambahkan loading="lazy", decoding="async", dan sizes="100vw"
  • Gambar eksternal dapat diunduh lalu diubah menjadi file lokal yang telah dioptimalkan
    • Contohnya mengubah gambar Unsplash eksternal menjadi path seperti _jampack/ab99b9d280ce4cf7cfc810b59f3a7739.jpg.webp
    • Gambar hasil konversi mencakup width, height, srcset, sizes, loading, dan decoding

Above-the-fold serta optimasi CSS dan tautan

  • Jampack mengoptimalkan aset above-the-fold secara terpisah
    • Gambar dimuat dengan prioritas lebih tinggi
    • Gambar kecil disematkan ke dalam HTML
  • Aset below-the-fold dimuat secara lazy
    • Gambar dan iframe menjadi target lazy load
  • Critical CSS di-inline ke dalam HTML
    • Tujuannya untuk menghindari FOUC yang dapat terjadi saat stylesheet diunduh dan diparse
    • Sisa CSS dimuat secara lazy
  • Prefetch tautan adalah fitur untuk mempercepat perpindahan ke halaman berikutnya
    • Dapat diproses secara dinamis saat tautan masuk ke viewport menggunakan quicklink

Kompresi aset dan cara menjalankan

  • Jampack mengompresi semua aset yang belum disentuh pada pass kedua, sambil mempertahankan nama dan format yang sama
  • Alat kompresi per ekstensi adalah sebagai berikut
  • Saat situs web statis berada di folder dist, jalankan dengan perintah berikut
npx @divriots/jampack ./dist

Contoh penggunaan dan makna nama

Bacaan terkait

1 komentar

 
GN⁺ 2024-03-26
Komentar Hacker News

  • Ini persis alat yang saya cari. Selama ini saya menulis sendiri skrip berbasis Sharp untuk melakukan optimasi gambar seperti ini, tetapi Jampack sepenuhnya menggantikannya dan bekerja jauh lebih baik
    Setelah membangun situs statis Quarto lalu menjalankan Jampack, ukuran folder berkurang 32%, dan sejauh ini belum ada kekurangan yang terlihat
    Menurut PageSpeed Insights, sebelum Jampack skor mobile adalah performa 52, aksesibilitas 73, praktik terbaik 100, SEO 85; sedangkan desktop adalah performa 90, aksesibilitas 75, praktik terbaik 100, SEO 82
    Setelah diterapkan, hasilnya mobile: performa 49, aksesibilitas 80, praktik terbaik 100, SEO 92; desktop: performa 85, aksesibilitas 82, praktik terbaik 100, SEO 91

    • Skor Lighthouse dan PageSpeed Insights bisa berfluktuasi. Saat melakukan perbandingan performa seperti ini, sebaiknya jalankan beberapa kali dan lihat mediannya
      Ada juga materi yang mengatakan “median skor Lighthouse dari 5 kali eksekusi dua kali lebih stabil daripada 1 kali eksekusi”: https://developers.google.com/web/tools/lighthouse/variabili...
    • Senang mendengar kamu menyukainya. Namun saya kira metrik performa akan membaik lebih banyak. Kalau tidak keberatan, saya ingin melihat hasil situs statis sebelum Jampack diterapkan
      georges [at] divriots [dot] com

  • Ini mengingatkan saya pada modul PageSpeed untuk Apache dan Nginx: https://developers.google.com/speed/pagespeed/module

  • Wah, saya cukup suka ini. Akan saya coba
    Kalau ada yang merasa ini kurang bagus, saya ingin mereka menunjukkan cacatnya. Di mata saya, ini mirip seperti mengompilasi C menjadi assembly yang sangat teroptimasi, dan tampak seperti alat yang benar-benar mengambil alih pekerjaan yang tidak ingin saya lakukan sendiri

    • Kalau kita harus mendistribusikan sesuatu seperti assembly yang sangat teroptimasi untuk HTML dan CSS, saya tidak yakin kita sedang menuju arah yang benar
      Menurut saya, jika kita menulis HTML dan CSS yang paling sederhana dan intuitif, browser di semua perangkat seharusnya bisa merendernya dengan baik begitu saja
      Kalau memang harus mendistribusikan hasil optimasi di level seperti itu, mungkin lebih baik melewati HTML dan CSS sama sekali, mendistribusikan WebAssembly yang sangat teroptimasi, lalu membiarkan developer memakai bahasa apa pun yang mereka mau

  • Akan bagus kalau ada cara untuk membuat subset font berdasarkan rentang Unicode dari output SSG, dan mengunci axis OpenType berdasarkan font-feature-settings yang didefinisikan di CSS

    • Benar, ada banyak hal keren yang bisa dilakukan di sisi font. Di TODO ada pekerjaan untuk otomatis menambahkan fallback font sistem dengan metrik yang benar agar CLS otomatis membaik
      Saya penasaran apakah itu yang dimaksud dengan “mengunci axis OpenType berdasarkan font-feature-settings”, atau maksudnya hal lain
      Saya juga ingin melakukan optimasi subset font, tetapi belum yakin seberapa besar peningkatannya. Penasaran apakah kamu pernah mencobanya secara manual
    • Kalau memakai font browser/sistem, kita bisa mengoptimalkannya menjadi ukuran font 0, jadi saya tidak yakin perlu repot-repot

  • Konsep mengidentifikasi CSS penting yang harus di-inline alih-alih diletakkan di stylesheet terpisah terasa menarik
    Saya berharap ada cara prinsipil untuk membedakan CSS penting dan tidak penting. Misalnya efek interaksi pengguna seperti :hover selalu dianggap tidak penting
    Namun library yang digunakan tampaknya merender halaman lalu membuat tebakan terbaik tentang aturan mana yang bisa dianggap penting, jadi agak disayangkan: https://github.com/GoogleChromeLabs/critters

    • Kalau CSS-nya di bawah 50KB, inline saja semuanya. Kalau CSS-mu lebih dari 50KB, mungkin ada yang salah
      Tentu kalau font juga di-inline, itu bisa dimengerti, tetapi jika hanya style lain saja melebihi 50KB, biasanya arahnya keliru
      Seriusnya, inlining sangat bagus untuk performa bahkan dibandingkan cache yang sudah hangat, dan ambang ketika stylesheet atau skrip eksternal menjadi lebih baik ternyata cukup tinggi—dalam standar pasar umum bisa sampai ratusan KB
      Konsep CSS penting terasa seperti pendekatan defetis untuk mengambil kembali sedikit performa yang terbuang, alih-alih memperbaiki masalah mendasarnya
      Namun ini bukan teknik yang sistematis, hanya penilaian berdasarkan sedikit pengalaman dan observasi. Akan bagus kalau ada yang mengukur konsep ini dengan lebih benar, tetapi sepertinya bukan saya yang akan melakukannya

  • Ini tampaknya mencakup berbagai kegunaan yang membuat orang sejak awal memilih SSG dan plugin, terutama jika memilih Astro atau Eleventy
    Apakah ada alasan untuk lebih memilih menjadikannya langkah terpisah setelah build? Rebuild saat pengembangan memang jadi lebih cepat, tetapi tampaknya ada trade-off dengan kemungkinan melewatkan bug halus yang muncul saat menambahkan hal-hal seperti deklarasi width gambar

  • Sebagai orang yang membenci pekerjaan layout halaman web dan menolak mempelajarinya, tetapi sesekali tetap harus melakukannya, alat ini tampak sangat bagus

  • Kelihatannya bagus. Namun secara pribadi saya tidak suka harus menunggu gambar saat menggulir halaman ke bagian bawah fold
    Secara default, apakah setelah konten fold pertama selesai, sisa konten di bawahnya dimuat di latar belakang?

    • Tidak. Ini memanfaatkan lazy loading native browser. Browser utama memperlakukan atribut loading="lazy" sebagai “jangan muat gambar/iframe ini sampai hampir terlihat”: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/im...
      Namun rasio aspek dimasukkan secara inline, jadi layout tidak akan bergeser setelah loading selesai. Dengan begitu, dosa terbesar lazy loading bisa dihindari
    • Seperti yang ditunjukkan @lelandfe, Jampack menggunakan loading="lazy" native browser
      Saat ini belum ada cara untuk mengubah perilaku ini, tetapi kami bisa menambahkan opsi untuk memuat gambar di bawah fold secara pre-load di latar belakang setelah seluruh halaman dimuat. Itu ide yang cukup bagus
      Namun saya khawatir gambar yang tidak diperlukan di bagian bawah halaman juga ikut dimuat. Kalau berupa opsi, tiap orang bisa menyalakan atau mematikannya, jadi sepertinya baik-baik saja

  • Apa saja static site generator yang digunakan di lingkungan produksi? Sepertinya outputnya bisa dioptimalkan lebih jauh dengan alat ini
    Misalnya kemarin saya menghabiskan satu hari penuh mengikuti contoh untuk mengubah situs web Divjoy React menjadi HTML sederhana agar bisa disajikan dari bucket S3. Saya tidak menyangka akan sesulit ini dan masih kebingungan
    Idealnya ada sesuatu yang otomatis men-deploy ke bucket S3 dan sekaligus menghubungkan domain. Menyakitkan karena saya sudah membayar, tetapi developernya menghilang dan Discord-nya juga terbengkalai. Karena itu saya selalu lebih menyukai FOSS

    • Ada Hugo, Zola, Jekyll, dan semacamnya
      Sampai taraf tertentu, mereka sudah memiliki sebagian fungsi seperti ini

  • Di salah satu proyek saya, tidak ada perubahan besar. Misalnya ukuran bundle total memang turun, tetapi ukuran gzip naik, jadi secara praktis saya justru rugi bersih
    Meski begitu, peningkatan CSS tampaknya benar-benar membantu
    Idenya terlihat bagus, dan kalau proyeknya memiliki gambar, mungkin akan membantu

    • Kalau tidak ada gambar, memang manfaatnya terbatas. Selain itu, karena kompatibilitas browser ditingkatkan secara otomatis, ukuran CSS akhir juga bisa menjadi lebih besar
      Kamu bisa mematikan fitur ini dengan menyetel browserlist ke string kosong: https://jampack.divriots.com/features/browser-compatibility/