Berbicara Perihal Meningkatkan Secara Optimal Kecepatan Muat Halaman

Beberapa orang beropini bahwa kompresi JavaScript, CSS, gambar atau bahkan HTML sanggup mempercepat proses muat halaman sebuah situs. Tapi Saya tidak pernah baiklah dengan itu 100%. Ada begitu banyak hal yang harus menjadi pertimbangan lebih lanjut dibandingkan sekedar memfokuskan perhatian Anda terhadap perhitungan besar kecilnya ukuran file. Kebanyakan alat kompresi hanya akan memperkecil ukuran berkas tidak lebih dari 20%:

Beberapa orang beropini bahwa kompresi JavaScript Berbicara Tentang Optimasi Kecepatan Muat Halaman — Hasil Kompresi CSS – CSSDrive

Dan lagipula, kompresi yang dilakukan hanya berada pada seputar peringkasan variabel dan pembuangan abjad spasi yang tidak diperlukan. Itu sama sekali tidak mempercepat proses muat halaman sepenuhnya, itu hanya akan mempercepat proses pengunduhan file secara sepihak. Dalam hal ini yaitu CSS/JavaScript yang notabene hanyalah file berupa teks, sehingga mengunduh teks yang dikompresi dengan teks yang tidak dikompresi tidak akan menawarkan begitu banyak perbedaan. Kecepatan muat halaman situs tidak semata-mata dipengaruhi oleh faktor ukuran file, tapi juga oleh validasi, undangan HTTP dan juga ketepatan pendeklarasian arahan kiprah yang akan menawarkan timbal balik berupa akomodasi peramban dalam membaca dokumen Anda.

JavaScript Packer vs. Minifier

Mana yang lebih cepat dimuat, antara JavaScript yang dikompres dengan teknik Packer dan teknik Minifier? Seharusnya Packer lebih cepat alasannya yaitu mereka akan mengompres arahan jauh lebih banyak dibandingkan Minifier.

Mohon pertimbangkan sekali lagi. Packer memang akan memperkecil ukuran JavaScript jauh lebih banyak dibandingkan Minifier, tapi imbasnya yaitu peramban harus menawarkan waktu aksesori untuk menyusun kembali kode-kode yang sudah dipecah meskipun kenyataannya ukuran mereka sudah diperkecil. Packer (dan Obfuscator) akan menciptakan JavaScript lebih usang dimuat bukan alasannya yaitu ukuran file yang besar, namun alasannya yaitu menciptakan waktu membaca peramban menjadi lebih lama. Saat kita mengompres JavaScript dengan Packer atau Obfuscator, kita menyerupai sedang menawarkan teka-teki sandi perintah terlebih dahulu untuk dijawab oleh peramban sebelum pada alhasil mereka berhasil menjawabnya dan menjalankan tugasnya. Lebih baik gunakan Minifier dibandingkan Packer bila memang ingin mengurangi ukuran file JavaScript:

Menggunakan Base62 menambahkan langkah aksesori sebelum JavaScript sanggup dimanfaatkan oleh klien. Untuk jenis perpustakaan jQuery langkah ini sanggup mengambil ekstra waktu 100 - 500ms pada klien, tergantung pada banyak faktor. Sekarang kita sanggup membandingkan pengurangan "waktu untuk mengunduh script" dan "waktu aksesori yang dibutuhkan untuk mengeksekusi script". Ini (packer/teknik base62) sanggup mengurangi waktu pengunduhan sebanyak 50ms tetapi mengambil ekstra 100ms hanya untuk memprosesnya (menyusun kembali arahan yang sudah terpecah-pecah) - Sumber

Lalu bagaimana dengan alasan pinjaman kode? Bukankah Packer dan Obfuscator jauh lebih melindungi arahan dibandingkan Minifier? Ini semua yaitu pilihan. Pada dasarnya setiap teknik kompresi masih tetap sanggup menjaga semoga file sanggup dibaca oleh peramban. Ambil keputusan yang sekiranya mempunyai kerugian terkecil menurut tujuan.

Memperkecil Permintaan HTTP

Semakin banyak undangan HTTP (HTTP Requests) yang terjadi, maka akan semakin lambat halaman termuat. Permintaan HTTP intinya hanyalah perihal seberapa banyak peramban menghubungi server untuk memanggil data. Cara mengecek undangan yang terjadi sebetulnya sangat mudah. Perhatikan saja status kafe pada peramban Anda ketika halaman sedang dimuat:

Dari situ Anda sanggup melihat mana data yang cepat diakses dan mana yang lebih usang diakses menurut kecepatan perubahan status. Jika Anda sudah menemukan apa yang menciptakan situs Anda menjadi lambat, Anda sanggup segera mengambil keputusan terhadap file yang berafiliasi dengan itu. Apakah akan membuangnya atau mengubah pengurutan undangan yang lebih lambat menuju ke level yang lebih rendah (tidak dinomorsatukan). Misalnya, dengan cara meletakkan file yang lebih usang termuat di sebelah bawah.

