Hari ini saya menjelajahi sekilas "Situs Web Berkinerja Tinggi". Versi bahasa Mandarin dari buku ini adalah "Panduan Konstruksi Situs Web Berkinerja Tinggi".
Buku ini juga memiliki bab lanjutan "Situs Web Lebih Cepat" yang mengeksplorasi secara mendalam setiap masalah, dan terjemahan bahasa Mandarinnya adalah "Panduan Tingkat Lanjut untuk Membangun Situs Web Berkinerja Tinggi".
Penulis memperkenalkannya di tautan Douban di atas, jadi saya tidak akan menyalinnya di sini.
Buku ini memberikan 14 prinsip untuk meningkatkan kinerja website, masing-masing prinsip merupakan bab independen dengan contoh. Sebagian besar prinsip-prinsip ini sangat praktis dan cocok untuk arsitek situs dan insinyur front-end. Ini sangat penting bagi para insinyur front-end.
Kali ini saya menonton versi aslinya. Saya kurang pengalaman praktis dalam pengembangan web, dan saya membacanya dengan tergesa-gesa, jadi mungkin ada kelalaian dan ekspresi yang tidak tepat.
Prinsip 1 Kurangi jumlah permintaan HTTP
Dibutuhkan waktu untuk menyusun permintaan dan menunggu respons, jadi semakin sedikit permintaan, semakin baik. Ide umum untuk mengurangi permintaan adalah dengan menggabungkan sumber daya dan mengurangi jumlah file yang diperlukan untuk menampilkan halaman.
1. Peta Gambar
Dengan mengatur atribut usemap pada tag <img> dan menggunakan tag <map>, Anda dapat membagi gambar menjadi beberapa area dan mengarahkan ke link yang berbeda. Dibandingkan dengan menggunakan banyak gambar untuk membuat tautan secara terpisah, jumlah permintaan berkurang.
2. CSS SPRite (integrasi tekstur CSS/jahitan tekstur/posisi tekstur)
Hal ini dilakukan dengan mengatur gaya posisi latar belakang elemen. Umumnya digunakan untuk ikon antarmuka. Yang umum dapat merujuk ke tombol kecil di atas editor TinyMCE. Beberapa gambar kecil pada dasarnya dipotong dari gambar besar terpadu dengan offset berbeda. Dengan cara ini, banyak tombol pada antarmuka pemuatan sebenarnya hanya perlu diminta satu kali (meminta gambar besar satu kali), sehingga mengurangi jumlah permintaan HTTP.
3. Gambar Sebaris
Jangan tentukan URL file gambar eksternal di src dari <img>, tetapi langsung masukkan informasi gambar. Misalnya, src="data:image/gif;base64,R0lGODlhDAAMAL..." berguna dalam beberapa kasus khusus (misalnya, gambar kecil hanya digunakan pada halaman saat ini).
Prinsip 2: Memanfaatkan CDN multi-baris
Berikan situs Anda akses ke beberapa jalur (seperti telekomunikasi domestik, China Unicom, China Mobile) dan beberapa lokasi geografis (utara, selatan, barat) sehingga semua pengguna dapat mengaksesnya dengan cepat.
Prinsip 3: Gunakan HTTP Cache
Tambahkan informasi header Kedaluwarsa yang lebih panjang ke sumber daya yang tidak sering diperbarui (seperti gambar statis). Setelah sumber daya ini di-cache, sumber daya tersebut tidak akan dikirimkan lagi untuk waktu yang lama di masa mendatang.
Prinsip 4: Gunakan kompresi Gzip
Gunakan Gzip untuk mengompresi pesan HTTP guna mengurangi ukuran dan waktu transmisi.
Prinsip 5: Tempatkan style sheet di bagian depan halaman
Muat style sheet terlebih dahulu agar rendering halaman dapat dimulai lebih awal, sehingga pengguna merasa bahwa halaman dimuat lebih cepat.
Prinsip 6: Tempatkan skrip di akhir halaman
Alasannya sama dengan 5. Tampilan halaman diproses terlebih dahulu, rendering halaman selesai lebih awal, dan logika skrip dijalankan kemudian, sehingga pengguna merasa bahwa halaman dimuat lebih cepat.
Prinsip 7 Hindari penggunaan ekspresi CSS
Logika skrip JavaScript yang terlalu rumit, pencarian DOM, dan operasi pemilihan akan mengurangi efisiensi pemrosesan halaman.
Prinsip 8 Gunakan Javascript dan CSS sebagai sumber daya eksternal
Hal ini tampaknya bertentangan dengan ide penggabungan pada prinsip 1, namun sebenarnya tidak: mengingat setiap halaman memperkenalkan sumber daya JavaScript publik (seperti jQuery atau perpustakaan JavaScript seperti ExtJS), dilihat dari kinerja satu halaman saja, inline (yaitu menyematkan JavaScript ke dalam HTML) halaman akan dimuat lebih cepat (karena jumlah permintaan HTTP yang lebih sedikit) dibandingkan halaman keluar (diperkenalkan menggunakan tag <script>). Namun jika banyak halaman memperkenalkan sumber daya JavaScript publik ini, maka skema inline akan menyebabkan transmisi berulang (karena sumber daya ini tertanam di setiap halaman, bagian dari sumber daya ini harus dikirimkan setiap kali halaman dibuka, sehingga menyebabkan pemborosan transmisi jaringan sumber daya). Masalah ini dapat diselesaikan dengan menjadikan sumber daya ini independen dan merujuknya secara eksternal.
Karena JavaScript dan CSS relatif stabil, kita dapat menetapkan tanggal kedaluwarsa yang lebih lama untuk sumber daya terkait (lihat Prinsip 3).
Prinsip 9 Kurangi pencarian DNS
Saran penulis adalah:
1. Gunakan Keep-Alive untuk tetap terhubung
Jika koneksi terputus, pencarian DNS harus dilakukan saat koneksi dibuat lagi. Bahkan jika pemetaan nama domain-IP yang sesuai telah di-cache, pencarian akan memerlukan waktu.
2. Kurangi nama domain
Setiap kali Anda meminta nama domain baru, Anda perlu mencari nama domain yang berbeda melalui DNS, dan cache DNS tidak dapat berfungsi. Oleh karena itu, Anda harus berusaha semaksimal mungkin untuk mengatur situs di bawah nama domain terpadu dan menghindari penggunaan terlalu banyak nama subdomain.
Prinsip 10 Perkecil JavaScript Anda
Gunakan alat kompresi JS untuk mengompresi JavaScript Anda, ini sangat efektif. Lihat saja dua distribusi jQuery yang berbeda untuk melihat perbedaannya:
http://code.jquery.com/jquery-1.6.2.js membaca versi kode jQuery, 230KB
http://code.jquery.com/jquery-1.6.2.min.js versi terkompresi kode jQuery (untuk penerapan sebenarnya), 89.4KB
Prinsip 11 Cobalah untuk menghindari pengalihan
Pengalihan berarti bahwa putaran permintaan HTTP tambahan ditambahkan sebelum Anda benar-benar mengakses halaman yang ingin Anda lihat (klien memulai permintaan HTTP → server HTTP mengembalikan respons pengalihan → klien memulai permintaan untuk URL baru → HTTP server mengembalikan konten, bagian yang digarisbawahi adalah permintaan tambahan), sehingga menghabiskan lebih banyak waktu (yang juga membuat orang merasa responsnya lebih lambat). Jadi jangan gunakan pengalihan kecuali diperlukan. Beberapa situasi yang "perlu":
1. Hindari URL yang tidak valid
Setelah situs lama dimigrasi, untuk mencegah URL lama menjadi tidak valid, permintaan URL lama biasanya dialihkan ke alamat yang sesuai di sistem baru.
2. Kecantikan URL
Konversi antara URL yang dapat dibaca dan URL sumber daya sebenarnya. Misalnya, untuk Google Toolbar, pengguna mengingat http://toolbar.google.com, yang merupakan alamat semantik bagi manusia, namun sulit untuk mengingat http://www .google .com/tools/Firefox/toolbar/FT3/intl/en/index.html adalah alamat sumber daya sebenarnya. Oleh karena itu, penting untuk mempertahankan permintaan yang pertama dan mengalihkan permintaan dari yang pertama ke permintaan yang terakhir.
Prinsip 12 Hapus skrip duplikat
Jangan menyertakan skrip yang sama berulang kali pada suatu halaman. Misalnya, skrip B dan C keduanya bergantung pada A, sehingga mungkin terdapat referensi berulang ke A di halaman yang menggunakan B dan C. Solusinya adalah dengan memeriksa dependensi secara manual untuk situs sederhana dan menghilangkan pengenalan berulang; untuk situs yang kompleks, Anda perlu membangun mekanisme manajemen dependensi/kontrol versi Anda sendiri.
Prinsip 13 Tangani ETag dengan hati-hati
ETag adalah metode HTTP Cache lain selain Last-Modified. Identifikasi apakah sumber daya telah dimodifikasi melalui hashing. Namun ada beberapa masalah pada ETag, seperti:
1. Inkonsistensi: Server web yang berbeda (Apache, IIS, dll.) menentukan format ETag yang berbeda
2. Perhitungan ETag tidak stabil (karena terlalu mempertimbangkan banyak faktor), seperti:
1) Sumber daya yang sama memiliki ETag berbeda yang dihitung pada server berbeda, dan aplikasi web skala besar biasanya dilayani oleh lebih dari satu server. Hal ini menyebabkan sumber daya cache klien di server A masih valid, tetapi pada saat berikutnya meminta B Karena Jika ETag berbeda, maka dianggap tidak valid, sehingga terjadi transmisi berulang pada sumber daya yang sama.
2) Sumber daya tetap tidak berubah, tetapi ETag berubah karena perubahan beberapa faktor lain, seperti perubahan file konfigurasi. Konsekuensi langsungnya adalah setelah pembaruan sistem, kegagalan cache klien terjadi dalam skala besar, yang mengakibatkan peningkatan besar dalam volume transmisi dan penurunan kinerja situs.
Saran penulis adalah: perbaiki metode perhitungan ETag yang ada sesuai dengan karakteristik aplikasi Anda, atau jangan gunakan ETag dan gunakan Last-Modified yang paling sederhana.
Prinsip 14 Memanfaatkan Cache HTTP dengan Ajax
Ajax adalah permintaan asinkron. Permintaan asinkron tidak akan memblokir operasi Anda saat ini, dan ketika permintaan selesai, Anda dapat langsung melihat hasilnya. Namun asynchronous bukan berarti dapat diselesaikan secara instan, juga tidak berarti dapat ditoleransi dan membutuhkan waktu yang tidak terbatas untuk menyelesaikannya. Oleh karena itu, kinerja permintaan Ajax juga perlu diperhatikan. Ada banyak permintaan Ajax yang mengakses sumber daya yang relatif stabil, jadi jangan lupa untuk memanfaatkan mekanisme HTTP Cache untuk permintaan Ajax. Untuk detailnya, lihat Prinsip 3 dan 13.
Penulis: Yang Mengdong
Sumber artikel: Blog Yang Mengdong. Harap tunjukkan tautan sumber saat mencetak ulang.