Mengoptimalkan Data Web Inti untuk pengambil keputusan bisnis

Pelajari cara pengambil keputusan bisnis dan non-developer dapat meningkatkan Data Web Inti.

Pengantar

Pengalaman pengguna situs telah terbukti memiliki dampak langsung terhadap hasil bisnis. Memberikan pengalaman yang lebih baik, saat situs dimuat dan merespons pengguna dengan lebih cepat, sering kali menghasilkan peningkatan interaksi dan konversi. Data Web Inti adalah inisiatif untuk mengukur pengalaman pengguna situs guna mengidentifikasi area yang perlu ditingkatkan.

Namun, banyak dokumentasi Data Web Inti ditujukan untuk developer web, dengan pemahaman teknis mendalam dan kontrol penuh atas kode mereka. Banyak situs yang dibuat oleh non-developer menggunakan platform "pembuat situs" seperti WordPress, Shopify, Wix, atau solusi serupa lainnya, biasanya tanpa tim pengembangan web.

Bahkan bila ada tim atau developer web khusus, mereka bukan satu-satunya yang bertanggung jawab atas performa web. Pengambil keputusan bisnis memiliki pengaruh besar terhadap performa situs, mulai dari menentukan konten dan desain, hingga mengembangkan strategi iklan dalam upaya untuk mendorong lebih banyak traffic ke situs mereka. Keputusan ini sering kali memiliki dampak yang signifikan terhadap performa situs.

Panduan ini bertujuan memberikan beberapa informasi yang relevan bagi pembuat dan pemilik situs untuk memahami—dan meningkatkan—pengalaman pengguna mereka sebanyak mungkin, tanpa memerlukan pengetahuan teknis yang mendalam tentang pengembangan web.

Pada saat yang sama, banyak masalah performa yang mengharuskan developer menerapkan perbaikan teknis, dan panduan yang berfokus pada developer dapat membantu upaya ini. Artikel ini tidak dimaksudkan sebagai panduan komprehensif, melainkan lebih merupakan pengantar inisiatif Data Web Inti untuk pengambil keputusan bisnis dengan beberapa penyebab umum non-pengembangan performa halaman yang buruk. Di luar ini, pengembang web mungkin perlu dilibatkan untuk membuat kemajuan lebih lanjut.

Apa yang dimaksud dengan Data Web Inti?

Data Web Inti adalah kumpulan tiga metrik yang dirancang untuk mengukur pengalaman pengguna di suatu halaman, dan khususnya seberapa cepat halaman tersebut terasa bagi pengguna. Masing-masing memiliki singkatan tiga huruf:

Setiap metrik mengukur aspek yang berbeda dari pengalaman pengguna. Google juga memberikan nilai minimum yang direkomendasikan untuk setiap metrik, di bawahnya pengalaman pengguna dianggap baik, dan di atasnya dianggap buruk. Di antara nilai minimum ini, halaman dianggap berada dalam rentang yang perlu ditingkatkan. Perhatikan bahwa dengan metrik ini, angka yang lebih rendah lebih baik.

Bagaimana cara Data Web Inti diukur?

Data Web Inti diukur oleh pengguna sebenarnya di situs Anda, dan pengguna yang berbeda akan memiliki hasil yang berbeda. Hal ini bukanlah "apa yang dipikirkan Google" atau "apa yang dipikirkan Googlebot", tetapi apa yang dialami oleh pengguna situs web yang sebenarnya.

Beberapa pengguna akan menggunakan perangkat yang lebih cepat dan jaringan yang lebih cepat. Beberapa akan menggunakan perangkat yang lebih lambat atau jaringan yang lebih lambat. Sebagian pengguna akan mengunjungi halaman yang lebih sederhana dan lebih cepat di situs Anda, sedangkan pengguna lainnya mengunjungi halaman yang lebih kompleks dan lambat. Hasil dari semua pengalaman pengguna ini kemudian digabungkan untuk memberikan ukuran keseluruhan situs Anda secara keseluruhan.

Google menyediakan data dari pengguna Chrome yang ikut serta dalam Laporan Pengalaman Pengguna Chrome (CrUX), yang dimasukkan ke banyak alat Google seperti PageSpeed Insights dan Google Search Console.

