[🛠] Mengurangi Waktu Build Blog Multibahasa dari 21 Menit ke Kisaran 1 Menit

✨ Ringkasan GPT-5.5 　

Catatan menelusuri build Jekyll yang setelah ekspansi multibahasa melewati 20 menit melalui profile, lalu memangkas render berulang dan pemindaian seluruh situs hingga turun ke 1 menit 50 detik.

Dalam post sebelumnya tentang pengenalan multibahasa, saya menambahkan struktur operasi multibahasa ke blog.

Pada awalnya, saya cukup bangga dengan hal ini.

ko, en, ja, zh-Hans, es, pt-BR, fr, id.

Ada postingan, menu, hreflang, dan jumlah views juga dibagikan. Di permukaan, ini ternyata merupakan blog multibahasa yang cukup bagus.

Namun masalah lain segera muncul.

Pembangunannya memakan waktu terlalu lama.

Pembuatan produksi pertama adalah seperti ini.

done in 1311.791 seconds

21 menit 52 detik.

Ini bukan angka yang seharusnya keluar dari blog sederhana. Jika mengedit satu post membuat build memakan lebih dari 20 menit, lama-lama saya akan menghabiskan lebih banyak waktu menunggu build daripada menulis.

Pada awalnya, Anda mungkin hanya berpikir, “Pasti lambat karena teksnya dalam 8 bahasa.”

Tapi itu kesimpulan yang terlalu terburu-buru.

Memang benar jumlah halamannya bertambah. Namun, ada sesuatu yang lebih untuk mencapai tanda 20 menit. Jadi kali ini saya tidak memperbaikinya dengan intuisi dan mengaktifkan jekyll build --profile.

Pelaku pertama: Menyematkan kalender JSON di setiap halaman

Pertama, saya melihat ukurannya _site.

_site: 1.2G
Total HTML: sekitar 840MB

HTML blog statis adalah 840MB.

Itu tidak masuk akal.

Ketika saya membuka salah satu artikel representatif, saya langsung melihat alasannya. Kalender sidebar menyisipkan daftar lengkap artikel dalam bahasa inline, JSON, di setiap halaman artikel.

<script type="application/json" data-calendar-posts>
[
  ...
]
</script>

Bukan itu saja.

Saat saya membuat daftar cadangan kalender, saya memeriksa kembali seluruh daftar postingan untuk setiap tanggal. Artikel yang tidak memenuhi syarat juga dicetak massal sebagai ruang kosong di Liquid. Layar yang terlihat kecil, tapi ada ruang besar dan daftar berulang yang tersembunyi di dalam HTML.

Ini adalah masalah struktural, bukan masalah fungsional.

Server tidak perlu membuat kalender untuk setiap halaman sebagai HTML lengkap. JS sudah bisa menggambar kalender secara dinamis. Kemudian, server hanya perlu menyediakan kerangka dasar bulan ini dan jalur file datanya.

Jadi, saya menghapus data kalender untuk setiap bahasa ke dalam file JSON terpisah.

/assets/data/calendar-posts-ko.json
/assets/data/calendar-posts-en.json
/assets/data/calendar-posts-ja.json
/assets/data/calendar-posts-zh-Hans.json
/assets/data/calendar-posts-es.json
/assets/data/calendar-posts-pt-BR.json
/assets/data/calendar-posts-fr.json
/assets/data/calendar-posts-id.json

Dan hanya itu yang tersisa di halaman.

data-calendar-posts-src="/assets/data/calendar-posts-en.json"

Hasilnya langsung menurun.

1311,791 detik -> 745,273 detik

Sudah berkurang hampir setengahnya, tapi masih lama.

Saya mengetahuinya saat ini.

Kalender adalah penyebab utama, namun bukan satu-satunya penyebab.

Pelaku kedua: Statistik menu dihitung 80.000 kali

Profil selanjutnya lebih eksplisit.

_includes/sidebar-nav-stats.html  81120 calls  173.084s
_includes/masthead.html            2704 calls  319.860s
_includes/seo.html                 2704 calls  119.985s
sitemap.xml                           1 call   117.495s

Yang paling lucu di sini adalah sidebar-nav-stats.html.

Penyertaan ini adalah bagian kecil yang menambahkan jumlah postingan dan waktu postingan terbaru di sebelah kategori sidebar.

Misalnya saja seperti ini.

Daily Review (310) 1 days ago
Devlog (24) 2 days ago

Namun setiap kali bagian kecil ini dipanggil, ia menyortir ulang dan memfilter ulang seluruh daftar postingan.

Setiap item menu per bahasa.

Setiap halaman.

Juga di sidebar desktop dan menu seluler.

Hasilnya, dipanggil sebanyak 81.120 kali.

Nilai ini sebenarnya tidak perlu dihitung ulang untuk setiap halaman. Jika URL menunya sama dan bahasanya sama, maka hasilnya akan sama. Jadi saya mengubah jekyll-include-cache menjadi include_cached.

{% include_cached sidebar-nav-stats.html url=child.url lang=current_lang %}

Kemudian jumlah panggilan berubah seperti ini:

81120 calls -> 210 calls
173 detik -> 0,4 detik

Ini hampir mencapai tingkat perbaikan bug.

Pelaku ketiga: Terus memindai seluruh situs untuk membuat tautan bahasa

