Saya memutuskan untuk membantu mereka yang sibuk memilih SSG. Kolega saya telah mengumpulkan daftar pertanyaan untuk membantu Anda menemukan generator situs statis. Terlampir pada daftar ini adalah ringkasan SSG populer. Ini hanya kekurangan penilaian tentang bagaimana kinerja SSG yang berbeda.
Kesamaan yang dimiliki semua SSG adalah cara kerjanya. Yakni, mereka menerima beberapa data sebagai masukan dan meneruskan data ini melalui mesin templat. Outputnya adalah file HTML. Proses ini biasa disebut dengan membangun proyek.
Untuk mendapatkan data kinerja yang sebanding untuk SSG yang berbeda, ada banyak perbedaan yang perlu dipertimbangkan. Perlu memperhatikan fitur proyek, faktor-faktor yang memperlambat atau mempercepat perakitan. Di sinilah eksplorasi kami atas kinerja SSG populer dimulai.
Meski begitu, tujuan kami bukan hanya menemukan SSG tercepat. Reputasi sebagai "yang tercepat" telah menguasai Hugo . Maksud saya, situs web proyek mengatakan bahwa Hugo adalah kerangka kerja pembuatan situs web tercepat di dunia. Dan itu berarti - apa adanya.
Artikel ini membandingkan kinerja SSG populer. Yakni, kita berbicara tentang waktu pembangunan proyek. Tetapi yang paling penting di sini adalah analisis mendalam tentang mengapa alat tertentu menunjukkan hasil tertentu. Ini akan menjadi kesalahan, terlepas dari apapun kecuali waktu perakitan proyek, untuk memilih "SSG tercepat" atau segera meninggalkan yang "paling lambat". Mari kita bicarakan mengapa demikian.
Tes
Proses pengujian SSG dirancang untuk dimulai dengan meneliti beberapa proyek populer dan menjelajahi pemrosesan format data sederhana. Ini adalah dasar untuk membangun studi tentang generator situs yang lebih statis dan memperluas studi ini dengan format data yang lebih kompleks. Studi tersebut sekarang mencakup enam SSG populer:
Saat mempelajari masing-masing, pendekatan berikut dan kondisi berikut diterapkan:
- Sumber data untuk setiap pengujian (proses pembuatan proyek) adalah file penurunan harga yang berisi header yang dibuat secara acak (yang disebut "materi depan") dan badan dokumen (tiga paragraf teks).
- Tidak ada gambar di dalam dokumen.
- Tes dijalankan beberapa kali di komputer yang sama. Hal ini membuat nilai spesifik yang diperoleh dari pengujian kurang penting dibandingkan perbandingan hasil relatif.
- Outputnya berupa teks biasa pada halaman HTML. Pemrosesan data dilakukan dengan menggunakan pengaturan standar, yang dijelaskan dalam panduan memulai untuk setiap SSG yang diperiksa.
- « ». Markdown-.
Tes ini dianggap tes kinerja (tolok ukur). Mereka menggunakan file penurunan harga sederhana, menghasilkan kode HTML tanpa gaya.
Dengan kata lain, outputnya adalah, dari sudut pandang teknis, sebuah situs web yang dapat digunakan dalam produksi. Tapi ini bukan implementasi dari skenario SSG yang sebenarnya. Alih-alih mencoba mereproduksi situasi nyata, kami ingin mendapatkan dasar untuk membandingkan kerangka kerja yang diteliti. Saat menggunakan alat di atas untuk membuat situs nyata, SSG akan bekerja dengan data yang lebih kompleks dan dengan pengaturan berbeda, yang akan memengaruhi waktu pembuatan proyek (ini biasanya memperlambat pembangunan).
Misalnya, salah satu perbedaan antara pengujian kami dan kasus penggunaan SSG dunia nyata adalah fakta bahwa kami sedang menyelidiki proses pembuatan dingin. Pada kenyataannya, semuanya sedikit berbeda. Misalnya, jika proyek menyertakan 10.000 file penurunan harga yang merupakan sumber data untuk SSG, dan jika Gatsby digunakan untuk membangun proyek, maka cache Gatsby akan digunakan. Dan ini sangat (hampir setengahnya) mengurangi waktu perakitan.
Hal yang sama dapat dikatakan untuk build tambahan. Hal ini berkaitan dengan membandingkan build panas dan dingin dalam arti bahwa hanya file yang diubah yang diproses saat melakukan build tambahan. Kami tidak memeriksa build inkremental dalam pengujian ini. Kedepannya, sangat mungkin studi ini akan dikembangkan ke arah tersebut.
SSG dari level yang berbeda
Sebelum kita mulai, mari kita lihat fakta bahwa sebenarnya ada dua jenis SSG, dua tingkat generator situs statis. Sebut saja mereka "dasar" dan "lanjutan".
- Generator dasar (meskipun tidak sesederhana itu), pada kenyataannya, adalah alat baris perintah (Command-Line Interface, CLI) yang mengambil data dan menghasilkan HTML. Seringkali kemampuan mereka memungkinkan perluasan ke arah pemrosesan sumber daya tambahan (kami tidak melakukan ini di sini).
- Generator tingkat lanjut menawarkan beberapa fitur tambahan selain membuat situs statis. Ini adalah, misalnya, rendering halaman sisi server, fungsi tanpa server, integrasi dengan berbagai kerangka web. Mereka biasanya, segera setelah instalasi, dikonfigurasi untuk memberikan kemampuan yang lebih dinamis kepada pengguna daripada generator dasar.
Untuk tes ini, saya secara khusus memilih tiga generator di setiap level. Yang dasar termasuk Eleventy, Hugo dan Jekyll. Tiga generator lainnya didasarkan pada kerangka kerja frontend. SSG ini mencakup berbagai alat tambahan. Gatsby dan Next didasarkan pada React, sedangkan Nuxt didasarkan pada Vue.
| Generator dasar | Generator tingkat lanjut |
| Sebelas | Gatsby |
| Hugo | Lanjut |
| Jekyll | Nuxt |
Hipotesis dan asumsi
Saya mengusulkan untuk menerapkan metode ilmiah dalam penelitian kami . Sains sangat mengasyikkan (dan bisa sangat bermanfaat).
Hipotesis saya adalah jika SSG maju itu berarti akan berjalan lebih lambat dari generator dasar. Saya yakin hal ini akan tercermin dalam hasil studi, karena lebih banyak mekanisme yang terlibat dalam kerja SSG tingkat lanjut daripada dalam kerja SSG dasar. Akibatnya, sangat mungkin bahwa, berdasarkan penelitian, generator dasar dan lanjutan dapat dengan jelas dibagi menjadi dua kelompok. Pada saat yang sama, generator dasar akan bekerja lebih cepat daripada generator tingkat lanjut.
▍Dasar SSG: kecepatan tinggi dan ketergantungan linier kecepatan build pada jumlah file
Hugo dan Eleventy akan memproses kumpulan data kecil dengan sangat cepat. Mereka adalah proses (relatif) sederhana yang dibuat oleh Go dan Node.js. Hasil tes mereka harus mencerminkan hal ini. Sementara kedua SSG ini akan melambat seiring bertambahnya jumlah file, saya berharap mereka tetap menjadi yang terdepan. Pada saat yang sama, ada kemungkinan bahwa Eleventy, dengan peningkatan beban, akan mendemonstrasikan dinamika perubahan waktu perakitan, yang lebih menyimpang dari linier daripada Hugo. Ini bisa menjadi konsekuensi sederhana dari fakta bahwa kinerja Go secara umum lebih baik daripada kinerja Node.js.
▍ SSG Lanjutan: Mulai membangun lambat dan peningkatan kecepatan berikutnya, tetapi tidak terlalu serius
SSG tingkat lanjut, atau yang terkait dengan beberapa jenis kerangka web, akan dimulai dengan lambat, dan akan terlihat. Saya menduga bahwa dalam pengujian file tunggal, perbedaan antara kerangka kerja dasar dan lanjutan akan cukup signifikan. Untuk yang dasar, itu akan menjadi beberapa milidetik, dan untuk yang tingkat lanjut, untuk Gatsby, Next dan Nuxt, itu akan menjadi beberapa detik.
SSG yang didasarkan pada kerangka web menggunakan webpack, yang menambahkan beban tambahan ke sistem saat dijalankan. Pada saat yang sama, beban tambahan ini tidak bergantung pada jumlah data yang diproses. Tapi kami sendiri setuju dengan ini, menggunakan alat yang lebih canggih (kami akan membicarakannya lebih lanjut di bawah).
Dan ketika harus memproses ribuan file, saya menduga bahwa kesenjangan antara grup generator dasar dan lanjutan akan menyempit. Pada saat yang sama, bagaimanapun, SSG tingkat lanjut masih akan sangat tertinggal dari yang dasar.
Jika kita berbicara tentang sekelompok generator tingkat lanjut, maka saya mengharapkan yang tercepat dari mereka adalah Gatsby. Saya hanya berpikir demikian karena tidak memiliki komponen rendering sisi server yang dapat memperlambat segalanya. Tapi ini hanyalah cerminan dari perasaan batin saya. Mungkin, di server Next dan Nuxt rendering dioptimalkan sedemikian rupa sehingga jika tidak digunakan, maka itu tidak mempengaruhi waktu pembuatan proyek dengan cara apa pun. Saya menduga Nuxt akan lebih cepat dari Next. Saya membuat asumsi ini berdasarkan fakta bahwa Vue "lebih ringan" dari pada React.
▍Jekyll adalah perwakilan SSG dasar yang tidak biasa
Platform Ruby terkenal karena kinerjanya yang buruk. Ini dioptimalkan dari waktu ke waktu, menjadi lebih cepat, tetapi saya tidak mengharapkan kecepatannya sebanding dengan Node.js, apalagi Go. Namun, di saat yang sama, Jekyll tidak menanggung beban tambahan yang terkait dengan kerangka kerja web.
Saya rasa pada awal pengujian, saat memproses sejumlah kecil file, Jekyll akan menunjukkan kecepatan tinggi. Mungkin setinggi Eleventy. Tetapi saat kami memeriksa pemrosesan ribuan file, kinerja akan terpukul. Menurut saya, ada alasan lain mengapa Jekyll menjadi yang paling lambat dari enam SSG yang dipelajari. Untuk mengujinya, kami memeriksa kinerja generator kami pada kumpulan file dengan ukuran berbeda - hingga 100.000.
Di bawah ini adalah grafik yang menunjukkan asumsi saya.
Asumsi mengenai ketergantungan kecepatan kerja berbagai SSG
Sumbu Y mewakili waktu pembuatan proyek, sumbu X adalah jumlah file. Berikutnya ditampilkan dalam warna hijau, Nuxt dengan warna kuning, Gatsby dengan warna pink, Jekyll dengan warna biru, Eleventy dengan warna biru kehijauan, Hugo dengan warna jingga. Semua baris mencerminkan peningkatan waktu pembuatan proyek seiring bertambahnya jumlah file. Pada saat yang sama, garis yang berhubungan dengan Jekyll memiliki sudut kemiringan terbesar.
hasil
Berikut adalah kode yang menghasilkan hasil yang sekarang akan saya bahas. Saya juga membuat halaman yang mengumpulkan hasil tes relatif.
Setelah banyak upaya untuk menemukan kondisi untuk menjalankan pengujian, saya menetapkan 10 proses dari setiap pengujian menggunakan tiga kumpulan data yang berbeda.
- Dataset dasar (Base). Ini adalah satu file. Pemrosesannya memungkinkan Anda memperkirakan waktu yang dibutuhkan SSG untuk bersiap-siap bekerja. Ini adalah waktu yang dibutuhkan SSG untuk diluncurkan. Ini bisa disebut dasar, berapa pun jumlah file yang sedang diproses.
- Sekumpulan "situs kecil" (Situs kecil). Ini memeriksa perakitan kumpulan file dari 1 hingga 1024. Setiap lulus tes baru dilakukan dengan jumlah file dua kali lipat (untuk mempermudah mengetahui apakah waktu pemrosesan file tumbuh secara linier dengan pertumbuhan jumlahnya).
- Sekumpulan "situs besar" (Situs besar). Di sini jumlah file berubah dari 1000 menjadi 64000, dua kali lipat setiap kali pengujian baru dijalankan. Awalnya saya ingin mendapatkan 128.000 file, tetapi saya mengalami kemacetan di beberapa kerangka kerja. Hasilnya, ternyata 64.000 file cukup untuk mengetahui bagaimana SSG yang dipelajari berperilaku saat memproses situs skala besar.
Inilah hasil yang saya dapatkan.
Dataset dasar
Dataset situs kecil
Dataset situs besar
Meringkas hasil
Beberapa hasil mengejutkan saya, tetapi beberapa ternyata persis seperti yang saya harapkan. Berikut beberapa temuan umum:
- Seperti yang diharapkan, SSG tercepat adalah Hugo. Ini berfungsi dengan baik pada kumpulan file dari semua ukuran. Tetapi saya tidak berharap bahwa generator lain setidaknya akan mendekatinya, bahkan pada dataset Base (saya tidak mengharapkannya untuk menunjukkan perilaku linier, tetapi lebih dari itu di bawah).
- Baik SSG, dasar dan lanjutan, sangat berbeda dalam grafik yang menunjukkan pemrosesan file dari kumpulan situs Kecil. Ini sudah bisa diduga. Namun, tidak disangka bahwa Next lebih cepat dari Jekyll pada satu set 32000 file, dan itu melewati Jekyll dan Eleventy pada 64000 file. Dan yang mengejutkan, Jekyll memiliki 64.000 file lebih cepat dari Eleventy.
- SSG . Next, , , . Hugo , — - .
- , Gatsby , , . , .
- , , , . , , Hugo 170 , Gatsby. 64000 Hugo 25 . , Hugo, SSG, . , - .
Apa maksud semua ini?
Ketika saya membagikan temuan saya dengan pencipta SSG ini, dan dengan mereka yang mendukung mereka, saya menerima dari mereka, jika tidak merinci, pesan yang sama. Jika pesan-pesan ini direduksi menjadi semacam pesan "rata-rata", maka Anda mendapatkan yang berikut:
Generator yang menghabiskan lebih banyak waktu untuk membangun proyek bekerja dengan cara ini karena mereka harus menyelesaikan lebih banyak masalah. Mereka memberi pengembang lebih banyak opsi, sementara alat yang lebih cepat (yaitu, "dasar") terutama berkaitan dengan mengonversi template ke file HTML.
Saya setuju dengan itu.
Singkatnya, ternyata penskalaan situs Jamstack sangat sulit.
Kesulitan yang akan dihadapi oleh pengembang, yang proyeknya tumbuh dan berkembang, bergantung pada karakteristik masing-masing proyek. Tidak ada data untuk mendukung ini. Dan mereka tidak bisa berada di sini, karena setiap proyek, dalam satu atau lain cara, unik.
Tapi itu semua tergantung pada preferensi pribadi pengembang, kompromi antara waktu pembuatan situs dan kenyamanan bekerja dengan SSG, yang siap dia buat.
Misalnya, jika Anda akan membuat situs besar yang penuh dengan gambar dan berencana menggunakan Gatsby, maka Anda perlu bersiap dengan kenyataan bahwa situs ini akan membutuhkan waktu lama untuk dibangun. Namun sebagai imbalannya, Anda mendapatkan ekosistem plugin yang sangat besar dan fondasi untuk membangun situs web berbasis komponen yang kuat dan terorganisir dengan baik. Jika Anda menggunakan Jekyll dalam proyek yang sama, Anda harus berusaha lebih keras untuk menjaga proyek dalam keadaan terorganisir dengan baik, untuk memastikan efektivitas pekerjaan pada proyek tersebut. Dan perakitan situs akan lebih cepat.
Di tempat kerja, saya biasanya membangun situs dengan Gatsby(atau menggunakan Next, tergantung pada tingkat interaktivitas dinamis proyek yang diperlukan). Kami bekerja dengan Gatsby untuk membuat kerangka kerja untuk membangun situs web yang sangat dapat disesuaikan dengan cepat yang berisi banyak gambar berdasarkan sejumlah besar komponen. Seiring bertambahnya ukuran situs ini, butuh waktu lebih lama untuk membuatnya, dan kami mulai menjadi kreatif. Ini tentang menerapkan ujung-tepi mikro , pemrosesan gambar di luar sistem build utama, pratinjau konten, dan banyak pengoptimalan lainnya.
Dalam proyek sendiriSaya biasanya menggunakan Eleventy. Biasanya hanya saya yang menulis kode untuk proyek semacam itu, kebutuhan saya agak sederhana (saya menganggap diri saya sebagai klien baik saya sendiri). Saya memiliki kontrol yang lebih baik atas hasil build, yang membantu saya mencapai produktivitas sisi klien yang tinggi. Dan ini penting bagi saya.
Alhasil, pilihan SSG bukan hanya pilihan antara "cepat" dan "lambat". Ini adalah pemilihan alat yang paling cocok untuk proyek tertentu, yang hasil kerjanya sesuai dengan waktu yang berlalu dalam menunggu hasil ini.
Hasil
Sebenarnya apa yang saya katakan hanyalah permulaan. Tujuan dari pekerjaan saya adalah untuk membuat basis di mana kita semua dapat mengukur waktu pembangunan relatif proyek yang dihasilkan oleh SSG populer.
Apakah Anda menemukan ketidakkonsistenan dalam proses pengujian yang saya usulkan untuk generator situs statis? Bagaimana cara meningkatkan prosedur pengujian? Bagaimana cara mendekatkan cobaan ke kenyataan? Apakah saya perlu mentransfer pemrosesan gambar ke komputer terpisah? Saya mengundang semua orang yang peduli dengan SSG untuk bergabung dengan saya dan membantu saya menemukan jawaban atas pertanyaan ini dan banyak lagi lainnya.
Generator situs statis apa yang Anda gunakan?