CrUX tersedia di jutaan situs web populer, tetapi tidak semua situs web ada di CrUX. Alat Real User Monitoring (RUM) lainnya juga dapat mengumpulkan metrik ini untuk situs Anda.

Bagaimana cara menemukan Data Web Inti situs saya?

Ada banyak alat yang menampilkan metrik Core Web Vitals yang disediakan oleh Google dan pihak ketiga. Postingan ini memperkenalkan dua alat yang memungkinkan Anda melihat Data Web Inti untuk situs Anda dengan cepat. Untuk memahami lebih lanjut alat Google lainnya—termasuk alur kerja untuk menggunakannya dalam menangani Data Web Inti—lihat postingan Alur kerja Data Web Inti dengan alat Google.

Jika platform Anda menyediakan solusi RUM terintegrasi, platform tersebut dapat menyediakan informasi yang lebih detail untuk halaman di situs Anda, atau memungkinkan Anda melihat perincian halaman tertentu atau segmen pengguna Anda untuk membantu memahami dan mengidentifikasi masalah.

PageSpeed Insights

Untuk tampilan cepat yang tidak memerlukan penyiapan, Anda dapat menggunakan PageSpeed Insights (PSI). Ketik URL dan klik Analisis. Jika situs Anda disertakan dalam CrUX, Anda akan segera melihat bagian "Temukan apa yang dialami pengguna Anda yang sebenarnya":

Screenshot cara PageSpeed Insights menggambarkan data CrUX untuk Data Web Inti URL. Setiap Data Web Inti ditampilkan secara terpisah, meskipun mengelompokkan setiap Core Web Vitals dalam nilai minimum 'Baik', 'Perlu Peningkatan', dan 'Buruk' selama 28 hari terakhir.
PageSpeed Insights menunjukkan Data Web Inti yang dialami pengguna nyata.

Laporan ini menunjukkan pengalaman pengguna Chrome yang sebenarnya terhadap situs Anda selama 28 hari terakhir. Anda akan melihat tiga Data Web Inti di bagian atas, bersama dengan metrik pendukung lainnya di bawah (termasuk metrik INP yang tertunda). Hanya Data Web Inti yang dihitung dalam penilaian Lulus/Gagal secara keseluruhan di bagian atas halaman, tetapi metrik lainnya dapat berguna dalam memecahkan masalah terkait Data Web Inti, seperti yang akan ditampilkan di bagian berikutnya.

Anda dapat beralih antara tampilan Seluler dan Desktop menggunakan tombol di atas bagian ini. Anda juga dapat beralih antara URL ini dan semua data untuk Asal tersebut menggunakan tombol di kanan atas, tempat data untuk keduanya berada.

Angka ini akan memberikan indikator luas tentang performa situs Anda dan metrik mana yang dapat ditingkatkan serta jenis perangkat yang digunakan.

Google Search Console

Google Search Console (GSC) hanya untuk pemilik situs, sehingga memerlukan pendaftaran dan verifikasi kepemilikan situs agar dapat digunakan. Halaman ini memberikan detail tentang cara Google Penelusuran melihat situs Anda.

Tidak seperti PageSpeed Insights, GSC mencantumkan semua halaman yang diketahui Google Penelusuran di situs Anda, dan memberikan detail Data Web Inti untuk semua halaman tersebut:

Screenshot laporan Data Web Inti di Search Console. Laporan ini dikelompokkan ke dalam kategori Desktop dan Seluler, dengan grafik garis yang memerinci distribusi halaman yang memiliki Data Web Inti dalam kategori 'Baik', 'Perlu Peningkatan', dan 'Buruk' dari waktu ke waktu.
Laporan Data Web Inti Google Search Console.

Halaman dikumpulkan ke Grup URL agar Anda dapat dengan mudah melihat apakah kategori halaman tertentu (misalnya, Halaman Detail Produk, halaman Blog, dan sebagainya) memiliki masalah Data Web Inti. Karena platform ini biasanya dibuat menggunakan teknologi atau template serupa, mungkin terdapat penyebab umum untuk masalah apa pun di halaman ini.

Masalah umum Data Web Inti untuk pembuat situs

