Dalam upaya bersama kita untuk mendorong web agar web melakukan lebih banyak hal, kita mengalami masalah umum: kinerja. Situs memiliki lebih banyak fitur daripada sebelumnya. Begitu banyak, bahwa banyak situs sekarang berusaha mencapai kinerja tingkat tinggi di berbagai kondisi jaringan dan perangkat.
Masalah kinerja sangat beragam. Yang paling ringan, masalahnya berupa pelambatan kecil yang agak mengganggu pengguna. Yang terburuk, masalahnya berupa situs yang benar-benar tidak bisa diakses, tidak ada respons sama sekali saat pengguna menginput sesuatu, atau keduanya.
Kinerja adalah tentang pengguna yang tetap aktif di situs tersebut
Kita ingin pengguna berinteraksi secara penuh makna dengan apa yang kita buat. Jika sebuah blog, kita berharap orang membaca postingannya. Jika sebuah toko online, kita berharap orang-orang membeli barang dagangan. Jika media sosial, kita ingin mereka saling berinteraksi.
Kinerja memainkan peran penting dalam keberhasilan perusahaan online. Berikut adalah beberapa studi kasus yang menunjukkan bagaimana situs berkinerja tinggi akan mampu mempertahankan interaksi penggunanya secara lebih baik daripada yang berkinerja rendah:
- Pinterest meningkatkan traffic mesin pencarian dan pendaftaran baru sebesar 15% saat mereka mengurangi waktu tunggu yang dirasakan sebesar 40%.
- COOK meningkatkan konversi sebesar 7%, menurunkan bounce rate sebesar 7%, dan meningkatkan halaman per sesi sebesar 10% ketika mereka mengurangi waktu muat halaman rata-rata sebesar 850 milidetik.
Berikut adalah beberapa studi kasus ketika kinerja rendah berdampak negatif terhadap sasaran bisnis:
- BBC mendapati bahwa mereka kehilangan tambahan 10% pengguna untuk setiap detik lebih lama pemuatan situs mereka.
- DoubleClick oleh Google mendapati 53% kunjungan melalui ponsel dibatalkan jika halaman memuat lebih dari 3 detik.
Dalam penelitian DoubleClick oleh Google yang dikutip di atas, ditemukan bahwa waktu muat situs dalam 5 detik memiliki sesi 70% lebih lama, 35% bounce rate lebih rendah, dan 25% iklan dilihat lebih tinggi daripada situs yang mengambil hampir empat kali lipat lebih lama dalam 19 detik. Untuk mendapatkan gambaran kasar bagaimana kinerja situs Anda jika dibandingkan dengan pesaing Anda, cobalah fitur Speed Scorecard.
Kinerja adalah tentang peningkatan konversi
Mempertahankan pengguna adalah sesuatu yang krusial untuk peningkatan konversi. Situs yang lambat memiliki dampak negatif terhadap pendapatan, begitu pula sebaliknya. Berikut beberapa contoh bagaimana kinerja telah memainkan peran dalam membuat bisnis lebih menguntungkan (atau kurang) menguntungkan:
- Untuk Mobify, setiap 100 milidetik peningkatan kecepatan pemuatan halaman beranda memberikan 1,11% peningkatan konversi berbasis sesi, menghasilkan peningkatan pendapatan tahunan rata-rata hampir $380.000. Selain itu, peningkatan 100 milidetik kecepatan pemuatan halaman proses memberikan 1,55% peningkatan dalam konversi berbasis sesi, yang pada gilirannya menghasilkan peningkatan pendapatan tahunan rata-rata hampir $530.000.
- DoubleClick menemukan bahwa penerbit konten yang situsnya dimuat dalam lima detik memperoleh hingga dua kali pendapatan iklan lebih banyak daripada situs yang dimuat dalam 19 detik.
- Saat AutoAnything menurunkan waktu muat halaman hingga separuh, mereka mendapatkan peningkatan 12-13% penjualan .
Jika Anda menjalankan bisnis di web, kinerja menjadi faktor yang sangat krusial. Situs bisa memberi Anda kinerja yang baik hanya jika pengalaman pengguna situs Anda cepat dan responsif terhadap input pengguna. Untuk melihat bagaimana potensi pengaruh kinerja terhadap pendapatan, cobalah fitur Impact Calculator.
Kinerja adalah tentang pengalaman pengguna
Saat membuka URL, Anda melakukannya dari sejumlah titik awal potensial. Bergantung pada sejumlah kondisi, seperti kualitas koneksi dan perangkat yang Anda gunakan, pengalaman Anda mungkin sangat berbeda dari pengguna lain.
Saat situs mulai memuat, ada periode waktu ketika pengguna menunggu konten ditampilkan. Hingga konten terbuka, tidak ada pengalaman pengguna untuk dibicarakan. Kurangnya pengalaman ini cepat berlalu pada koneksi cepat. Sementara pada koneksi yang lambat, pengguna harus menunggu. Pengguna mungkin mengalami lebih banyak masalah ketika resource halaman terbuka dengan sangat lambat.
Kinerja adalah aspek dasar dari pengguna yang baik. Ketika situs mengirimkan banyak kode, browser harus menggunakan banyak megabyte paket data pengguna untuk mendownload kode. Perangkat seluler memiliki daya CPU dan memori yang terbatas. Perangkat seluler sering kewalahan dengan apa yang kita anggap sedikit kode yang tidak dioptimalkan. Kinerja yang buruk ini menyebabkan tidak adanya respons. Setelah memahami apa yang kita ketahui tentang perilaku manusia, pengguna hanya akan menoleransi aplikasi berperforma rendah untuk waktu yang lama sebelum meninggalkannya. Jika Anda ingin tahu lebih banyak tentang cara mengukur kinerja situs dan menemukan peluang perbaikan, cobalah Fitur Cara Memikirkan Kecepatan.
Kinerja tentang orang
Situs dan aplikasi yang berkinerja buruk juga dapat memboroskan biaya nyata bagi orang-orang yang menggunakannya.
Seiring terus berkembangnya pengguna internet di seluruh dunia, perlu untuk diperhatikan bahwa sebagian besar pengguna ini mengakses melalui jaringan LTE, 4G, 3G, bahkan 2G. Seperti yang telah disoroti oleh Ben Schwarz dari Calibre dalam studinya tentang kinerja, biaya paket data prabayar mengalami penurunan, yang pada gilirannya akan membuat akses ke internet semakin terjangkau. Perangkat seluler dan akses internet bukan lagi barang mewah. Keduanya sudah menjadi alat umum yang diperlukan untuk bernavigasi dan berfungsi dalam dunia yang semakin terhubung.
Ukuran halaman total semakin meningkat, setidaknya sejak 2011, dan trennya terus berlanjut. Karena halaman secara umum mengirim lebih banyak data, pengguna harus lebih sering mengisi paket data mereka, yang membutuhkan biaya.
Selain menghemat uang pengguna Anda, pengalaman pengguna yang cepat dan ringan juga terbukti krusial bagi pengguna yang mengalami krisis. Fasilitas-fasilitas publik seperti rumah sakit, klinik, dan pusat krisis memiliki resource online yang memberikan pengguna informasi penting dan spesifik yang mereka butuhkan selama krisis. Walaupun desain sangat penting dalam menyajikan informasi penting secara efisien di saat-saat yang penuh tekanan, pentingnya menyampaikan informasi ini dengan cepat tidak dapat diabaikan. Ini adalah bagian dari tugas kita.
Ke mana berikutnya
Meskipun daftar di bawah ini mungkin tampak menakutkan, pahami bahwa Anda tidak perlu melakukan semua hal untuk meningkatkan kinerja situs Anda. Itu hanya titik awal, jadi jangan merasa terlalu terbebani! _Apa pun_yang dapat Anda lakukan untuk meningkatkan kinerja akan sangat membantu pengguna Anda.
Pikirkan resource yang Anda kirimkan
Metode yang efektif untuk membangun aplikasi berkinerja tinggi adalah mengaudit resource apa yang Anda kirim kepada pengguna. Meskipun panel Jaringan di Chrome DevTools melakukan pekerjaan yang luar biasa dalam meringkas semua resource yang digunakan pada halaman tertentu, dapat menjadi hal yang sulit untuk mengetahui di mana harus memulai jika Anda belum mempertimbangkan kinerja sampai sekarang. Berikut beberapa saran:
- Jika Anda menggunakan Bootstrap atau Fondasi untuk membangun UI, tanyakan pada diri sendiri apakah Anda membutuhkannya. Abstraksi semacam itu akan menambah banyak CSS yang harus diunduh oleh browser, mem-parse, dan menerapkannya ke halaman, semuanya sebelum CSS spesifik situs Anda masuk ke gambar. Flexbox dan Grid hebat dalam membuat layout sederhana maupun kompleks dengan kode yang relatif sedikit. Karena CSS adalah resource yang menghalangi render, maka overhead framework CSS bisa memperlambat rendering secara signifikan. Jika memungkinkan, Anda bisa mempercepat rendering dengan menghapus overhead yang tidak perlu.
- Library JavaScript itu nyaman, tetapi tidak selalu diperlukan. Kita ambil jQuery
misalnya: Pemilihan elemen telah sangat disederhanakan berkat penggunaan metode seperti
querySelectordanquerySelectorAll. Event binding mudah dilakukan denganaddEventListener.classList,setAttribute, dangetAttributemenawarkan cara mudah bekerja dengan kelas atau atribut elemen. Jika Anda harus menggunakan library, cari alternatif yang lebih efektif. Misalnya, Zepto adalah alternatif jQuery yang lebih kecil, sedangkan Preact adalah alternatif yang jauh lebih kecil untuk. - Tidak semua situs web memerlukan aplikasi halaman tunggal atau single page application (SPA), karena seringkali menggunakan JavaScript secara ekstensif. JavaScript adalah resource termahal yang kita sajikan pada byte web untuk byte, karena ia tidak hanya harus didownload, tetapi juga harus di-parse, dikompilasi, dan dieksekusi. Misalnya , situs berita dan blog dengan arsitektur front end yang dioptimalkan dapat berkinerja dengan sangat baik sebagai pengalaman multihalaman tradisional. Secara khusus caching HTTP dikonfigurasi dengan baik, dan opsional, jika service worker digunakan.
Pikirkan bagaimana Anda mengirimkan resource
Pengiriman yang efisien sangat vital untuk membangun pengguna yang cepat.
- Migrasikan ke HTTP/2. HTTP/2 memecahkan banyak masalah kinerja yang melekat di dalam HTTP/1.1, seperti batas permintaan serentak dan kurangnya kompresi header.
- Download resource lebih ceapt menggunakan petunjuk
resource.
rel=preloadadalah salah satu petunjuk resource yang memungkinkan pengambilan awal data resource penting sebelum browser akan menemukannya. Ini bisa memiliki dampak poisitif nyata terhadap rendering halaman dan menurunkan Waktu untuk Interaktif saat digunakan secara bijaksana.rel=preconnectadalah petunjuk resource lainnya yang bisa menutupi latensi pembukaan koneksi baru untuk sumber daya yang dihosting pada domain pihak ketiga. - Rata-rata situs-situs modern membawa banyak sekali JavaScript dan CSS. Sudah umum untuk menyatukan gaya dan skrip ke dalam paket besar pada lingkungan HTTP/1. Ini dilakukan karena banyak permintaan sangat mengganggu kinerja. Tidak masalah lagi sekarang ketika HTTP/2 berada di skenario, karena beberapa permintaan serentak lebih murah. Pertimbangkan menggunakan pemecahan kode di webpack untuk membatasi jumlah skrip yang didownload ke jumlah yang diperlukan oleh halaman atau tampilan saat ini saja. Pisahkan CSS Anda menjadi file-file templat atau file-file spesifik komponen yang lebih kecil, dan hanya sertakan resource yang dapat digunakan.
Pikirkan seberapa besar data yang Anda kirimkan
Berikut adalah beberapa saran untuk membatasi seberapa banyak data yang Anda kirimkan:
- Kurangi aset teks. Minifikasi adalah penghapusan spasi kosong, komentar, dan konten lain yang tidak diperlukan dalam resource berbasis teks. Minifikasi ini secara signifikan mengurangi jumlah data yang Anda kirimkan ke pengguna tanpa memengaruhi fungsionalitas. Gunakan uglification di JavaScript untuk mendapatkan lebih banyak penghematan melalui penyingkatan variabel dan nama metode. Karean SVG adalah format berbasis gambar, maka bisa dioptimalkan dengan SVGO.
- Konfigurasi server Anda untuk mengompresi resource. Kompresi bisa secara drastis menurunkan jumlah data yang Anda kirimkan kepada pengguna, khususnya aset teks. GZIP adalah opsi yang populer, tetapi kompresi Brotli bisa tetap digunakan. Namun demikian, harus dipahami bahwa kompresi bukanlah obat mujarab untuk segala masalah kinerja: Beberapa format file yang dikompresi secara implisit (mis., JPEG, PNG, GIF, WOFF, dan sebagainya) tidak merespons kompresi karena sudah dikompresi.
- Optimalkan gambar untuk memastikan situs Anda mengirimkan data gambar sesedikit mungkin. Karena gambar adalah bagian besar dari payload per halaman pada web, pengoptimalan gambar merepresentasikan peluang besar dan unik untuk meningkatkan kinerja.
- Jika ada waktu, pertimbangkan untuk menyajikan format gambar alternatif. WebP memiliki cukup dukungan browser yang luas, dan menggunakan lebih sedikit data daripada JPEG dan PNG namun tetap memiliki kualitas visual yang tinggi. JPEG XR adalah format alternatif lain yang didukung dalam IE dan Edge yang menawarkan penghematan serupa.
- Mengirimkan gambar
secara responsif.
Begitu beragamnya perangkat dan layar yang mereka gunakan
menghadirkan peluang yang luar biasa untuk meningkatkan kinerja dengan mengirim gambar yang paling cocok
untuk layar yang menampilkan gambar itu. Dalam kasus penggunaan paling sederhana, Anda bisa menambahkan Atribut
srcsetke elemen<img>untuk menentukan array gambar browser untuk Anda pilih. Pada sisi yang lebih rumit, Anda dapat menggunakan<picture>untuk membantu browser memilih format yang paling optimal (mis., WebP dengan JPEG atau PNG), atau menyajikan perlakuan gambar yang sama sekali berbeda untuk ukuran layar yang berbeda. - Gunakan video alih-alih GIF animasi. GIF animasi banyak digunakan. Video dengan kualitas yang serupa berukuran jauh lebih kecil, 80% atau lebih kecil. Jika situs Anda banyak menggunakan GIF animasi, ini mungkin menjadi hal yang paling berdampak yang bisa Anda lakukan untuk meningkatkan kinerja pemuatan.
- Petunjuk klien bisa
menyelaraskan pengiriman resource berdasarkan kondisi jaringan dan karakteristik
perangkat saat ini. Header
DPR,Width, danViewport-Widthbisa membantu Anda mengirimkan gambar terbaik untuk perangkat yang menggunakan kode sisi server dan mengirimkan lebih sedikit markup. HeaderSave-Databisa membantu Anda memberikan pengalaman aplikasi yang lebih ringan bagi para pengguna yang secara khusus meminta Anda melakukannya. NetworkInformationAPI menampilkan informasi tentang koneksi jaringan pengguna. Informasi ini bisa digunakan untuk mengubah pengalaman aplikasi bagi para pengguna di jaringan yang lebih lambat.
Untuk panduan yang lebih holistik tentang peningkatan kinerja, lihat artikel kami pada model kinerja RAIL, yang berfokus pada peningkatan waktu muat dan respons aplikasi. Panduan pola PRPL kami juga merupakan resource yang unggul untuk meningkatkan kinerja aplikasi halaman tunggal modern.
Jika Anda ingin untuk mempelajari lebih lanjut tentang kinerja dan cara membuat situs Anda lebih cepat, dalami dokumentasi kinerja kami untuk panduan tentang berbagai topik. Kami terus menambahkan panduan baru dan memperbarui yang sudah ada, jadi selalu lihat update terbaru dari kami!
Terima kasih untuk Addy Osmani, Jeff Posnick, Matt Gaunt, Philip Walton, Vinamrata Singal, Daniel An, dan Pete LePage untuk umpan balik luas dalam menyempurnakan dan meluncurkan resource ini!_