Dan lagipula, kompresi yang dilakukan hanya berada pada seputar peringkasan variabel dan pembuangan karakter 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 adalah CSS/JavaScript yang notabene hanyalah file berupa teks, sehingga mengunduh teks yang dikompresi dengan teks yang tidak dikompresi tidak akan memberikan begitu banyak perbedaan. Kecepatan muat halaman situs tidak semata-mata dipengaruhi oleh faktor ukuran file, tapi juga oleh validasi, permintaan HTTP dan juga ketepatan pendeklarasian kode tugas yang akan memberikan timbal balik berupa kemudahan 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 karena mereka akan mengompres kode jauh lebih banyak dibandingkan Minifier.Mohon pertimbangkan sekali lagi. Packer memang akan memperkecil ukuran JavaScript jauh lebih banyak dibandingkan Minifier, tapi imbasnya adalah peramban harus memberikan waktu tambahan untuk menyusun kembali kode-kode yang sudah dipecah meskipun kenyataannya ukuran mereka sudah diperkecil. Packer (dan Obfuscator) akan membuat JavaScript lebih lama dimuat bukan karena ukuran file yang besar, namun karena membuat waktu membaca peramban menjadi lebih lama. Saat kita mengompres JavaScript dengan Packer atau Obfuscator, kita seperti sedang memberikan teka-teki sandi perintah terlebih dahulu untuk dijawab oleh peramban sebelum pada akhirnya mereka berhasil menjawabnya dan menjalankan tugasnya. Lebih baik gunakan Minifier dibandingkan Packer jika memang ingin mengurangi ukuran file JavaScript:
Menggunakan Base62 menambahkan langkah tambahan sebelum JavaScript dapat dimanfaatkan oleh klien. Untuk jenis perpustakaan JQuery langkah ini dapat mengambil ekstra waktu 100 - 500ms pada klien, tergantung pada banyak faktor.
Sekarang kita dapat membandingkan pengurangan "waktu untuk mengunduh script" dan "waktu tambahan yang dibutuhkan untuk mengeksekusi script". Ini (packer/teknik base62) dapat mengurangi waktu pengunduhan sebanyak 50ms tetapi mengambil ekstra 100ms hanya untuk memprosesnya (menyusun kembali kode yang sudah terpecah-pecah) - Sumber
Lalu bagaimana dengan alasan perlindungan kode? Bukankah Packer dan Obfuscator jauh lebih melindungi kode dibandingkan Minifier?
Ini semua adalah pilihan. Pada dasarnya setiap teknik kompresi masih tetap bisa menjaga agar file bisa dibaca oleh peramban. Ambil keputusan yang sekiranya memiliki kerugian terkecil berdasarkan tujuan.
- http://dean.edwards.name/packer/
- http://javascriptobfuscator.com/default.aspx
- http://www.daftlogic.com/projects-online-javascript-obfuscator.htm
Memperkecil Permintaan HTTP
Semakin banyak permintaan HTTP (HTTP Requests) yang terjadi, maka akan semakin lambat halaman termuat. Permintaan HTTP pada dasarnya hanyalah tentang seberapa banyak peramban menghubungi server untuk memanggil data. Cara mengecek permintaan yang terjadi sebenarnya sangat mudah. Perhatikan saja status bar pada peramban Anda saat halaman sedang dimuat:
Dari situ Anda bisa melihat mana data yang cepat diakses dan mana yang lebih lama diakses berdasarkan kecepatan perubahan status. Jika Anda sudah menemukan apa yang membuat situs Anda menjadi lambat, Anda bisa segera mengambil keputusan terhadap file yang berhubungan dengan itu. Apakah akan membuangnya atau mengubah pengurutan permintaan yang lebih lambat menuju ke level yang lebih rendah (tidak dinomorsatukan). Misalnya, dengan cara meletakkan file yang lebih lama termuat di sebelah bawah.
Usahakan untuk mengurangi permintaan HTTP dari situs pihak ke tiga sebanyak mungkin. Katakanlah kita memiliki 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, kode CSS yang disimpan di GitHub dan JavaScript yang disimpan di Google Code. Kita bisa mengatakan itu semua sebagai komponen permintaan situs pihak ke tiga, karena kita telah menyisipkan berbagai 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 saat Anda membuka halaman blog dimana file-file yang disertakan di dalamnya masih merupakan milik situs lain, itu tetap saja akan memiliki arti yang sama seperti halnya Anda sedang membuka semua situs tersebut secara bersamaan!
Menggabungkan Semua File Eksternal Sejenis
Menggabungkan semua file sejenis ke dalam sebuah file besar bisa menjadi solusi termudah untuk mengurangi permintaan HTTP. Artinya bahwa kita akan mengubah sesuatu yang tadinya seperti ini:<link rel="stylesheet" type="text/css" href="style1.css">
<link rel="stylesheet" type="text/css" href="style2.css">
<link rel="stylesheet" type="text/css" href="style3.css">
<script type="text/javascript" src="script1.js"></script>
<script type="text/javascript" src="script2.js"></script>
<script type="text/javascript" src="script3.js"></script>menjadi seperti ini:
<link rel="stylesheet" type="text/css" href="style-123.css">
<script type="text/javascript" src="script-123.js"></script>Ini berlaku juga untuk JavaScript dan CSS internal. Meskipun mereka tidak memiliki hubungan dengan permintaan HTTP, namun mengurangi jumlah tag
<style> dan <script> di dalam dokumen juga bisa 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://goo.gl/jAX6N');
}
</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 kode di atas menjadi seperti 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://goo.gl/jAX6N');
}
$(function() {
// DOM ready 1 ...
// DOM ready 2 ...
// DOM ready 3 ...
});
</script>
<script>
abc();
def();
ghi();
</script>Meletakkan JavaScript di atas </body>
Ini memiliki arti bahwa kita meletakkan JavaScript sejauh mungkin dari sebelah atas. Hal ini disarankan untuk mencegah keterlambatan pemuatan kerangka HTML di bawahnya karena 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 sampai pada masa untuk membaca JavaScript. Posisikan juga CSS lebih awal dibandingkan JavaScript sehingga pembentukan tubuh halaman akan dieksekusi terlebih dahulu dibandingkan pengerjaan JavaScript.Tapi tunggu dulu! Meletakkan JavaScript di bagian bawah juga tidak sepenuhnya benar. Beberapa faktor bisa membuat mereka tidak bekerja.
Katakanlah kita memiliki fungsi induk yang panjang, dan sebuah fungsi eksekusi. Jika kita mengambil prinsip bahwa file JavaScript yang lebih besar diletakkan setelah file yang lebih pendek maka yang terjadi adalah fungsi akan dieksekusi sebelum sempat dibangun.
Saya memiliki sebuah fungsi panjang bernama
loadtoc() dan Saya akan mengeksekusi fungsi tersebut pada sidebar:<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Table of Content</title>
</head>
<body>
<article> ... </article>
<aside>
<script>loadtoc(abcd);</script>
</aside>
<script>
function loadtoc() {
// Kode panjang Anda...
}
</script>
</body>
</html>Kode di atas tidak benar. Dalam Web Console akan terlihat bahwa
loadtoc tidak terdefinisi:
Sebenarnya bukannya tidak terdefinisi, hanya saja fungsi
loadtoc() dieksekusi sebelum sempat dibaca (Kasus ini persis seperti halnya seorang manusia yang memutuskan untuk mengatakan cinta sebelum merumuskan kata-kata).Anda boleh saja meletakkan JavaScript di sebelah bawah, tapi pastikan semuanya masih berada dalam satu susunan fungsi yang berurutan:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Table of Content</title>
<!-- Pastikan fungsi induk terbaca terlebih dahulu -->
<script>
function loadtoc() {
// Kode panjang Anda...
}
</script>
</head>
<body>
<article> ... </article>
<aside>
<!-- Eksekusi dilakukan setelah fungsi terbaca -->
<script>loadtoc();</script>
</aside>
</body>
</html><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Table of Content</title>
</head>
<body>
<article> ... </article>
<aside>
<!-- Pastikan fungsi induk terbaca terlebih dahulu -->
<script>
function loadtoc() {
// Kode panjang Anda...
}
</script>
<!-- Eksekusi dilakukan setelah fungsi terbaca -->
<script>loadtoc();</script>
</aside>
</body>
</html>Merasa Blog/Situs Anda Sudah Cukup Cepat?
Jangan senang dulu. Mungkin itu karena Anda sering mengunjungi situs Anda, yang juga berarti bahwa cache dari situs Anda masih tersimpan di dalam peramban. Sekarang coba Anda hapus semua cache yang ada kemudian muat ulang halaman situs Anda kembali:
Saat cache sudah terhapus, maka Anda akan merasakan kecepatan situs Anda yang sesungguhnya seperti halnya saat pengunjung Anda membuka situs Anda.
Tentunya akan terasa sedikit lebih lambat. Itu juga merupakan kesimpulan sederhana mengenai pertanyaan bodoh tentang mengapa saat kita pertama kali mengunjungi sebuah situs terasa begitu berat, namun saat kita telah menjadi langganan mereka, semuanya berubah menjadi lebih cepat.
Pembicaraan optimasi ini sepertinya lebih banyak berputar di sekitar JavaScript dan CSS saja. Ya, karena Saya pikir pembicaraan selain itu masih bisa dipahami seperti apa adanya. Saya hanya ingin menuliskan sesuatu yang seringkali menjadi sumber kesalahpahaman. Punya tambahan?
Sumber
0 komentar:
Posting Komentar