Banyak masalah performa yang mengharuskan developer menerapkan perbaikan teknis dan panduan yang berfokus pada developer dapat membantu developer mengatasi masalah tersebut. Di bagian ini, kita akan membahas beberapa masalah umum non-developer yang dapat dibantu oleh pengambil keputusan bisnis untuk meningkatkan metrik ini.

Saat kami mengatakan "non-developer", kami mengacu pada mereka yang menggunakan platform pembuat situs yang memiliki kontrol terbatas atas cara situs sebenarnya dikodekan atau pengambil keputusan bisnis yang mungkin memutuskan desain situs, atau membantu memprioritaskan anggaran.

Masalah Largest Contentful Paint (LCP)

LCP bertujuan untuk mengukur kecepatan pemuatan halaman web dengan mengukur waktu mulai dari saat link diklik hingga konten terbesar (biasanya gambar banner atau judul) muncul di browser.

Screenshot halaman beranda situs ini dengan gambar LCP yang ditandai dengan warna hijau.
Elemen LCP adalah elemen terbesar saat halaman dimuat, dan ditandai dengan warna hijau dalam contoh ini.

Untuk pengalaman halaman yang baik, halaman web harus menampilkan konten ini dalam waktu 2,5 detik sejak link diklik. Jika memerlukan waktu lebih dari 4 detik, proses ini dianggap sebagai pengalaman yang buruk.

Beberapa masalah umum yang memengaruhi LCP yang dapat dipengaruhi oleh pengambil keputusan bisnis akan dijelaskan di bagian berikutnya.

Penundaan dalam mulai memuat halaman

Kami sering memikirkan cara meningkatkan waktu muat halaman itu sendiri, tetapi sering kali ada penundaan bahkan sebelum memulainya. Tidak mungkin memiliki LCP di bawah batas baik 2,5 detik jika situs bahkan tidak didownload selama beberapa detik.

Time to First Byte (TTFB) adalah waktu yang diperlukan untuk mendownload bagian pertama halaman web Anda. Jika PageSpeed Insights menampilkan metrik diagnostik TTFB yang besar dalam warna merah atau kuning, maka mengatasinya adalah hal yang penting dan akan memberikan dampak langsung pada LCP.

Pahami audiens Anda

Untuk masalah TTFB, penting untuk memahami audiens Anda. Jika situs Anda dihosting di satu negara, tetapi melayani audiens global, maka kedekatan geografis antara pengguna situs dan server web Anda menjadi faktor dalam TTFB halaman. Jaringan Penayangan Konten (CDN) memungkinkan salinan situs Anda disimpan dalam cache di seluruh dunia, sehingga lebih dekat dengan pengguna Anda. Banyak penyedia hosting menyertakan CDN sebagai bagian dari layanan mereka, dan akan menangani hal ini secara otomatis. Periksa apakah hal ini berlaku untuk tempat situs Anda dihosting. Beberapa platform menawarkan tingkat layanan yang berbeda dengan lebih banyak lokasi CDN untuk tingkat berbayar yang lebih tinggi. Dalam kasus ini, bisnis global harus mempertimbangkan tingkatan yang lebih tinggi.

Minimalkan pengalihan

Pengalihan adalah penyebab umum lain untuk TTFB yang lambat. Saat menjalankan kampanye iklan atau mengirim komunikasi email, coba minimalkan jumlah pengalihan dengan menghindari penggunaan beberapa penyingkat link, atau menyertakan URL yang harus dialihkan. Misalnya, penggunaan example.com/blog di kampanye yang harus mengalihkan ke www.example.com/blog, yang kemudian mengalihkan ke https://www.example.com/blog akan menambahkan waktu ke TTFB halaman. Pastikan kampanye pemasaran Anda menggunakan pengalihan seminimal mungkin.

Memastikan kampanye iklan ditujukan untuk audiens yang tepat

Pastikan juga kampanye iklan Anda menargetkan audiens secara efektif. Mendapatkan banyak traffic baru dari pengguna yang berada di belahan dunia lain—tetapi tidak dapat Anda kirimi produk—adalah pemborosan iklan dan berdampak negatif pada performa situs Anda.

Parameter URL dapat memengaruhi performa web