Saat menambahkan konversi multi-bahasa, logika ini ditambahkan ke masthead, seo, dan sitemap.

Apakah URL bahasa ini benar-benar ada?

Niatnya benar.

Jangan memasukkan URL terjemahan yang tidak ada ke hreflang atau menu ubah bahasa. Jadi, pertama-tama, saya memeriksa semua halaman dan semua dokumen koleksi untuk memeriksa apakah URL-nya ada.

Masalahnya adalah hal ini terulang di setiap halaman.

2704 pages * site.pages scan * translated collections scan

Struktur ini terus memburuk seiring dengan berkembangnya situs multibahasa.

Jadi saya mengubah metode saya.

Sudah ada aturan untuk terjemahan URL blog ini.

/some/post/
/en/some/post/
/ja/some/post/
...

Dan pengecualian dapat dikelola secara terpisah sebagai data.

Kali ini sesi memoar yang masih menunggu terjemahannya ditempatkan di _data/i18n_pending.yml.

entries:
  - source_url: /devlog/github-pages-blog/github-pages-blog-english-version-lessons/
    locales:
      - en
      - ja
      - zh-Hans
      - es
      - pt-BR
      - fr
      - id

Dengan melakukan ini, postingan biasa dihubungkan menggunakan aturan awalan, dan postingan yang tertunda akan dikembalikan ke bahasa asal lain. Kami tidak memindai seluruh situs.

Hasilnya luar biasa.

kepala tiang: 319,860 detik -> 9,882 detik
seo: 119,985 detik -> 7,181 detik
peta situs: 117,495 detik -> 4,633 detik

Dan build terakhir berakhir seperti ini.

done in 110.344 seconds

Dari 21 menit 52 detik menjadi 1 menit 50 detik.

Masih sulit untuk mengatakan bahwa ini adalah blog yang cepat, tapi setidaknya tidak lagi dalam kondisi “Saya terlalu takut dengan build untuk menulis.”

Hal-hal yang harus diperhatikan saat memperbaiki

Pengoptimalan ini tampaknya mudah hanya dengan melihat kecepatannya.

Namun yang benar-benar harus diwaspadai adalah sisi yang fungsinya rusak.

Khususnya di situs multibahasa, Anda mungkin menyukai pembuatannya yang lebih cepat, tetapi masalah ini mungkin muncul.

Ganti bahasa, tautannya ke 404
hreflang menunjuk ke URL yang tidak ada
Terjemahan yang tertunda ditampilkan secara bergantian di mesin pencari.
Tombol Tentang/Bahasa tidak lagi muncul di ponsel
Kalender dibiarkan kosong

Jadi pada akhirnya, saya menjalankan browser dan pemeriksaan otomatis bersama-sama.

Yang saya konfirmasi adalah ini:

kesuksesan production build
Tautan untuk beralih antara 8 bahasa untuk postingan perjalanan berbahasa Inggris adalah normal.
hreflang 8 bahasa + x-default normal
Postingan yang ditahan untuk diterjemahkan akan dikembalikan ke bahasa asal lainnya
Tentang, 🇮🇩Bahasa Inggris, dan kalender ditampilkan normal di ponsel
200 URL multibahasa teratas
Mengonfirmasi semua struktur rendering di 2481 postingan sumber
Periksa penguraian JSON kalender
i18n post coverage errors: 0

2.481 artikel tersebut tidak dibaca satu per satu dengan mata manusia.

Namun, setidaknya “Apakah ada file keluaran?”, “Apakah struktur teks dirender?”, “Apakah tautan bahasa rusak?”, dan “Apakah data kalender ada?” semua diverifikasi melalui inspeksi otomatis.

Inilah inti dari pekerjaan ini.

Pengoptimalan build bukan hanya tentang mengurangi kecepatan, namun juga tentang menentukan ulang kontrak fitur yang ada.

Apa yang saya pelajari kali ini

Jekyll terlihat sederhana karena merupakan generator situs statis.

Namun begitu Anda mulai menelusuri seluruh situs di Liquid, bahkan situs statis pun menjadi cukup berat.

Khususnya dalam struktur multibahasa, inefisiensi kecil akan segera berlipat ganda.

Jumlah halaman * Jumlah bahasa * Jumlah menu * Jumlah total postingan

Jika jenis perkalian ini disembunyikan, maka build tersebut akan tiba-tiba meledak nantinya.

Apa yang saya pelajari kali ini sederhana saja.

Pertama, jangan mengulang data yang sama sebaris di setiap halaman.

Kedua, jika inputnya sama, penyertaannya di-cache.

Ketiga, jangan memindai seluruh situs di setiap halaman untuk memeriksa keberadaan URL.

Keempat, jangan menangani pengecualian berdasarkan intuisi, namun memperlakukannya sebagai data.

Kelima, setelah optimalisasi, kontrak fungsional diverifikasi dengan inspeksi otomatis.

Blog ini kini berangsur-angsur menjadi sebuah sistem dari blog pribadi sederhana.

Itu bagus, tapi juga melelahkan.

Tapi setidaknya rasa lelah kali ini masuk akal.

Menurunkan build yang telah menunggu lebih dari 21 menit menjadi hanya 1 menit merupakan titik balik dalam pengalaman saya.

Sekarang saya setidaknya memiliki ruang untuk bernapas untuk terus mengembangkan blog multibahasa saya.