Bagaimana Majalah Smashing Mengelola Konten: Migrasi Dari WordPress Ke JAMstack

Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Netlify, platform lengkap untuk mengotomatisasi proyek web modern. Terima kasih!

Setiap kali pengembang berbicara tentang WordPress, persentase pangsa pasar mereka berubah. “ 20% dari semua situs ada di WordPress! ” “ 40% dari semua situs ada di WordPress! Berapapun persentasenya, pesannya sama: dalam hal adopsi, WordPress MASSIVE.

Jadi mengapa, dengan adopsi semacam itu, situs yang menggunakan WordPress mempertimbangkan untuk pindah ke JAMstack? Dalam seri artikel dua bagian ini, kami akan membahas seperti apa migrasi WordPress yang sebenarnya, menggunakan studi kasus dari situs yang sedang Anda baca sekarang.

Kami akan membicarakan keuntungan dan kerugian, hal-hal yang kami harap kami ketahui sebelumnya, dan apa yang membuat kami terkejut. Dan kemudian kami akan menindaklanjutinya dengan demonstrasi teknis dari satu kemungkinan jalur migrasi — tidak sepenuhnya keluar dari WordPress — tetapi bagaimana Anda dapat melayani WordPress yang dipisahkan sehingga Anda dapat memiliki yang terbaik dari kedua dunia: implementasi JAMstack dari WordPress yang memberi Anda semua kekuatan dasbor dan fungsionalitasnya, dengan kinerja dan keamanan yang lebih baik.

Mari kita menggali!

Mengapa?

Pada tahun 2015, salah satu pendiri Netlify Mathias Biilmann dan pendiri Smashing Vitaly Friedman berbicara tentang toko. Saat arsitektur JAMstack mulai berkembang, Smashing semakin tertarik pada ide tumpukan. Vitaly dan Markus (mantan direktur pelaksana di Smashing) bertanya kepada Matt apa yang akan terjadi jika Smashing bermigrasi dari situs WordPress/LAMPstack tradisional mereka ke arsitektur JAMstack.

Sebagai percobaan, Matt menghapus semua HTML dari Smashing dan menghostingnya di Netlify, mengirimkan konten secara statis dari CDN. Hasilnya menarik — versi statis rata-rata lebih dari enam kali lebih cepat!

Jenis arsitektur ini bekerja dengan sangat baik sebagian karena halaman tidak dikompilasi sesuai permintaan saat Anda mengunjunginya. Karena Anda menyajikan konten yang dibuat sebelumnya langsung dari Jaringan Pengiriman Konten , situs sudah "ada" dan siap untuk pengguna.

Karena Anda melayani melalui CDN, Anda juga dapat mendistribusikan konten ke seluruh dunia — lebih dekat dengan calon pengunjung. Tidak ada titik pusat asal, yang sangat penting dalam kasus publikasi online yang ingin cepat untuk semua pembacanya.

Jadi panggung sudah diatur. Majalah Smashing bermigrasi ke JAMstack — ke Netlify sebagai platform pada khususnya. Dalam 10 tahun beroperasi, Smashing telah berkembang dari publikasi online kecil menjadi blog WordPress besar, menjual barang-barang seperti buku, tiket konferensi, dan lokakarya.

Ada beberapa bagian dari situs ini:

• blog WordPress
• Papan pekerjaan rel
• Toko Shopify
• CMS lain untuk situs konferensi

Ketika Netlify pertama kali memulai migrasi, situs tersebut mengalami beberapa masalah kinerja, terbebani oleh 20 ribu komentar dan ribuan artikel. Smashing juga tertarik dengan otentikasi sebagai bagian dari rencana berlangganan baru, serta desain ulang untuk tampilan yang lebih modern.

Keandalan

Smashing secara teratur mencapai apa yang diimpikan oleh platform lain: artikel dibagikan secara luas melalui komunitas yang sangat besar. Namun, ketika titik kritis lalu lintas tercapai untuk sebuah pos, Smashing secara teratur memiliki masalah dengan pemadaman. Untuk mengurangi ini, penggunaan berat plugin WordPress diperkenalkan ke tumpukan mereka, tetapi mereka masih berjuang untuk mempertahankan metrik waktu aktif yang baik.