Parameter URL seperti parameter UTM sering digunakan untuk kampanye pemasaran. Hal ini dapat mengurangi efektivitas penyimpanan dalam cache pada infrastruktur Anda, karena setiap URL dapat terlihat seperti halaman unik—meskipun halaman yang sama ditayangkan setiap waktu. Jika Anda menggunakan parameter UTM, hubungi tim infrastruktur atau penyedia CDN untuk memastikan parameter URL ini diabaikan oleh infrastruktur dalam cache mereka agar kampanye dapat memperoleh manfaat dari halaman yang telah di-cache.

Performa media bisa sangat mahal

Pertimbangkan dampak media pada halaman Anda. Media seperti gambar dan video biasanya jauh lebih besar, sehingga membutuhkan waktu download yang lebih lama daripada teks. Tindakan ini juga dapat memperlambat pemuatan halaman lainnya. Hal ini sangat penting jika elemen LCP adalah media, bukan teks. Elemen LCP adalah gambar yang ada di sekitar 80% halaman web, jadi Anda harus mempertimbangkan dampak media di situs Anda.

Pada saat yang sama, aset media dapat memberikan pengalaman visual yang kaya bagi pengguna yang lebih menarik daripada situs dengan banyak teks. Oleh karena itu, menghapus media jarang menjadi pilihan, tetapi waspada terhadap biaya media dan cara menguranginya dapat meminimalkan masalah performa.

Menghindari carousel

Carousel yang terbuat dari beberapa gambar dapat memengaruhi waktu pemuatan halaman secara keseluruhan karena carousel dapat mengharuskan beberapa gambar untuk didownload secara bersamaan jika tidak diterapkan secara optimal. Selain itu, meskipun ada di mana-mana, carousel sering kali tidak memberikan pengalaman pengguna yang baik, jadi pikirkan baik-baik sebelum menggunakannya di situs Anda.

Gunakan gambar yang dioptimalkan untuk web

Lalu ada ukuran aset media. Banyak gambar di web yang ditayangkan dengan resolusi yang terlalu tinggi. Pastikan setiap partner media atau agensi desain menyediakan gambar yang dioptimalkan untuk web, dan bukan gambar berkualitas cetak berukuran penuh yang sering mereka sediakan. Anda dapat menggunakan layanan seperti TinyJPG untuk menghapus data yang tidak diperlukan dari gambar dengan cepat sebelum menguploadnya. Banyak platform web akan mencoba mengoptimalkan gambar saat diupload secara otomatis, tetapi karena mereka tidak mengetahui dimensi gambar yang akan ditampilkan di perangkat pengguna, menyediakan gambar yang lebih kecil sebagai tahap awal dapat memberikan keuntungan yang signifikan.

Hati-hati dengan video

Berikan pertimbangan ekstra saat menggunakan video. Video adalah salah satu konten terbesar—dan karenanya paling lambat—untuk didownload dan ditampilkan di situs web, jadi cobalah untuk tidak menggunakannya secara berlebihan. Hindari menggunakannya di bagian atas halaman web, dan simpan di bagian bawah halaman. Hal ini kemudian dapat memungkinkan konten yang lebih murah dimuat lebih cepat untuk memberikan pengalaman pemuatan yang lebih baik kepada pengguna dan memastikan LCP Anda tidak terpengaruh.

Pengujian A/B

Banyak bisnis melakukan pengujian A/B untuk bereksperimen dengan perubahan pada situs mereka. Cara penerapannya dapat berdampak besar pada LCP.

Banyak solusi pengujian A/B menunda saat situs pertama kali ditampilkan kepada pengguna hingga perubahan dalam pengujian diterapkan. Hal ini membuat versi asli situs tidak ditampilkan, tetapi dapat menyebabkan penundaan visibilitas situs kepada pengguna. Solusi lain diterapkan di sisi server untuk menghindari penundaan ini. Luangkan waktu untuk memahami cara melakukan pengujian A/B, dan apakah pengujian dapat mengalami penundaan ini. Selain itu, jika memungkinkan, pertimbangkan solusi pengujian A/B sisi server.

Pengujian A/B dapat memberikan masukan yang sangat berharga sebelum meluncurkan perubahan baru, tetapi biaya untuk performa halaman harus dipertimbangkan berdasarkan potensi manfaat yang diberikan.

