Apa yang perlu diketahui pengembang tentang analisis kinerja HTML5

Komentar: Artikel berikut ini ditulis oleh seorang teknisi TI bernama Zhang Liming, dan diterbitkan di halaman web InfoQ. Kali ini, ia menganalisis kinerja HTML5 dari 9 aspek yang berbeda dalam teks lengkap, yang masih layak dibaca oleh pengembang yang sesuai.

Pertama, dari perspektif keterbacaan pengguna, ada banyak hal yang awalnya tidak dipahami oleh pemula untuk pertama kalinya untuk melihat hal -hal ini, dan metode deklarasi HTML5 jelas lebih ramah kepada pengguna.

Kedua, deklarasi pengkodean dokumen sangat sederhana jika ada di HTML5. Banyak orang bertanya apa itu HTML5? Kami mengatakan bahwa cara kami dapat menggunakan HTML5 terlebih dahulu adalah dengan mengubah Doctype terlebih dahulu, karena banyak halaman masih dengan cara tradisional. Metode HTML5 kompatibel dengan browser IE, dan dapat digunakan dari IE6 ke IE10, dan dapat didukung oleh browser canggih. Jadi cara termudah untuk merangkul HTML5 adalah dengan mengubah Doctype.

Hal berikutnya mungkin bukan hal yang sangat umum, tetapi itu adalah sesuatu yang saya sukai, menggunakan metode label yang lebih sederhana. Seperti yang Anda tahu dari nama ini, HTML5 diwarisi dari HTML4. HTML4 memiliki mode dan mode transisi yang ketat. HTML5 mendukung mode transisi ini, yang berarti Anda tidak dapat menutup beberapa tag. Namun, saya tidak merekomendasikan semua tag, misalnya, tag tubuh tidak ditutup, yang tidak kami rekomendasikan. Tetapi p-label yang paling umum digunakan juga adalah daftar tag li. Mengapa Anda mengatakan ini? Pertama -tama, dari perspektif visual, metode ini sedikit lebih sederhana. Maka kuncinya adalah bahwa selama proses transfer dokumen, akan ada lebih sedikit konten.

Deklarasi atribut tag HTML5 mendukung tiga cara: kurung tunggal, kurung ganda, dan kurung yang tidak bercabang. Untuk mengurangi ukuran dokumen, saya memilih metode tanpa kutipan ganda atau kutipan tunggal. Namun, perlu dicatat bahwa dengan asumsi itu adalah deklarasi atribut kelas, karena atribut dapat mencakup beberapa kelas, dan ketika beberapa kelas, mereka harus dilampirkan dalam kurung. Dalam hal ini, izinkan saya menunjukkan kepada Anda praktik Google. Google sendiri memiliki halaman yang sepenuhnya mempraktikkan di atas, mengurangi ukuran dokumen sebesar 20%, mengurangi transfer dokumen HTML sebesar 20%. Jika semuanya dipraktikkan, ia dapat mencapai penurunan antara 5% dan 20%. Ini adalah langkah pertama, mengurangi ukuran dokumen HTML.

Berikutnya adalah tentang optimalisasi gambar, yang selalu merupakan elemen yang mencintai dan membenci. Karena ketika ada terlalu banyak gambar, itu akan secara serius menyeret kecepatan pemuatan seluruh halaman. Mengenai metode optimasi gambar, ada banyak perkenalan dalam buku "Situs Web Kinerja Tinggi". Untuk meringkas, ada tiga poin utama: menggunakan elf, mengoptimalkan ukuran gambar, dan menggunakan data URI. Saya tidak akan membahas detailnya di sini.

Gagasan lain tentang pengoptimalan gambar adalah: no-image. Abaikan gambar dan rangkul CSS3. Awalnya, saya perlu mengatur gambar dengan efek sudut bulat, tetapi sekarang saya menggunakan perbatasan-radius di CSS3; Saya menggunakan gambar dengan efek bayangan, tetapi sekarang saya menggunakan kotak-shadow di CSS3; Saya biasa mengatur gambar latar belakang gradien, tetapi sekarang saya menggunakan gradien di CSS3.