Usahakan untuk mengurangi undangan HTTP dari situs pihak ke tiga sebanyak mungkin. Katakanlah kita mempunyai sebuah blog yang dilengkapi dengan widget Facebook Like, Twitter Feed, Chatbox dan Disqus dalam satu halaman yang sama. Ditambah lagi foto-foto artikel dan gambar latar belakang yang diunggah di Photobucket, arahan CSS yang disimpan di GitHub dan JavaScript yang disimpan di Google Code. Kita sanggup menyampaikan itu semua sebagai komponen undangan situs pihak ke tiga, alasannya yaitu kita telah menyisipkan aneka macam URL file yang disimpan di ruang penyimpanan lain ke dalam blog kita. Meskipun mereka semua hanya berupa file-file kecil yang umumnya berupa teks, namun ketika Anda membuka halaman blog dimana file-file yang disertakan di dalamnya masih merupakan milik situs lain, itu tetap saja akan mempunyai arti yang sama menyerupai halnya Anda sedang membuka semua situs tersebut secara bersamaan!

Menggabungkan Semua File Eksternal Sejenis

Menggabungkan semua file sejenis ke dalam sebuah file besar sanggup menjadi solusi termudah untuk mengurangi undangan HTTP. Artinya bahwa kita akan mengubah sesuatu yang tadinya menyerupai ini:

<link rel="stylesheet" href="style1.css"> <link rel="stylesheet" href="style2.css"> <link rel="stylesheet" href="style3.css"> <script src="script1.js"></script> <script src="script2.js"></script> <script src="script3.js"></script>

menjadi menyerupai ini:

<link rel="stylesheet" href="style-123.css"> <script src="script-123.js"></script>

Ini berlaku juga untuk JavaScript dan CSS internal. Meskipun mereka tidak mempunyai hubungan dengan undangan HTTP, namun mengurangi jumlah tag <style> dan <script> di dalam dokumen juga sanggup mempermudah peramban dalam membaca dokumen (memperpendak jarak baca dan mengurangi pengulangan baca file dengan tipe yang sama):

<script> function abc() {    document.write('abc'); } </script> <script> function def() {    alert('def'); } </script> <script> function ghi() {    var c = confirm('ghi?');    if(c) window.open('http://nama_blog.com'); } </script> <script> $(function() {     // DOM ready 1 ... }); $(function() {     // DOM ready 2 ... }); $(function() {     // DOM ready 3 ... }); </script> <script> abc(); def(); ghi(); </script> <style>#lorem {width:200px}</style> <style>#ipsum {color:red}</style> <style>#dolor {border:1px solid blue}</style>

Ubah semua susunan arahan di atas menjadi menyerupai ini:

<style> #lorem {width:200px} #ipsum {color:red} #dolor {border:1px solid blue} </style> <script> function abc() {    document.write('abc'); } function def() {    alert('def'); } function ghi() {    var c = confirm('ghi?');    if(c) window.open('http://nama_blog.com'); } $(function() {     // DOM ready 1 ...     // DOM ready 2 ...     // DOM ready 3 ... }); </script> <script> abc(); def(); ghi(); </script>

Meletakkan JavaScript di atas `</body>`

Ini mempunyai arti bahwa kita meletakkan JavaScript sejauh mungkin dari sebelah atas dokumen. Hal ini disarankan untuk mencegah keterlambatan pemuatan kerangka HTML di bawahnya alasannya yaitu lambatnya proses muat JavaScript di atasnya. Dengan meletakkan JavaScript di bawah, maka setidaknya kita telah mengizinkan peramban untuk merayapi kerangka halaman terlebih dahulu sebelum kemudian hingga pada masa untuk memuat dan membaca JavaScript. Posisikan juga CSS lebih awal dibandingkan JavaScript sehingga pembentukan badan halaman akan dihukum terlebih dahulu dibandingkan pengerjaan JavaScript.

Tapi tunggu dulu! Meletakkan JavaScript di bab bawah juga tidak sepenuhnya benar. Beberapa faktor sanggup menciptakan mereka tidak bekerja. Selengkapnya sanggup di baca di sini

Merasa Blog/Situs Anda Sudah Cukup Cepat?

Jangan bahagia dulu. Mungkin itu alasannya yaitu Anda telah mengunjungi situs web Anda berkali-kali, yang juga berarti bahwa cache dari situs Anda masih tersimpan di dalam komputer. Sekarang coba Anda hapus semua cache yang ada kemudian muat ulang halaman situs Anda kembali:

Saat cache sudah terhapus, maka Anda akan mencicipi kecepatan situs Anda yang sesungguhnya menyerupai halnya ketika pengunjung Anda membuka situs Anda.

Tentunya akan terasa sedikit lebih lambat. Itu juga merupakan kesimpulan sederhana mengenai pertanyaan udik perihal mengapa ketika kita pertama kali mengunjungi sebuah situs terasa begitu berat, namun ketika kita telah menjadi langganan mereka, semuanya berkembang menjadi lebih cepat.

Pembicaraan meningkatkan secara optimal ini tampaknya lebih banyak berputar di sekitar JavaScript dan CSS saja. Ya, alasannya yaitu Saya pikir pembicaraan selain itu masih sanggup dipahami menyerupai apa adanya. Saya hanya ingin menuliskan sesuatu yang seringkali menjadi sumber kesalahpahaman. Punya tambahan?

Sumber https://www.dte.web.id/