Pindah ke Netlify memungkinkan tim Smashing untuk menghindari kesalahan koneksi database dan tidak khawatir tentang downtime bahkan ketika sebuah artikel melihat sejumlah besar lalu lintas. Mengapa? Karena saat melayani tanpa server, konten bawaan tidak harus dibuat dan disajikan — konten sudah ada, siap untuk dilihat. Tidak ada yang diminta di tempat kecuali untuk seluruh halaman statis.

Melayani melalui CDN juga memungkinkan Smashing untuk tidur sedikit lebih mudah dalam hal keamanan. wp-login.php telah lama menjadi sumber lubang keamanan dan vektor serangan. Konten bawaan tidak dapat diakses dengan cara yang sama dan lubang keamanan tidak ada di mana-mana.

Pembatalan Cache

Smashing telah menggilir setiap plugin caching WordPress, dengan hasil yang bervariasi dan banyak masalah. Vitaly Friedman dari Smashing menyebutkan,

“Masalah utama yang kami miliki terkait dengan 'Kesalahan Saat Membuat Koneksi Database' yang terus kami alami setiap minggu, dan kami benar-benar mencoba setiap plugin caching WordPress di luar sana. Performanya cukup OK (secara keseluruhan), tetapi kami ingin meningkatkannya lebih jauh. Plus, kami memang ingin meluncurkan Keanggotaan dan menghubungkan semua penawaran yang berbeda — konferensi, posting pekerjaan, artikel, buku, eBuku — dengan satu platform tunggal, dan itu sangat sulit dicapai dengan WordPress yang sedang dimainkan.”

Pindah ke Netlify memungkinkan tim Smashing untuk melihat pembatalan cache instan sambil juga menyajikan konten yang di-cache dan berkinerja, tanpa overhead tambahan.

Saat Anda menerapkan situs, file HTML dihosting di CDN Netlify. Ini dioptimalkan untuk tingkat cache-hit yang tinggi, dan waktu yang cepat untuk byte pertama, sementara dapat langsung membatalkan semua file HTML yang telah berubah. Netlify juga sidik jari semua link ke aset seperti file CSS, gambar, font, atau file JS, dan melayani Smashing dengan header caching yang cache mereka selamanya. Sidik jari menjamin bahwa mereka unik, dan jika Anda memperbarui versi baru, versi yang lebih baru akan disajikan sebagai gantinya.

alur kerja

Melihat penyiapan yang ada, salah satu alasan utama migrasi adalah untuk menyatukan properti yang ada. Harus mengubah konteks antara semua tumpukan dan pengaturan teknologi yang berbeda ini menjadi masalah pemeliharaan yang sulit yang menugaskan para insinyur.

Ketika sebelumnya infrastruktur mereka dipecah di antara begitu banyak sistem yang berbeda, proses migrasi ini juga menyatukan semuanya , menjaga situs utama, situs konferensi, bagian langganan dan e-niaga semua bekerja bersama alih-alih dikelola secara terpisah dengan tumpukan yang berbeda. Ini membantu menjaga biaya pengembangan tetap rendah dan pengalaman pengembang bekerja di semua properti secara konsisten.

Bagian migrasi WordPress terbukti menjadi yang terbesar dan paling rumit. Netlify mencoba mengekspor data dari eksportir WP, hanya untuk menemukan bahwa konten memiliki penyematan yang perlu dipertahankan, atau terkadang diubah oleh plugin. Untuk menjaga keseimbangan dengan apa yang ada di situs, serangkaian scraper ditulis, dipecah berdasarkan artikel, aset, komentar, dan beranda.

Setelah itu ditulis dan diubah, itu dimuat ke dalam repo baru di GitHub, dan Netlify CMS digunakan sebagai gantinya. Apa yang membuat Netlify CMS unik adalah ringan, dan mengintegrasikan editor konten ke dalam alur kerja Git — artinya ia akan secara harfiah menarik dan menyajikan file penurunan harga dari repo git alih-alih database. Selain itu, Netlify CMS adalah platform agnostik dan bekerja dengan (hampir) semua generator situs statis dan situs yang disimpan di GitHub.