3. Pra-Fetch

Selanjutnya, mari kita bicara tentang prefetching, yang merupakan cara optimisasi lain. Gagasan optimasi kami saat ini tidak lebih dari sedikit. Banyak dari mereka berasal dari perspektif hal -hal yang lebih sedikit, misalnya, ukuran dokumen dikurangi sebelumnya dan ukuran gambar dikurangi. Banyak gambar menjadi elf, untuk mengurangi jumlah permintaan pengiriman. Untuk prefetching, itu adalah cara berpikir lain. Memuat sumber daya lebih awal. Ketika pengguna pergi ke titik, itu benar -benar dimuat, jadi pasti akan lebih cepat.

Ada dua bagian untuk prefetching: satu adalah prefetching sumber daya, dan yang lainnya adalah pra-penyelesaian DNS.

Ada beberapa poin yang perlu diperhatikan saat sumber daya preloading:

Preloading hanya akan menarik ketika browser menganggur, tetapi tidak dijamin untuk menariknya. Ini adalah poin yang sangat penting. Karena browser itu sendiri memiliki pendengar global, yang merupakan antarmuka internal. Ketika udara penelusuran menganggur, ia akan menjalankan browser saat menganggur, tetapi panggilan balik idle ini mungkin tidak dipicu, sehingga tidak menjamin bahwa preloading akan dilakukan.

Chrome tidak mendukung preloading sumber daya HTTPS. Misalnya, Alipay adalah halaman HTTPS, Chrome tidak akan pra-tarik.

Meskipun halaman yang telah ditarik tidak terlihat setelah itu ada, itu sebenarnya parsing secara normal. Jika saya melakukan pra-tarik halaman login, halaman login memiliki banyak sumber daya, seperti gambar, file CSS, dan file JS. Ini akan diuraikan dari atas ke bawah secara normal. Selama proses parsing, halaman ini tidak muncul, tetapi sebenarnya ada. Di HTML5, Anda bisa mendapatkan status halaman saat ini melalui Document.visibilityState. Biasanya halaman memiliki dua negara bagian, terlihat dan tidak terlihat, tetapi sekarang ada negara baru yang disebut status pra-render. Anda dapat secara langsung menentukan apakah halaman tersebut berada dalam keadaan prerender dengan apakah dokumen. VisibilitasState sama dengan prerender.

4. Resolusi DNS

Berikutnya adalah resolusi DNS. Terkadang ketika kita masuk ke halaman, relatif sulit untuk mendeteksi di mana pengguna dapat mengklik. Tentu saja, kadang -kadang kami akan melakukan beberapa poin penguburan untuk mengetahui bahwa perilaku pengguna berikutnya sebagian besar masuk. Tetapi dalam beberapa kasus, kami tidak tahu halaman mana yang akan digunakan pengguna berikutnya, tetapi kami tahu domain mana yang akan ia tuju. Pada saat ini, saya dapat melakukan pra-parse DNS. Karena pada kenyataannya, ada proses resolusi DNS yang panjang di seluruh proses permintaan halaman. Jika kami melakukan ini terlebih dahulu, kami dapat membiarkan pengguna melihat halaman ini.

Berikut ini adalah kasus wallpaper Q+. Q+ Wallpaper adalah sistem tertentu. Pertama -tama, seluruh arsitektur Q+ didasarkan pada Web+ klien. Apa yang kami lihat sekarang adalah halaman web. Meskipun ini adalah shell klien di luar, jantungnya adalah web. Ketika kami menyelesaikan seluruh proses untuk pertama kalinya, karena ada banyak gambar, semua sumber daya statis dialokasikan untuk lebih dari selusin server statis. Dengan kata lain, jika saya ingin menarik, saya harus mengurai 10 DN. Waktu ini cukup memakan waktu, dan waktu paling lambat mungkin ditunda beberapa detik, yang merupakan sesuatu yang bisa kita rasakan dengan mata telanjang. Jika Anda melakukan pra-resolusi DNS, karena saya tidak tahu sumber daya mana, semua gambar acak, jadi kami hanya dapat mengatakan bahwa kami bekerja keras pada pra-resolusi DNS untuk meningkatkan kecepatannya. Dengan cara ini, mungkin perlu 2 detik, dan saya akan menjadi 1 detik.

