Bereaksi Strategi SEO dan Praktik Terbaik
Diterbitkan: 2022-03-11React dikembangkan untuk membuat UI interaktif yang bersifat deklaratif , modular , dan lintas platform . Saat ini, ini adalah salah satu kerangka kerja JavaScript yang lebih populer — jika bukan yang paling populer — untuk menulis aplikasi front-end yang berkinerja baik. Awalnya dikembangkan untuk menulis Single Page Applications (SPA), React sekarang digunakan untuk membuat situs web dan aplikasi seluler yang lengkap.
Jika Anda memiliki pengalaman yang luas dalam pengembangan web konvensional dan pindah ke React, Anda akan melihat peningkatan jumlah kode HTML dan CSS Anda pindah ke JavaScript. Ini karena React tidak merekomendasikan membuat atau memperbarui elemen UI secara langsung, melainkan menjelaskan "status" UI. React kemudian akan memperbarui DOM agar sesuai dengan keadaan dengan cara yang paling efisien.
Akibatnya, semua perubahan pada UI atau DOM harus dilakukan melalui mesin React. Meskipun nyaman bagi pengembang, ini mungkin berarti waktu pemuatan yang lebih lama bagi pengguna dan lebih banyak pekerjaan bagi mesin telusur untuk menemukan dan mengindeks konten.
Dalam artikel ini, kami akan membahas tantangan yang dihadapi saat membangun aplikasi dan situs web React yang berkinerja SEO, dan kami akan menguraikan beberapa strategi yang digunakan untuk mengatasinya.
Bagaimana Google Merangkak dan Mengindeks Halaman Web
Google menerima lebih dari 90% dari semua pencarian online. Mari kita lihat lebih dekat proses perayapan dan pengindeksannya.
Cuplikan yang diambil dari dokumentasi Google ini dapat membantu kami. Harap dicatat bahwa ini adalah diagram blok yang disederhanakan. Googlebot sebenarnya jauh lebih canggih.
Poin yang perlu diperhatikan:
- Googlebot mempertahankan antrean perayapan yang berisi semua URL yang perlu dirayapi dan diindeks di masa mendatang.
- Saat perayap menganggur, perayap mengambil URL berikutnya dalam antrean, membuat permintaan, dan mengambil HTML.
- Setelah menguraikan HTML, Googlebot menentukan apakah perlu mengambil dan menjalankan JavaScript untuk merender konten. Jika ya, URL ditambahkan ke antrian render.
- Di lain waktu, perender mengambil dan menjalankan JavaScript untuk merender halaman. Ini mengirimkan HTML yang diberikan kembali ke unit pemrosesan.
- Unit pemrosesan mengekstrak semua
<a> tagsURL yang disebutkan di halaman web dan menambahkannya kembali ke antrean perayapan. - Konten ditambahkan ke indeks Google.
Perhatikan bahwa ada perbedaan yang jelas antara tahap Processing yang mem-parsing HTML dan tahap Renderer yang mengeksekusi JavaScript.
Perbedaan ini ada karena mengeksekusi JavaScript mahal , mengingat Googlebot perlu melihat lebih dari 130 triliun halaman web. Jadi, saat Googlebot merayapi laman web, ia segera mem-parsing HTML dan kemudian mengantrekan JavaScript untuk dijalankan nanti. Dokumentasi Google menyebutkan bahwa halaman tetap dalam antrian render selama beberapa detik, meskipun mungkin lebih lama.
Perlu juga disebutkan konsep anggaran perayapan. Perayapan Google dibatasi oleh bandwidth, waktu, dan ketersediaan instance Googlebot. Ini mengalokasikan anggaran atau sumber daya tertentu untuk mengindeks setiap situs web. Jika Anda membuat situs web besar dengan konten besar dengan ribuan halaman (misalnya, situs web e-niaga) dan halaman ini menggunakan banyak JavaScript untuk merender konten, Google mungkin dapat membaca lebih sedikit konten dari situs web Anda.
Catatan: Anda dapat membaca panduan Google untuk mengelola anggaran perayapan Anda di sini.
Mengapa Mengoptimalkan React untuk SEO Itu Menantang
Ikhtisar singkat kami tentang Googlebot, perayapan, dan pengindeksan hanya menggores permukaan. Namun, insinyur perangkat lunak harus mengidentifikasi potensi masalah yang dihadapi oleh mesin pencari yang mencoba merayapi dan mengindeks halaman React. Sekarang kita dapat melihat lebih dekat apa yang membuat React SEO menantang dan apa yang dapat dilakukan pengembang untuk mengatasi dan mengatasi beberapa tantangan ini.
Konten First-pass Kosong
Kami tahu aplikasi React sangat bergantung pada JavaScript, dan mereka sering mengalami masalah dengan mesin pencari. Ini karena React menggunakan model shell aplikasi secara default. HTML awal tidak berisi konten yang berarti, dan pengguna atau bot harus menjalankan JavaScript untuk melihat konten halaman yang sebenarnya.
Pendekatan ini berarti bahwa Googlebot mendeteksi halaman kosong selama lintasan pertama. Konten hanya dilihat oleh Google saat halaman dirender. Ini akan menunda pengindeksan konten ketika berhadapan dengan ribuan halaman.
Memuat Waktu dan Pengalaman Pengguna
Mengambil, menguraikan, dan menjalankan JavaScript membutuhkan waktu. Selanjutnya, JavaScript mungkin perlu melakukan panggilan jaringan untuk mengambil konten, dan pengguna mungkin perlu menunggu beberapa saat sebelum mereka dapat melihat informasi yang diminta.
Google telah menyusun serangkaian data vital web yang terkait dengan pengalaman pengguna, yang digunakan dalam kriteria peringkatnya. Waktu pemuatan yang lebih lama dapat memengaruhi skor pengalaman pengguna, mendorong Google untuk memberi peringkat situs lebih rendah.
Kami meninjau kinerja situs web secara rinci di bagian berikut.
Metadata Halaman
Tag <meta> sangat membantu karena memungkinkan Google dan situs media sosial lainnya menampilkan judul, gambar mini, dan deskripsi yang sesuai untuk halaman. Tetapi situs web ini mengandalkan tag <head> dari laman web yang diambil untuk mendapatkan informasi ini. Situs web ini tidak menjalankan JavaScript untuk halaman target.
React merender semua konten, termasuk tag meta, pada klien. Karena shell aplikasi sama untuk seluruh situs web/aplikasi, mungkin sulit untuk mengadaptasi metadata untuk setiap halaman.
peta situs
Peta situs adalah file tempat Anda memberikan informasi tentang halaman, video, dan file lain di situs Anda dan hubungan di antara mereka. Mesin telusur seperti Google membaca file ini untuk merayapi situs Anda dengan lebih cerdas.
React tidak memiliki cara bawaan untuk menghasilkan peta situs. Jika Anda menggunakan sesuatu seperti React Router untuk menangani perutean, Anda dapat menemukan alat yang dapat menghasilkan peta situs meskipun mungkin memerlukan beberapa upaya.
Pertimbangan SEO lainnya
Pertimbangan ini terkait dengan pengaturan praktik SEO yang baik secara umum.
- Miliki struktur URL yang optimal untuk memberi manusia dan mesin telusur ide bagus tentang apa yang diharapkan pada halaman.
- Mengoptimalkan file robots.txt dapat membantu bot penelusuran memahami cara merayapi laman di situs web Anda.
- Gunakan CDN untuk menyajikan semua aset statis seperti CSS, JS, font, dll., dan gunakan gambar responsif untuk mengurangi waktu muat.
Kami dapat mengatasi banyak masalah yang diuraikan di atas dengan menggunakan server-side rendering (SSR) atau pra-rendering. Kami akan meninjau pendekatan ini di bawah ini.
Masukkan Reaksi Isomorfik
Definisi kamus dari isomorfik adalah "sesuai atau serupa dalam bentuk."
Dalam istilah React, ini berarti server memiliki bentuk yang mirip dengan klien. Dengan kata lain, Anda dapat menggunakan kembali komponen React yang sama di server dan klien.
Pendekatan isomorfik ini memungkinkan server untuk merender aplikasi React dan mengirim versi yang dirender ke pengguna dan mesin telusur kami sehingga mereka dapat melihat konten secara instan saat JavaScript dimuat dan dijalankan di latar belakang.
Kerangka kerja seperti Next.js atau Gatsby telah mempopulerkan pendekatan ini. Kita harus mencatat bahwa komponen isomorfik dapat terlihat sangat berbeda dari komponen React konvensional. Misalnya, mereka dapat menyertakan kode yang berjalan di server alih-alih klien. Mereka bahkan dapat menyertakan rahasia API (meskipun kode server dihapus sebelum dikirim ke klien).
Satu hal yang perlu diperhatikan adalah bahwa kerangka kerja ini menghilangkan banyak kerumitan tetapi juga memperkenalkan cara penulisan kode yang berpendirian. Kami akan menggali lebih dalam tentang pertukaran kinerja di artikel ini.
Kami juga akan melakukan analisis matriks untuk memahami hubungan antara jalur render dan kinerja situs web. Namun sebelum itu, mari kita lihat beberapa dasar pengukuran kinerja situs web.
Metrik untuk Kinerja Situs Web
Mari kita periksa beberapa faktor yang digunakan mesin pencari untuk menentukan peringkat situs web.
Selain menjawab pertanyaan pengguna dengan cepat dan akurat, Google percaya bahwa situs web yang baik harus memiliki atribut berikut:
- Ini harus memuat dengan cepat.
- Pengguna harus dapat mengakses konten tanpa terlalu banyak waktu menunggu.
- Ini harus menjadi interaktif untuk tindakan pengguna lebih awal.
- Seharusnya tidak mengambil data yang tidak perlu atau mengeksekusi kode mahal untuk mencegah menguras data atau baterai pengguna.
Fitur-fitur ini dipetakan secara kasar ke metrik berikut:
- TTFB : Time to First Byte – Waktu antara mengklik tautan dan bit pertama konten yang masuk.
- LCP : Cat Contentful Terbesar – Waktu ketika artikel yang diminta menjadi terlihat. Google merekomendasikan untuk menjaga nilai ini di bawah 2,5 detik.
- TTI : Time To Interactive – Waktu di mana halaman menjadi interaktif (pengguna dapat menggulir, mengklik, dll.).
- Ukuran bundel – Jumlah total byte yang diunduh dan kode yang dieksekusi sebelum halaman menjadi terlihat sepenuhnya dan interaktif.
Kami akan meninjau kembali metrik ini untuk lebih memahami bagaimana berbagai jalur rendering dapat memengaruhi masing-masing jalur tersebut.

