Dalam sebuah cerita baru-baru ini di Hacker News, dikatakan bahwa kecepatan halaman web tidak meningkat meskipun kecepatan Internet meningkat.
Dalam artikel saya, saya akan menjelaskan mengapa kesimpulan seperti itu tidak bisa diambil dari data awal.
Kami juga akan melihat perubahan yang terjadi pada perangkat dan web selama sepuluh tahun terakhir dan bagaimana pengukuran ini memengaruhi kecepatan web.
Menafsirkan Data Arsip HTTP
Grafik ini, dari sebuah artikel oleh Nielsen Norman Group, menjelaskan kepada kami bahwa peningkatan bandwidth seluler tidak menghasilkan waktu muat halaman yang lebih cepat.
Namun, kecepatan koneksi yang digunakan oleh Arsip HTTP tidak meningkat selama ini.
Sebaliknya, itu turun pada tahun 2013, beralih dari WiFi ke koneksi 3G yang diemulasi .
Sejak 2013, metrik onLoad telah meningkat sebesar 55%, dari 12,7 detik menjadi 19,7 detik. Jika Anda membeli ponsel pada tahun 2013 dan telah terhubung ke Internet melalui 3G sejak saat itu, web menjadi lebih lambat untuk Anda.
Sebelum saya berbicara tentang bagaimana perangkat dan web telah berubah selama sepuluh tahun terakhir, berikut adalah beberapa catatan tentang cara menafsirkan data ini.
Mengapa melihat onLoad?
Acara
loaddikirim oleh halaman ketika semua sumber daya halaman, seperti skrip dan gambar, telah diunduh.
Jika tajuk halaman dirender dengan cepat, tetapi halaman juga memuat 20 gambar lagi di bawah, metrik onLoad akan memberi tahu kami bahwa halaman tersebut lambat.
Halaman lain mungkin awalnya tidak merender sesuatu yang berguna, tetapi hanya mulai memuat sumber daya tambahan dan merender konten dengan kuat setelah peristiwa onLoad. Namun, halaman seperti itu akan muncul dengan cepat.
Oleh karena itu, onLoad sangat tidak cocok untuk mengukur apakah pengguna melihat halaman dengan cepat.
Mengapa repot-repot melihat metrik ini? Karena sudah lama digunakan dan HTTP Archive sudah melacaknya sejak 2010. Metrik yang lebih baru sepertiFirst Contentful Paint, atau Time to Interactive, hanya ditambahkan ke Arsip HTTP pada tahun 2017.
Haruskah kita mengharapkan peningkatan bandwidth untuk menghasilkan pemuatan halaman yang lebih cepat?
Meningkatkan bandwidth hanya akan mempercepat pemuatan halaman jika bandwidth menjadi hambatan di beberapa titik. Ini tidak akan membantu jika Anda menggunakan koneksi gigabit, dan waktu transmisi sinyal di kedua arah melalui jaringan sama dengan satu detik.
Namun, koneksi HTTP Archive 3G yang diemulasi pada 1,6 Mbps sangat lambat, jadi Anda harus mengharapkan peningkatan kecepatan yang signifikan saat Anda meningkatkan bandwidth. Rata-rata situs web mengunduh 1,7 MB data pada tahun 2020, yang berarti perlu setidaknya 9 detik untuk mengunduh dengan kecepatan koneksi Arsip HTTP.
Kehalusan lain dari Arsip HTTP
Dalam artikel ini, saya akan berbicara banyak tentang "situs web rata-rata". Perlu dicatat bahwa Arsip HTTP hanya mengumpulkan data di halaman master, bukan di halaman yang lebih dalam di hierarki situs. Selain itu, seiring waktu, korpus domain yang diuji telah berkembang.
Pengujian tidak selalu dilakukan pada perangkat yang sama. Awalnya iPhone 4 fisik digunakan, dan pengujian hari ini dilakukan pada perangkat Android yang diemulasi.
Dalam artikel ini, kita melihat nilai metrik median. Jika sebagian besar situs web cepat, tetapi satu dari lima situs web memperlambat telepon selama 20 detik, kami tidak akan dapat meningkatkan metrik ini.
Kecepatan di desktop
Dalam artikel ini, kita akan melihat kecepatan pada perangkat seluler AS. Namun, jika Anda melihat data desktop dari artikel aslinya, perlu diperhatikan bahwa pada tahun 2013 throughput pengujian meningkat dan latensi menurun.
Bagaimana jaringan dan perangkat seluler berubah selama sepuluh tahun terakhir?
Mari kita lihat empat faktor:
- bandwidth jaringan
- penundaan jaringan
- kecepatan prosesor
- kecepatan browser
Bandwidth seluler AS
Grafik ini menunjukkan rata-rata bandwidth jaringan seluler AS selama bertahun-tahun, berdasarkan berbagai sumber. Ini telah meningkat dari 1 Mbps menjadi sekitar 30 Mbps.
(Saya tidak mengumpulkan data ini dengan sangat hati-hati. Misalnya, saya tidak selalu mengetahui apakah tanggal pengumpulan data sama dengan tanggal dipublikasikan. Sumber saya dapat ditemukan di sini .)
Latensi di jaringan seluler AS
Data untuk parameter ini lebih sulit ditemukan, namun hasilnya menunjukkan bahwa latency menurun dari sekitar 200ms (2011) menjadi 50ms (2020).
Kecepatan prosesor seluler
Saya tidak dapat menemukan data tentang kecepatan seluler AS rata-rata. Namun, Alex Russell dan Surma menerbitkan peringkat jadwal GeekBench 4 bersama dengan rilis berbagai ponsel selama bertahun-tahun.
Bahkan telepon anggaran 4x lebih cepat, dan iPhone 20x lebih bertenaga.
Bagaimana browser berubah?
Selama sepuluh tahun terakhir, banyak pekerjaan telah dilakukan untuk meningkatkan browser. JavaScript telah menjadi bagian web yang jauh lebih penting, begitu banyak perbaikan terkonsentrasi di area ini.
Berdasarkan grafik dari blog V8 ini, konsumsi CPU per halaman telah dipotong empat kali.
Jaringan
Pekerjaan browser dengan jaringan juga meningkat. Misalnya, sejak diperkenalkannya HTTP / 2 pada tahun 2015, 64% permintaan diproses melalui HTTP / 2.
Bagaimana situs web berubah?
Mari kita lihat data dari Arsip HTTP untuk memahami bagaimana situs web telah berubah.
Bobot halaman
Dari 2013 hingga 2020, bobot halaman seluler meningkat 337%. Hal ini terutama disebabkan oleh peningkatan jumlah gambar dan kode JavaScript.
Volume sumber daya lain juga meningkat pesat - Saya menduga bahwa ini terutama video.
Grafik dimulai pada 2013 karena pada Oktober 2012 Arsip HTTP mengubah metodologi pengukuran. Sebelumnya, bobot halaman diremehkan karena pengujian berhenti setelah peristiwa pemuatan halaman dipicu, meskipun data lain dimuat setelahnya.
Waktu proses JavaScript
Jika, meskipun jaringan seluler mempercepat, halaman menjadi lebih lambat, JavaScript kemungkinan besar penyebabnya. Sayangnya, Arsip HTTP baru mulai mengumpulkan data ini pada akhir 2017, dan tampaknya stabil sejak saat itu.
Penurunan pada pertengahan 2018 kemungkinan besar disebabkan oleh perubahan korpus URL yang diuji.
Perhatikan bahwa durasi absolut pertunjukan (0,5 detik) lebih pendek daripada yang biasanya kita temukan di instrumen seperti Lighthouse. Alat semacam itu biasanya memperlambat eksekusi JavaScript untuk meniru perangkat seluler, tetapi dalam pengujian Arsip HTTP, sistem ini rusak . Oleh karena itu, meskipun angka ini mungkin realistis untuk ponsel kelas menengah, secara umum diyakini bahwa ponsel anggaran sekitar empat kali lebih lambat.
Menjawab pertanyaan jika web menjadi lebih lambat
Apakah web menjadi lebih lambat? Secara umum, ini tergantung pada perangkat Anda, koneksi jaringan, dan situs web yang paling sering dikunjungi.
Kami perlu mengukur data kecepatan dunia nyata untuk mendapatkan distribusi yang menunjukkan bagaimana persepsi web berubah dari waktu ke waktu oleh pengguna yang berbeda. Selain itu, pertanyaannya tetap, haruskah pengalaman seseorang yang membuka ribuan halaman sehari dihitung dengan cara yang sama seperti pengalaman seseorang yang hanya mengunjungi Facebook seminggu sekali?
Saya tidak memiliki data mendetail untuk setiap pengguna, tetapi kami dapat melihat masalah ini dari beberapa sudut pandang yang berbeda:
- Data pengguna nyata dari Chrome UX Report (CrUX)
- Pemodelan naif berdasarkan perubahan situs web dan perangkat
Saya juga mencoba mengunduh halaman versi lama dari archive.org dan mengujinya dengan Lighthouse, tetapi saya tidak bisa mendapatkan data yang berarti dalam jangka waktu yang wajar. Misalnya, terkadang gambar hilang dari arsip halaman.
Data dari Laporan Pengalaman Pengguna Chrome
Batasan besar data CrUX adalah data ini baru mulai dikumpulkan dari akhir 2017. Namun kami masih dapat menggunakannya untuk melihat apakah web menjadi lebih lambat selama dua setengah tahun terakhir.
Perhatikan bahwa tidak seperti Arsip HTTP, CrUX memeriksa seluruh domain, bukan hanya halaman utama.
Kami akan menganggap persentil ke-75 sebagai data, yang berarti untuk 75% pengguna, halaman dimuat dengan kecepatan ini atau lebih cepat.
(Saya mengambil rata-rata, bukan median, di beberapa situs web, yang tidak sepenuhnya benar.)
Waktu muat halaman di AS
Data CrUX untuk AS tidak menunjukkan penurunan kecepatan halaman.
Metrik onLoad menunjukkan sedikit peningkatan, kemungkinan karena peningkatan throughput. Atau mungkin lebih banyak tindakan sekarang terjadi setelah pemuatan halaman awal.
Metrik cat tampaknya cukup stabil. Largest Contentful Paint (Main Content Load Time) adalah metrik baru yang baru dikumpulkan sejak pertengahan 2019.
Seluruh dunia
Tren penurunan pada metrik onLoad di AS konsisten dengan data global. Namun, ada perbedaan yang signifikan dalam waktu muat halaman di berbagai negara, misalnya waktu onLoad India hampir dua kali lipat dari Korea Selatan.
Kita dapat menggunakan data CrUX untuk lebih memahami data Arsip HTTP. Pada Januari 2020, Arsip HTTP melaporkan waktu muat median (persentil ke-50) berdasarkan data sintetis selama 18,7 detik.
Sebaliknya, CrUX memperkirakan waktu muat hanya 5,8 detik, yang merupakan persentil ke-75.
(Perhatikan bahwa nilai global (Global) diambil hanya sebagai rata-rata dan tidak dihitung oleh populasi.)
Pemodelan waktu muat halaman
Kami dapat membuat model teoretis tentang bagaimana perubahan pada perangkat, jaringan, dan situs web memengaruhi kecepatan secara keseluruhan.
Modelnya tidak akan sempurna, tapi mudah-mudahan bisa memberi kita wawasan.
Waktu pengunduhan halaman teoretis
Bobot halaman meningkat dari waktu ke waktu, begitu pula bandwidth. Waktu round trip sinyal juga menurun.
Diperlukan 1,7 detik untuk mengunduh file seukuran situs web seluler median pada tahun 2013. Jika kecepatan koneksi kami tidak berubah sejak saat itu, maka hari ini akan membutuhkan 4,4 detik. Namun dengan kecepatan koneksi rata-rata saat ini, hanya membutuhkan waktu 0,9 detik.
Dalam praktiknya, situs web tidak akan terdiri dari satu permintaan, dan faktor lain, seperti kecepatan pemrosesan dan latensi server, akan memengaruhi kecepatan pemuatan halaman. Waktu onLoad menurut Arsip HTTP 2-3 kali lebih tinggi dari batas bawah ini.
Tetapi kami masih dapat menggunakan ini sebagai indikator bahwa latensi yang lebih rendah dan peningkatan bandwidth secara umum telah membantu situs web memuat lebih cepat.
(Saya mulai dari 2013, bukan 2011, karena metrik berat halaman Arsip HTTP baru mulai diukur secara konsisten sejak saat itu.)
CPU
Saya tidak begitu mengerti bagaimana mendekati parameter ini, tetapi saya akan membuat beberapa asumsi.
Seseorang yang menggunakan Galaxy S4 pada tahun 2013 dan sekarang menggunakan Galaxy S10 memiliki kekuatan pemrosesan lima kali lebih besar. Mari kita asumsikan bahwa browser menjadi empat kali lebih efisien sejak saat itu. Jika kita langsung mengalikan kedua angka ini, kita mendapatkan peningkatan 20 kali lipat.
Sejak 2013, bobot JavaScript pada sebuah halaman telah meningkat 3,7x, dari 107KB menjadi 392KB. Minifikasi dan kompresi mungkin telah meningkat sejak saat itu, jadi jumlah kode JavaScript yang sama sekarang cocok dengan byte yang lebih sedikit. Mari kita kumpulkan faktor ini menjadi enam. Bayangkan bobot JavaScript pada halaman sebanding dengan waktu eksekusi JavaScript.
Alhasil, kita masih akan mendapatkan peningkatan kecepatan 3,3x lipat.
Kesimpulan
Situs web menjalankan lebih banyak kode hari ini dan berkali-kali lebih besar daripada situs web sepuluh tahun yang lalu. Namun, saya tidak percaya bahwa web seluler secara keseluruhan menjadi lebih lambat bagi pengguna.
Pada saat yang sama, lebih banyak orang sekarang menggunakan web seluler . Ini menurunkan kecepatan web yang dirasakan secara keseluruhan.
Daya komputasi perangkat seluler mengejar ketertinggalan perangkat desktop, begitu pula bandwidth jaringan. Pada saat yang sama, perangkat baru tingkat anggaran yang lebih murah muncul.
Data ini dapat dilihat dari dua sudut. Di satu sisi, web secara bertahap semakin cepat. Di sisi lain, peningkatan jaringan dan perangkat mewakili peluang yang terlewatkan untuk peningkatan produktivitas yang lebih besar.
Periklanan
VDSina menawarkan server murah dengan pembayaran harian, setiap server terhubung ke saluran Internet 500 Megabit dan dilindungi dari serangan DDoS secara gratis!