Selanjutnya, mari kita bicara tentang aplikasi di Q+. Kami akan memiliki banyak rantai teks di QQ dan Q+, seperti di QQ, yang berarti ada dorongan informasi aplikasi teks di sudut kiri bawah jendela. Ini adalah backend ditarik dari waktu ke waktu melalui web, dan backend ditarik dari dan kemudian ditampilkan di latar depan. Tetapi pada periode tertentu, total informasi operasional yang didorong oleh semua aplikasi sebenarnya diperbaiki. Jika Anda menganalisis array yang sesuai dari setiap rantai teks sesuai dengan aplikasi tertentu, itu adalah data yang sangat besar saat ini. Karena satu di sini memiliki sekitar tiga atau empat ratus byte, dari perspektif optimasi, kami akan menarik area ini ke atas secara lokal. Kemudian simpan LocalStorage lokal. Kami berada di domain yang sama, dan semua informasi antar aplikasi dapat diakses oleh satu sama lain. Maka Anda tidak akan menarik semua ID yang Anda tarik lagi.

Ada juga titik yang perlu diperhatikan di sini. Saat ini, banyak produsen LocalStorage disinkronkan. Jika Anda memanggil LocalStorage dalam jumlah besar, itu benar -benar akan memblokir proses rendering Anda. Pada saat ini, ketika pengguna menyeret halaman ke bawah, Anda menyimpan data saat ini, dan data relatif besar. Pada saat ini, pengguna akan merasa bahwa halaman Anda sangat macet. Mereka telah membahas masalah ini sebelumnya. Desain antarmuka ini dirancang secara tidak sinkron, dan mereka dirancang sebagai sinkron. Ini akan menyebabkan Anda membuat alasan ini ketika Anda membuat lebih banyak aplikasi karena ada proses serialisasi, urutan ke disk. Dengan cara ini, seluruh proses akan tampak lebih lambat. Selain itu, LocalStorage dapat membagikan data ini di antara jendela yang berbeda, dan akan mengunci data ini. Jika sejumlah besar data memanggil antarmuka lokal ini, itu akan tampak relatif macet. Jadi tidak ada solusi yang bagus saat ini, tetapi ini adalah sesuatu yang perlu diingat. Bahkan jika yang terbesar saat ini lebih dari jam 5, jika Anda menggunakan lebih dari jam 5, itu akan membuat pengguna sangat menyedihkan. Karena jika Anda menyebut alasan ini dan pengguna menyeret dan menggunakan mouse, itu akan terasa sangat macet.

Selanjutnya, mari kita bicara tentang manfaat penyimpanan offline kepada pengguna dalam hal kinerja. Pertama -tama, file definisi dimasukkan penyimpanan offline. Semua modul sistem di Q+ memiliki definisi dukungan offline. Dengan kata lain, jika semua aplikasi terputus, mereka masih dapat digunakan. Tambahkan file manifes ke dokumen. Manifest adalah file definisi yang menyatakan halaman mana yang perlu disimpan secara lokal? Mana yang tidak perlu disimpan? Mana yang harus diganti jika permintaan gagal? Ini dibagi menjadi tiga bagian:

Pertama, cache, yang perlu disimpan secara lokal.

Kedua, jaringan tidak akan disimpan secara lokal. Ini akan kembali dan memintanya setiap saat. Tetapi harus ditunjukkan di sini bahwa penyimpanan lokal dan penyimpanan browser sebenarnya adalah dua hal yang berbeda. Mereka menyimpan dua bagian yang berbeda. Bahkan jika jaringan perlu memberi tahu aplikasi bahwa saya perlu menariknya sekali setiap kali, karena seperti Chrome, cache penyimpanannya sangat penuh kebencian dan sulit untuk dibersihkan. Itu harus dibersihkan secara manual agar berlaku. Jadi, bahkan jika Anda mengaturnya untuk tidak menyimpannya secara lokal, browser dapat menyimpannya sendiri karena menyimpan dua tempat yang berbeda.

