Perkara yang perlu diketahui oleh pembangun tentang analisis prestasi HTML5_html5 kemahiran tutorial

Dari perspektif prestasi, HTML5 mula-mula mengurangkan dokumen HTML untuk menjadikannya lebih mudah.
Pertama, dari segi kebolehbacaan pengguna, pada asalnya terdapat banyak perkara yang tidak dapat difahami oleh pemula apabila mereka melihatnya buat kali pertama, tetapi kaedah pengisytiharan HTML5 jelas lebih mesra pengguna.
Kedua, pengisytiharan pengekodan dokumen adalah sangat mudah menggunakan HTML5. Ramai yang bertanya apa itu HTML5? Kami mengatakan bahawa cara menggunakan HTML5 dahulu ialah menukar DOCTYPE terlebih dahulu, kerana pada masa ini banyak halaman masih menggunakan kaedah tradisional. Kaedah HTML5 itu sendiri serasi dengan penyemak imbas IE, dari IE6 hingga IE10, termasuk penyemak imbas lanjutan. Jadi cara paling mudah untuk menerima HTML5 ialah menukar DOCTYPE.

1. Teg yang lebih ringkas
Perkara seterusnya mungkin bukan perkara biasa, tetapi ia adalah sesuatu yang saya cadangkan dan ia lebih mudah digunakan kaedah pelabelan. Seperti yang anda boleh ketahui daripada namanya, HTML5 diwarisi daripada HTML4. HTML4 mempunyai mod ketat dan mod peralihan HTML5 menyokong mod peralihan ini, iaitu, anda tidak boleh menutup beberapa teg. Walau bagaimanapun, saya tidak mengesyorkan semua tag Contohnya, jika tag BODY tidak ditutup, kami tidak mengesyorkan ini. Tetapi tag P yang paling biasa digunakan ialah tag senarai LI. Mengapa anda mengatakan ini? Pertama sekali, dari perspektif visual, kaedah ini lebih mudah. Kemudian kuncinya ialah semasa proses pemindahan dokumen, kandungan akan menjadi kurang.
Pengisytiharan atribut teg HTML5 menyokong tiga kaedah: kurungan tunggal, kurungan berganda dan tiada kurungan. Untuk mengurangkan saiz dokumen, saya memilih kaedah tanpa petikan berganda atau kaedah dengan petikan tunggal. Walau bagaimanapun, sila ambil perhatian bahawa andaian ialah pengisytiharan atribut kelas, kerana atribut itu mungkin termasuk berbilang kelas dan mesti disertakan dalam kurungan apabila terdapat berbilang kelas. Dalam hal ini, izinkan saya menunjukkan kepada anda amalan Google. Google sendiri mempunyai halaman yang melaksanakan sepenuhnya perkara di atas, mengurangkan saiz dokumen sebanyak 20% dan mengurangkan penghantaran dokumen HTML sebanyak 20%. Jika anda mempraktikkan semuanya, anda boleh mencapai pengurangan antara 5% dan 20%. Ini adalah langkah pertama, mengurangkan saiz dokumen HTML.
　2. Pengoptimuman Imej
Seterusnya ialah pengoptimuman imej sentiasa unsur cinta-benci. Kerana apabila terdapat banyak gambar, ia akan memperlahankan kelajuan memuatkan keseluruhan halaman. Mengenai kaedah pengoptimuman imej, terdapat banyak pengenalan dalam buku "Laman Web Prestasi Tinggi". .
Idea lain untuk pengoptimuman imej ialah: tiada imej. Parit imej dan terima CSS3. Ia pada asalnya perlu untuk menetapkan gambar dengan kesan sudut bulat, dan kini ia menggunakan jejari sempadan dalam CSS3 ia pada asalnya perlu untuk menetapkan gambar dengan kesan bayang-bayang, dan kini ia menggunakan bayang-kotak dalam CSS3; menjadi gambar latar belakang yang diperlukan untuk menetapkan kecerunan, dan kini ia digunakan dalam CSS3.
　3 Prefetching
Seterusnya mari kita bincangkan tentang Prefetching, prefetching, yang merupakan idea lain untuk pengoptimuman. Idea pengoptimuman semasa kami tidak lebih daripada sedikit. Kebanyakannya adalah dari sudut pengurangan, seperti mengecilkan saiz dokumen dan mengecilkan saiz gambar. Banyak gambar diubah menjadi imej sprite untuk mengurangkan bilangan permintaan yang dihantar. Prefetching ialah satu lagi cara berfikir Sumber dimuatkan lebih awal Apabila pengguna mengklik padanya, ia sudah dimuatkan, yang pastinya lebih pantas.
Prafetching mempunyai dua bahagian: satu adalah pra-penyelesaian sumber dan satu lagi ialah prapenyelesaian DNS.
Terdapat beberapa perkara yang perlu diperhatikan tentang pramuat sumber:
Pramuat hanya akan dilakukan apabila penyemak imbas melahu, tetapi tiada jaminan bahawa ia akan dilakukan. Ini adalah perkara yang sangat penting. Kerana penyemak imbas itu sendiri mempunyai pendengar global, iaitu antara muka dalaman Apabila penyemak imbas melahu, ia akan melakukan perkara yang harus dilakukan oleh penyemak imbas apabila ia melahu, tetapi panggilan balik terbiar ini mungkin tidak dicetuskan, jadi Tiada jaminan bahawa. pramuat akan dilakukan.
Chrome tidak menyokong pramuat sumber HTTPS Contohnya, jika Alipay ialah halaman HTTPS, Chrome tidak akan pramuatnya.
Walaupun halaman pra-ambil tidak kelihatan selepas ia wujud, ia sebenarnya sedang dihuraikan seperti biasa. Katakan saya pra-mengambil halaman log masuk Halaman log masuk mempunyai banyak sumber, seperti gambar, fail CSS dan fail JS. Ia akan dihuraikan secara normal dari atas ke bawah Semasa proses penghuraian, halaman ini tidak muncul, tetapi ia sebenarnya wujud. Dalam HTML5, keadaan halaman semasa boleh diperolehi melalui document.visibilityState Biasanya halaman mempunyai dua keadaan, kelihatan dan tidak kelihatan, tetapi kini terdapat keadaan baharu yang dipanggil keadaan pra-diberikan. Anda boleh menentukan secara langsung sama ada halaman berada dalam keadaan pra-dipaparkan dengan sama ada document.visibilityState adalah sama dengan prapaparan.
　4.Analisis DNS
Seterusnya ialah analisis DNS. Kadang-kadang pada halaman log masuk kami, agak sukar untuk mengesan tempat di mana pengguna boleh mengklik Sudah tentu, kadang-kadang kami akan melakukan beberapa penggalian untuk mengetahui bahawa kebanyakan tindakan pengguna seterusnya adalah masuk. Tetapi dalam beberapa kes, kami tidak tahu halaman mana pengguna akan pergi ke seterusnya, tetapi kami tahu domain mana yang akan dia pergi. Pada masa ini, saya boleh pra-menyelesaikan DNS. Kerana sebenarnya, terdapat proses penyelesaian DNS yang panjang dalam keseluruhan proses permintaan halaman Jika kami melakukan ini lebih awal, kami boleh membenarkan pengguna melihat halaman ini.
Berikut ialah contoh kertas dinding Q. Kertas dinding Q ialah sistem Q tertentu. Pertama sekali, keseluruhan seni bina Q adalah berdasarkan klien WEB. Apa yang kita lihat sekarang ialah halaman WEB Walaupun ia adalah shell pelanggan di luar, jantungnya adalah WEB. Apabila kami menyelesaikan keseluruhan proses buat kali pertama, kerana terdapat banyak gambar, semua sumber statik telah diperuntukkan kepada lebih daripada sedozen pelayan statik. Dalam erti kata lain, jika saya ingin menarik, saya perlu menyelesaikan 10 DNS Masa ini agak memakan masa, ia mungkin tertunda untuk beberapa saat, yang boleh kita rasakan dengan mata kasar. Jika kami melakukan pra-peleraian DNS, saya tidak tahu sumber mana itu, dan semua gambar adalah rawak, jadi kami hanya boleh mengatakan bahawa kami harus bekerja keras pada pra-peleraian DNS untuk meningkatkan kelajuannya. Dalam kes ini, ia mungkin mengambil masa 2 saat, tetapi ia akan mengambil masa 1 saat.
Seterusnya mari kita bincangkan tentang aplikasi dalam Q. Kita akan menjadi seperti dalam QQ Terdapat banyak pautan teks dalam QQ dan Q, iaitu, terdapat tolakan teks maklumat APP di sudut kiri bawah tetingkap. Di sini, bahagian belakang ditarik dari semasa ke semasa melalui WEB, dan bahagian belakang ditarik ke atas dan dipaparkan di latar depan. Tetapi pada tempoh tertentu, maklumat operasi yang ditolak oleh semua aplikasi ditetapkan. Jika kita menganalisis tatasusunan yang sepadan dengan setiap pautan teks mengikut APP tertentu, ini merupakan jumlah data yang sangat besar. Kerana setiap satu di sini adalah kira-kira tiga hingga empat ratus bait Dari sudut pandangan pengoptimuman, kami menyimpan fail ini secara setempat setiap kali. Kemudian simpannya secara setempat dalam localStorage Kami berada dalam domain yang sama, dan semua maklumat antara APP boleh diakses oleh satu sama lain. Kemudian semua ID yang telah ditarik tidak akan ditarik lagi.
Terdapat juga perkara yang memerlukan perhatian di sini Pelaksanaan localStorage oleh banyak pengeluar adalah segerak. Jika anda banyak memanggil antara muka localStorage, ia sebenarnya akan menyekat proses pemaparan anda. Pada masa ini, apabila pengguna menyeret halaman ke bawah, dan anda sedang menyimpan data pada masa ini, dan datanya agak besar, pengguna akan merasakan halaman anda sangat tersekat. Mereka telah membincangkan isu ini sebelum ini Reka bentuk antara muka IE adalah tidak segerak, manakala reka bentuk mereka adalah segerak. Ini akan membawa kepada andaian bahawa anda mempunyai banyak program semasa melaraskan antara muka ini, kerana terdapat proses bersiri, bersiri ke cakera. Dalam kes ini, keseluruhan proses akan kelihatan lebih perlahan. Selain itu, localStorage sendiri boleh berkongsi data ini antara tetingkap yang berbeza, dan ia akan mengunci data ini. Jika sejumlah besar data memanggil antara muka tempatan ini, ia akan kelihatan tersekat. Oleh itu, tiada penyelesaian yang sangat baik sekarang, tetapi ia adalah sesuatu yang perlu diingat. Walaupun maksimum semasa adalah lebih daripada lima megabait, jika anda menggunakan lebih daripada lima megabait, ia akan menyebabkan pengguna sengsara. Kerana jika anda memanggil alasan ini dan pengguna menyeret tetikus, ia akan berasa sangat tersangkut.
　5 Storan luar talian
Seterusnya mari kita bincangkan tentang faedah yang dibawa oleh storan luar talian kepada pengguna dari segi prestasi. Yang pertama ialah fail definisi untuk storan luar talian Semua modul sistem dalam Q mempunyai sokongan luar talian yang ditentukan. Ini bermakna semua aplikasi masih boleh digunakan jika rangkaian diputuskan. Tambah fail MANIFEST pada dokumen MANIFEST ialah fail definisi yang mengisytiharkan bahagian mana pada halaman semasa yang perlu disimpan secara setempat? ? Cara ini Terbahagi kepada tiga bahagian:
Pertama, CACHE, yang perlu disimpan secara setempat.
Kedua, NETWORK tidak akan disimpan secara setempat dan memintanya setiap kali Tetapi apa yang perlu ditunjukkan di sini ialah storan tempatan dan storan pelayar sebenarnya adalah dua tempat yang berbeza . Walaupun NETWORK perlu memberitahu APP bahawa saya perlu menariknya setiap kali, kerana seperti Chrome, cache storannya sangat membenci dan sukar untuk dikosongkan secara manual untuk menjadi berkesan sepenuhnya. Jadi, walaupun anda menetapkannya untuk tidak menyimpannya secara setempat, penyemak imbas mungkin menyimpannya sendiri kerana ia menyimpannya di dua tempat berbeza.
Ketiga, FALLBACK. Jika gambar mengatakan bahawa permintaan itu gagal, itu adalah 404. Gambar apa yang patut saya gunakan sebaliknya saya rasa ini lebih menyeronokkan.
Bagaimana untuk menetapkan MAEIFEST? Terdapat tiga perkara yang perlu diperhatikan di sini dalam MANIFEST:
Pengehadan asal yang sama
Jenis MIME mesti dalam bentuk teks/cache-manifes format, ia tidak akan berkesan;
CHROME, jika anda ingin melihat sama ada perkara ini berkesan, anda boleh memasukkannya dalam penyemak imbas melalui pseudo-protocol CHROME, chrome://appcache-internals.
Mengenai cara mengemas kini cache aplikasi. Mengapa storan luar talian adalah setempat Apabila penyemak imbas mengetahui bahawa anda mempunyai storan luar talian, ia akan pergi ke direktori storan luar talian terlebih dahulu untuk mengetahui sama ada sumber itu telah dicache. Apabila ia telah dicache, dia akan mendapatkan sumber terus dari sini dan tidak akan menghantar permintaan lain. Sebab request browser macam ni, bila ada offline storage, request pun tak akan dihantar, jadi lebih cepat. Jika kadangkala kami perlu mengemas kini, apakah yang perlu kami lakukan semasa mengemas kini
Pengguna boleh mengosongkan Cache penyemak imbas secara manual dan storan setempat akan dikosongkan secara automatik pada masa ini.
Ubah suai mana-mana kandungan MANIFEST Ini adalah kaedah yang disyorkan, dan ia juga kaedah yang kami gunakan dalam talian. Maksudnya, kita boleh mengubah suai item tertentu di dalam, tetapi lebih baik untuk mengubah suai komen di sini, kerana setiap kali saya menerbitkan, kami mempunyai mekanisme penerbitan automatik Apabila menerbitkan, ubah suai komen di atas. Dalam kes ini, setiap kali kandungan diterbitkan, ia akan disegerakkan kepada klien tempatan dalam masa nyata;
Ia dilaksanakan melalui program dan program ialah window.applicationCache.update(). Iaitu, saya ingin mengendalikan storan luar talian, saya kadang-kadang memanggilnya storan aplikasi kerana semantiknya adalah storan aplikasi. Mari kemas kini kedai aplikasi secara manual.
　6.Web Worker
　 Seterusnya ialah Web Worker. Pekerja Web ialah proses JS berbilang benang. Sebenarnya, kami tidak mempunyai senario aplikasi dalam talian, jadi saya tidak akan menggunakannya. Tetapi saya boleh bercakap tentang senario aplikasi khusus yang saya lihat.
Mula-mula, mari perkenalkan apakah itu WEBWORK? Ia adalah urutan peringkat OS. Sebelum kami meniru multi-threading, kami sebenarnya membuka satu lagi tetingkap. Tetapi sekarang, penyemak imbas itu sendiri menyediakannya. Ini akan membawa lebih banyak kemudahan kepada operasi dan menjadikan keseluruhan dokumen kami lebih berat, yang bukan kaedah yang sangat disyorkan.
Kemudian keupayaan akses WebWorker adalah terhad, dan ia tidak boleh mengakses banyak objek global. Sebagai contoh, objek documnet tidak boleh diakses. Senario yang paling sesuai untuk WebWorker ialah operasi pengkomputeran intensif CPU. Apabila kami membuat permainan sebelum ini, kami menggunakan BOX2D. Ramai orang pasti pernah mendengar bahawa ia melibatkan banyak pengiraan, iaitu, dalam keseluruhan halaman, semua objek di bawah perlu mengira hubungan perlanggaran mereka. Jumlah pengiraan ini sangat besar. Tetapi jika ia dilaksanakan dalam proses JS semasa, jumlah pengiraan adalah besar Setelah dikira, keseluruhan halaman akan menjadi sangat tersekat. Tetapi jika anda menggunakan WebWorker untuk melakukannya, ia adalah proses tak segerak, dihantar dalam masa nyata, dan anda boleh melakukan perkara lain semasa proses pengiraan Ini adalah multi-threading.
　7. API Peranti
Mari kita bincangkan tentang API peranti. Saya fikir API peranti adalah yang paling penting dari segi prestasi, dan ia juga merupakan API terawal yang dilaksanakan pada masa ini. Satu ialah CONNECTION, iaitu lebar jalur rangkaian. Apakah yang dilakukan oleh ini? Dalam senario ini di China, kita mesti ingat bahawa kelajuan Internet ramai pengguna masih sangat rendah. Kami berharap untuk membenarkan pengguna menurunkan taraf secara automatik kepada pelan yang lebih rendah apabila kelajuan rangkaian mereka rendah. Kita tidak boleh melakukannya dengan teknologi sedia ada. Tetapi kita boleh menggunakan API peranti. Kerana kita tahu bahawa maklumat ini boleh diperolehi daripada peranti. Apakah lebar jalurnya, dan apakah yang boleh kita lakukan dengan lebar jalur itu? Sebagai contoh, apabila jalur lebar baik, saya akan menggunakan gambar definisi tinggi. Apabila lebar jalur agak rendah, gambar dengan definisi yang lebih rendah digunakan.
　8 Bateri
　Yang seterusnya ialah mengenai bateri. Saya fikir dari perspektif prestasi, ia terutamanya mengenai kuasa. Jika kuasa bateri pengguna agak rendah, saya fikir mereka harus melakukan sesedikit mungkin. Tidak pernah ada satu kejayaan dalam teknologi bateri telefon mudah alih Saya rasa menjadikan APP kelihatan lebih berprestasi tinggi juga merupakan kemuncak promosi.
　9.CANVAS
　Seterusnya ialah CANVAS. Mari kita bincangkan tentang beberapa titik pengoptimuman prestasi CANVAS Dengan menggunakan perkara ini, prestasi akan dipertingkatkan sebanyak 10 kali ganda.
Pertama, setiap CANVAS ialah kanvas Apabila kita ingin membuat grafik, kita boleh melapiskannya. Sama seperti dalam PS, terdapat satu lapisan, dua lapisan dan tiga lapisan. Apabila ramai pengguna membuat permainan, mereka terus meletakkan segala-galanya ke dalam satu lapisan, dan semuanya akan dikemas kini apabila ia dikemas kini. Tetapi jika anda melapisinya, anda meletakkan latar belakang pada lapisan latar belakang dan aksara pada lapisan aksara. Dalam kes ini, apabila saya ingin mengemas kini watak, hanya watak yang akan dikemas kini, dan lapisan latar belakang tidak perlu diubah. Biarkan CPU melakukan lebih sedikit kerja, dan prestasi secara semula jadi akan bertambah baik.
Kedua, context.drawImage. Jangan skala imej Kami membuat kesilapan pada mulanya Imej yang dibuat oleh artis kami sentiasa tidak konsisten dengan imej kami. Kerana saiz imej peranti itu sendiri adalah seperti ini, kita mesti menskalakan imej secara proporsional. Selepas mengezum gambar, kami mendapati bahawa ia akan tersekat pada peranti rendah, seperti iPad atau iPhone Kami fikir mengapa kami menjalankan analisis kod ini, ia memerlukan banyak masa.
Ketiga, requestAnimationFrame. Ini ialah kaedah yang dioptimumkan khusus untuk pemaparan. Prinsipnya ialah ini Setiap kali penyemak imbas melepasi bingkai, kaedah ini akan dicetuskan apabila saya mencetuskannya, Canvas mendapat bahawa penyemak imbas bersedia untuk melakukan bingkai seterusnya. Jika anda menggunakan kaedah tradisional, ia tidak akan mempertimbangkan lebih banyak perkara anda. Ia hanya akan mengetahui berapa lama masa telah berlalu dan saya akan melaksanakannya. Jika pengguna telah disekat sebelum ini dan kaedah ini dilaksanakan setiap 10 saat, dalam masa 10 saat, kerja sebelumnya sebenarnya belum selesai, dan kemudian kerja ini akan ditangguhkan. Ia dioptimumkan untuk menjadikan animasi kelihatan lebih lancar, kerana pada setiap bingkai, ia memberitahu anda bahawa anda boleh melakukan sesuatu. (Teks: infoq)