Minimalkan Permintaan HTTP
80% dari waktu respon end-user dihabiskan di front-end. Sebagian besar waktu ini terikat dalam men-download semua komponen di halaman: gambar, stylesheet, script, Flash, dll Mengurangi jumlah komponen pada gilirannya akan mengurangi jumlah permintaan HTTP yang dibutuhkan untuk membuat halaman. Ini adalah kunci untuk halaman lebih cepat.
Salah satu cara untuk mengurangi jumlah komponen dalam halaman adalah untuk menyederhanakan desain halaman. Tapi apakah ada cara untuk membangun halaman dengan konten yang lebih kaya sementara juga mencapai waktu respon yang cepat? Berikut adalah beberapa teknik untuk mengurangi jumlah permintaan HTTP, sementara masih mendukung desain halaman kaya.
File gabungan adalah cara untuk mengurangi jumlah permintaan HTTP dengan menggabungkan semua skrip ke dalam satu naskah, dan juga menggabungkan semua CSS ke stylesheet tunggal. Menggabungkan file lebih menantang ketika script dan stylesheet bervariasi dari halaman ke halaman, tetapi membuat ini bagian dari proses pembebasan Anda meningkatkan waktu respon.
CSS Sprite adalah metode yang disukai untuk mengurangi jumlah permintaan gambar. Menggabungkan gambar latar belakang Anda menjadi gambar tunggal dan menggunakan CSS background-image dan background-position properti untuk menampilkan segmen gambar yang diinginkan.
Peta gambar menggabungkan beberapa gambar menjadi satu gambar. Ukuran keseluruhan adalah sama, tetapi mengurangi jumlah permintaan HTTP mempercepat halaman. Peta gambar hanya bekerja jika gambar yang bersebelahan di halaman, seperti sebuah bar navigasi. Mendefinisikan koordinat peta gambar dapat membosankan dan rawan kesalahan. Menggunakan peta gambar untuk navigasi tidak dapat diakses juga, sehingga tidak dianjurkan.
Gambar Inline menggunakan Data: skema URL untuk menanamkan data gambar dalam halaman yang sebenarnya. Hal ini dapat meningkatkan ukuran dokumen HTML Anda. Menggabungkan gambar inline ke dalam (cached) stylesheet adalah cara untuk mengurangi permintaan HTTP dan menghindari meningkatkan ukuran halaman Anda. Gambar inline belum didukung di semua browser utama.
Mengurangi jumlah permintaan HTTP di halaman Anda adalah tempat untuk memulai. Ini adalah pedoman yang paling penting untuk meningkatkan kinerja untuk pertama kalinya pengunjung. Seperti dijelaskan dalam Tenni Theurer post blog Browser Cache Penggunaan - Exposed , 40-60% dari pengunjung harian ke situs Anda datang dengan cache kosong. Membuat halaman Anda cepat bagi pengunjung pertama kali ini adalah kunci untuk pengalaman pengguna yang lebih baik.
Gunakan Pengiriman Jaringan Konten
Kedekatan pengguna ke server web Anda memiliki dampak pada waktu respon. Menyebarkan konten Anda di beberapa, server secara geografis akan membuat halaman Anda memuat lebih cepat dari perspektif pengguna. Tapi di mana Anda harus mulai?
Sebagai langkah pertama untuk menerapkan konten geografis, jangan mencoba untuk mendesain ulang aplikasi web Anda untuk bekerja dalam arsitektur terdistribusi. Tergantung pada aplikasi, mengubah arsitektur dapat mencakup tugas-tugas yang menakutkan seperti sinkronisasi negara sesi dan mereplikasi database transaksi di Lokasi server. Upaya untuk mengurangi jarak antara pengguna dan konten Anda bisa tertunda oleh, atau tidak pernah lulus, aplikasi ini arsitektur langkah.
Ingat bahwa 80-90% dari waktu respon end-user dihabiskan men-download semua komponen di halaman: gambar, stylesheet, script, Flash, dll ini adalah Kinerja Golden Rule . Daripada memulai dengan tugas yang sulit untuk mendesain ulang arsitektur aplikasi Anda, lebih baik untuk pertama membubarkan konten statis Anda. Hal ini tidak hanya mencapai pengurangan yang lebih besar dalam waktu respon, tapi itu lebih mudah berkat jaringan pengiriman konten.
Sebuah jaringan pengiriman konten (CDN) adalah kumpulan server web didistribusikan di beberapa lokasi untuk memberikan konten yang lebih efisien bagi pengguna. Server yang dipilih untuk menyampaikan konten ke pengguna tertentu biasanya didasarkan pada ukuran jaringan kedekatan. Sebagai contoh, server dengan jaringan paling sedikit hop atau server dengan waktu respon tercepat dipilih.
Beberapa perusahaan Internet besar memiliki CDN mereka sendiri, tapi itu biaya-efektif untuk menggunakan penyedia layanan CDN, seperti Akamai Technologies , EdgeCast , atau level3 . Bagi perusahaan start-up dan situs web pribadi, biaya layanan CDN dapat menjadi penghalang, tetapi sebagai audiens target Anda tumbuh lebih besar dan menjadi lebih global, CDN yang diperlukan untuk mencapai waktu respon yang cepat. Di Yahoo!, properti yang bergerak konten statis dari server web aplikasi mereka ke CDN (baik pihak ke-3 seperti yang disebutkan di atas serta Yahoo sendiri CDN ) meningkatkan waktu respon end-user sebesar 20% atau lebih. Beralih ke CDN adalah perubahan kode yang relatif mudah yang secara dramatis akan meningkatkan kecepatan situs web Anda.
Tambahkan Expires atau Cache-Control header
Ada dua aspek dari aturan ini:
Untuk komponen statis: melaksanakan "Jangan pernah berakhir" kebijakan dengan menetapkan masa depan yang jauh Expires Header
Untuk komponen dinamis: menggunakan sesuai Cache-Control header untuk membantu browser dengan permintaan kondisional
Desain halaman web menjadi makin kaya dan kaya, yang berarti lebih banyak script, stylesheet, gambar, dan Flash di halaman. Baru pertama kali pengunjung ke halaman Anda mungkin harus membuat beberapa permintaan HTTP, tetapi dengan menggunakan Expires header Anda membuat komponen-komponen disimpan di cache. Hal ini untuk menghindari permintaan HTTP yang tidak perlu pada tampilan halaman berikutnya. Habis header yang paling sering digunakan dengan gambar, tetapi mereka harus digunakan pada semua komponen termasuk script, stylesheet, dan komponen Flash.
Browser (dan proxy) menggunakan cache untuk mengurangi jumlah dan ukuran permintaan HTTP, membuat halaman web memuat lebih cepat. Sebuah server web menggunakan Expires header di respon HTTP untuk memberitahu klien berapa lama komponen dapat di-cache. Ini adalah masa depan yang jauh Expires header, memberitahu browser bahwa respons ini tidak akan basi sampai dengan 15 April 2010.
Jika server Anda Apache, gunakan direktif ExpiresDefault untuk menetapkan tanggal kedaluwarsa relatif terhadap tanggal saat ini. Ini contoh dari direktif ExpiresDefault menetapkan Habis tanggal 10 tahun keluar dari waktu permintaan.
Perlu diingat, jika Anda menggunakan masa depan yang jauh Expires header Anda harus mengubah nama file komponen setiap kali perubahan komponen. Di Yahoo! kita sering membuat langkah ini bagian dari proses membangun: sebuah nomor versi tertanam dalam nama file komponen, misalnya, yahoo_2.0.6.js.
Menggunakan masa depan yang jauh Expires header mempengaruhi tampilan halaman setelah pengguna telah mengunjungi situs Anda. Ini tidak berpengaruh pada jumlah permintaan HTTP ketika pengguna mengunjungi situs Anda untuk pertama kalinya dan cache browser kosong. Oleh karena itu dampak dari peningkatan kinerja ini tergantung pada seberapa sering pengguna memukul halaman Anda dengan cache prima. (A "Cache prima" sudah mengandung semua komponen dalam halaman.) Kami mengukur ini di Yahoo! dan menemukan jumlah tampilan halaman dengan cache prima adalah 75-85%. Dengan menggunakan masa depan yang jauh Expires header, Anda meningkatkan jumlah komponen yang di-cache oleh browser dan digunakan kembali pada tampilan halaman berikutnya tanpa mengirimkan satu byte melalui koneksi internet pengguna.
Gzip Komponen
Waktu yang dibutuhkan untuk mentransfer permintaan HTTP dan respon di seluruh jaringan dapat dikurangi secara signifikan oleh keputusan yang dibuat oleh para insinyur front-end. Memang benar bahwa kecepatan bandwidth pengguna akhir, penyedia layanan internet, kedekatan dengan mengintip pertukaran poin, dll berada di luar kendali dari tim pengembangan. Tetapi ada variabel lain yang mempengaruhi waktu respon. Kompresi mengurangi waktu respon dengan mengurangi ukuran dari respon HTTP.
Dimulai dengan HTTP/1.1, web klien menunjukkan dukungan untuk kompresi dengan Accept-Encoding header permintaan HTTP.
Terima-Encoding: gzip, deflate
Jika server web melihat header ini dalam permintaan, mungkin menekan respon menggunakan salah satu metode yang terdaftar oleh klien. Web server memberitahu klien web ini melalui Content-Encoding header di respon.
Content-Encoding: gzip
Gzip adalah metode kompresi yang paling populer dan efektif saat ini. Ini dikembangkan oleh proyek GNU dan distandarisasi oleh RFC 1952 . Satu-satunya format kompresi lain yang mungkin Anda lihat adalah mengempis, tapi itu kurang efektif dan kurang populer.
Gzipping umumnya mengurangi ukuran respon sekitar 70%. Sekitar 90% dari lalu lintas internet saat ini perjalanan melalui browser yang mengklaim mendukung gzip. Jika Anda menggunakan Apache, modul mengkonfigurasi gzip tergantung pada versi Anda: Apache 1.3 menggunakan mod_gzip sementara Apache 2.x menggunakan mod_deflate .
Ada masalah yang diketahui dengan browser dan proxy yang dapat menyebabkan ketidakcocokan dalam apa yang diharapkan browser dan apa yang diterimanya berkaitan dengan konten terkompresi. Untungnya, kasus tepi ini berkurang sebagai penggunaan browser lama menurun. Modul Apache membantu dengan menambahkan sesuai Vary header respon otomatis.
Server memilih apa yang harus gzip berdasarkan tipe file, tetapi biasanya terlalu terbatas dalam apa yang mereka memutuskan untuk kompres. Sebagian besar situs web gzip dokumen HTML mereka. Ini juga berguna untuk gzip script dan stylesheet, tapi banyak situs web lewatkan kesempatan ini. Bahkan, ini berguna untuk kompres respon teks apapun termasuk XML dan JSON. Gambar dan PDF file tidak boleh gzip karena mereka sudah dikompresi. Mencoba untuk gzip mereka tidak hanya limbah CPU tetapi berpotensi dapat meningkatkan ukuran file.
Gzipping banyak jenis file mungkin adalah cara mudah untuk mengurangi berat badan halaman dan mempercepat pengalaman pengguna.
Pasang stylesheet di Puncak
Sementara meneliti kinerja di Yahoo!, kami menemukan bahwa pindah ke stylesheet HEAD dokumen membuat halaman muncul untuk memuat lebih cepat. Hal ini karena menempatkan stylesheet di HEAD memungkinkan halaman untuk membuat progresif.
Insinyur Front-end yang peduli tentang performa ingin halaman untuk memuat progresif, yaitu, kita ingin agar browser untuk menampilkan konten apapun itu secepat mungkin. Hal ini sangat penting untuk halaman dengan banyak konten dan bagi pengguna koneksi internet lambat. Pentingnya memberikan pengguna umpan balik visual, seperti indikator kemajuan, telah diteliti dan didokumentasikan . Dalam kasus kami halaman HTML adalah indikator kemajuan! Ketika browser load halaman semakin header, bar navigasi, logo di bagian atas, dll semua berfungsi sebagai umpan balik visual bagi pengguna yang sedang menunggu untuk halaman. Hal ini meningkatkan pengalaman pengguna secara keseluruhan.
Masalah dengan menempatkan stylesheet dekat bagian bawah dokumen adalah bahwa ia melarang render progresif di banyak browser, termasuk Internet Explorer. Browser ini memblokir render untuk menghindari harus redraw elemen halaman jika gaya mereka berubah. Pengguna yang terjebak melihat halaman putih kosong.
The spesifikasi HTML jelas menyatakan bahwa stylesheet harus dimasukkan dalam HEAD halaman: "Tidak seperti A, [LINK] hanya mungkin muncul di bagian HEAD dokumen, meskipun mungkin muncul beberapa kali." Tak satu pun dari alternatif, layar putih kosong atau flash konten unstyled, yang sepadan dengan risikonya. Solusi optimal adalah mengikuti spesifikasi HTML dan memuat stylesheet di HEAD dokumen.
Masukan Script di Bawah
Masalah yang disebabkan oleh script adalah bahwa mereka memblokir paralel download. The HTTP/1.1 spesifikasi menunjukkan bahwa browser men-download tidak lebih dari dua komponen secara paralel per hostname. Jika Anda melayani gambar Anda dari beberapa hostname, Anda bisa mendapatkan lebih dari dua downloads terjadi secara paralel. Sementara naskah adalah men-download, namun, browser tidak akan memulai download lain, bahkan pada nama host yang berbeda.
Dalam beberapa situasi tidak mudah untuk memindahkan script ke bawah. Jika, misalnya, script menggunakan document.write untuk memasukkan bagian dari isi halaman, tidak bisa bergerak lebih rendah di halaman. Ada juga mungkin scoping masalah. Dalam banyak kasus, ada cara untuk solusi situasi ini.
Sebuah saran alternatif yang sering muncul adalah dengan menggunakan script ditangguhkan. The DEFER atribut menunjukkan bahwa script tidak mengandung document.write, dan petunjuk untuk browser yang mereka dapat terus rendering. Sayangnya, Firefox tidak mendukung DEFER atribut. Di Internet Explorer, script dapat ditangguhkan, tetapi tidak sebanyak yang diinginkan. Jika script bisa ditunda, juga dapat dipindahkan ke bagian bawah halaman. Itu akan membuat halaman web Anda memuat lebih cepat.
Hindari Expressions CSS
Ekspresi CSS adalah kuat (dan berbahaya) cara untuk mengatur properti CSS dinamis. Mereka didukung di Internet Explorer dimulai dengan versi 5, tetapi usang dimulai dengan IE8 . Sebagai contoh, warna latar belakang dapat diatur untuk bergantian setiap jam menggunakan ekspresi CSS:
background-color: ekspresi (. (new Date ()) getHours ()% 2 "# B8D4FF":? "# F08A00");
Seperti ditunjukkan di sini, ekspresi metode menerima ekspresi JavaScript. Properti CSS diatur dengan hasil evaluasi ekspresi JavaScript. The ekspresi Metode diabaikan oleh browser lain, sehingga sangat berguna untuk pengaturan properti di Internet Explorer diperlukan untuk menciptakan pengalaman yang konsisten di seluruh browser.
Masalah dengan ekspresi adalah bahwa mereka dievaluasi lebih sering daripada kebanyakan orang harapkan. Bukan saja mereka dievaluasi saat halaman diberikan dan ukurannya, tetapi juga saat halaman menggulir dan bahkan ketika pengguna menggerakkan mouse di atas halaman. Menambahkan counter untuk ekspresi CSS memungkinkan kita untuk melacak kapan dan seberapa sering ekspresi CSS dievaluasi. Menggerakkan mouse di sekitar halaman dengan mudah dapat menghasilkan lebih dari 10.000 evaluasi.
Salah satu cara untuk mengurangi jumlah kali ekspresi CSS Anda dievaluasi adalah dengan menggunakan ekspresi satu kali, dimana pertama kalinya ekspresi dievaluasi set properti gaya ke nilai eksplisit, yang menggantikan ekspresi CSS. Jika properti gaya harus diatur secara dinamis sepanjang hidup halaman, menggunakan event handler bukan ekspresi CSS adalah sebuah pendekatan alternatif. Jika Anda harus menggunakan ekspresi CSS, ingat bahwa mereka dapat dievaluasi ribuan kali dan bisa mempengaruhi kinerja halaman Anda.
Membuat JavaScript dan CSS External
Banyak aturan kinerja ini berurusan dengan bagaimana komponen eksternal dikelola. Namun, sebelum pertimbangan ini muncul Anda harus mengajukan pertanyaan yang lebih mendasar: Haruskah JavaScript dan CSS terkandung dalam file eksternal, atau inline dalam halaman itu sendiri?
Menggunakan file eksternal di dunia nyata umumnya menghasilkan halaman dengan lebih cepat karena file-file JavaScript dan CSS cache oleh browser. JavaScript dan CSS yang inline dalam dokumen HTML mendapatkan download setiap kali dokumen HTML diminta. Hal ini akan mengurangi jumlah permintaan HTTP yang diperlukan, tetapi meningkatkan ukuran dokumen HTML. Di sisi lain, jika JavaScript dan CSS dalam file eksternal cache oleh browser, ukuran dokumen HTML berkurang tanpa meningkatkan jumlah permintaan HTTP.
Faktor kunci, kemudian, adalah frekuensi yang JavaScript eksternal dan komponen CSS cache relatif terhadap jumlah dokumen HTML yang diminta. Faktor ini, meskipun sulit untuk mengukur, dapat diukur dengan menggunakan berbagai metrik. Jika pengguna di situs Anda memiliki beberapa tampilan halaman per sesi dan banyak halaman Anda kembali menggunakan script dan stylesheet yang sama, ada potensi manfaat lebih besar dari file eksternal cache.
Banyak situs web jatuh di tengah metrik ini. Untuk situs-situs tersebut, solusi terbaik umumnya adalah untuk menyebarkan JavaScript dan CSS sebagai file eksternal. Satu-satunya pengecualian di mana inlining lebih baik adalah dengan halaman rumah, seperti halaman depan Yahoo! 's dan My Yahoo! . Halaman rumah yang memiliki sedikit (mungkin hanya satu) tampilan halaman per sesi mungkin menemukan bahwa inlining JavaScript dan CSS hasil dalam waktu respon end-user lebih cepat.
Untuk halaman depan yang biasanya yang pertama dari banyak tampilan halaman, ada teknik yang memanfaatkan pengurangan permintaan HTTP yang menyediakan inlining, serta manfaat caching dicapai melalui menggunakan file eksternal. Salah satu teknik tersebut adalah untuk inline JavaScript dan CSS di halaman depan, tapi secara dinamis men-download file eksternal setelah halaman selesai loading. Halaman berikutnya akan referensi file eksternal yang harus berada dalam cache browser.
Mengurangi DNS lookup
Domain Name System (DNS) memetakan nama host ke alamat IP, seperti buku telepon memetakan nama orang ke nomor telepon mereka. Ketika Anda mengetik www.yahoo.com ke browser Anda, penyelesai DNS dihubungi oleh browser kembali alamat IP yang server. DNS memiliki biaya. Ini biasanya memakan waktu 20-120 milidetik untuk DNS lookup alamat IP untuk nama host yang diberikan. Browser tidak dapat men-download apa pun dari nama host ini sampai lookup DNS selesai.
Lookup DNS cache untuk kinerja yang lebih baik. Caching ini dapat terjadi pada server caching khusus, dikelola oleh jaringan ISP atau lokal pengguna daerah, tetapi ada juga caching yang terjadi pada komputer pengguna individu. Informasi DNS tetap dalam DNS cache sistem operasi ("layanan Klien DNS" pada Microsoft Windows). Kebanyakan browser memiliki cache mereka sendiri, terpisah dari cache sistem operasi. Selama browser menyimpan catatan DNS dalam cache sendiri, itu tidak mengganggu sistem operasi dengan permintaan untuk catatan.
Internet Explorer cache DNS lookups selama 30 menit secara default, sebagaimana ditentukan oleh DnsCacheTimeout pengaturan registri. Firefox cache DNS lookups selama 1 menit, yang dikendalikan oleh network.dnsCacheExpiration pengaturan konfigurasi. (Fasterfox perubahan ini untuk 1 jam.)
Ketika cache DNS klien kosong (baik untuk browser dan sistem operasi), jumlah pencarian DNS adalah sama dengan jumlah hostname unik dalam halaman web. Ini termasuk nama host yang digunakan dalam URL halaman, gambar, file naskah, stylesheet, obyek Flash, dll Mengurangi jumlah hostname unik mengurangi jumlah pencarian DNS.
Mengurangi jumlah hostname unik memiliki potensi untuk mengurangi jumlah paralel download yang berlangsung di halaman. Menghindari lookup DNS memotong waktu respon, tapi mengurangi paralel download dapat meningkatkan waktu respon. Pedoman saya adalah untuk membagi komponen-komponen ini di setidaknya dua tetapi tidak lebih dari empat hostname. Hal ini menghasilkan kompromi yang baik antara mengurangi DNS lookup dan memungkinkan tingkat tinggi paralel download.
Mengecilkan JavaScript dan CSS
Minification adalah praktek menghapus karakter yang tidak perlu dari kode untuk mengurangi ukuran demikian meningkatkan beban kali nya. Ketika kode minified semua komentar dihapus, serta karakter spasi yang tidak diperlukan (spasi, baris baru, dan tab). Dalam kasus JavaScript, ini meningkatkan kinerja waktu respon karena ukuran file yang didownload berkurang. Dua alat yang populer untuk minifying kode JavaScript yang JSMin dan YUI Compressor . The YUI kompresor juga dapat mengecilkan CSS.
Kebingungan optimasi alternatif yang dapat diterapkan pada kode sumber. Ini lebih kompleks daripada minification dan dengan demikian lebih mungkin untuk menghasilkan bug sebagai akibat dari kebingungan langkah sendiri. Dalam sebuah survei dari sepuluh situs web top AS, minification mencapai pengurangan ukuran 21% versus 25% untuk kebingungan. Meskipun kebingungan memiliki pengurangan ukuran yang lebih tinggi, minifying JavaScript kurang berisiko.
Selain minifying skrip eksternal dan gaya, inline <script> dan <style> blok dapat dan juga harus minified. Bahkan jika Anda gzip script Anda dan gaya, minifying mereka masih akan mengurangi ukuran sebesar 5% atau lebih. Seperti penggunaan dan ukuran JavaScript dan CSS meningkat, sehingga akan penghematan yang diperoleh dengan minifying kode Anda.
Hindari Redirects
Pengalihan yang dicapai dengan menggunakan 301 dan 302 kode status. Berikut ini adalah contoh dari header HTTP dalam respon 301:
HTTP/1.1 301 Moved Permanently
Lokasi: http://example.com/newuri
Content-Type: text / html
Browser secara otomatis membawa pengguna ke URL yang ditentukan dalam Lokasi lapangan. Semua informasi yang diperlukan untuk redirect adalah dalam header. Tubuh respon biasanya kosong. Meskipun nama mereka, baik 301 maupun 302 respon cache dalam praktek kecuali header tambahan, seperti Habis atau Cache-Control , menunjukkan seharusnya. Meta tag refresh dan JavaScript cara lain untuk mengarahkan pengguna ke URL yang berbeda, tetapi jika Anda harus melakukan redirect, teknik yang lebih disukai adalah dengan menggunakan kode status HTTP 3xx standar, terutama untuk memastikan tombol kembali bekerja dengan benar.
Hal utama yang perlu diingat adalah bahwa pengalihan memperlambat pengalaman pengguna. Memasukkan redirect antara pengguna dan dokumen HTML menunda segala sesuatu di halaman karena tidak ada dalam halaman dapat diberikan dan tidak ada komponen dapat mulai didownload sampai dokumen HTML telah tiba.
Salah satu pengalihan paling boros sering terjadi dan pengembang web umumnya tidak menyadari hal itu. Hal ini terjadi ketika spasi (/) hilang dari URL yang harus dinyatakan memiliki satu. Misalnya, akan http://astrology.yahoo.com/astrology hasil dalam 301 tanggapan yang berisi redirect ke http://astrology.yahoo.com/astrology/ (perhatikan ditambahkan membuntuti slash). Ini diperbaiki di Apache dengan menggunakan Alias atau mod_rewrite , atau DirectorySlash direktif jika Anda menggunakan penangan Apache.
Menghubungkan situs web lama ke yang baru adalah penggunaan umum lain untuk pengalihan. Lainnya termasuk menghubungkan bagian yang berbeda dari sebuah situs web dan mengarahkan pengguna berdasarkan kondisi tertentu (jenis browser, jenis account pengguna, dll). Menggunakan redirect untuk menghubungkan dua situs web sederhana dan memerlukan sedikit coding tambahan. Meski menggunakan pengalihan dalam situasi seperti ini mengurangi kompleksitas untuk pengembang, akan merusak pengalaman pengguna. Alternatif untuk penggunaan ini pengalihan termasuk menggunakan Alias dan mod_rewrite jika dua jalur kode yang di-host pada server yang sama. Jika perubahan nama domain adalah penyebab menggunakan pengalihan, alternatif adalah untuk menciptakan sebuah CNAME (catatan DNS yang menciptakan alias menunjuk dari satu nama domain yang lain) dalam kombinasi dengan Alias atau mod_rewrite .
Remove Scripts Duplikat
Sungguh menyakitkan kinerja untuk menyertakan file JavaScript yang sama dua kali dalam satu halaman. Hal ini tidak biasa seperti yang Anda bayangkan. Sebuah tinjauan dari sepuluh situs web top AS menunjukkan bahwa dua dari mereka mengandung script digandakan. Dua faktor utama meningkatkan kemungkinan naskah yang digandakan dalam satu halaman web: ukuran tim dan jumlah skrip. Ketika itu tidak terjadi, duplikat script melukai kinerja dengan menciptakan permintaan HTTP yang tidak perlu dan terbuang JavaScript eksekusi.
Permintaan HTTP yang tidak perlu terjadi di Internet Explorer, tapi tidak di Firefox. Di Internet Explorer, jika skrip eksternal termasuk dua kali dan tidak disimpan di cache, itu menghasilkan dua permintaan HTTP selama loading halaman. Bahkan jika script disimpan di cache, permintaan HTTP tambahan terjadi ketika pengguna reload halaman.
Selain menghasilkan permintaan HTTP boros, waktu terbuang mengevaluasi script beberapa kali. Eksekusi JavaScript berlebihan ini terjadi di kedua Firefox dan Internet Explorer, terlepas dari apakah script disimpan di cache.
Salah satu cara untuk menghindari sengaja termasuk script yang sama dua kali adalah untuk menerapkan modul manajemen naskah dalam sistem template Anda. Cara khas untuk memasukkan script adalah dengan menggunakan tag SCRIPT di halaman HTML Anda.
<script type="text/javascript" src="menu_1.0.17.js"> </ script>
Sebuah alternatif dalam PHP akan membuat fungsi yang disebut insertScript .
<? Php insertScript ("menu.js")>
Selain mencegah script yang sama dari yang dimasukkan beberapa kali, fungsi ini bisa menangani masalah lain dengan script, seperti ketergantungan memeriksa dan menambahkan nomor versi untuk nama file script untuk mendukung masa depan yang jauh Expires header.
top | membahas aturan ini
Konfigurasi ETags
Tag Entity (ETags) adalah mekanisme bahwa server web dan browser digunakan untuk menentukan apakah komponen dalam cache browser sesuai dengan satu di server asal. (An "entitas" adalah kata lain "komponen": gambar, script, stylesheet, dll) ETags ditambahkan untuk menyediakan mekanisme untuk memvalidasi entitas yang lebih fleksibel dibandingkan dengan tanggal modifikasi terakhir. Sebuah ETag adalah string yang secara unik mengidentifikasi versi tertentu dari sebuah komponen. Satu-satunya kendala Format adalah bahwa string dikutip. Server asal menentukan ETag komponen yang menggunakan ETag header respon.
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Desember 2006 03:03:59 GMT
ETag: "10c24bc-4AB-457e1c1f"
Content-Length: 12195
Kemudian, jika browser harus memvalidasi komponen, menggunakan Jika-Tidak-Match header untuk lulus ETag kembali ke server asal. Jika ETags cocok, kode status 304 dikembalikan mengurangi respon oleh 12195 byte untuk contoh ini.
GET / i / yahoo.gif HTTP/1.1
Host: us.yimg.com
Jika-Diubah-Sejak: Tue, 12 Desember 2006 03:03:59 GMT
Jika-Tidak-Match: "10c24bc-4AB-457e1c1f"
HTTP/1.1 304 Not Modified
Masalah dengan ETags adalah bahwa mereka biasanya dibangun menggunakan atribut yang membuat mereka unik ke server hosting situs tertentu. ETags tidak akan cocok bila browser mendapat komponen asli dari satu server dan kemudian mencoba untuk memvalidasi komponen yang pada server yang berbeda, situasi yang terlalu umum pada situs Web yang menggunakan sekelompok server untuk menangani permintaan. Secara default, baik Apache dan IIS menanamkan data dalam ETag yang secara dramatis mengurangi kemungkinan uji validitas berhasil di situs web dengan beberapa server.
The ETag format untuk Apache 1.3 dan 2.x adalah inode-size-timestamp . Meskipun file yang diberikan mungkin berada di direktori yang sama di beberapa server, dan memiliki ukuran file yang sama, perizinan, timestamp, dan lain-lain, inode yang berbeda dari satu server ke yang berikutnya.
IIS 5.0 dan 6.0 memiliki masalah yang sama dengan ETags. Format untuk ETags pada IIS adalah Filetimestamp: ChangeNumber . Sebuah ChangeNumber adalah counter digunakan untuk melacak perubahan konfigurasi IIS. Ini tidak mungkin bahwa ChangeNumber adalah sama di semua server IIS di balik situs web.
Hasil akhirnya adalah ETags dihasilkan oleh Apache dan IIS untuk komponen yang sama persis tidak akan cocok dari satu server ke yang lain. Jika ETags tidak cocok, pengguna tidak menerima kecil, cepat 304 respon yang ETags dirancang untuk, melainkan, mereka akan mendapatkan 200 respon normal bersama dengan semua data untuk komponen. Jika Anda meng-host situs web Anda hanya pada satu server, ini bukan masalah. Tapi jika Anda memiliki beberapa server hosting situs web Anda, dan Anda menggunakan Apache atau IIS dengan konfigurasi ETag default, pengguna mendapatkan halaman lambat, server Anda telah beban yang lebih tinggi, Anda mengkonsumsi bandwidth yang lebih besar, dan proxy aren ' t caching konten Anda secara efisien. Bahkan jika komponen Anda memiliki masa depan yang jauh Expires header, permintaan GET bersyarat masih dibuat setiap kali pengguna hits Reload atau Refresh.
Jika Anda tidak mengambil keuntungan dari model validasi yang fleksibel yang memberikan ETags, lebih baik untuk hanya menghapus ETag sama sekali. The Last-Modified header yang memvalidasi berdasarkan timestamp komponen. Dan menghapus ETag mengurangi ukuran header HTTP baik dalam respon dan permintaan berikutnya. Ini Artikel Dukungan Microsoft menjelaskan cara menghapus ETags. Dalam Apache, hal ini dilakukan dengan hanya menambahkan baris berikut ke file konfigurasi Apache Anda:
FileETag none
Buat Ajax Cacheable
Salah satu manfaat yang dikutip dari Ajax adalah bahwa ia menyediakan umpan balik instan kepada pengguna karena permintaan informasi asynchronously dari web server backend. Namun, dengan menggunakan Ajax ada jaminan bahwa pengguna tidak akan memutar-mutar ibu jari menunggu orang JavaScript dan XML tanggapan asynchronous untuk kembali. Dalam banyak aplikasi, apakah atau tidak pengguna disimpan menunggu tergantung pada seberapa Ajax digunakan. Misalnya, dalam klien email berbasis web pengguna akan terus menunggu hasil dari permintaan Ajax untuk menemukan semua pesan email yang sesuai dengan kriteria pencarian mereka. Sangat penting untuk diingat bahwa "asynchronous" tidak berarti "seketika".
Untuk meningkatkan kinerja, penting untuk mengoptimalkan tanggapan Ajax ini. Cara yang paling penting untuk meningkatkan kinerja Ajax adalah untuk membuat tanggapan disimpan di cache, seperti dibahas dalam Tambah sebuah Habis atau Cache-Control header . Beberapa aturan lain juga berlaku untuk Ajax:
Gzip Komponen
Mengurangi DNS lookup
Mengecilkan JavaScript
Hindari Redirects
Konfigurasi ETags
Mari kita lihat sebuah contoh. Sebuah Web 2.0 email client mungkin menggunakan Ajax untuk men-download buku alamat pengguna untuk autocompletion. Jika pengguna belum diubah buku alamat nya sejak terakhir kali dia menggunakan aplikasi web email, respon buku alamat sebelumnya dapat dibaca dari cache jika respon Ajax dibuat disimpan di cache dengan masa depan Habis atau sundulan Cache-Control. Browser harus diberitahu kapan harus menggunakan cache sebelumnya respon buku alamat dibandingkan meminta yang baru. Hal ini dapat dilakukan dengan menambahkan timestamp ke buku alamat URL Ajax menunjukkan waktu terakhir pengguna diubah buku alamat nya, misalnya, & t = 1190241612 . Jika buku alamat belum dimodifikasi sejak download terakhir, timestamp akan sama dan buku alamat akan dibaca dari cache browser menghilangkan HTTP jemput ekstra. Jika pengguna telah diubah buku alamat nya, timestamp memastikan URL baru tidak sesuai dengan respon cache, dan browser akan meminta entri buku alamat diperbarui.
Meskipun tanggapan Ajax Anda dibuat secara dinamis, dan mungkin hanya berlaku untuk satu pengguna, mereka masih dapat di-cache. Melakukan hal ini akan membuat Anda Web 2.0 aplikasi lebih cepat.
Siram Buffer Dini
Ketika pengguna meminta halaman, itu bisa berlangsung dari 200 sampai 500ms untuk server backend untuk menjahit bersama halaman HTML. Selama waktu ini, browser idle karena menunggu data tiba. Dalam PHP Anda memiliki fungsi flush () . Hal ini memungkinkan Anda untuk mengirim respon HTML parsial siap Anda ke browser sehingga browser dapat mulai mengambil komponen sementara backend Anda sibuk dengan sisa halaman HTML. Manfaat ini terutama terlihat pada backends sibuk atau frontends cahaya.
Tempat yang baik untuk mempertimbangkan pembilasan tepat setelah KEPALA karena HTML untuk kepala biasanya lebih mudah untuk memproduksi dan memungkinkan Anda untuk menyertakan CSS dan file JavaScript untuk browser untuk mulai mengambil secara paralel sementara backend masih memproses.
Contoh:
... <-! - Css, js>
</ head> <? php flush ();>
<body>
<! - konten -> ...
Yahoo! pencarian memelopori penelitian dan pengujian pengguna nyata untuk membuktikan manfaat menggunakan teknik ini.
puncak
Gunakan GET untuk AJAX Permintaan
The Yahoo! Mail tim menemukan bahwa ketika menggunakan XMLHttpRequest , POST diimplementasikan dalam browser sebagai proses dua langkah: mengirim header pertama, kemudian mengirimkan data. Jadi yang terbaik untuk menggunakan GET, yang hanya membutuhkan waktu satu paket TCP untuk mengirimkan (kecuali jika Anda memiliki banyak cookie). Panjang maksimum URL di IE adalah 2K, jadi jika Anda mengirim data lebih dari 2K Anda mungkin tidak dapat menggunakan GET.
Sebuah sisi menarik mempengaruhi adalah bahwa POST tanpa benar-benar mem-posting data apapun berperilaku seperti GET. Berdasarkan spesifikasi HTTP , GET dimaksudkan untuk mengambil informasi, sehingga masuk akal (semantik) untuk menggunakan GET ketika Anda hanya meminta data, sebagai lawan mengirim data yang akan disimpan server-side.
puncak
Post-beban Komponen
Anda dapat melihat lebih dekat pada halaman Anda dan tanyakan pada diri sendiri: "Apa yang benar-benar diperlukan untuk membuat halaman awalnya?". Sisa isi dan komponen bisa menunggu.
JavaScript adalah calon yang ideal untuk membelah sebelum dan sesudah event onload. Sebagai contoh jika Anda memiliki kode JavaScript dan perpustakaan yang melakukan drag and drop dan animasi, mereka bisa menunggu, karena menyeret elemen pada halaman muncul setelah rendering awal. Tempat-tempat lain untuk mencari calon untuk pasca pemuatan termasuk konten tersembunyi (konten yang muncul setelah tindakan pengguna) dan gambar di bawah flip.
Alat untuk membantu Anda dalam usaha Anda: YUI Gambar Loader memungkinkan Anda untuk menunda gambar di bawah flip dan YUI Dapatkan utilitas adalah cara mudah untuk memasukkan JS dan CSS on the fly. Sebagai contoh di alam liar lihatlah Yahoo! Halaman dengan Panel Bersih Firebug diaktifkan.
Ada baiknya bila tujuan kinerja yang sejalan dengan praktik terbaik pengembangan web lainnya. Dalam hal ini, gagasan peningkatan progresif mengatakan bahwa JavaScript, bila didukung, dapat meningkatkan pengalaman pengguna tetapi Anda harus memastikan halaman bekerja bahkan tanpa JavaScript. Jadi setelah Anda memastikan halaman bekerja dengan baik, Anda dapat meningkatkan dengan beberapa script pasca-loaded yang memberikan Anda lebih banyak bel dan peluit seperti drag and drop dan animasi.
puncak
Preload Komponen
Preload mungkin terlihat seperti kebalikan dari pasca-beban, tetapi sebenarnya memiliki tujuan yang berbeda. Dengan preloading komponen Anda dapat mengambil keuntungan dari waktu browser idle dan komponen permintaan (seperti gambar, gaya dan skrip) yang Anda perlukan di masa depan. Dengan cara ini ketika pengguna mengunjungi halaman berikutnya, Anda bisa memiliki sebagian besar komponen sudah dalam cache dan halaman Anda akan memuat lebih cepat bagi pengguna.
Sebenarnya ada beberapa jenis preloading:
Unconditional preload - segera setelah kebakaran onload, Anda terus maju dan mengambil beberapa komponen tambahan. Periksa google.com untuk contoh bagaimana gambar sprite diminta onload. Gambar sprite ini tidak diperlukan pada homepage google.com, tetapi dibutuhkan pada halaman hasil pencarian berturut-turut.
Conditional preload - didasarkan pada tindakan pengguna Anda membuat tebakan mana pengguna menuju berikutnya dan preload sesuai. Pada search.yahoo.com Anda dapat melihat bagaimana beberapa komponen tambahan yang diminta setelah Anda mulai mengetik di kotak input.
Diduga preload - preload terlebih dahulu sebelum meluncurkan desain ulang. Sering terjadi setelah desain ulang yang Anda dengar: "Situs baru yang keren, tapi itu lebih lambat dari sebelumnya". Sebagian dari masalah dapat bahwa pengguna mengunjungi situs lama Anda dengan cache penuh, tapi yang baru selalu merupakan pengalaman tembolok kosong. Anda dapat mengurangi efek samping ini dengan preloading beberapa komponen bahkan sebelum Anda meluncurkan desain ulang. Situs lama Anda dapat menggunakan waktu browser idle dan gambar permintaan dan skrip yang akan digunakan oleh situs baru
puncak
Kurangi Jumlah DOM Elements
Halaman kompleks berarti lebih byte untuk men-download dan itu juga berarti akses DOM lambat dalam JavaScript. Itu membuat perbedaan jika Anda loop melalui 500 atau 5000 elemen DOM pada halaman bila Anda ingin menambahkan event handler misalnya.
Sejumlah tinggi elemen DOM dapat merupakan gejala bahwa ada sesuatu yang harus diperbaiki dengan markup halaman tanpa harus menghapus konten. Apakah Anda menggunakan tabel bersarang untuk keperluan tata letak? Apakah Anda melemparkan lebih <div> s hanya untuk memperbaiki masalah tata letak? Mungkin ada cara yang lebih baik dan lebih semantik benar untuk melakukan markup Anda.
Sebuah membantu dengan layout adalah utilitas YUI CSS : grids.css dapat membantu Anda dengan tata letak keseluruhan, fonts.css dan reset.css dapat membantu Anda mengupas format default browser. Ini adalah kesempatan untuk memulai segar dan berpikir tentang markup Anda, misalnya menggunakan <div> s hanya ketika masuk akal semantis, dan bukan karena membuat baris baru.
Jumlah elemen DOM mudah untuk menguji, ketik saja konsol Firebug: document.getElementsByTagName ('*') panjang.
Dan berapa banyak elemen DOM terlalu banyak? Periksa halaman serupa lainnya yang memiliki markup yang baik. Misalnya Yahoo! Halaman adalah halaman cukup sibuk dan masih di bawah 700 elemen (tag HTML).
Komponen Berpisah Di Domain
Memisahkan komponen memungkinkan Anda untuk memaksimalkan paralel download. Pastikan Anda menggunakan tidak lebih dari 2-4 domain karena hukuman lookup DNS. Misalnya, Anda dapat meng-host HTML dan konten dinamis pada www.example.org dan membagi komponen statis antara static1.example.org dan static2.example.org
Untuk informasi lebih lanjut memeriksa " Memaksimalkan Paralel Download di Carpool Lane "oleh Tenni Theurer dan Patty Chi.
Minimalkan Jumlah iframe
Iframe memungkinkan dokumen HTML yang akan dimasukkan dalam dokumen induk. Sangat penting untuk memahami bagaimana iframe bekerja sehingga mereka dapat digunakan secara efektif.
<iframe> Pro:
Membantu dengan konten pihak ketiga lambat seperti lencana dan iklan
Keamanan sandbox
Download script secara paralel
<iframe> kontra:
Mahal bahkan jika kosong
Halaman Blok onload
Non-semantik
Tidak ada 404s
Permintaan HTTP mahal jadi membuat permintaan HTTP dan mendapatkan respon yang tidak berguna (yaitu 404 Not Found) sama sekali tidak perlu dan akan memperlambat pengalaman pengguna tanpa imbalan apapun.
Beberapa situs memiliki 404s bermanfaat "Did you mean X?", Yang sangat bagus untuk pengalaman pengguna tetapi juga limbah sumber daya server (seperti basis data, dll). Terutama buruk adalah ketika link ke JavaScript eksternal yang salah dan hasilnya adalah 404. Pertama, unduhan ini akan memblokir paralel download. Selanjutnya browser mungkin mencoba untuk mengurai tubuh 404 respon seolah-olah kode JavaScript, mencoba untuk menemukan sesuatu yang dapat digunakan di dalamnya.
Mengurangi Cookie Ukuran
Cookie HTTP digunakan untuk berbagai alasan seperti otentikasi dan personalisasi. Informasi tentang cookie dipertukarkan dalam header HTTP antara server web dan browser. Sangat penting untuk menjaga ukuran cookie serendah mungkin untuk meminimalkan dampak pada waktu respon pengguna.
Untuk informasi lebih lanjut, periksa "Ketika Cookie runtuh" oleh Tenni Theurer dan Patty Chi. The dibawa pulang dari penelitian ini:
Menghilangkan cookies yang tidak perlu
Jauhkan ukuran kue serendah mungkin untuk meminimalkan dampak pada waktu respon pengguna
Berhati-hati pengaturan cookie pada tingkat domain yang sesuai sehingga sub-domain lainnya tidak terpengaruh
Menetapkan tanggal Habis tepat. Sebuah sebelumnya Habis tanggal atau tidak menghapus cookie cepat, meningkatkan waktu respon pengguna
Gunakan Domain Cookie bebas untuk Komponen
Ketika browser membuat permintaan untuk gambar statis dan mengirimkan cookies bersama-sama dengan permintaan, server tidak memiliki gunakan untuk cookie. Jadi mereka hanya membuat lalu lintas jaringan tanpa alasan yang baik. Anda harus memastikan komponen statis diminta dengan permintaan cookie-bebas. Membuat subdomain dan tuan rumah semua komponen statis Anda di sana.
Jika domain Anda adalah www.example.org , Anda dapat meng-host komponen statis Anda pada static.example.org . Namun, jika Anda sudah mengatur cookie pada top-level domain example.org sebagai lawan www.example.org , maka semua permintaan untuk static.example.org akan termasuk orang-orang cookies. Dalam hal ini, Anda dapat membeli domain baru, tuan komponen statis Anda di sana, dan menjaga domain ini cookie-bebas. Yahoo! menggunakan yimg.com , YouTube menggunakan ytimg.com , Amazon menggunakan gambar-amazon.com dan sebagainya.
Manfaat lain hosting komponen statis pada domain cookie-bebas adalah bahwa beberapa proxy mungkin menolak untuk cache komponen yang diminta dengan cookie. Pada catatan terkait, jika Anda bertanya-tanya apakah Anda harus menggunakan example.org atau www.example.org untuk halaman rumah Anda, mempertimbangkan dampak kue. Menghilangkan www membuat Anda tidak punya pilihan selain untuk menulis cookie untuk *. example.org , jadi untuk alasan kinerja yang terbaik untuk menggunakan subdomain www dan menulis cookie ke subdomain tersebut.
Minimalkan Access DOM
Mengakses elemen DOM dengan JavaScript lambat agar dapat memiliki halaman lebih responsif, Anda harus:
Cache referensi ke elemen diakses
Perbarui node "offline" dan kemudian menambahkannya ke pohon
Hindari memperbaiki tata letak dengan JavaScript
Untuk informasi lebih lanjut memeriksa YUI teater "High Performance Ajax Aplikasi" oleh Julien Lecomte.
Mengembangkan Cerdas Acara Handlers
Kadang-kadang halaman merasa kurang responsif karena terlalu banyak event handler yang melekat pada unsur-unsur yang berbeda dari pohon DOM yang kemudian dieksekusi terlalu sering. Itu sebabnya menggunakan delegasi event adalah pendekatan yang baik. Jika Anda memiliki 10 tombol di dalam div , melampirkan hanya satu event handler untuk pembungkus div, bukan satu handler untuk setiap tombol. Acara meluap sehingga Anda akan dapat menangkap acara tersebut dan mencari tahu tombol mana ia berasal dari.
Anda juga tidak perlu menunggu untuk acara onload untuk mulai melakukan sesuatu dengan pohon DOM. Seringkali semua yang Anda butuhkan adalah elemen yang ingin Anda akses akan tersedia di pohon. Anda tidak perlu menunggu untuk semua gambar yang akan didownload. DOMContentLoaded adalah acara Anda mungkin mempertimbangkan untuk menggunakan bukannya onload, tapi sampai ini tersedia di semua browser, Anda dapat menggunakan YUI acara utilitas, yang memiliki onAvailable metode.
Untuk informasi lebih lanjut memeriksa YUI teater "High Performance Ajax Aplikasi" oleh Julien Lecomte.
Pilih <link> lebih @ import
Salah satu praktik terbaik sebelumnya menyatakan bahwa CSS harus di atas dalam rangka untuk memungkinkan render progresif.
Dalam IE @ import berperilaku sama dengan menggunakan <link> di bagian bawah halaman, jadi yang terbaik untuk tidak menggunakannya.
Hindari Filter
The IE-proprietary AlphaImageLoader penyaring bertujuan untuk memperbaiki masalah dengan semi-transparan benar PNGs warna dalam versi IE <7. Masalah dengan filter ini adalah bahwa hal itu blok rendering dan membeku browser saat gambar sedang didownload. Hal ini juga meningkatkan konsumsi memori dan diterapkan per elemen, bukan per image, sehingga masalah dikalikan.
Pendekatan terbaik adalah untuk menghindari AlphaImageLoader sepenuhnya dan menggunakan PNG8 anggun merendahkan sebaliknya, yang baik-baik saja di IE. Jika Anda benar-benar membutuhkan AlphaImageLoader , gunakan garis bawah hack _filter untuk tidak menghukum Anda IE7 + pengguna.
Optimalkan Images
Setelah desainer ini dilakukan dengan menciptakan gambar untuk halaman web Anda, masih ada beberapa hal yang dapat Anda coba sebelum Anda FTP gambar-gambar ke server web Anda.
Anda dapat memeriksa GIF dan melihat apakah mereka menggunakan ukuran palet yang sesuai dengan jumlah warna dalam gambar. Menggunakan ImageMagick mudah untuk memeriksa menggunakan mengidentifikasi-verbose image.gif Ketika Anda melihat gambar menggunakan 4 warna dan 256 warna "slot" di palet, ada ruang untuk perbaikan.
Cobalah mengubah GIF ke PNG dan melihat apakah ada penghematan a. Lebih sering daripada tidak, ada. Pengembang sering ragu-ragu untuk menggunakan PNGs karena dukungan terbatas dalam browser, tapi ini sekarang menjadi sesuatu dari masa lalu. Satu-satunya masalah adalah alpha-PNG transparansi dalam true color, tapi sekali lagi, GIF tidak warna yang benar dan tidak mendukung transparansi variabel baik. Jadi apa pun yang bisa dilakukan GIF, PNG palet (PNG8) bisa melakukan terlalu (kecuali untuk animasi). Ini hasil perintah ImageMagick sederhana benar-benar aman digunakan PNGs: mengkonversi image.gif image.png "Semua yang kami katakan adalah: Berikan PING Chance!"
Jalankan pngcrush (atau alat optimasi PNG lainnya) pada semua PNGs Anda. Contoh: pngcrush image.png-rem result.png alla-mengurangi-brute
Jalankan jpegtran pada semua file JPEG Anda. Alat ini dapat melakukan operasi JPEG lossless seperti rotasi dan juga dapat digunakan untuk mengoptimalkan dan menghapus komentar dan informasi berguna lainnya (seperti informasi EXIF) dari gambar Anda. jpegtran-copy none-mengoptimalkan-sempurna src.jpg dest.jpg
Optimalkan CSS Sprite
Mengatur gambar dalam sprite horizontal sebagai lawan vertikal biasanya menghasilkan ukuran file yang lebih kecil.
Menggabungkan warna yang sama dalam sprite akan membantu Anda menjaga warna count rendah, idealnya di bawah 256 warna sehingga untuk masuk dalam PNG8 a.
"Jadilah ponsel-friendly" dan tidak meninggalkan kesenjangan besar antara gambar dalam sprite. Ini tidak mempengaruhi ukuran file sebanyak tetapi membutuhkan lebih sedikit memori untuk agen pengguna untuk dekompresi gambar ke peta pixel. 100x100 gambar adalah 10 ribu piksel, di mana 1000x1000 adalah 1 juta piksel
Jangan Skala Gambar dalam HTML
Jangan gunakan gambar yang lebih besar dari yang Anda butuhkan hanya karena Anda dapat mengatur lebar dan tinggi dalam HTML. Jika Anda perlu <img width="100" height="100" src="mycat.jpg" alt="Teman Cat" /> maka gambar Anda (mycat.jpg) harus 100x100px daripada skala bawah gambar 500x500px.
Membuat favicon.ico Kecil dan Cacheable
Favicon.ico adalah gambar yang tetap di root server Anda. Ini adalah kejahatan yang diperlukan karena bahkan jika Anda tidak peduli tentang hal itu browser masih akan meminta itu, jadi lebih baik tidak menanggapi dengan 404 Not Found . Juga karena itu pada server yang sama, cookie akan dikirim setiap kali itu diminta. Gambar ini juga mengganggu urutan download, misalnya di IE ketika Anda meminta komponen tambahan di onload, favicon akan di-download sebelum ini komponen tambahan.
Jadi untuk mengurangi kelemahan memiliki favicon.ico pastikan:
Ini kecil, sebaiknya di bawah 1K.
Set Expires header dengan apa yang Anda merasa nyaman (karena Anda tidak dapat mengubah nama jika Anda memutuskan untuk mengubahnya). Anda mungkin dapat dengan aman mengatur Habis tajuk beberapa bulan ke depan. Anda dapat memeriksa tanggal diubah terakhir favicon.ico Anda saat ini untuk membuat keputusan.
ImageMagick dapat membantu Anda membuat Favicons kecil
Jauhkan Komponen bawah 25K
Pembatasan ini berkaitan dengan fakta bahwa iPhone tidak akan komponen cache yang lebih besar dari 25K. Catatan bahwa ini adalah terkompresi ukuran. Di sinilah minification penting karena gzip saja mungkin tidak cukup.
Untuk informasi lebih lanjut cek " Penelitian Kinerja, Bagian 5: iPhone ynd Bisa - Sehingga Tetap "oleh Wayne Shea dan Tenni Theurer.
Komponen Pack ke dalam Dokumen Multipart
Packing komponen ke dalam dokumen multipart seperti email dengan attachment, ada baiknya Anda mengambil beberapa komponen dengan satu permintaan HTTP (ingat: HTTP request mahal). Bila Anda menggunakan teknik ini, pertama-tama memeriksa apakah user agent mendukungnya (iPhone tidak).
Hindari Kosong Gambar src
Gambar dengan string kosong src atribut terjadi lebih dari satu akan mengharapkan. Ini muncul dalam dua bentuk:
HTML lurus
<img src="">
JavaScript
var img = new Image ();
img.src = "";
Kedua bentuk menyebabkan efek yang sama: Browser membuat permintaan lain ke server Anda.
Internet Explorer membuat permintaan ke direktori di mana halaman berada.
Safari dan Chrome membuat permintaan ke halaman itu sendiri.
Firefox 3 dan versi sebelumnya berperilaku sama seperti Safari dan Chrome, tapi versi 3.5 membahas masalah ini [bug 444931] dan tidak lagi mengirimkan permintaan.
Opera tidak melakukan apa-apa ketika gambar src kosong ditemui.
Mengapa perilaku buruk ini?
Melumpuhkan server Anda dengan mengirimkan sejumlah besar lalu lintas yang tak terduga, terutama untuk halaman yang mendapatkan jutaan tampilan halaman per hari.
Siklus komputasi Server Limbah menghasilkan halaman yang tidak akan pernah dilihat.
Data pengguna mungkin korup. Jika Anda negara pelacakan dalam permintaan, baik oleh cookie atau dengan cara lain, Anda memiliki kemungkinan merusak data. Meskipun permintaan gambar tidak mengembalikan gambar, semua header dibaca dan diterima oleh browser, termasuk semua cookie. Sementara sisa respon dibuang, kerusakan mungkin sudah bisa dilakukan.
Akar penyebab perilaku ini adalah cara bahwa resolusi URI dilakukan dalam browser. Perilaku ini didefinisikan dalam RFC 3986 - Uniform Resource Identifier. Ketika string kosong ditemui sebagai URI, itu dianggap sebagai URI relatif dan diselesaikan sesuai dengan algoritma didefinisikan dalam bagian 5.2. Ini contoh spesifik, string kosong, terdaftar dalam bagian 5.4. Firefox, Safari, dan Chrome semua menyelesaikan string kosong dengan benar sesuai spesifikasi, sementara Internet Explorer menyelesaikan itu salah, ternyata sejalan dengan versi sebelumnya dari spesifikasi, RFC 2396 - Uniform Resource Identifier (ini usang oleh RFC 3986) . Jadi secara teknis, browser melakukan apa yang seharusnya mereka lakukan untuk menyelesaikan URI relatif. Masalahnya adalah bahwa dalam konteks ini, string kosong jelas tidak disengaja.
HTML5 menambah deskripsi tag src atribut untuk menginstruksikan browser untuk tidak membuat permintaan tambahan dalam bagian 4.8.2:
The src atribut harus hadir, dan harus berisi URL yang valid referensi non-interaktif, animasi opsional, sumber daya gambar yang tidak paged atau scripted. Jika basis URI dari elemen adalah sama dengan alamat dokumen, maka nilai src atribut itu tidak harus menjadi string kosong.
Mudah-mudahan, browser tidak akan memiliki masalah ini di masa depan. Sayangnya, tidak ada klausul tersebut untuk <script src=""> dan <link href="">. Mungkin masih ada waktu untuk membuat penyesuaian untuk memastikan bahwa browser tidak sengaja menerapkan perilaku ini.
80% dari waktu respon end-user dihabiskan di front-end. Sebagian besar waktu ini terikat dalam men-download semua komponen di halaman: gambar, stylesheet, script, Flash, dll Mengurangi jumlah komponen pada gilirannya akan mengurangi jumlah permintaan HTTP yang dibutuhkan untuk membuat halaman. Ini adalah kunci untuk halaman lebih cepat.
Salah satu cara untuk mengurangi jumlah komponen dalam halaman adalah untuk menyederhanakan desain halaman. Tapi apakah ada cara untuk membangun halaman dengan konten yang lebih kaya sementara juga mencapai waktu respon yang cepat? Berikut adalah beberapa teknik untuk mengurangi jumlah permintaan HTTP, sementara masih mendukung desain halaman kaya.
File gabungan adalah cara untuk mengurangi jumlah permintaan HTTP dengan menggabungkan semua skrip ke dalam satu naskah, dan juga menggabungkan semua CSS ke stylesheet tunggal. Menggabungkan file lebih menantang ketika script dan stylesheet bervariasi dari halaman ke halaman, tetapi membuat ini bagian dari proses pembebasan Anda meningkatkan waktu respon.
CSS Sprite adalah metode yang disukai untuk mengurangi jumlah permintaan gambar. Menggabungkan gambar latar belakang Anda menjadi gambar tunggal dan menggunakan CSS background-image dan background-position properti untuk menampilkan segmen gambar yang diinginkan.
Peta gambar menggabungkan beberapa gambar menjadi satu gambar. Ukuran keseluruhan adalah sama, tetapi mengurangi jumlah permintaan HTTP mempercepat halaman. Peta gambar hanya bekerja jika gambar yang bersebelahan di halaman, seperti sebuah bar navigasi. Mendefinisikan koordinat peta gambar dapat membosankan dan rawan kesalahan. Menggunakan peta gambar untuk navigasi tidak dapat diakses juga, sehingga tidak dianjurkan.
Gambar Inline menggunakan Data: skema URL untuk menanamkan data gambar dalam halaman yang sebenarnya. Hal ini dapat meningkatkan ukuran dokumen HTML Anda. Menggabungkan gambar inline ke dalam (cached) stylesheet adalah cara untuk mengurangi permintaan HTTP dan menghindari meningkatkan ukuran halaman Anda. Gambar inline belum didukung di semua browser utama.
Mengurangi jumlah permintaan HTTP di halaman Anda adalah tempat untuk memulai. Ini adalah pedoman yang paling penting untuk meningkatkan kinerja untuk pertama kalinya pengunjung. Seperti dijelaskan dalam Tenni Theurer post blog Browser Cache Penggunaan - Exposed , 40-60% dari pengunjung harian ke situs Anda datang dengan cache kosong. Membuat halaman Anda cepat bagi pengunjung pertama kali ini adalah kunci untuk pengalaman pengguna yang lebih baik.
Gunakan Pengiriman Jaringan Konten
Kedekatan pengguna ke server web Anda memiliki dampak pada waktu respon. Menyebarkan konten Anda di beberapa, server secara geografis akan membuat halaman Anda memuat lebih cepat dari perspektif pengguna. Tapi di mana Anda harus mulai?
Sebagai langkah pertama untuk menerapkan konten geografis, jangan mencoba untuk mendesain ulang aplikasi web Anda untuk bekerja dalam arsitektur terdistribusi. Tergantung pada aplikasi, mengubah arsitektur dapat mencakup tugas-tugas yang menakutkan seperti sinkronisasi negara sesi dan mereplikasi database transaksi di Lokasi server. Upaya untuk mengurangi jarak antara pengguna dan konten Anda bisa tertunda oleh, atau tidak pernah lulus, aplikasi ini arsitektur langkah.
Ingat bahwa 80-90% dari waktu respon end-user dihabiskan men-download semua komponen di halaman: gambar, stylesheet, script, Flash, dll ini adalah Kinerja Golden Rule . Daripada memulai dengan tugas yang sulit untuk mendesain ulang arsitektur aplikasi Anda, lebih baik untuk pertama membubarkan konten statis Anda. Hal ini tidak hanya mencapai pengurangan yang lebih besar dalam waktu respon, tapi itu lebih mudah berkat jaringan pengiriman konten.
Sebuah jaringan pengiriman konten (CDN) adalah kumpulan server web didistribusikan di beberapa lokasi untuk memberikan konten yang lebih efisien bagi pengguna. Server yang dipilih untuk menyampaikan konten ke pengguna tertentu biasanya didasarkan pada ukuran jaringan kedekatan. Sebagai contoh, server dengan jaringan paling sedikit hop atau server dengan waktu respon tercepat dipilih.
Beberapa perusahaan Internet besar memiliki CDN mereka sendiri, tapi itu biaya-efektif untuk menggunakan penyedia layanan CDN, seperti Akamai Technologies , EdgeCast , atau level3 . Bagi perusahaan start-up dan situs web pribadi, biaya layanan CDN dapat menjadi penghalang, tetapi sebagai audiens target Anda tumbuh lebih besar dan menjadi lebih global, CDN yang diperlukan untuk mencapai waktu respon yang cepat. Di Yahoo!, properti yang bergerak konten statis dari server web aplikasi mereka ke CDN (baik pihak ke-3 seperti yang disebutkan di atas serta Yahoo sendiri CDN ) meningkatkan waktu respon end-user sebesar 20% atau lebih. Beralih ke CDN adalah perubahan kode yang relatif mudah yang secara dramatis akan meningkatkan kecepatan situs web Anda.
Tambahkan Expires atau Cache-Control header
Ada dua aspek dari aturan ini:
Untuk komponen statis: melaksanakan "Jangan pernah berakhir" kebijakan dengan menetapkan masa depan yang jauh Expires Header
Untuk komponen dinamis: menggunakan sesuai Cache-Control header untuk membantu browser dengan permintaan kondisional
Desain halaman web menjadi makin kaya dan kaya, yang berarti lebih banyak script, stylesheet, gambar, dan Flash di halaman. Baru pertama kali pengunjung ke halaman Anda mungkin harus membuat beberapa permintaan HTTP, tetapi dengan menggunakan Expires header Anda membuat komponen-komponen disimpan di cache. Hal ini untuk menghindari permintaan HTTP yang tidak perlu pada tampilan halaman berikutnya. Habis header yang paling sering digunakan dengan gambar, tetapi mereka harus digunakan pada semua komponen termasuk script, stylesheet, dan komponen Flash.
Browser (dan proxy) menggunakan cache untuk mengurangi jumlah dan ukuran permintaan HTTP, membuat halaman web memuat lebih cepat. Sebuah server web menggunakan Expires header di respon HTTP untuk memberitahu klien berapa lama komponen dapat di-cache. Ini adalah masa depan yang jauh Expires header, memberitahu browser bahwa respons ini tidak akan basi sampai dengan 15 April 2010.
Jika server Anda Apache, gunakan direktif ExpiresDefault untuk menetapkan tanggal kedaluwarsa relatif terhadap tanggal saat ini. Ini contoh dari direktif ExpiresDefault menetapkan Habis tanggal 10 tahun keluar dari waktu permintaan.
Perlu diingat, jika Anda menggunakan masa depan yang jauh Expires header Anda harus mengubah nama file komponen setiap kali perubahan komponen. Di Yahoo! kita sering membuat langkah ini bagian dari proses membangun: sebuah nomor versi tertanam dalam nama file komponen, misalnya, yahoo_2.0.6.js.
Menggunakan masa depan yang jauh Expires header mempengaruhi tampilan halaman setelah pengguna telah mengunjungi situs Anda. Ini tidak berpengaruh pada jumlah permintaan HTTP ketika pengguna mengunjungi situs Anda untuk pertama kalinya dan cache browser kosong. Oleh karena itu dampak dari peningkatan kinerja ini tergantung pada seberapa sering pengguna memukul halaman Anda dengan cache prima. (A "Cache prima" sudah mengandung semua komponen dalam halaman.) Kami mengukur ini di Yahoo! dan menemukan jumlah tampilan halaman dengan cache prima adalah 75-85%. Dengan menggunakan masa depan yang jauh Expires header, Anda meningkatkan jumlah komponen yang di-cache oleh browser dan digunakan kembali pada tampilan halaman berikutnya tanpa mengirimkan satu byte melalui koneksi internet pengguna.
Gzip Komponen
Waktu yang dibutuhkan untuk mentransfer permintaan HTTP dan respon di seluruh jaringan dapat dikurangi secara signifikan oleh keputusan yang dibuat oleh para insinyur front-end. Memang benar bahwa kecepatan bandwidth pengguna akhir, penyedia layanan internet, kedekatan dengan mengintip pertukaran poin, dll berada di luar kendali dari tim pengembangan. Tetapi ada variabel lain yang mempengaruhi waktu respon. Kompresi mengurangi waktu respon dengan mengurangi ukuran dari respon HTTP.
Dimulai dengan HTTP/1.1, web klien menunjukkan dukungan untuk kompresi dengan Accept-Encoding header permintaan HTTP.
Terima-Encoding: gzip, deflate
Jika server web melihat header ini dalam permintaan, mungkin menekan respon menggunakan salah satu metode yang terdaftar oleh klien. Web server memberitahu klien web ini melalui Content-Encoding header di respon.
Content-Encoding: gzip
Gzip adalah metode kompresi yang paling populer dan efektif saat ini. Ini dikembangkan oleh proyek GNU dan distandarisasi oleh RFC 1952 . Satu-satunya format kompresi lain yang mungkin Anda lihat adalah mengempis, tapi itu kurang efektif dan kurang populer.
Gzipping umumnya mengurangi ukuran respon sekitar 70%. Sekitar 90% dari lalu lintas internet saat ini perjalanan melalui browser yang mengklaim mendukung gzip. Jika Anda menggunakan Apache, modul mengkonfigurasi gzip tergantung pada versi Anda: Apache 1.3 menggunakan mod_gzip sementara Apache 2.x menggunakan mod_deflate .
Ada masalah yang diketahui dengan browser dan proxy yang dapat menyebabkan ketidakcocokan dalam apa yang diharapkan browser dan apa yang diterimanya berkaitan dengan konten terkompresi. Untungnya, kasus tepi ini berkurang sebagai penggunaan browser lama menurun. Modul Apache membantu dengan menambahkan sesuai Vary header respon otomatis.
Server memilih apa yang harus gzip berdasarkan tipe file, tetapi biasanya terlalu terbatas dalam apa yang mereka memutuskan untuk kompres. Sebagian besar situs web gzip dokumen HTML mereka. Ini juga berguna untuk gzip script dan stylesheet, tapi banyak situs web lewatkan kesempatan ini. Bahkan, ini berguna untuk kompres respon teks apapun termasuk XML dan JSON. Gambar dan PDF file tidak boleh gzip karena mereka sudah dikompresi. Mencoba untuk gzip mereka tidak hanya limbah CPU tetapi berpotensi dapat meningkatkan ukuran file.
Gzipping banyak jenis file mungkin adalah cara mudah untuk mengurangi berat badan halaman dan mempercepat pengalaman pengguna.
Pasang stylesheet di Puncak
Sementara meneliti kinerja di Yahoo!, kami menemukan bahwa pindah ke stylesheet HEAD dokumen membuat halaman muncul untuk memuat lebih cepat. Hal ini karena menempatkan stylesheet di HEAD memungkinkan halaman untuk membuat progresif.
Insinyur Front-end yang peduli tentang performa ingin halaman untuk memuat progresif, yaitu, kita ingin agar browser untuk menampilkan konten apapun itu secepat mungkin. Hal ini sangat penting untuk halaman dengan banyak konten dan bagi pengguna koneksi internet lambat. Pentingnya memberikan pengguna umpan balik visual, seperti indikator kemajuan, telah diteliti dan didokumentasikan . Dalam kasus kami halaman HTML adalah indikator kemajuan! Ketika browser load halaman semakin header, bar navigasi, logo di bagian atas, dll semua berfungsi sebagai umpan balik visual bagi pengguna yang sedang menunggu untuk halaman. Hal ini meningkatkan pengalaman pengguna secara keseluruhan.
Masalah dengan menempatkan stylesheet dekat bagian bawah dokumen adalah bahwa ia melarang render progresif di banyak browser, termasuk Internet Explorer. Browser ini memblokir render untuk menghindari harus redraw elemen halaman jika gaya mereka berubah. Pengguna yang terjebak melihat halaman putih kosong.
The spesifikasi HTML jelas menyatakan bahwa stylesheet harus dimasukkan dalam HEAD halaman: "Tidak seperti A, [LINK] hanya mungkin muncul di bagian HEAD dokumen, meskipun mungkin muncul beberapa kali." Tak satu pun dari alternatif, layar putih kosong atau flash konten unstyled, yang sepadan dengan risikonya. Solusi optimal adalah mengikuti spesifikasi HTML dan memuat stylesheet di HEAD dokumen.
Masukan Script di Bawah
Masalah yang disebabkan oleh script adalah bahwa mereka memblokir paralel download. The HTTP/1.1 spesifikasi menunjukkan bahwa browser men-download tidak lebih dari dua komponen secara paralel per hostname. Jika Anda melayani gambar Anda dari beberapa hostname, Anda bisa mendapatkan lebih dari dua downloads terjadi secara paralel. Sementara naskah adalah men-download, namun, browser tidak akan memulai download lain, bahkan pada nama host yang berbeda.
Dalam beberapa situasi tidak mudah untuk memindahkan script ke bawah. Jika, misalnya, script menggunakan document.write untuk memasukkan bagian dari isi halaman, tidak bisa bergerak lebih rendah di halaman. Ada juga mungkin scoping masalah. Dalam banyak kasus, ada cara untuk solusi situasi ini.
Sebuah saran alternatif yang sering muncul adalah dengan menggunakan script ditangguhkan. The DEFER atribut menunjukkan bahwa script tidak mengandung document.write, dan petunjuk untuk browser yang mereka dapat terus rendering. Sayangnya, Firefox tidak mendukung DEFER atribut. Di Internet Explorer, script dapat ditangguhkan, tetapi tidak sebanyak yang diinginkan. Jika script bisa ditunda, juga dapat dipindahkan ke bagian bawah halaman. Itu akan membuat halaman web Anda memuat lebih cepat.
Hindari Expressions CSS
Ekspresi CSS adalah kuat (dan berbahaya) cara untuk mengatur properti CSS dinamis. Mereka didukung di Internet Explorer dimulai dengan versi 5, tetapi usang dimulai dengan IE8 . Sebagai contoh, warna latar belakang dapat diatur untuk bergantian setiap jam menggunakan ekspresi CSS:
background-color: ekspresi (. (new Date ()) getHours ()% 2 "# B8D4FF":? "# F08A00");
Seperti ditunjukkan di sini, ekspresi metode menerima ekspresi JavaScript. Properti CSS diatur dengan hasil evaluasi ekspresi JavaScript. The ekspresi Metode diabaikan oleh browser lain, sehingga sangat berguna untuk pengaturan properti di Internet Explorer diperlukan untuk menciptakan pengalaman yang konsisten di seluruh browser.
Masalah dengan ekspresi adalah bahwa mereka dievaluasi lebih sering daripada kebanyakan orang harapkan. Bukan saja mereka dievaluasi saat halaman diberikan dan ukurannya, tetapi juga saat halaman menggulir dan bahkan ketika pengguna menggerakkan mouse di atas halaman. Menambahkan counter untuk ekspresi CSS memungkinkan kita untuk melacak kapan dan seberapa sering ekspresi CSS dievaluasi. Menggerakkan mouse di sekitar halaman dengan mudah dapat menghasilkan lebih dari 10.000 evaluasi.
Salah satu cara untuk mengurangi jumlah kali ekspresi CSS Anda dievaluasi adalah dengan menggunakan ekspresi satu kali, dimana pertama kalinya ekspresi dievaluasi set properti gaya ke nilai eksplisit, yang menggantikan ekspresi CSS. Jika properti gaya harus diatur secara dinamis sepanjang hidup halaman, menggunakan event handler bukan ekspresi CSS adalah sebuah pendekatan alternatif. Jika Anda harus menggunakan ekspresi CSS, ingat bahwa mereka dapat dievaluasi ribuan kali dan bisa mempengaruhi kinerja halaman Anda.
Membuat JavaScript dan CSS External
Banyak aturan kinerja ini berurusan dengan bagaimana komponen eksternal dikelola. Namun, sebelum pertimbangan ini muncul Anda harus mengajukan pertanyaan yang lebih mendasar: Haruskah JavaScript dan CSS terkandung dalam file eksternal, atau inline dalam halaman itu sendiri?
Menggunakan file eksternal di dunia nyata umumnya menghasilkan halaman dengan lebih cepat karena file-file JavaScript dan CSS cache oleh browser. JavaScript dan CSS yang inline dalam dokumen HTML mendapatkan download setiap kali dokumen HTML diminta. Hal ini akan mengurangi jumlah permintaan HTTP yang diperlukan, tetapi meningkatkan ukuran dokumen HTML. Di sisi lain, jika JavaScript dan CSS dalam file eksternal cache oleh browser, ukuran dokumen HTML berkurang tanpa meningkatkan jumlah permintaan HTTP.
Faktor kunci, kemudian, adalah frekuensi yang JavaScript eksternal dan komponen CSS cache relatif terhadap jumlah dokumen HTML yang diminta. Faktor ini, meskipun sulit untuk mengukur, dapat diukur dengan menggunakan berbagai metrik. Jika pengguna di situs Anda memiliki beberapa tampilan halaman per sesi dan banyak halaman Anda kembali menggunakan script dan stylesheet yang sama, ada potensi manfaat lebih besar dari file eksternal cache.
Banyak situs web jatuh di tengah metrik ini. Untuk situs-situs tersebut, solusi terbaik umumnya adalah untuk menyebarkan JavaScript dan CSS sebagai file eksternal. Satu-satunya pengecualian di mana inlining lebih baik adalah dengan halaman rumah, seperti halaman depan Yahoo! 's dan My Yahoo! . Halaman rumah yang memiliki sedikit (mungkin hanya satu) tampilan halaman per sesi mungkin menemukan bahwa inlining JavaScript dan CSS hasil dalam waktu respon end-user lebih cepat.
Untuk halaman depan yang biasanya yang pertama dari banyak tampilan halaman, ada teknik yang memanfaatkan pengurangan permintaan HTTP yang menyediakan inlining, serta manfaat caching dicapai melalui menggunakan file eksternal. Salah satu teknik tersebut adalah untuk inline JavaScript dan CSS di halaman depan, tapi secara dinamis men-download file eksternal setelah halaman selesai loading. Halaman berikutnya akan referensi file eksternal yang harus berada dalam cache browser.
Mengurangi DNS lookup
Domain Name System (DNS) memetakan nama host ke alamat IP, seperti buku telepon memetakan nama orang ke nomor telepon mereka. Ketika Anda mengetik www.yahoo.com ke browser Anda, penyelesai DNS dihubungi oleh browser kembali alamat IP yang server. DNS memiliki biaya. Ini biasanya memakan waktu 20-120 milidetik untuk DNS lookup alamat IP untuk nama host yang diberikan. Browser tidak dapat men-download apa pun dari nama host ini sampai lookup DNS selesai.
Lookup DNS cache untuk kinerja yang lebih baik. Caching ini dapat terjadi pada server caching khusus, dikelola oleh jaringan ISP atau lokal pengguna daerah, tetapi ada juga caching yang terjadi pada komputer pengguna individu. Informasi DNS tetap dalam DNS cache sistem operasi ("layanan Klien DNS" pada Microsoft Windows). Kebanyakan browser memiliki cache mereka sendiri, terpisah dari cache sistem operasi. Selama browser menyimpan catatan DNS dalam cache sendiri, itu tidak mengganggu sistem operasi dengan permintaan untuk catatan.
Internet Explorer cache DNS lookups selama 30 menit secara default, sebagaimana ditentukan oleh DnsCacheTimeout pengaturan registri. Firefox cache DNS lookups selama 1 menit, yang dikendalikan oleh network.dnsCacheExpiration pengaturan konfigurasi. (Fasterfox perubahan ini untuk 1 jam.)
Ketika cache DNS klien kosong (baik untuk browser dan sistem operasi), jumlah pencarian DNS adalah sama dengan jumlah hostname unik dalam halaman web. Ini termasuk nama host yang digunakan dalam URL halaman, gambar, file naskah, stylesheet, obyek Flash, dll Mengurangi jumlah hostname unik mengurangi jumlah pencarian DNS.
Mengurangi jumlah hostname unik memiliki potensi untuk mengurangi jumlah paralel download yang berlangsung di halaman. Menghindari lookup DNS memotong waktu respon, tapi mengurangi paralel download dapat meningkatkan waktu respon. Pedoman saya adalah untuk membagi komponen-komponen ini di setidaknya dua tetapi tidak lebih dari empat hostname. Hal ini menghasilkan kompromi yang baik antara mengurangi DNS lookup dan memungkinkan tingkat tinggi paralel download.
Mengecilkan JavaScript dan CSS
Minification adalah praktek menghapus karakter yang tidak perlu dari kode untuk mengurangi ukuran demikian meningkatkan beban kali nya. Ketika kode minified semua komentar dihapus, serta karakter spasi yang tidak diperlukan (spasi, baris baru, dan tab). Dalam kasus JavaScript, ini meningkatkan kinerja waktu respon karena ukuran file yang didownload berkurang. Dua alat yang populer untuk minifying kode JavaScript yang JSMin dan YUI Compressor . The YUI kompresor juga dapat mengecilkan CSS.
Kebingungan optimasi alternatif yang dapat diterapkan pada kode sumber. Ini lebih kompleks daripada minification dan dengan demikian lebih mungkin untuk menghasilkan bug sebagai akibat dari kebingungan langkah sendiri. Dalam sebuah survei dari sepuluh situs web top AS, minification mencapai pengurangan ukuran 21% versus 25% untuk kebingungan. Meskipun kebingungan memiliki pengurangan ukuran yang lebih tinggi, minifying JavaScript kurang berisiko.
Selain minifying skrip eksternal dan gaya, inline <script> dan <style> blok dapat dan juga harus minified. Bahkan jika Anda gzip script Anda dan gaya, minifying mereka masih akan mengurangi ukuran sebesar 5% atau lebih. Seperti penggunaan dan ukuran JavaScript dan CSS meningkat, sehingga akan penghematan yang diperoleh dengan minifying kode Anda.
Hindari Redirects
Pengalihan yang dicapai dengan menggunakan 301 dan 302 kode status. Berikut ini adalah contoh dari header HTTP dalam respon 301:
HTTP/1.1 301 Moved Permanently
Lokasi: http://example.com/newuri
Content-Type: text / html
Browser secara otomatis membawa pengguna ke URL yang ditentukan dalam Lokasi lapangan. Semua informasi yang diperlukan untuk redirect adalah dalam header. Tubuh respon biasanya kosong. Meskipun nama mereka, baik 301 maupun 302 respon cache dalam praktek kecuali header tambahan, seperti Habis atau Cache-Control , menunjukkan seharusnya. Meta tag refresh dan JavaScript cara lain untuk mengarahkan pengguna ke URL yang berbeda, tetapi jika Anda harus melakukan redirect, teknik yang lebih disukai adalah dengan menggunakan kode status HTTP 3xx standar, terutama untuk memastikan tombol kembali bekerja dengan benar.
Hal utama yang perlu diingat adalah bahwa pengalihan memperlambat pengalaman pengguna. Memasukkan redirect antara pengguna dan dokumen HTML menunda segala sesuatu di halaman karena tidak ada dalam halaman dapat diberikan dan tidak ada komponen dapat mulai didownload sampai dokumen HTML telah tiba.
Salah satu pengalihan paling boros sering terjadi dan pengembang web umumnya tidak menyadari hal itu. Hal ini terjadi ketika spasi (/) hilang dari URL yang harus dinyatakan memiliki satu. Misalnya, akan http://astrology.yahoo.com/astrology hasil dalam 301 tanggapan yang berisi redirect ke http://astrology.yahoo.com/astrology/ (perhatikan ditambahkan membuntuti slash). Ini diperbaiki di Apache dengan menggunakan Alias atau mod_rewrite , atau DirectorySlash direktif jika Anda menggunakan penangan Apache.
Menghubungkan situs web lama ke yang baru adalah penggunaan umum lain untuk pengalihan. Lainnya termasuk menghubungkan bagian yang berbeda dari sebuah situs web dan mengarahkan pengguna berdasarkan kondisi tertentu (jenis browser, jenis account pengguna, dll). Menggunakan redirect untuk menghubungkan dua situs web sederhana dan memerlukan sedikit coding tambahan. Meski menggunakan pengalihan dalam situasi seperti ini mengurangi kompleksitas untuk pengembang, akan merusak pengalaman pengguna. Alternatif untuk penggunaan ini pengalihan termasuk menggunakan Alias dan mod_rewrite jika dua jalur kode yang di-host pada server yang sama. Jika perubahan nama domain adalah penyebab menggunakan pengalihan, alternatif adalah untuk menciptakan sebuah CNAME (catatan DNS yang menciptakan alias menunjuk dari satu nama domain yang lain) dalam kombinasi dengan Alias atau mod_rewrite .
Remove Scripts Duplikat
Sungguh menyakitkan kinerja untuk menyertakan file JavaScript yang sama dua kali dalam satu halaman. Hal ini tidak biasa seperti yang Anda bayangkan. Sebuah tinjauan dari sepuluh situs web top AS menunjukkan bahwa dua dari mereka mengandung script digandakan. Dua faktor utama meningkatkan kemungkinan naskah yang digandakan dalam satu halaman web: ukuran tim dan jumlah skrip. Ketika itu tidak terjadi, duplikat script melukai kinerja dengan menciptakan permintaan HTTP yang tidak perlu dan terbuang JavaScript eksekusi.
Permintaan HTTP yang tidak perlu terjadi di Internet Explorer, tapi tidak di Firefox. Di Internet Explorer, jika skrip eksternal termasuk dua kali dan tidak disimpan di cache, itu menghasilkan dua permintaan HTTP selama loading halaman. Bahkan jika script disimpan di cache, permintaan HTTP tambahan terjadi ketika pengguna reload halaman.
Selain menghasilkan permintaan HTTP boros, waktu terbuang mengevaluasi script beberapa kali. Eksekusi JavaScript berlebihan ini terjadi di kedua Firefox dan Internet Explorer, terlepas dari apakah script disimpan di cache.
Salah satu cara untuk menghindari sengaja termasuk script yang sama dua kali adalah untuk menerapkan modul manajemen naskah dalam sistem template Anda. Cara khas untuk memasukkan script adalah dengan menggunakan tag SCRIPT di halaman HTML Anda.
<script type="text/javascript" src="menu_1.0.17.js"> </ script>
Sebuah alternatif dalam PHP akan membuat fungsi yang disebut insertScript .
<? Php insertScript ("menu.js")>
Selain mencegah script yang sama dari yang dimasukkan beberapa kali, fungsi ini bisa menangani masalah lain dengan script, seperti ketergantungan memeriksa dan menambahkan nomor versi untuk nama file script untuk mendukung masa depan yang jauh Expires header.
top | membahas aturan ini
Konfigurasi ETags
Tag Entity (ETags) adalah mekanisme bahwa server web dan browser digunakan untuk menentukan apakah komponen dalam cache browser sesuai dengan satu di server asal. (An "entitas" adalah kata lain "komponen": gambar, script, stylesheet, dll) ETags ditambahkan untuk menyediakan mekanisme untuk memvalidasi entitas yang lebih fleksibel dibandingkan dengan tanggal modifikasi terakhir. Sebuah ETag adalah string yang secara unik mengidentifikasi versi tertentu dari sebuah komponen. Satu-satunya kendala Format adalah bahwa string dikutip. Server asal menentukan ETag komponen yang menggunakan ETag header respon.
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Desember 2006 03:03:59 GMT
ETag: "10c24bc-4AB-457e1c1f"
Content-Length: 12195
Kemudian, jika browser harus memvalidasi komponen, menggunakan Jika-Tidak-Match header untuk lulus ETag kembali ke server asal. Jika ETags cocok, kode status 304 dikembalikan mengurangi respon oleh 12195 byte untuk contoh ini.
GET / i / yahoo.gif HTTP/1.1
Host: us.yimg.com
Jika-Diubah-Sejak: Tue, 12 Desember 2006 03:03:59 GMT
Jika-Tidak-Match: "10c24bc-4AB-457e1c1f"
HTTP/1.1 304 Not Modified
Masalah dengan ETags adalah bahwa mereka biasanya dibangun menggunakan atribut yang membuat mereka unik ke server hosting situs tertentu. ETags tidak akan cocok bila browser mendapat komponen asli dari satu server dan kemudian mencoba untuk memvalidasi komponen yang pada server yang berbeda, situasi yang terlalu umum pada situs Web yang menggunakan sekelompok server untuk menangani permintaan. Secara default, baik Apache dan IIS menanamkan data dalam ETag yang secara dramatis mengurangi kemungkinan uji validitas berhasil di situs web dengan beberapa server.
The ETag format untuk Apache 1.3 dan 2.x adalah inode-size-timestamp . Meskipun file yang diberikan mungkin berada di direktori yang sama di beberapa server, dan memiliki ukuran file yang sama, perizinan, timestamp, dan lain-lain, inode yang berbeda dari satu server ke yang berikutnya.
IIS 5.0 dan 6.0 memiliki masalah yang sama dengan ETags. Format untuk ETags pada IIS adalah Filetimestamp: ChangeNumber . Sebuah ChangeNumber adalah counter digunakan untuk melacak perubahan konfigurasi IIS. Ini tidak mungkin bahwa ChangeNumber adalah sama di semua server IIS di balik situs web.
Hasil akhirnya adalah ETags dihasilkan oleh Apache dan IIS untuk komponen yang sama persis tidak akan cocok dari satu server ke yang lain. Jika ETags tidak cocok, pengguna tidak menerima kecil, cepat 304 respon yang ETags dirancang untuk, melainkan, mereka akan mendapatkan 200 respon normal bersama dengan semua data untuk komponen. Jika Anda meng-host situs web Anda hanya pada satu server, ini bukan masalah. Tapi jika Anda memiliki beberapa server hosting situs web Anda, dan Anda menggunakan Apache atau IIS dengan konfigurasi ETag default, pengguna mendapatkan halaman lambat, server Anda telah beban yang lebih tinggi, Anda mengkonsumsi bandwidth yang lebih besar, dan proxy aren ' t caching konten Anda secara efisien. Bahkan jika komponen Anda memiliki masa depan yang jauh Expires header, permintaan GET bersyarat masih dibuat setiap kali pengguna hits Reload atau Refresh.
Jika Anda tidak mengambil keuntungan dari model validasi yang fleksibel yang memberikan ETags, lebih baik untuk hanya menghapus ETag sama sekali. The Last-Modified header yang memvalidasi berdasarkan timestamp komponen. Dan menghapus ETag mengurangi ukuran header HTTP baik dalam respon dan permintaan berikutnya. Ini Artikel Dukungan Microsoft menjelaskan cara menghapus ETags. Dalam Apache, hal ini dilakukan dengan hanya menambahkan baris berikut ke file konfigurasi Apache Anda:
FileETag none
Buat Ajax Cacheable
Salah satu manfaat yang dikutip dari Ajax adalah bahwa ia menyediakan umpan balik instan kepada pengguna karena permintaan informasi asynchronously dari web server backend. Namun, dengan menggunakan Ajax ada jaminan bahwa pengguna tidak akan memutar-mutar ibu jari menunggu orang JavaScript dan XML tanggapan asynchronous untuk kembali. Dalam banyak aplikasi, apakah atau tidak pengguna disimpan menunggu tergantung pada seberapa Ajax digunakan. Misalnya, dalam klien email berbasis web pengguna akan terus menunggu hasil dari permintaan Ajax untuk menemukan semua pesan email yang sesuai dengan kriteria pencarian mereka. Sangat penting untuk diingat bahwa "asynchronous" tidak berarti "seketika".
Untuk meningkatkan kinerja, penting untuk mengoptimalkan tanggapan Ajax ini. Cara yang paling penting untuk meningkatkan kinerja Ajax adalah untuk membuat tanggapan disimpan di cache, seperti dibahas dalam Tambah sebuah Habis atau Cache-Control header . Beberapa aturan lain juga berlaku untuk Ajax:
Gzip Komponen
Mengurangi DNS lookup
Mengecilkan JavaScript
Hindari Redirects
Konfigurasi ETags
Mari kita lihat sebuah contoh. Sebuah Web 2.0 email client mungkin menggunakan Ajax untuk men-download buku alamat pengguna untuk autocompletion. Jika pengguna belum diubah buku alamat nya sejak terakhir kali dia menggunakan aplikasi web email, respon buku alamat sebelumnya dapat dibaca dari cache jika respon Ajax dibuat disimpan di cache dengan masa depan Habis atau sundulan Cache-Control. Browser harus diberitahu kapan harus menggunakan cache sebelumnya respon buku alamat dibandingkan meminta yang baru. Hal ini dapat dilakukan dengan menambahkan timestamp ke buku alamat URL Ajax menunjukkan waktu terakhir pengguna diubah buku alamat nya, misalnya, & t = 1190241612 . Jika buku alamat belum dimodifikasi sejak download terakhir, timestamp akan sama dan buku alamat akan dibaca dari cache browser menghilangkan HTTP jemput ekstra. Jika pengguna telah diubah buku alamat nya, timestamp memastikan URL baru tidak sesuai dengan respon cache, dan browser akan meminta entri buku alamat diperbarui.
Meskipun tanggapan Ajax Anda dibuat secara dinamis, dan mungkin hanya berlaku untuk satu pengguna, mereka masih dapat di-cache. Melakukan hal ini akan membuat Anda Web 2.0 aplikasi lebih cepat.
Siram Buffer Dini
Ketika pengguna meminta halaman, itu bisa berlangsung dari 200 sampai 500ms untuk server backend untuk menjahit bersama halaman HTML. Selama waktu ini, browser idle karena menunggu data tiba. Dalam PHP Anda memiliki fungsi flush () . Hal ini memungkinkan Anda untuk mengirim respon HTML parsial siap Anda ke browser sehingga browser dapat mulai mengambil komponen sementara backend Anda sibuk dengan sisa halaman HTML. Manfaat ini terutama terlihat pada backends sibuk atau frontends cahaya.
Tempat yang baik untuk mempertimbangkan pembilasan tepat setelah KEPALA karena HTML untuk kepala biasanya lebih mudah untuk memproduksi dan memungkinkan Anda untuk menyertakan CSS dan file JavaScript untuk browser untuk mulai mengambil secara paralel sementara backend masih memproses.
Contoh:
... <-! - Css, js>
</ head> <? php flush ();>
<body>
<! - konten -> ...
Yahoo! pencarian memelopori penelitian dan pengujian pengguna nyata untuk membuktikan manfaat menggunakan teknik ini.
puncak
Gunakan GET untuk AJAX Permintaan
The Yahoo! Mail tim menemukan bahwa ketika menggunakan XMLHttpRequest , POST diimplementasikan dalam browser sebagai proses dua langkah: mengirim header pertama, kemudian mengirimkan data. Jadi yang terbaik untuk menggunakan GET, yang hanya membutuhkan waktu satu paket TCP untuk mengirimkan (kecuali jika Anda memiliki banyak cookie). Panjang maksimum URL di IE adalah 2K, jadi jika Anda mengirim data lebih dari 2K Anda mungkin tidak dapat menggunakan GET.
Sebuah sisi menarik mempengaruhi adalah bahwa POST tanpa benar-benar mem-posting data apapun berperilaku seperti GET. Berdasarkan spesifikasi HTTP , GET dimaksudkan untuk mengambil informasi, sehingga masuk akal (semantik) untuk menggunakan GET ketika Anda hanya meminta data, sebagai lawan mengirim data yang akan disimpan server-side.
puncak
Post-beban Komponen
Anda dapat melihat lebih dekat pada halaman Anda dan tanyakan pada diri sendiri: "Apa yang benar-benar diperlukan untuk membuat halaman awalnya?". Sisa isi dan komponen bisa menunggu.
JavaScript adalah calon yang ideal untuk membelah sebelum dan sesudah event onload. Sebagai contoh jika Anda memiliki kode JavaScript dan perpustakaan yang melakukan drag and drop dan animasi, mereka bisa menunggu, karena menyeret elemen pada halaman muncul setelah rendering awal. Tempat-tempat lain untuk mencari calon untuk pasca pemuatan termasuk konten tersembunyi (konten yang muncul setelah tindakan pengguna) dan gambar di bawah flip.
Alat untuk membantu Anda dalam usaha Anda: YUI Gambar Loader memungkinkan Anda untuk menunda gambar di bawah flip dan YUI Dapatkan utilitas adalah cara mudah untuk memasukkan JS dan CSS on the fly. Sebagai contoh di alam liar lihatlah Yahoo! Halaman dengan Panel Bersih Firebug diaktifkan.
Ada baiknya bila tujuan kinerja yang sejalan dengan praktik terbaik pengembangan web lainnya. Dalam hal ini, gagasan peningkatan progresif mengatakan bahwa JavaScript, bila didukung, dapat meningkatkan pengalaman pengguna tetapi Anda harus memastikan halaman bekerja bahkan tanpa JavaScript. Jadi setelah Anda memastikan halaman bekerja dengan baik, Anda dapat meningkatkan dengan beberapa script pasca-loaded yang memberikan Anda lebih banyak bel dan peluit seperti drag and drop dan animasi.
puncak
Preload Komponen
Preload mungkin terlihat seperti kebalikan dari pasca-beban, tetapi sebenarnya memiliki tujuan yang berbeda. Dengan preloading komponen Anda dapat mengambil keuntungan dari waktu browser idle dan komponen permintaan (seperti gambar, gaya dan skrip) yang Anda perlukan di masa depan. Dengan cara ini ketika pengguna mengunjungi halaman berikutnya, Anda bisa memiliki sebagian besar komponen sudah dalam cache dan halaman Anda akan memuat lebih cepat bagi pengguna.
Sebenarnya ada beberapa jenis preloading:
Unconditional preload - segera setelah kebakaran onload, Anda terus maju dan mengambil beberapa komponen tambahan. Periksa google.com untuk contoh bagaimana gambar sprite diminta onload. Gambar sprite ini tidak diperlukan pada homepage google.com, tetapi dibutuhkan pada halaman hasil pencarian berturut-turut.
Conditional preload - didasarkan pada tindakan pengguna Anda membuat tebakan mana pengguna menuju berikutnya dan preload sesuai. Pada search.yahoo.com Anda dapat melihat bagaimana beberapa komponen tambahan yang diminta setelah Anda mulai mengetik di kotak input.
Diduga preload - preload terlebih dahulu sebelum meluncurkan desain ulang. Sering terjadi setelah desain ulang yang Anda dengar: "Situs baru yang keren, tapi itu lebih lambat dari sebelumnya". Sebagian dari masalah dapat bahwa pengguna mengunjungi situs lama Anda dengan cache penuh, tapi yang baru selalu merupakan pengalaman tembolok kosong. Anda dapat mengurangi efek samping ini dengan preloading beberapa komponen bahkan sebelum Anda meluncurkan desain ulang. Situs lama Anda dapat menggunakan waktu browser idle dan gambar permintaan dan skrip yang akan digunakan oleh situs baru
puncak
Kurangi Jumlah DOM Elements
Halaman kompleks berarti lebih byte untuk men-download dan itu juga berarti akses DOM lambat dalam JavaScript. Itu membuat perbedaan jika Anda loop melalui 500 atau 5000 elemen DOM pada halaman bila Anda ingin menambahkan event handler misalnya.
Sejumlah tinggi elemen DOM dapat merupakan gejala bahwa ada sesuatu yang harus diperbaiki dengan markup halaman tanpa harus menghapus konten. Apakah Anda menggunakan tabel bersarang untuk keperluan tata letak? Apakah Anda melemparkan lebih <div> s hanya untuk memperbaiki masalah tata letak? Mungkin ada cara yang lebih baik dan lebih semantik benar untuk melakukan markup Anda.
Sebuah membantu dengan layout adalah utilitas YUI CSS : grids.css dapat membantu Anda dengan tata letak keseluruhan, fonts.css dan reset.css dapat membantu Anda mengupas format default browser. Ini adalah kesempatan untuk memulai segar dan berpikir tentang markup Anda, misalnya menggunakan <div> s hanya ketika masuk akal semantis, dan bukan karena membuat baris baru.
Jumlah elemen DOM mudah untuk menguji, ketik saja konsol Firebug: document.getElementsByTagName ('*') panjang.
Dan berapa banyak elemen DOM terlalu banyak? Periksa halaman serupa lainnya yang memiliki markup yang baik. Misalnya Yahoo! Halaman adalah halaman cukup sibuk dan masih di bawah 700 elemen (tag HTML).
Komponen Berpisah Di Domain
Memisahkan komponen memungkinkan Anda untuk memaksimalkan paralel download. Pastikan Anda menggunakan tidak lebih dari 2-4 domain karena hukuman lookup DNS. Misalnya, Anda dapat meng-host HTML dan konten dinamis pada www.example.org dan membagi komponen statis antara static1.example.org dan static2.example.org
Untuk informasi lebih lanjut memeriksa " Memaksimalkan Paralel Download di Carpool Lane "oleh Tenni Theurer dan Patty Chi.
Minimalkan Jumlah iframe
Iframe memungkinkan dokumen HTML yang akan dimasukkan dalam dokumen induk. Sangat penting untuk memahami bagaimana iframe bekerja sehingga mereka dapat digunakan secara efektif.
<iframe> Pro:
Membantu dengan konten pihak ketiga lambat seperti lencana dan iklan
Keamanan sandbox
Download script secara paralel
<iframe> kontra:
Mahal bahkan jika kosong
Halaman Blok onload
Non-semantik
Tidak ada 404s
Permintaan HTTP mahal jadi membuat permintaan HTTP dan mendapatkan respon yang tidak berguna (yaitu 404 Not Found) sama sekali tidak perlu dan akan memperlambat pengalaman pengguna tanpa imbalan apapun.
Beberapa situs memiliki 404s bermanfaat "Did you mean X?", Yang sangat bagus untuk pengalaman pengguna tetapi juga limbah sumber daya server (seperti basis data, dll). Terutama buruk adalah ketika link ke JavaScript eksternal yang salah dan hasilnya adalah 404. Pertama, unduhan ini akan memblokir paralel download. Selanjutnya browser mungkin mencoba untuk mengurai tubuh 404 respon seolah-olah kode JavaScript, mencoba untuk menemukan sesuatu yang dapat digunakan di dalamnya.
Mengurangi Cookie Ukuran
Cookie HTTP digunakan untuk berbagai alasan seperti otentikasi dan personalisasi. Informasi tentang cookie dipertukarkan dalam header HTTP antara server web dan browser. Sangat penting untuk menjaga ukuran cookie serendah mungkin untuk meminimalkan dampak pada waktu respon pengguna.
Untuk informasi lebih lanjut, periksa "Ketika Cookie runtuh" oleh Tenni Theurer dan Patty Chi. The dibawa pulang dari penelitian ini:
Menghilangkan cookies yang tidak perlu
Jauhkan ukuran kue serendah mungkin untuk meminimalkan dampak pada waktu respon pengguna
Berhati-hati pengaturan cookie pada tingkat domain yang sesuai sehingga sub-domain lainnya tidak terpengaruh
Menetapkan tanggal Habis tepat. Sebuah sebelumnya Habis tanggal atau tidak menghapus cookie cepat, meningkatkan waktu respon pengguna
Gunakan Domain Cookie bebas untuk Komponen
Ketika browser membuat permintaan untuk gambar statis dan mengirimkan cookies bersama-sama dengan permintaan, server tidak memiliki gunakan untuk cookie. Jadi mereka hanya membuat lalu lintas jaringan tanpa alasan yang baik. Anda harus memastikan komponen statis diminta dengan permintaan cookie-bebas. Membuat subdomain dan tuan rumah semua komponen statis Anda di sana.
Jika domain Anda adalah www.example.org , Anda dapat meng-host komponen statis Anda pada static.example.org . Namun, jika Anda sudah mengatur cookie pada top-level domain example.org sebagai lawan www.example.org , maka semua permintaan untuk static.example.org akan termasuk orang-orang cookies. Dalam hal ini, Anda dapat membeli domain baru, tuan komponen statis Anda di sana, dan menjaga domain ini cookie-bebas. Yahoo! menggunakan yimg.com , YouTube menggunakan ytimg.com , Amazon menggunakan gambar-amazon.com dan sebagainya.
Manfaat lain hosting komponen statis pada domain cookie-bebas adalah bahwa beberapa proxy mungkin menolak untuk cache komponen yang diminta dengan cookie. Pada catatan terkait, jika Anda bertanya-tanya apakah Anda harus menggunakan example.org atau www.example.org untuk halaman rumah Anda, mempertimbangkan dampak kue. Menghilangkan www membuat Anda tidak punya pilihan selain untuk menulis cookie untuk *. example.org , jadi untuk alasan kinerja yang terbaik untuk menggunakan subdomain www dan menulis cookie ke subdomain tersebut.
Minimalkan Access DOM
Mengakses elemen DOM dengan JavaScript lambat agar dapat memiliki halaman lebih responsif, Anda harus:
Cache referensi ke elemen diakses
Perbarui node "offline" dan kemudian menambahkannya ke pohon
Hindari memperbaiki tata letak dengan JavaScript
Untuk informasi lebih lanjut memeriksa YUI teater "High Performance Ajax Aplikasi" oleh Julien Lecomte.
Mengembangkan Cerdas Acara Handlers
Kadang-kadang halaman merasa kurang responsif karena terlalu banyak event handler yang melekat pada unsur-unsur yang berbeda dari pohon DOM yang kemudian dieksekusi terlalu sering. Itu sebabnya menggunakan delegasi event adalah pendekatan yang baik. Jika Anda memiliki 10 tombol di dalam div , melampirkan hanya satu event handler untuk pembungkus div, bukan satu handler untuk setiap tombol. Acara meluap sehingga Anda akan dapat menangkap acara tersebut dan mencari tahu tombol mana ia berasal dari.
Anda juga tidak perlu menunggu untuk acara onload untuk mulai melakukan sesuatu dengan pohon DOM. Seringkali semua yang Anda butuhkan adalah elemen yang ingin Anda akses akan tersedia di pohon. Anda tidak perlu menunggu untuk semua gambar yang akan didownload. DOMContentLoaded adalah acara Anda mungkin mempertimbangkan untuk menggunakan bukannya onload, tapi sampai ini tersedia di semua browser, Anda dapat menggunakan YUI acara utilitas, yang memiliki onAvailable metode.
Untuk informasi lebih lanjut memeriksa YUI teater "High Performance Ajax Aplikasi" oleh Julien Lecomte.
Pilih <link> lebih @ import
Salah satu praktik terbaik sebelumnya menyatakan bahwa CSS harus di atas dalam rangka untuk memungkinkan render progresif.
Dalam IE @ import berperilaku sama dengan menggunakan <link> di bagian bawah halaman, jadi yang terbaik untuk tidak menggunakannya.
Hindari Filter
The IE-proprietary AlphaImageLoader penyaring bertujuan untuk memperbaiki masalah dengan semi-transparan benar PNGs warna dalam versi IE <7. Masalah dengan filter ini adalah bahwa hal itu blok rendering dan membeku browser saat gambar sedang didownload. Hal ini juga meningkatkan konsumsi memori dan diterapkan per elemen, bukan per image, sehingga masalah dikalikan.
Pendekatan terbaik adalah untuk menghindari AlphaImageLoader sepenuhnya dan menggunakan PNG8 anggun merendahkan sebaliknya, yang baik-baik saja di IE. Jika Anda benar-benar membutuhkan AlphaImageLoader , gunakan garis bawah hack _filter untuk tidak menghukum Anda IE7 + pengguna.
Optimalkan Images
Setelah desainer ini dilakukan dengan menciptakan gambar untuk halaman web Anda, masih ada beberapa hal yang dapat Anda coba sebelum Anda FTP gambar-gambar ke server web Anda.
Anda dapat memeriksa GIF dan melihat apakah mereka menggunakan ukuran palet yang sesuai dengan jumlah warna dalam gambar. Menggunakan ImageMagick mudah untuk memeriksa menggunakan mengidentifikasi-verbose image.gif Ketika Anda melihat gambar menggunakan 4 warna dan 256 warna "slot" di palet, ada ruang untuk perbaikan.
Cobalah mengubah GIF ke PNG dan melihat apakah ada penghematan a. Lebih sering daripada tidak, ada. Pengembang sering ragu-ragu untuk menggunakan PNGs karena dukungan terbatas dalam browser, tapi ini sekarang menjadi sesuatu dari masa lalu. Satu-satunya masalah adalah alpha-PNG transparansi dalam true color, tapi sekali lagi, GIF tidak warna yang benar dan tidak mendukung transparansi variabel baik. Jadi apa pun yang bisa dilakukan GIF, PNG palet (PNG8) bisa melakukan terlalu (kecuali untuk animasi). Ini hasil perintah ImageMagick sederhana benar-benar aman digunakan PNGs: mengkonversi image.gif image.png "Semua yang kami katakan adalah: Berikan PING Chance!"
Jalankan pngcrush (atau alat optimasi PNG lainnya) pada semua PNGs Anda. Contoh: pngcrush image.png-rem result.png alla-mengurangi-brute
Jalankan jpegtran pada semua file JPEG Anda. Alat ini dapat melakukan operasi JPEG lossless seperti rotasi dan juga dapat digunakan untuk mengoptimalkan dan menghapus komentar dan informasi berguna lainnya (seperti informasi EXIF) dari gambar Anda. jpegtran-copy none-mengoptimalkan-sempurna src.jpg dest.jpg
Optimalkan CSS Sprite
Mengatur gambar dalam sprite horizontal sebagai lawan vertikal biasanya menghasilkan ukuran file yang lebih kecil.
Menggabungkan warna yang sama dalam sprite akan membantu Anda menjaga warna count rendah, idealnya di bawah 256 warna sehingga untuk masuk dalam PNG8 a.
"Jadilah ponsel-friendly" dan tidak meninggalkan kesenjangan besar antara gambar dalam sprite. Ini tidak mempengaruhi ukuran file sebanyak tetapi membutuhkan lebih sedikit memori untuk agen pengguna untuk dekompresi gambar ke peta pixel. 100x100 gambar adalah 10 ribu piksel, di mana 1000x1000 adalah 1 juta piksel
Jangan Skala Gambar dalam HTML
Jangan gunakan gambar yang lebih besar dari yang Anda butuhkan hanya karena Anda dapat mengatur lebar dan tinggi dalam HTML. Jika Anda perlu <img width="100" height="100" src="mycat.jpg" alt="Teman Cat" /> maka gambar Anda (mycat.jpg) harus 100x100px daripada skala bawah gambar 500x500px.
Membuat favicon.ico Kecil dan Cacheable
Favicon.ico adalah gambar yang tetap di root server Anda. Ini adalah kejahatan yang diperlukan karena bahkan jika Anda tidak peduli tentang hal itu browser masih akan meminta itu, jadi lebih baik tidak menanggapi dengan 404 Not Found . Juga karena itu pada server yang sama, cookie akan dikirim setiap kali itu diminta. Gambar ini juga mengganggu urutan download, misalnya di IE ketika Anda meminta komponen tambahan di onload, favicon akan di-download sebelum ini komponen tambahan.
Jadi untuk mengurangi kelemahan memiliki favicon.ico pastikan:
Ini kecil, sebaiknya di bawah 1K.
Set Expires header dengan apa yang Anda merasa nyaman (karena Anda tidak dapat mengubah nama jika Anda memutuskan untuk mengubahnya). Anda mungkin dapat dengan aman mengatur Habis tajuk beberapa bulan ke depan. Anda dapat memeriksa tanggal diubah terakhir favicon.ico Anda saat ini untuk membuat keputusan.
ImageMagick dapat membantu Anda membuat Favicons kecil
Jauhkan Komponen bawah 25K
Pembatasan ini berkaitan dengan fakta bahwa iPhone tidak akan komponen cache yang lebih besar dari 25K. Catatan bahwa ini adalah terkompresi ukuran. Di sinilah minification penting karena gzip saja mungkin tidak cukup.
Untuk informasi lebih lanjut cek " Penelitian Kinerja, Bagian 5: iPhone ynd Bisa - Sehingga Tetap "oleh Wayne Shea dan Tenni Theurer.
Komponen Pack ke dalam Dokumen Multipart
Packing komponen ke dalam dokumen multipart seperti email dengan attachment, ada baiknya Anda mengambil beberapa komponen dengan satu permintaan HTTP (ingat: HTTP request mahal). Bila Anda menggunakan teknik ini, pertama-tama memeriksa apakah user agent mendukungnya (iPhone tidak).
Hindari Kosong Gambar src
Gambar dengan string kosong src atribut terjadi lebih dari satu akan mengharapkan. Ini muncul dalam dua bentuk:
HTML lurus
<img src="">
JavaScript
var img = new Image ();
img.src = "";
Kedua bentuk menyebabkan efek yang sama: Browser membuat permintaan lain ke server Anda.
Internet Explorer membuat permintaan ke direktori di mana halaman berada.
Safari dan Chrome membuat permintaan ke halaman itu sendiri.
Firefox 3 dan versi sebelumnya berperilaku sama seperti Safari dan Chrome, tapi versi 3.5 membahas masalah ini [bug 444931] dan tidak lagi mengirimkan permintaan.
Opera tidak melakukan apa-apa ketika gambar src kosong ditemui.
Mengapa perilaku buruk ini?
Melumpuhkan server Anda dengan mengirimkan sejumlah besar lalu lintas yang tak terduga, terutama untuk halaman yang mendapatkan jutaan tampilan halaman per hari.
Siklus komputasi Server Limbah menghasilkan halaman yang tidak akan pernah dilihat.
Data pengguna mungkin korup. Jika Anda negara pelacakan dalam permintaan, baik oleh cookie atau dengan cara lain, Anda memiliki kemungkinan merusak data. Meskipun permintaan gambar tidak mengembalikan gambar, semua header dibaca dan diterima oleh browser, termasuk semua cookie. Sementara sisa respon dibuang, kerusakan mungkin sudah bisa dilakukan.
Akar penyebab perilaku ini adalah cara bahwa resolusi URI dilakukan dalam browser. Perilaku ini didefinisikan dalam RFC 3986 - Uniform Resource Identifier. Ketika string kosong ditemui sebagai URI, itu dianggap sebagai URI relatif dan diselesaikan sesuai dengan algoritma didefinisikan dalam bagian 5.2. Ini contoh spesifik, string kosong, terdaftar dalam bagian 5.4. Firefox, Safari, dan Chrome semua menyelesaikan string kosong dengan benar sesuai spesifikasi, sementara Internet Explorer menyelesaikan itu salah, ternyata sejalan dengan versi sebelumnya dari spesifikasi, RFC 2396 - Uniform Resource Identifier (ini usang oleh RFC 3986) . Jadi secara teknis, browser melakukan apa yang seharusnya mereka lakukan untuk menyelesaikan URI relatif. Masalahnya adalah bahwa dalam konteks ini, string kosong jelas tidak disengaja.
HTML5 menambah deskripsi tag src atribut untuk menginstruksikan browser untuk tidak membuat permintaan tambahan dalam bagian 4.8.2:
The src atribut harus hadir, dan harus berisi URL yang valid referensi non-interaktif, animasi opsional, sumber daya gambar yang tidak paged atau scripted. Jika basis URI dari elemen adalah sama dengan alamat dokumen, maka nilai src atribut itu tidak harus menjadi string kosong.
Mudah-mudahan, browser tidak akan memiliki masalah ini di masa depan. Sayangnya, tidak ada klausul tersebut untuk <script src=""> dan <link href="">. Mungkin masih ada waktu untuk membuat penyesuaian untuk memastikan bahwa browser tidak sengaja menerapkan perilaku ini.