Ketiga, Fallback. Jika gambar gagal, itu adalah 404. Jadi gambar apa yang harus digunakan sebagai gantinya? Saya pikir ini lebih menyenangkan.

Bagaimana cara mengatur Maeifest? Ada tiga hal yang perlu diperhatikan tentang manifes:

Pembatasan homolog manifes;

Jenis MIME harus teks/cache-manifest, yang merupakan standar dan tidak akan berlaku jika dalam format lain;

Chrome, jika Anda ingin melihat apakah hal ini berlaku, Anda dapat memasukkannya di browser melalui pseudo-protocol chrome, chrome: // appcache-internal.

Tentang cara memperbarui cache aplikasi. Mengapa Anda membutuhkan penyimpanan offline? Simpan offline secara lokal. Ketika browser tahu bahwa Anda memiliki penyimpanan offline, pertama -tama akan pergi ke direktori penyimpanan offline untuk mengetahui apakah sumber daya ini telah di -cache. Ketika telah di -cache, ia akan mendapatkan sumber daya langsung dari sini dan tidak akan mengirim permintaan lain. Karena permintaan browser seperti ini, ketika ada penyimpanan offline, bahkan permintaan tidak akan dikirim, jadi itu akan lebih cepat. Jika kadang -kadang kita perlu memperbarui, apa yang harus kita lakukan saat kita memperbarui?

Pengguna dapat secara manual menghapus cache browser, dan penyimpanan lokal akan secara otomatis dihapus saat ini.

Memodifikasi konten manifes adalah cara yang lebih direkomendasikan dan juga cara kami menggunakannya secara online. Dengan kata lain, kami dapat memodifikasi proyek spesifik di dalam, tetapi yang terbaik adalah memodifikasi komentar di sini, karena setiap kali saya menerbitkan, kami secara otomatis mempublikasikan mekanisme, dan hanya berkomentar dan memodifikasinya saat menerbitkan. Dengan cara ini, setiap kali konten diterbitkan, itu akan disinkronkan ke area lokal klien secara real time;

Jalankan melalui program, dan programnya adalah window.applicationCache.update (). Itu berarti saya ingin mengoperasikan penyimpanan offline. Bahkan, saya terkadang menyebutnya penyimpanan aplikasi karena semantiknya adalah penyimpanan aplikasi. Kami pergi untuk memperbarui penyimpanan aplikasi secara manual.

6. Pekerja

Pekerja web berikutnya. Pekerja Web adalah proses JS multi-threaded. Faktanya, jika kami tidak memiliki skenario aplikasi online, saya tidak akan membicarakannya. Tetapi kita dapat berbicara tentang skenario aplikasi spesifik yang telah saya lihat.

Pertama, izinkan saya memperkenalkan apa itu webwork? Ini adalah utas level OS. Sebelumnya, kami meniru multi-threading, tetapi sebenarnya kami membuka satu jendela lagi. Tetapi sekarang, browser itu sendiri menyediakannya, yang akan membawa kenyamanan lebih pada operasi dan merupakan cara untuk membuat seluruh dokumen kami lebih berat dan tidak terlalu disarankan.

Kemudian WebWorker memiliki kemampuan akses yang terbatas dan tidak dapat mengakses banyak objek global. Misalnya, objek DocumNet tidak dapat diakses. Skenario yang paling cocok untuk WebWorker adalah operasi komputasi intensif CPU. Ketika kami bermain game sebelumnya, kami menggunakan Box2D. Banyak orang pernah mendengarnya. Ini melibatkan banyak perhitungan, yaitu, semua objek di bawah ini di seluruh halaman perlu menghitung hubungan tabrakan mereka, yang sangat besar. Namun, jika dieksekusi dalam proses JS saat ini, perhitungannya besar, dan setelah perhitungan dihitung, seluruh halaman akan sangat gagap. Namun, jika Anda menggunakan WebWorker untuk melakukannya, itu adalah proses asinkron yang dikirim secara real time dan dapat melakukan hal-hal lain selama proses perhitungan, yang merupakan multi-threading.