Apa pun infrastruktur Anda, siapa pun yang menjalankan pengujian A/B harus selalu memperhatikan praktik terbaik berikut:

  • Batasi alat pengujian A/B hanya untuk halaman yang merupakan bagian dari pengujian, bukan menunda semua halaman, saat sebagian besar halaman mungkin tidak menjalankan pengujian A/B pada waktu tertentu.
  • Batasi pengujian A/B ke sebagian pengguna agar tidak berdampak pada sebagian besar pengguna.
  • Batasi pengujian A/B ke jumlah waktu minimum yang diperlukan untuk memberikan hasil yang konklusif. Semakin lama pengujian A/B berjalan, semakin lama pengguna mungkin mengalami kinerja halaman yang buruk.
  • Yang terpenting, jangan lupa untuk menghapus eksperimen pengujian A/B jika tidak diperlukan lagi.

Masalah Pergeseran Tata Letak Kumulatif (CLS)

CLS mengukur stabilitas visual halaman—seberapa banyak konten halaman bergeser saat konten dimuat. Hal ini dapat mengganggu jika pengguna sudah mulai membaca halaman web, tetapi kemudian kehilangan tempatnya karena adanya lebih banyak konten atau slot iklan pada tempatnya. Hal ini juga dapat menyebabkan pengguna secara tidak sengaja mengklik konten yang salah jika tata letak halaman bergeser secara berlebihan. Berhati-hatilah dengan konten dinamis yang dimuat nanti, dan dapat memindahkan beberapa konten halaman awal.

Screencast yang menggambarkan dampak negatif ketidakstabilan tata letak terhadap pengguna.

Nilai ini diukur dengan formula matematika yang menghitung seberapa banyak konten yang digeser, dan seberapa banyak konten tersebut digeser. Ini dinyatakan sebagai pecahan tanpa unit dengan nilai 0,1 atau kurang dianggap sebagai baik dan nilai di atas 0,25 sebagai buruk.

Beberapa masalah umum yang memengaruhi CLS yang dapat dipengaruhi oleh pengambil keputusan bisnis akan diberikan di bagian berikutnya.

Memeriksa pemuatan gambar saat Anda men-scroll halaman ke bawah

Banyak template menghindari pemuatan gambar di bagian bawah halaman untuk memberikan lebih banyak resource ke gambar yang muncul di layar selama pemuatan halaman awal. Gambar kemudian dimuat saat pengguna men-scroll ke bawah. Teknik pemuatan gambar ini dikenal sebagai pemuatan lambat.

Template halaman harus menyediakan ruang untuk gambar yang lambat dimuat sehingga, jika pengguna men-scroll sangat cepat sebelum gambar sempat dimuat, konten di sekitarnya tidak akan bergeser. Jika template atau platform Anda tidak mendukung hal ini, pertimbangkan untuk beralih ke template atau platform yang mendukungnya.

Hati-hati dengan iklan yang ditempatkan di tengah konten

Iklan yang disisipkan di tengah konten berisiko mendorong konten Anda ke bawah, karena iklan sering kali membutuhkan waktu sedikit lebih lama untuk dimuat—sering kali lebih panjang daripada gambar yang dijelaskan di bagian sebelumnya. Menempatkan atribut tersebut di sisi konten halaman utama adalah pola umum yang mengurangi risiko ini. Cara mencapai hal ini dalam praktiknya bergantung pada platform tertentu Anda, dan template apa yang Anda gunakan untuk membuat situs Anda.

Menghindari penambahan konten dinamis ke bagian atas halaman

Hindari menambahkan notifikasi dan banner ke bagian atas halaman setelah pemuatan halaman—misalnya, banner cookie atau penawaran spesial. Memilih untuk menempatkan pemberitahuan dan banner di atas konten utama akan mencegah pergeseran konten halaman. Serupa dengan bagian sebelumnya, opsi Anda di sini akan bergantung pada platform dan template yang digunakan untuk halaman Anda.

Masalah Interaction to Next Paint (INP)

INP mengukur responsivitas halaman, yang menilai apakah halaman merespons interaksi seperti klik, ketukan, dan input keyboard dengan cepat. Halaman yang tidak merespons input pengguna dengan cepat sering kali terasa lambat dan dapat membuat pengguna frustrasi.