Selanjutnya, mari kita pahami berbagai jalur render yang tersedia untuk pengembang React.
Jalan Render
Kita dapat merender aplikasi React di browser atau di server dan menghasilkan output yang bervariasi.
Dua fungsi berubah secara signifikan antara aplikasi yang dirender sisi klien dan sisi server, yaitu perutean dan pemisahan kode . Kami melihat lebih dekat di bawah ini.
Rendering Sisi Klien (CSR)
Render sisi klien adalah jalur render default untuk React SPA. Server akan menyajikan aplikasi shell yang tidak berisi konten apa pun. Setelah browser mengunduh, mem-parsing, dan mengeksekusi sumber JavaScript yang disertakan, konten HTML diisi atau dirender .
Fungsi perutean ditangani oleh aplikasi klien dengan mengelola riwayat browser. Ini berarti bahwa file HTML yang sama disajikan terlepas dari rute mana yang diminta, dan klien memperbarui status tampilannya setelah dirender.
Pemisahan kode relatif mudah. Anda dapat membagi kode Anda menggunakan impor dinamis atau React.lazy sehingga hanya dependensi yang diperlukan yang dimuat berdasarkan rute atau tindakan pengguna.
Jika halaman perlu mengambil data dari server untuk merender konten—misalnya, judul blog atau deskripsi produk—itu hanya dapat dilakukan jika komponen yang relevan dipasang dan dirender.
Pengguna kemungkinan besar akan melihat tanda atau indikator “Memuat data” saat situs web mengambil data tambahan.
Rendering Sisi Klien Dengan Data Bootstrapped (CSRB)
Pertimbangkan skenario yang sama seperti CSR tetapi alih-alih mengambil data setelah DOM dirender, katakanlah server mengirim data relevan yang di-bootstrap di dalam HTML yang disajikan.
Kami dapat menyertakan simpul yang terlihat seperti ini:
<script type="application/json"> {"title": "My blog title", "comments":["comment 1","comment 2"]} </script>Dan parsing ketika komponen dipasang:
var data = JSON.parse(document.getElementById('data').innerHTML);Kami baru saja menyelamatkan diri dari perjalanan pulang pergi ke server. Kita akan melihat pengorbanannya sebentar lagi.
Rendering Sisi Server ke Konten Statis (SSRS)
Bayangkan sebuah skenario di mana kita perlu membuat HTML dengan cepat.
Misalnya, jika kita membuat kalkulator online dan pengguna mengeluarkan kueri semacam /calculate/34+15 (mengabaikan pelolosan URL). Kita perlu memproses kueri, mengevaluasi hasilnya, dan merespons dengan HTML yang dihasilkan.
HTML kami yang dihasilkan cukup sederhana dalam struktur dan kami tidak perlu Bereaksi untuk mengelola dan memanipulasi DOM setelah HTML yang dihasilkan disajikan.
Jadi kami hanya menyajikan konten HTML dan CSS. Anda dapat menggunakan metode renderToStaticMarkup untuk mencapai ini.
Perutean akan sepenuhnya ditangani oleh server karena perlu menghitung ulang HTML untuk setiap hasil, meskipun caching CDN dapat digunakan untuk melayani respons lebih cepat. File CSS juga dapat di-cache oleh browser untuk pemuatan halaman berikutnya yang lebih cepat.
Rendering sisi server dengan Rehidrasi (SSRH)
Bayangkan skenario yang sama seperti yang dijelaskan di atas, tetapi kali ini kita membutuhkan aplikasi React yang berfungsi penuh pada klien.
Kami akan melakukan render pertama di server dan mengirim kembali konten HTML bersama dengan file JavaScript. React akan menghidrasi ulang markup yang diberikan server dan aplikasi akan berperilaku seperti aplikasi CSR mulai saat ini.
React menyediakan metode bawaan untuk melakukan tindakan ini.
Permintaan pertama ditangani oleh server dan render berikutnya ditangani oleh klien. Oleh karena itu, aplikasi semacam itu disebut aplikasi React universal (dirender di server dan klien). Kode untuk menangani perutean dapat dibagi (atau digandakan) pada klien dan server.
Pemisahan kode juga sedikit rumit karena ReactDOMServer tidak mendukung React. malas, jadi Anda mungkin harus menggunakan sesuatu seperti Komponen yang Dapat Dimuat.
Perlu juga dicatat bahwa ReactDOMServer hanya melakukan render yang dangkal. Dengan kata lain, meskipun metode render untuk komponen Anda akan dipanggil, metode siklus hidup seperti componentDidMount tidak akan dipanggil. Jadi, Anda perlu memfaktorkan ulang kode Anda untuk menyediakan data ke komponen Anda menggunakan metode alternatif.
Di sinilah kerangka kerja seperti NextJS muncul. Mereka menutupi kerumitan yang terkait dengan perutean dan pemecahan kode di SSRH dan memberikan pengalaman pengembang yang lebih lancar.
Pendekatan ini menghasilkan hasil yang beragam dalam hal kinerja halaman seperti yang akan kita lihat sebentar lagi.
Pra-rendering ke Konten Statis (PRS)
Bagaimana jika kami dapat merender halaman web sebelum pengguna memintanya? Ini dapat dilakukan pada waktu pembuatan atau secara dinamis ketika data berubah.
Kami kemudian dapat men-cache konten HTML yang dihasilkan pada CDN dan menyajikannya lebih cepat saat pengguna memintanya.
Ini disebut pra-rendering sebelum kami merender konten, permintaan pra-pengguna. Pendekatan ini dapat digunakan untuk blog dan aplikasi e-niaga karena kontennya biasanya tidak bergantung pada data yang diberikan oleh pengguna.
Pra-rendering dengan Rehidrasi (PRH)
Kita mungkin ingin HTML yang telah dirender sebelumnya menjadi aplikasi React yang berfungsi penuh saat klien merendernya.
Setelah permintaan pertama dilayani, aplikasi akan berperilaku seperti aplikasi React standar. Mode ini mirip dengan SSRH, yang dijelaskan di atas, dalam hal fungsi perutean dan pemecahan kode.
Matriks Kinerja
Saat yang ditunggu-tunggu akhirnya tiba. Saatnya untuk showdown. Mari kita lihat bagaimana masing-masing jalur rendering ini memengaruhi metrik kinerja web dan menentukan pemenangnya.
Dalam matriks ini, kami menetapkan skor untuk setiap jalur rendering berdasarkan seberapa baik kinerjanya dalam metrik kinerja.
Skor berkisar dari 1 hingga 5:
- 1 = Tidak Memuaskan
- 2 = Miskin
- 3 = Sedang
- 4 = Bagus
- 5 = Luar biasa
| TTFB Waktu untuk byte pertama | LCP Cat puas terbesar | TTI Saatnya untuk interaktif | Ukuran bundel | Total | |
|---|---|---|---|---|---|
| CSR | 5 HTML dapat di-cache pada CDN | 1 Beberapa perjalanan ke server untuk mengambil HTML dan data | 2 Pengambilan data + penundaan eksekusi JS | 2 Semua dependensi JS perlu dimuat sebelum render | 10 |
| CSRB | 4 HTML dapat di-cache karena tidak bergantung pada data permintaan | 3 Data dimuat dengan aplikasi | 3 JS harus diambil, diuraikan, dan dieksekusi sebelum interaktif | 2 Semua dependensi JS perlu dimuat sebelum render | 12 |
| SSRS | 3 HTML dihasilkan pada setiap permintaan dan tidak di-cache | 5 Tidak ada muatan JS atau operasi asinkron | 5 Halaman interaktif segera setelah cat pertama | 5 Hanya berisi konten statis penting | 18 |
| SSRH | 3 HTML dihasilkan pada setiap permintaan dan tidak di-cache | 4 Render pertama akan lebih cepat karena server merender pass pertama | 2 Lebih lambat karena JS perlu menghidrasi DOM setelah parse HTML + cat pertama | 1 Ketergantungan HTML + JS yang diberikan perlu diunduh | 10 |
| PRS | 5 HTML di-cache pada CDN | 5 Tidak ada muatan JS atau operasi asinkron | 5 Halaman interaktif segera setelah cat pertama | 5 Hanya berisi konten statis penting | 20 |
| PRH | 5 HTML di-cache pada CDN | 4 Render pertama akan lebih cepat karena server merender pass pertama | 2 Lebih lambat karena JS perlu menghidrasi DOM setelah parse HTML + cat pertama | 1 Ketergantungan HTML + JS yang diberikan perlu diunduh | 12 |
Takeaways Kunci
Pra-rendering ke konten statis (PRS) mengarah ke situs web berperforma tertinggi sementara rendering sisi server dengan hidrasi (SSRH) atau rendering sisi klien (CSR) dapat menyebabkan hasil yang kurang memuaskan.
Dimungkinkan juga untuk mengadopsi beberapa pendekatan untuk berbagai bagian situs web . Misalnya, metrik kinerja ini mungkin penting untuk laman web yang terbuka untuk umum sehingga dapat diindeks lebih efisien sementara metrik tersebut mungkin tidak terlalu penting setelah pengguna masuk dan melihat data akun pribadi.
Setiap jalur render mewakili pengorbanan di mana dan bagaimana Anda ingin memproses data Anda. Yang penting adalah tim teknik dapat dengan jelas melihat dan mendiskusikan pengorbanan ini dan memilih arsitektur yang memaksimalkan kebahagiaan penggunanya.
Bacaan dan Pertimbangan Lebih Lanjut
Sementara saya mencoba untuk menutupi teknik populer saat ini, ini bukan analisis yang lengkap. Saya sangat merekomendasikan membaca artikel ini di mana pengembang dari Google mendiskusikan teknik lanjutan lainnya seperti rendering server streaming, rendering trisomorphic, dan rendering dinamis (melayani respons yang berbeda untuk crawler dan pengguna).
Beberapa faktor lain yang perlu Anda pertimbangkan saat membangun situs web yang sarat konten mencakup kebutuhan akan sistem manajemen konten (CMS) yang baik untuk penulis Anda, dan kemampuan untuk dengan mudah menghasilkan/memodifikasi pratinjau media sosial dan mengoptimalkan gambar untuk berbagai ukuran layar.