Saat itu, Sara Soueidan bekerja untuk Smashing sebagai pengembang front-end lepas pada desain ulang mereka. Dia membuat perpustakaan komponen untuk membangun arsitektur front-end dan mengatakan betapa lebih sederhananya untuk digunakan karena dia bekerja secara langsung di git, bahkan ketika bekerja dengan CMS.

“Semua yang saya dorong ke repositori diterapkan langsung ke pustaka pola yang berarti Anda tidak perlu memelihara dua set komponen yang berbeda... jenis kontinuitas ini hebat! Yang harus saya lakukan adalah menulis HTML, CSS, dan JavaScript dan mendorong ke repo dan semuanya bekerja seperti sulap. Alur kerjanya sangat fantastis.”

Semua ini mengatakan, CMS Netlify terkadang terlalu ringan untuk kasus penggunaan lalu lintas dan skala tinggi seperti itu. Smashing secara teratur memiliki penulis tamu dan staf editorial penuh. Beberapa fitur kaya yang ditawarkan WordPress sangat membantu untuk jenis lingkungan yang sangat kolaboratif ini.

Itu sebabnya dalam tutorial berikut, kami akan memandu Anda melalui model tanpa kepala , di mana Anda masih dapat menuai manfaat dari dasbor WordPress untuk pembuat konten, tetapi menggunakan WordPress melalui API dan membuat pengembangan bergantung pada alur kerja git-centric yang mudah untuk pengembang untuk mempertahankan juga. Pantau terus!

Pilihan Kerangka

Dalam prototipe awal yang dibuat Matt Biilmann, ia menulis semuanya dalam Preact minimal, dipasangkan dengan Hugo, karena ia sangat fokus pada kinerja. Dia hanya menggunakan alat peraga dan membuat semuanya sangat ringan. Saat ia melewati proyek untuk dikelola oleh pengembang Smashing, Ilya Pukhalski, ia menemukan bahwa Preact kekurangan beberapa fitur yang mereka lewatkan untuk memanfaatkan ekosistem React. Akhirnya, manfaat Redux dan perpustakaan lain melebihi biayanya.

Mencerminkan sekarang, Matt mengatakan dia akan menggunakan Vue, yang tidak memiliki pangsa pasar yang cukup pada saat itu (saya bersumpah saya tidak memintanya untuk mengatakan itu). Saya mengajukan pertanyaan yang jelas: mengapa tidak Svelte? Karena orang-orang yang berpikiran kinerja cenderung meraih perpustakaan itu. Dia menyebutkan bahwa Svelte belum memiliki ekosistem yang dimiliki Vue.

Ketika Matt merenungkan apakah dia masih akan menggunakan Hugo atau tidak, dia mengatakan bahwa dia mencintai Hugo, tetapi apa yang dia temukan sulit untuk proyek ini khususnya adalah bahwa itu tidak memiliki cukup sistem plugin — membuat iklan spanduk dan hal-hal lain. alam itu tidak cukup dapat diprogram dengan Hugo dan dia perlu menyuntikkan skrip untuk mencapainya. Skrip ini cenderung memperlambat proses pembuatan. Meskipun demikian, kami masih menggunakan Hugo untuk situs kami sendiri di netlify.com dan menyukainya — peringatan ini sangat khusus untuk kebutuhan situs Smashing pada khususnya.

Jika dia bisa melakukannya lagi, dia mungkin memilih Eleventy, yang memiliki kemampuan kaya dalam hal membuat plugin dan skrip yang dapat diperpanjang lainnya. Atau, jika dia menggunakan Vue, Nuxt akan menawarkannya beberapa kemampuan plugin yang bagus sambil memungkinkan menjadi pilihan yang baik untuk kerangka kerja itu, menawarkan rendering sisi server, perutean, dan pembuatan statis.

Membangun Situs Besar

Ada satu masalah yang muncul saat bekerja dengan situs sebesar Smashing dan mungkin Anda sudah tahu apa itu, kami baru saja menyentuhnya. Memang benar bahwa dengan situs besar dari halaman prebuilt yang disajikan di CDN, kinerjanya masih bagus karena kami tidak membangun apa pun dengan cepat untuk pengguna.