Mari kita bicara tentang API perangkat. Saya pikir hal terpenting tentang API perangkat adalah kinerja, dan itu juga API paling awal yang saat ini diimplementasikan. Salah satunya adalah koneksi, yang merupakan bandwidth jaringan. Apa fungsi ini? Dalam skenario ini di Cina, perlu diingat bahwa kecepatan internet banyak pengguna masih sangat rendah. Kami berharap bahwa ketika kecepatan internet pengguna rendah, mereka dapat secara otomatis menurunkan peringkat ke solusi yang relatif rendah. Kami tidak dapat melakukannya jika kami menggunakan teknologi yang ada. Tapi kita bisa menggunakan API perangkat. Karena kita tahu bahwa informasi ini dapat diperoleh dari perangkat. Apa broadbandnya? Apa broadband itu? Apa yang bisa kita lakukan saat itu. Misalnya, ketika broadband bagus, saya menggunakan gambar definisi tinggi. Ketika broadband relatif rendah, gunakan gambar dengan kejelasan yang lebih rendah.

8. Baterai

Yang berikut adalah tentang baterai. Saya pikir dari perspektif kinerja, ini terutama tentang kekuatan. Jika daya baterai pengguna relatif rendah, saya pikir dia harus mencoba melakukan lebih sedikit hal. Teknologi baterai ponsel itu sendiri belum membuat terobosan. Saya pikir membuat aplikasi terlihat lebih berkinerja tinggi juga merupakan sorotan publisitas.

9.Canvas

Berikutnya adalah kanvas. Mari kita bicara tentang beberapa titik optimasi kinerja kanvas. Jika Anda menggunakan hal -hal ini, kinerja akan ditingkatkan 10 kali.

Pertama, setiap kanvas adalah kanvas. Ketika kami ingin membuat grafik, kami dapat melapisinya. Sama seperti di dalam PS, itu satu, dua, dan tiga lapisan. Banyak pengguna secara langsung meniru semuanya dalam satu lapisan saat membuat game, dan semuanya perlu diperbarui setelah diperbarui. Tetapi jika Anda melapisinya, Anda meletakkan latar belakang di lapisan latar belakang dan karakter dalam peran. Dengan cara ini, ketika saya ingin memperbarui peran, saya hanya akan memperbarui peran, dan lapisan latar tidak perlu diubah. Karena CPU lebih sedikit, kinerja akan meningkat secara alami.

Kedua, Context.drawimage. Jangan skala gambar. Kami membuat kesalahan di awal. Gambar -gambar yang dibuat oleh seniman kami selalu tidak konsisten dengan kami, dan kemudian kami ingin mengukur gambar. Karena ukuran gambar perangkat itu sendiri seperti ini, kita harus skala gambar dengan rasio. Setelah memperbesar gambar, saya menemukan bahwa pada perangkat low-end, misalnya, iPad atau iPhone akan sangat macet. Mengapa? Cukup lakukan analisis kode. Saat menggunakan metode ini, harganya banyak.

Ketiga, RequestanimationFrame. Ini adalah metode yang secara khusus dioptimalkan untuk rendering. Prinsipnya sendiri adalah ini: Ketika browser melewati bingkai, metode ini akan dipicu. Ketika saya memicu, Canvas mendapatkan browser siap melakukan bingkai berikutnya. Jika Anda menggunakan metode tradisional, Anda tidak akan mempertimbangkan lebih banyak barang Anda. Itu hanya akan tahu berapa banyak waktu yang telah saya lewati dan saya akan menjalankannya. Jika pengguna diblokir sebelumnya dan menjalankan metode ini setiap 10 detik, dalam 10 detik, pekerjaan sebelumnya belum selesai, dan kemudian pekerjaan akan ditunda. Dioptimalkan agar animasi terlihat lebih halus, karena setiap bingkai, itu memberi tahu Anda bahwa Anda dapat melakukan sesuatu. (Teks: infoq)