Tidak ada keraguan bahwa halaman web saat ini penuh dengan konten yang kaya dan menggunakan lebih banyak bandwidth untuk memuat sepenuhnya, tetapi apakah menggunakan browser berbasis teks daripada yang berbasis GUI membuat perbedaan yang signifikan dalam mengurangi lalu lintas jaringan? Postingan Tanya Jawab SuperUser hari ini memiliki jawaban untuk pertanyaan pembaca yang penasaran.
Sesi Tanya & Jawab hari ini hadir atas kebaikan SuperUser — subdivisi Stack Exchange, pengelompokan situs web Tanya Jawab berbasis komunitas.
Tangkapan layar Lynx Browser milik Wikipedia .
Pertanyaan
Pembaca SuperUser Paulb ingin tahu apakah browser berbasis teks benar-benar dapat mengurangi lalu lintas jaringan:
Lakukan browser berbasis teks seperti Lynx , Tautan , dan ELinks mengkonsumsi lebih sedikit bandwidth daripada browser berbasis GUI seperti Firefox, Chrome, dan Internet Explorer?
Saya menduga tidak ada pengurangan lalu lintas. Alasan saya untuk ini adalah bahwa menurut saya browser berbasis teks mengunduh seluruh halaman seperti yang ditawarkan oleh server. Setiap pelurusan atau pengurangan widgetry halaman dilakukan secara lokal.
Mungkin ada sedikit penurunan lalu lintas karena sebagian besar browser berbasis teks tidak akan menjalankan skrip halaman atau file flash, yang dapat menyebabkan lebih banyak lalu lintas.
Dapatkah browser berbasis teks membuat perbedaan nyata dalam mengurangi lalu lintas jaringan?
Jawabannya
Kontributor SuperUser gronostaj memiliki jawabannya untuk kami:
Server web tidak mengirim seluruh situs web, tetapi dokumen yang diminta browser. Misalnya, saat Anda mengakses google.com, browser menanyakan server web untuk dokumen google.com. Server web memproses permintaan dan mengirimkan kembali beberapa kode HTML.
Kemudian browser memeriksa apa yang telah dikirim server web. Dalam hal ini, ini adalah halaman web HTML, jadi ia mengurai dokumen dan mencari skrip yang direferensikan, style sheet, gambar, font, dll.
Pada tahap ini, browser telah selesai mengunduh dokumen asli, tetapi masih belum mengunduh dokumen referensi. Itu dapat memilih untuk melakukannya atau melewati mengunduhnya. Browser biasa akan mencoba mengunduh semua dokumen referensi untuk pengalaman menonton terbaik. Jika Anda memiliki pemblokir iklan ( seperti Adblock Plus ) atau plugin privasi ( seperti Ghostery atau NoScript ), maka itu mungkin memblokir beberapa sumber daya juga.
Kemudian browser mengunduh dokumen yang direferensikan satu per satu, setiap kali meminta server web secara eksplisit untuk satu sumber daya. Dalam contoh Google kami, browser akan menemukan referensi berikut ( hanya untuk menyebutkan beberapa di antaranya ):
- https://www.google.com/images/srpr/logo11w.png (Logo Google)
- https://www.google.com/textinputassistant/tia.png (Ikon Keyboard)
- https://ssl.gstatic.com/gb/images/i1_3d265689.png (Beberapa gambar gabungan, trik yang digunakan untuk mengurangi jumlah permintaan browser.)
File sebenarnya mungkin berbeda untuk pengguna yang berbeda karena browser dan sesi dapat berubah seiring waktu. Browser berbasis teks tidak mengunduh gambar, file Flash, video HTML5, dll., Sehingga mereka mengunduh lebih sedikit data.
@NathanOsman membuat poin bagus di komentar . Terkadang gambar kecil disematkan langsung dalam dokumen HTML dan dalam kasus tersebut, mendownloadnya tidak dapat dihindari. Ini adalah trik lain yang digunakan untuk mengurangi jumlah permintaan. Mereka sangat kecil, jika tidak overhead pengkodean file biner di base64 terlalu besar. Ada beberapa gambar seperti itu di google.com ( ukuran yang dikodekan base64 / ukuran yang didekodekan ):
- Ikon Keyboard 19 × 11 piksel (106 Bytes / 76 Bytes)
- Ikon Mikrofon 28 × 38 piksel (334 Bytes / 248 Bytes)
- GIF Transparan 1 × 1 piksel (62 Bytes / 43 Bytes) Ini muncul di tab Sumber Daya Alat Pengembang Google Chrome, tetapi saya tidak dapat menemukannya di kode sumber (mungkin ditambahkan nanti dengan JavaScript).
- 1 × 1 piksel File GIF rusak yang muncul dua kali. (34 Bytes / 23 Bytes) Tujuannya adalah misteri bagi saya.
Punya sesuatu untuk ditambahkan ke penjelasannya? Suarakan di komentar. Ingin membaca lebih banyak jawaban dari pengguna Stack Exchange yang paham teknologi? Lihat utas diskusi lengkap di sini .