Contoh responsivitas buruk versus baik. Di sebelah kiri, tugas yang panjang akan memblokir akordeon agar tidak dapat dibuka. Hal ini menyebabkan pengguna mengklik beberapa kali, dan mengira bahwa pengalamannya akan buruk. Saat thread utama berhasil mengejar, thread utama akan memproses input yang tertunda, sehingga akordeon terbuka dan tertutup secara tidak terduga.

INP mengukur keseluruhan setiap interaksi yang memenuhi syarat selama masa aktif halaman, dan melaporkan interaksi terburuk. INP memiliki batas yang baik yaitu 200 milidetik, dan batas yang buruk yaitu 500 milidetik. INP adalah peningkatan pada FID, dan mengukur responsivitas dengan lebih baik, oleh karena itu mengapa INP menggantikan FID sebagai Core Web Vital untuk mengukur responsivitas.

Metrik responsivitas—dan khususnya INP—adalah metrik yang sulit dioptimalkan. Ketika metrik ini berada pada ambang batas buruk, biasanya karena interaksi tertunda oleh halaman web yang mencoba melakukan terlalu banyak hal, sehingga solusi utamanya di sini melibatkan penghapusan kode yang tidak perlu untuk membuat halaman yang lebih ringan.

Beberapa masalah umum yang memengaruhi INP yang dapat dipengaruhi oleh pengambil keputusan bisnis akan dijelaskan di bagian selanjutnya.

Bersih-bersih di musim semi!

Tinjau plugin dan widget yang ditambahkan ke situs Anda, dan hapus jika tidak digunakan lagi. Menambahkan plugin untuk mencoba sesuatu sering kali mudah dilakukan, tetapi bisa juga dengan mudah Anda lupa menghapusnya nanti jika menurut Anda tidak berguna. Ini adalah salah satu penyebab di balik interaksi yang lambat, tetapi pengoptimalan ini relatif lebih sederhana daripada yang lain.

Demikian pula, jika Anda menggunakan tag manager untuk kampanye pemasaran, pastikan kampanye lama dihapus. Meskipun jika ekstensi tersebut tidak diaktifkan lagi, kode dari kampanye pemasaran yang telah berakhir masa berlakunya masih harus didownload dan dikompilasi di setiap halaman, yang dapat memperlambat interaksi pengguna selama pemuatan halaman awal.

Menghindari widget dan plugin yang mahal

Widget dan plugin yang mahal secara komputasi mungkin terlihat bagus, tetapi apakah mereka meningkatkan pengalaman pengguna, atau benar-benar membuatnya lebih buruk? Laporan Diagnosis Masalah Performa/Lighthouse di PageSpeed Insights dapat membantu mengidentifikasi JavaScript yang memiliki dampak nyata pada performa situs Anda.

Idealnya, batasi widget hanya ke halaman yang diperlukan—jika Anda hanya menggunakan sematan Google Maps di halaman hubungi kami, maka Anda tidak perlu memuatnya di setiap halaman yang dapat menyebabkan masalah respons.

Mempertimbangkan jumlah iklan—terutama di perangkat seluler

Iklan adalah strategi monetisasi yang baik untuk banyak bisnis, tetapi sering kali rumit dan membutuhkan banyak sumber daya. Semakin banyak iklan yang Anda miliki, semakin intensif resource yang dapat mengganggu kecepatan halaman. Hal ini terutama berlaku di perangkat seluler, di mana memori daya pemrosesan sering kali tidak sebesar seperti di perangkat desktop atau laptop.

Keseimbangan antara monetisasi dan performa.

Pertimbangkan keseimbangan antara monetisasi dan performa. Jika pengguna berhenti lebih awal karena pengalaman buruk, iklan tambahan tersebut mungkin membuat Anda kehilangan pendapatan yang lebih besar daripada yang mereka tambahkan.

Menghindari ukuran halaman yang berlebihan

Halaman yang besar dan kompleks memerlukan waktu pemrosesan yang lebih lama untuk ditampilkan. Misalnya, jika Anda memiliki galeri produk dengan 1.000 produk yang berbeda, maka perlu waktu beberapa saat untuk ditampilkan di jendela browser pengguna. Pertimbangkan kapan harus memberi nomor halaman untuk mengurangi waktu ini.