Tetapi manfaat itu hanya dapat terjadi jika situs tersebut dibuat sebelumnya, dan proses itu dapat memakan waktu. Sementara situs yang lebih tradisional akan membuat halaman saat Anda memintanya, kami benar-benar membuat setiap halaman terlebih dahulu untuk berjaga-jaga jika pengguna mungkin membutuhkannya. Itu membuat kinerjanya sangat cepat! Namun waktu itu sekarang dialihkan ke waktu pengembangan dan penerbitan — membuat setiap halaman bisa memakan waktu.

Ini bukan masalah besar dengan situs yang lebih kecil, tetapi pada skala Majalah Smashing, kita perlu memikirkan waktu itu sedikit lebih lama, terutama agar orang dapat menjaga produktivitas tetap tinggi sambil secara aktif membuat konten setiap hari.

Apa yang dilakukan Netlify adalah membuat folder besar /production-articles yang memuat sebagian besar dari ribuan artikel yang sudah mereka hosting. Kemudian dibuat direktori kerja tersendiri yang disebut content/articles dimana artikel yang sedang aktif dibuat dan diedit dapat ditempatkan.

Proses pembuatan ini berarti bahwa setiap orang yang bekerja di situs bekerja dengan kumpulan artikel yang lebih kecil untuk pengembangan lokal, tanpa halangan dengan menunggu seluruh pembangunan. Proses ini dikelola oleh tugas tegukan untuk menyiapkan artikel produksi, dan membebaskan Hugo untuk hanya menangani apa yang sedang dikerjakan secara aktif.

Salah satu kekurangan dari pendekatan ini adalah masih memerlukan seluruh build untuk dijalankan, membuat prosesnya lambat. Pada publikasi yang lebih kecil, ini mungkin tidak terlalu penting, tetapi pada skala Smashing, ini memperlambat proses publikasi.

API Sumber Terbuka

Pada awalnya, kami menyebutkan bahwa antara lain, Smashing tertarik untuk memigrasikan solusi e-commerce yang ada, menangani komentar di luar WordPress, dan menambahkan fungsionalitas untuk auth. Semua bagian fungsionalitas ini dibangun dengan solusi open-source yang dipelihara Netlify, memecahnya menjadi API stateless:

• Beritahukan
  API dan alat build untuk menangani komentar dalam jumlah besar.
• GoCommerce
  API kecil berbasis Go untuk situs e-niaga yang menangani pesanan dan pembayaran.
• GoTrue
  API open-source kecil yang ditulis dalam Golang yang dapat bertindak sebagai layanan API mandiri untuk menangani pendaftaran pengguna dan otentikasi untuk proyek. Ini didasarkan pada OAuth2 dan JWT dan akan menangani pendaftaran pengguna, otentikasi, dan data pengguna khusus.

Masing-masing bagian ini memerlukan migrasi dan faktor unik mereka sendiri, dan sementara mereka berada di luar cakupan artikel ini, semuanya tercakup dalam buku gratis yang ditulis bersama Matt berjudul “ Modern Web Development on the JAMstack ”. Kami juga akan melakukan beberapa penyelaman mendalam seperti ini — dengan contoh yang dapat digunakan — ke dalam pencarian, dan otentikasi, di posting berikutnya.

Kesimpulan

Migrasi berjalan lancar. secara mengejutkan? Er… berjalan dengan baik. Menghancurkan tidak dihukum karena keberhasilannya sendiri — ketika sebuah artikel populer muncul, mereka dapat menyajikan konten secara konsisten, tidak lagi menanggung beban besar. Seiring dengan ini, perpindahan ke infrastruktur JAMstack membawa kinerja dan keamanan yang lebih baik.

Markus Seyfferth, mantan CEO Majalah Smashing, mencatat:

“Waktu untuk pertama kali memuat jauh lebih cepat dari sebelumnya… sebelumnya kami harus menunggu file HTML disajikan selama 800 md dan sekarang menjadi 80 md .”

Proses ini berhasil dan seperti proyek rekayasa besar lainnya, pelajaran telah dipelajari di sepanjang jalan. Dalam artikel berikutnya dalam seri ini, kami akan menjalankan tutorial dan demo untuk apa yang kami rekomendasikan berdasarkan apa yang telah kami pelajari. Jika Anda ingin memodernisasi pengembangan WordPress Anda dan menuai kinerja dan manfaat keamanan dari JAMstack, baca terus!