Bagaimana cara mendapatkan bantuan lebih lanjut?

Postingan ini mencantumkan beberapa pertimbangan umum yang dapat diambil oleh pemilik bisnis yang dapat memengaruhi performa. Selain itu, Anda mungkin perlu berkonsultasi dengan developer web guna mendapatkan lebih banyak analisis tentang apa yang dapat dilakukan untuk meningkatkan performa situs Anda.

Informasi khusus platform

Sebagian besar platform sangat peduli dengan performa webnya, dan mungkin memiliki saran khusus untuk platform terkait cara meningkatkan performa webnya. Anda mungkin juga memiliki akses ke tim performa web khusus sebagai bagian dari penggunaan platform tersebut yang dapat memberikan saran lebih lanjut tentang cara meningkatkan situs Anda.

Lighthouse juga menampilkan informasi khusus platform menggunakan fungsi Stack Pack, yang dapat memandu pengguna platform yang didukung untuk mendapatkan saran yang sesuai.

Platform terus berkembang dari waktu ke waktu dan banyak di antaranya yang saat ini berkonsentrasi pada performa serta Data Web Inti. Pastikan platform Anda terus diupdate untuk mendapatkan manfaat dari peningkatan terbaru yang telah dibuat developer platform.

Cara ini paling mudah saat Anda berada di platform yang dihosting, tempat penyedia platform otomatis mengelola platform, termasuk update platform. Jika Anda menghosting platform sendiri—misalnya, WordPress lokal yang diinstal di server Anda sendiri—maka memastikan platform tersebut diupdate secara rutin akan memungkinkan situs Anda mendapatkan manfaat dari peningkatan apa pun yang telah diterapkan developer platform. Bisnis harus memprioritaskan pemeliharaan ini, atau memilih layanan yang mengelola hal ini untuk mereka.

Berinteraksi dengan developer web

Developer web yang memiliki keahlian dalam performa web kemungkinan akan dapat mengatasi lebih banyak masalah dibandingkan pemilik bisnis. Anda mungkin sudah berinteraksi dengan developer web untuk mulai membuat situs pada awalnya, atau melakukan perubahan berkala, atau Anda mungkin memiliki tim pengembangan khusus, atau Anda mungkin harus menemukan developer untuk diajak berinteraksi (idealnya tim yang memiliki keahlian performa web).

Hubungi developer jika saran di atas tidak memberikan solusi yang memadai untuk mengatasi masalah performa pada situs Anda. Namun, semoga contoh sebelumnya juga menunjukkan bahwa Anda perlu bekerja sama dengan developer untuk menyeimbangkan prioritas bisnis dengan keputusan pengembangan guna mencapai solusi yang tepat bagi situs Anda.

Perlu diketahui bahwa performa web jarang merupakan pekerjaan satu kali. Mempertahankan performa situs yang baik sering kali memerlukan pemantauan dan pemeliharaan rutin untuk memastikan situs Anda tidak regresi setelah perbaikan dilakukan.

Kesimpulan

Situs web sering kali menjadi titik masuk pertama bagi sebuah bisnis dengan pelanggannya, dan Anda ingin hal itu menjadi pengalaman yang luar biasa bagi mereka. Hal ini berlaku baik untuk pengunjung kali pertama yang mendapatkan kesan pertama mereka tentang bisnis Anda, dan juga pengunjung berulang dan pelanggan setia, yang harus diberikan pengalaman semulus mungkin, idealnya bebas dari rasa frustrasi yang dapat meninggalkan kesan negatif. Data Web Inti adalah salah satu ukuran pengalaman pengguna yang direkomendasikan Google agar dipertimbangkan oleh situs. Dengan semua yang ditawarkan web, sangat mudah bagi pengguna untuk mencoba situs web lain jika mereka merasa frustrasi dengan situs web Anda.

Pada saat yang sama, Data Web Inti hanyalah salah satu ukuran situs Anda. Bisnis perlu memutuskan sendiri jumlah yang akan diinvestasikan di situs mereka, dan laba yang akan direalisasikan untuk investasi tersebut.

Ucapan terima kasih

Gambar thumbnail oleh Carlos Muza di Unsplash