Module 2: ປັບປຸງຄວາມໄວຂອງເວັບມືຖື
ໃນ module ນີ້ເຮົາຈະໄດ້ຮຽນຮູ້ກ່ຽວກັບການ render ຂໍ້ມູນຂອງ browser ແລະ ການປັບປຸງສະສິຕິພາບຂອງຂໍ້ມູນທີ່ຜູ່ໃຊ້ຂອງເຮົາຈະຕ້ອງໄດ້ດາວໂຫຼດໄປ (ຂະໜາດໜ້າເວັບຂອງເຮົາ ເວລາທີ່ຜູ່ໃຊ້ເຮົາເປີດ) ແລະ ເຕັກນິກຕ່າງໆເພື່ອເພີ່ມຄວາມໄວໃຫ້ກັບເວັບຂອງເຮົາ.
2.1.1 ເຄື່ອງມືທີ່ຈຳເປັນກ່ອນຈະເລີ່ມປັບປຸງປະສິດຕິພາບເວັບມືຖື
ຂັ້ນຕອນທີ 1: ກະກຽມ DevTools
ດຽວຂໍຍົກສະຖານະການໜຶ່ງຂຶ້ນມາເນາະ ເພື່ອງ່າຍໃນການອະທິບາຍ
ສະຖະນາການນີ້ມີຢູ່ວ່າ ເຮົາໄດ້ຮັບການແຈ້ງເຕືອນຈາກຜູ່ໃຊ້ງານທີ່ເຂົ້າມາເວັບໄຊເຮົາໂດຍຜ່ານອຸປະກອນໂທລະສັບມືຖືຂອງເຂົາວ່າ ມີໜ້າເວັບຂອງເຮົາໜ້າໜຶ່ງໂຫຼດຊ້າຫຼາຍ ລອງເອົາໄປກວດເບິ່ງຄືນແນ່.
ໜ້າທີ່ຂອງເຮົາກະຄືໄປກວດເບິ່ງວ່າ ມັນຊ້າແທ້ບໍ່? ຖ້າຊ້າແທ້ ມັນຊ້າຍ້ອນຫຍັງ? ແລະ ແກ້ໄຂ ໜ້າດັ່ງກ່າວໃຫ້ມັນໄວທັນໃຈຕໍ່ຜູ່ໃຊ້ງານຜ່ານໂທລະສັບມືຖື.
ຂັ້ນຕອນທີ່ເຮົາຈະຕ້ອງປະຕິບັດ
1. ເປີດໜ້າທີ່ເຂົາສົ່ງລີ້ງມາໃຫ້ເຮົາເບິ່ງ ໃນແຖບໃໝ່
2. ລິ້ງທີ່ເຂົາສົ່ງມາໃຫ້ເຮົາກວດສອບ SLOW PAGE
3. ເມື່ອເປີດໜ້າດັ່ງກ່າວຂຶ້ນມາ ແລະ ມັນໂຫຼດສຳເລັດແລ້ວ ໃຫ້ເຮົາກົດ Command+Option+I (Mac) ຫຼື Control+Shift+I (Windows, Linux) ເພື່ອເປີດໃຊ້ເຄື່ອງມື DevTools ທີ່ຕິດມາໃນ browser (ໂຕທີ່ໃຊ້ຢູ່ແມ່ນ Chrome) ຫຼື ສາມາດເຂົ້າໄດ້ຜ່ານ Menu -> More tools -> Developer tools
4. ໃນໜ້າເຄື່ງມື ໃຫ້ເຮົາກົດແຖບ Network
5. ກົດ Capture Screenshots 
ຂັ້ນຕອນທີ 2: ຈຳລອງປະສົບການ ການໃຊ້ງານໃນສະຖານະການເປັນຜູ່ໃຊ້ງານຜ່ານມືຖື
ເປັນຫຍັງເຮົາຄືຕ້ອງທົດສອບ ຈຳລອງສະຖານະການແບບຜູ່ໃຊ້ງານຜ່ານມືຖື?
ການທົດສອບປະສິດຕິພາບອິນເຕີເນັດຢູ່ laptop ຫຼື Desktop ອາດຈະຕົວເຮົາໄດ້ ຫຼື ເວົ້ສໃນສັບທາງການຄື ມັນອາດຈະເກີດການຜິດພາດດ້ານຜົນໄດ້ຮັບກໍເປັນໄດ້ ເນື່ອງຈາກວ່າ ການໃຊ້ງານອິນເຕີເນັດຢູ່ຄອມມັນອາດຈະໄວ ແລະ ສະຖຽນກ່ວາການໃຊ້ງານຜ່ານໂທລະສັບມືຖື (ຍົກຕົວຢ່າງກໍລະນີທີ່ໃຊ້ຜ່ານ LAN) ແລະ browser ຢູ່ຄອມສາມາດເກັບ cache ຈາກການເຂົ້າເບິ່ງກ່ອນໜ້ານນີ້ໄດ້.
1. ເຮົາຈະຕ້ອງ ຕິກເອົາ Disable Cache. ເມື່ອເຮົາຕິດເອົາໂຕນີ້ DevTools ຈະບໍ່ນຳເອົາຊັບພະຍາກອນໃດໆຈາກ cache ມາໃຊ້ ເຊິ່ງມັນຈະເຮັດໃຫ້ຜົນທົດສອບຂອງເຮົາຖືກຕ້ອງຂຶ້ນ ແລະ ຈະຄືກັບວ່າເຮົາໄດ້ເຂົ້າເວັບນັ້ນໄປຄັ້ງທຳອິດ (first-time user experience).
2. ໃນສ່ວນຂອງ drop-down ເມນູ ຈະເປັນ No Throttling (ສຳລັບ ຂອງເຈົ້າຂອງບັລອກ ໃຊ້ Chrome 64 beta ມັນຈະເປັນ Online) ໃຫ້ເລືອກ Regular 3G (Chrome 64 beta slow 3G). ເຮົາປັບໂຕນີ້ກໍເພື່ອໃຫ້ DevTools ຄວບຄຸມຄວາມໄວຂອງການເຊື່ອມຕໍ່ອິນເຕີເນັດຂອງເຮົາໃຫ້ຈຳລອງສະພາບແວວລ້ອມວ່າເຮົາກຳລັງໃຊ້ອິນເຕີເນັດ 3G ທີ່ຄວາມໄວແມ່ນເຂົ້າຂັ້ນຊ້າ ເຊິ່ງສະຖານະການນີ້ແມ່ນເປັນສະຖານະການທົ່ວໄປທີ່ຜູ່ໃຊ້ໂທລະສັບມືຖືຈະພົບເຈີກັນຖ້າຢູ່ໃນເຂດສັນຍານບໍ່ດີ (ໂດບສະເພາະຢູ່ ນະຄອນຫຼວງວຽງຈັນ).
ທີ່ສຳຄັນຂອງການຈຳລອງສະຖານະການທີ່ດີທີ່ສຸດກໍຄື ເຮົາຈະຕ້ອງຈຳລອງສະຖານະການທີ່ໂຫດຮ້າຍທີ່ສຸດ. ຖ້າເຮົາຕັ້ງຄ່າແບບນີ້ແລ້ວ ເວັບເຮົາໂຫຼດໄວຂຶ້ນ ສະແດງວ່າ ມັນກໍຈະໄວສຳລັບທຸກໆຄົນທີ່ເຂົ້າມາເວັບໄຊເຮົາ 😉
ຂັ້ນຕອນທີ 3: ວິເຄາະຜົນຈາກການເບິ່ງ request
ເຮົາຕ້ອງມາວິເຄາະເບິ່ງວ່າ ເວັບເຮົາມັນໂຫຼດຊ້າຍ້ອນຫຍັງ ໂດຍກົດ refresh ໜ້າຄືນ, ຫຼັງຈາກນັ້ນກະວິເຄາະຈາກການ request ທີ່ເຂົ້າມາ.
ສ່ວນທີ ກ: ຊອກຫາ script ທີ່ມັນບັລອກການສະແດງຜົນ (render-blocking scripts)
1. ກົດ Command+R (Mac) ຫຼື Control+R (Windows, Linux) ເພື່ອ reload/refresh ໜ້າຄືນໃໝ່.
2. ຈື່ຄ່າ (ຈົດດີກ່ວາຈື່) ຂອງ DOMContentLoaded ໄວ້ (ມັນຈະຢູ່ດ້ານລຸ່ມ ໂຕໜັງສືສີຟ້າ) ໃນໜ້າສະຫຼຸບຜົນ (summary page). ທ່ານຈະເຫັນວ່າຄ່າຂອງ DOM ນັ້ນສູງກ່ວາ 4ວິນາທີ (ປົກກະຕິດີແທ້ແມ່ນ ຕ້ອງຕ່ຳກ່ວາ 4ວິນາທີ). ຖ້າທ່ານເຫັນແບບນີ້ ທ່ານຕ້ອງກວດສອບເບິ່ງວ່າ script ໂຕໃດເຮັດໃຫ້ main document ໂຫຼດຊ້າ ແລະ ວິເຄາະມັນ.
3. ກົດທີ່ main.js ເພື່ອເຂົ້າໄປເບິ່ງ request.
4. ກົດແຖບ preview ເພື່ອເບິ່ງ source code ການ request . ທ່ານຈະເຫັນວ່າໃນ script ນີ້ ມັນບອກໃຫ້ຖ້າເຖິງ 4000ms (4s). ວິທີແກ້ກະຄື ເຮົາຈະເພີ່ມ tag attribute “async” ແລະ ຍ້າຍມັນລົງໄປທາງລຸ່ມຂອງ tag <body>, ໜ້າເວັບຈະສາມາດໂຫຼດໂດຍບໍ່ຈຳເປັນຕ້ອງຖ້າໃຫ້ script ນີ້ເຮັດວຽກແລ້ວ.
ສຳລັບຂໍ້ມູນເພີ່ມຕື່ມກ່ຽວກັບ render-blocking script Parser-blocking versus asynchronous JavaScript.
ສຳລັບໃຜຂີ້ຄ້ານເຂົ້າໄປອ່ານ ດຽວຈະອະທິບາຍແບບສັ້ນໆ ເຂົ້າໃຈງ່າຍໆ ເລີຍກະຄື:
ປົກກະຕິແລ້ວ ເວລາ browser ເຮົາໂຫຼດໜ້າເວັບເຮົາ ມັນຈະເບິ່ງ source code ໜ້າເວັບຂອງເຮົາ ແລະ ໄລ່ລົງໄປແຕ່ລະແຖວ. ແຕ່ວ່າ ຫຼັກການດັ່ງກ່າວນີ້ ຖ້າມັນເຈີ tag ທີ່ເປັນ script ມັນຈະຢຸດ DOM construction ແລ້ວ execute script ໂຕນີ້ໃຫ້ແລ້ວຈຶ່ງເລີ່ມສືບຕໍ່ໄປແຖວຕໍ່ໄປ (proceeding with DOM construction). ມັນຈະເຮັດໃຫ້ໜ້າເວັບເຮົາໂຫຼດຊ້າກະຍ້ອນຖ້າ execute script ນິລະ ຍິ່ງຮ້າຍຖ້າ script ເຮົາຢູ່ນອກ (eternal JavaScript) browser ຂອງເຮົາຈະຕ້ອງຖ້າໃຫ້ script ເຮົາຖືກເອີ້ນຈາກ ໜ່ວຍຄວາມຈຳ (disk) ລະກະຕ້ອງໄດ້ cache ໄວ້ ຫຼື remote server ເຊິ່ງການເຮັດວຽກທີ່ກ່າວມານີ້ຈະເພີ່ມໄລຍະເວລາເກືອບໆ 10ວິນາທີ ໃນການ render.
ສ່ວນວິທີແກ້ບັນຫານີ້ກະຄື ໃຊ້ “async” script attribute tag ໃສ່ ເພື່ອບອກໃຫ້ browser ຮູ້ວ່າ ບໍ່ຈຳເປັນຕ້ອງຢຸດການເຮັດວຽກຂອງ DOM construction ໃນຂະນະທີ່ຖ້າ execute script ດັ່ງກ່າວໃຫ້ແລ້ວ. ເຊິ່ງວິທີນີ້ຈະຊ່ວຍປັບປຸງປະສິຕິພາບການໂຫຼດໜ້າເວັບເຮົາໄດ້ດີຂຶ້ນຫຼາຍເຕີບ.
ສ່ວນ ຂ: ຄົ້ນຫາການຂໍ request ຂະໜາດໃຫຍ່ (large request)
ເວລາທີ່ໜ້າເວັບຖືກໂຫຼດແລ້ວໆ ທ່ານສັງເກດເຫັນບໍ່ວ່າ ໂລໂກ້ຮູບ DevTools ໃຊ້ເວລາໃນການໂຫຼດດົນ, ມັນບໍ່ໄດ້ມີສ່ວນໃນການຢຸດບໍ່ໃຫ້ໜ້າມັນໂຫຼດ ແຕ່ມັນເຮັດໃຫ້ໜ້າເວັບເຮົາເບິ່ງຄືວ່າໂຫຼດຊ້າ.
ເມື່ອເຮົາໃຊ້ເມົ້າລາກໄປເບິ່ງໂຕ timelines ແລ້ວເຮົາຈະເຫັນວ່າ ຮູບໃຊ້ເວລາໂຫຼດດົນ.
ຂັ້ນຕອນທີ 4: ແກ້ໄຂ ແລະ ທົດສອບໜ້າທີ່ໄດ້ຮັບການປັບປຸງແລ້ວ
ສົມມຸດວ່າເຮົາສຳເລັດການແກ້ໄຂເວັບເຮົາ ໂດຍການແກ້ໄຂໄປສອງຈຸດດ້ວຍກັນຄື:
- ຍ້າຍ script ໄປໄວ້ທາງລຸ່ມຂອງ <body> ແລະ ໃຊ້ async attribute tag ເພື່ອປ້ອງກັນບໍ່ໃຫ້ມັນຢຸດບໍ່ໃຫ້ໜ້າເວັບເຮົາໂຫຼດ ແລະ ບໍ່ຕ້ອງລໍຖ້າໃຫ້ execute script ຈົນສຳເລັດຈຶ່ງສາມາດສືບຕໍ່ເຮັດອັນອື່ນຕໍ່ໄປໄດ້.
- ປ່ຽນຮູບໃຫ້ເປັນຟາຍ SVG ເພື່ອຫຼຸດຂະໜາດຂອງຮູບລົງ
ສົມມຸດວ່າເຮົາປ່ຽນແລ້ວໆ ເຂົ້າໄປເບິ່ງໜ້າເວັບທີ່ເຮົາປັບປຸງ FAST PAGE ໂດຍການຕັ້ງຄ່າແບບເກົ່າເຮົານັ້ນລະຄື disable cache, ປັບເນັດໃຫ້ເປັນ slow 3G (Regular 3G). ເຫັນບໍ່ວ່າເວັບເຮົາໂຫຼດໄວຂຶ້ນ huh!
2.1.2 ມາຮູ້ຈັກກັບຄຳວ່າ low bandwidth ແລະ high latency
ຫົວຂໍ້ນີ້ຂໍຜ່ານ
2.1.3 ສິ່ງທີ່ຕ້ອງເອົາໃຈໃສ່
ດຽວເຮົາຈະມາເບິ່ງກັນວ່າ ສິ່ງທີ່ເຮົາຈະຕ້ອງເບິ່ງເພື່ອໃຫ້ເຮົາຮູ້ວ່າເຮົາຈະຕ້ອງປັບປຸງປະສິຕິພາບເວັບເຮົາສຳລັບໂທລະສັບແນວໃດແນ່ ມາເບິ່ງໂຕຊີ້ວັດກັນເລີຍ:
- ເວລາທີ່ສາມານຳໃຊ້ໄດ້ (Usable Time): ໝາຍວ່າ ເວລາທີ່ຜູ່ທີ່ເຂົ້າມາເວັບເຮົາຈະໄດ້ໃຫ້ເນື້ອຫາຂອງເຮົາໂຊຂຶ້ນໜ້າຈໍຂອງເຂົາ ຖ້າເວົ້າໃນສັບເຕັກນິກແມ່ນ “above-the-fold” ເຮົາຈະຕ້ອງສະແດງໃຫ້ໄວເທົ່າທີຈະໄວໄດ້. ການທີ່ເຮົາສາມາດໂຫຼດເນື້ອຫາທີ່ຈຳເປັນ ແລະ ສຳຄັນກ່ອນ ແລະ ສາມາດເຮັດໃຫ້ເວັບເຮົາສາມາດໃຊ້ໄດ້ພາຍໃນເວລາ 3ວິນາທີ.
- Total request ຈຳນວນຕົວເລກຂອງຊັບພາຍາກອນ request ທີ່ຈຳເປັນທີ່ຈະສ້າງໜ້າເວັບໃດໜຶ່ງຄວນຢູ່ໃນລະຫວ່າງ 80 ຫາ 100 request. ຖ້າມີຫຼາຍກ່ວານີ້, ທ່ານຕ້ອງປະເມີນວ່າໂຕໃດທີ່ບໍ່ຈຳເປັນ ແລະ ສາມາດຕັດອອກໄດ້ແນ່ ຫຼື ລວມ request ທີ່ຄືກັນຢູ່ນຳກັນ (combining specific request).
- ຂະໜາດຂອງໜ້າເວັບ (Page weight) ຊັບພະຍາກອນທັງໝົດທີ່ໃຊ້ສ້າງໜ້າໃດໜ້າໜຶ່ງບໍ່ຄວນໃຫຍ່ກ່ວາ 1MB. ຖ້າວ່າໃຫຍ່ກ່ວານີ້, ລອງປະເມີນຄືນເບິ່ງວ່າໂຕໃດບໍ່ຈຳເປັນກະຕ້ອງຕັດອອກ ຫຼື ບໍ່ກະຕ້ອງບີບອັດມັນໂຕທີ່ສາມາດບີບອັດໄດ້ (compressing where where possible)
ຕາຕະລາງດ້ານລຸ່ມແມ່ນ ຂໍ້ແນະນຳໃນສ່ວນຂອງຊັບພະຍາກອນແຕ່ລະສ່ວນໃນການສ້າງໜ້າເວັບ.
| Main Element | Target Request Ranfe |
|---|---|
| JS | <20 (not including pixels) |
| CSS | <5 |
| Images | <30 |
| Font | 0-3 |
| Total | 100 |
2.2 Critical rendering path
ການປັບປຸງ critical rendering path ໝາຍເຖິງ ການຈັດອັນດັບຄວາມສຳຄັນເນື້ອຫາວ່າຈະສະແດງອັນໃດກ່ອນເພື່ອໃຫ້ມັນເຂົ້າກັບພຶດຕິກຳຂອງຜູ່ໃຊ້ໃນຊ່ວງເວລານັ້ນໆ.
ການນຳເອົາປະສົບການ ການເຂົ້າເວັບໄຊທີ່ໄວນັ້ນ browser ຂອງເຮົາຈະຕ້ອງໄດ້ເຮັດວຽກຫຼາຍໆຢ່າງ ແລະ ວຽກສ່ວນຫຼາຍແມ່ນຈະຢູ່ເບື້ອງຫຼັງ. ການປັບປຸງປະສິດຕິພາບໃນນີ້ແມ່ນໝາຍເຖິງ ເຮົາຈະຕ້ອງເຂົ້າໃຈວ່າ ການ render ນັ້ນມັນເຮັດວຽກແນວໃດ.
2.2.1 Constructing the document object model
ກ່ອນ browser ຂອງເຮົາຈະ render ໜ້າເວັບໃດໜຶ່ງ ມັນຕ້ອງການຈັດຮູບແບບ (construct) DOM ແລະ CSSOM tree. ສະນັ້ນ, ເຮົາຈຶ່ງຕ້ອງໝັ້ນໃຈວ່າທັງ HTML ແລະ CSS ແມ່ນໄດ້ຖືກສົ່ງໃຫ້ browser ໄວເທົ່າທີ່ຈະໄວໄດ້.
ເລີ່ມຈະກໍລະນີທຳມະດາເບິ່ງກ່ອນ: ເວັບທີ່ມີ HTML ປະກອບດ້ວຍ Text ແລະ ຮູບໜຶ່ງພາບ. browser ຂອງເຮົາຈະ render ໜ້ານີ້ແນວໃດ?
1. Conversation: browser ຂອງເຮົາຈະອ່ານຄ່າຂອງ code HTML ຂອງເຮົາຈາກ ໜ່ວຍຄວາມຈຳ (disk) ຫຼື ຜ່ານ server ໂດຍຄ່າທີ່ browser ອ່ານນັ້ນຈະເປັນໃນຮູບແບບຂອງ raw byte ແລ້ວ browser ເຮົາຈະແປຄ່ານີ້ອອກມາເປັນແຕ່ລະ character ເຊິ່ງການແປນີ້ແມ່ນໄດ້ອີງຕາມການແປຄ່າ (encode) ສະເພາະເຈາະຈົງຂອງຟາຍນັ້ນໆ ເຊັ່ນ UTF-8.
2. Tokenizing: browser ຂອງເຮົາຈະປ່ຽນຄ່າທີ່ອ່ານໄດ້ຈາກ string of character ມາເປັນ distinct token ຕາມແບບຂອງ W3C HTML5 standard ເຊັ່ນ: <html>, <body> ແລະ string ອື່ນໆທີ່ຢູ່ໃນ <>. ແຕ່ລະ token ຈະມີຄວາມໝາຍພິເສດແຕກຕ່າງກັນໄປ.
3. Lexing: token ທີ່ໄດ້ຖືກປ່ຽນມາແລ້ວນັ້ນຈະຖືກປ່ຽນຮູບແບບອີກເທື່ອໜຶ່ງມາເປັນໃນຮູບແບບຂອງ “object” ທີ່ໃຫ້ຄ່າ properties ແລະ rules.
4. DOM construction: ກໍ່ຈະເປັນຂັ້ນຕອນສຸດທ້າຍຂອງທັງໝົດທັງມວນກ່ອນທີ່ມັນຈະສະແດງຜົນເປັນໜ້າເວັບໃຫ້ເຮົາ ວິທີການເຮັດວຽກຂອງມັນກະຄື ມັນຈະນຳເອົາ HTML markup ທີ່ໄດ້ລະບຸຄວາມສຳພັນກັນລະຫວ່າງ tag ຕ່າງໆ (ບາງ tag ຍັງມີ tag ທີ່ເປັນລູກຂອງມັນອີກ ເຊັ່ນ tag <body> ຍັງຈະຕ້ອງມີ <div> ແລ້ວ <div> ຍັງຈະຕ້ອງມີລູກຂອງມັນອີກຄື <p> ແລ້ວຍັງບໍ່ໝົດ <p> ອາດຈະມີລູກຂອງມັນອີກທີ່ເປັນ <span> ແລະ ຕໍ່ໆໄປ), ຫຼັງຈາກນັ້ນ object ທີ່ຖືກສ້າງມານັ້ນຈະຖືກລິ້ງເຂົ້າໃນ tree data structure (ຈະອະທິບາຍຕາມຫຼັງ) ເຊິ່ງມັນຈະຈັບເອົາ ຄວາມສຳພັນ HTML markup ລະຫວ່າງເຄື່ອຂອງ ພໍ່ແມ່ ແລະ ລູກໆຂອງມັນເຂົ້າກັນ (parent-child) (ໃຊ້ສັບແບບອົບອຸ່ນດີ ແຮະໆ). ໂຕ markup ດັ່ງກ່າວນີ້ ຈະປະກອບມີ HTML object (<html>) ທີ່ເປັນ ພໍ່ແມ່ ຂອງ object ຂອງ body <body>, body ກະຍັງຕ້ອງໄດ້ເປັນ ພໍ່ແມ່ ຂອງ paragraph (<p>) ແລະ ຕໍ່ໄປຈົນຮອດລຸ້ນລູກລຸ້ນຫຼານ.
ຮູບໂຄງຮ່າງ ຜົນໄດ້ຮັບຫຼັງຈາກ Document Object Model (DOM) ທີ່ປະມວນຜົນໜ້າເວັບແບບບ້ານໆຂອງເຮົາສຳເລັດເປັນທີຮຽບຮ້ອຍແລ້ວ.
ທຸກໆຄັ້ງທີ່ browser ຂອງເຮົາ ປະມວນຜົນ HTML markup ມັນຈະເຮັດຕາມຂັ້ນຕອນຄືຮູບຂ້າງເທິງນັ້ນລະຄື covert bytes to character -> identify tokens -> convert tokens to nodes -> build the DOM tree. ຖ້າເຮົາມີຟາຍ HTML ທີ່ໃຫຍ່ ການປະມວນຜົນຂອງຂັ້ນຕອນທັງໝົດນີ້ອາດຈະກິນເວລາເປັນແນ່ພໍສົນຄວນ.
ຈາກຮູບດ້ານເທິງ ເຮົາສາມາດເຂົ້າໄປເບິ່ງ timeline ຂອງການເຮັດວຽກຂອງ DOM ໄດ້, ຖ້າເຮົາເບິ່ງຮູບແລ້ວ ຈະເຫັນວ່າ DOM ປະມວນຜົນ HTML ໃຫ້ເປັນ DOM tree ຈະໃຊ້ເວລາປະມານ 5ວິນາທີ. ຖ້າໜ້າເວັບເຮົາໃຫຍ່ ມັນກໍຈະໃຊ້ເວລາຫຼາຍກ່ວານນີ້. ສະນັ້ນ, ເວລາທີ່ເຮົາສ້າງ animation ງາມໆມາຈັກອັນໜຶ່ງ ຜົນທີ່ຕາມມາກໍ່ຄືເຮັດໃຫ້ເກີດບັນຫາຄໍຂວດ (bottleneck) ມັນຈະເຮັດໃຫ້ browser ປະມວນຜົນໜັກຂຶ້ນ ແລະ ໃຊ້ເວລາດົນ .
ເຮົາຢ່າລືມວ່າ DOM tree structure ນັ້ນ ເປັນພຽງສ່ວນໜຶ່ງຂອງການປະມວນຜົນຂອງ browser ຂອງເຮົາກ່ອນທີ່ມັນຈະສະແດງໜ້າງາມໆໃຫ້ເຮົາເບິ່ງ ເພາະ DOM ຈັບເອົາແຕ່ property ແລະ relationship ຂອງ Document markup (HTML markup) ເທົ່ານັ້ນ, ແຕ່ມັນບໍ່ໄດ້ capture ເອົາສ່ວນທີ່ browser ຈະສະແດງສ່ວນຕ່າງໆຂອງເວັບໄຊນັ້ນອອກມາໜ້າຕາຈະເປັນແນວໃດ, ເຊິ່ງວ່າສ່ວນໂຕນີ້ ໂຕທີ່ຈະແຕ່ງໜ້າໃຫ້ກັບເວັບເຮົາກ່ອນຈະສະແດງຮູບໂສມໜ້າອັນງົດງາມຂອງເວັບເຮົາກ່ອນຈະໃຫ້ເຮົາເບິ່ງນັ້ນ ຈະແມ່ນ CSSOM ເປັນຄົນຮັບຜິດຊອບແຕ່ງໜ້າ (ໄກ່ງາມຍ້ອນຂົນ ເວັບງາມຍ້ອນແຕ່ງ) ບໍ່ແມ່ນລະ ອອກທະເລແລ້ວ ອິໆ.
CSS Object Model (CSSOM)
ໃຫ້ເຮົານຶກພາບວ່າ ເຮົາກຳລັງຫຼິ້ນເກມສ້າງໂຕລະຄອນ The Sim ປຽບທຽບ browser ເປັນໂຕເຮົາເອງ ແລ້ວ ແຂນ, ຂາ, ຕີນ, ຜົມ ສ່ວນປະກອບອື່ນໆຂອງຮ່າງກາຍຂອງເຮົາເປັນ DOM structure, ແລ້ວຂັ້ນຕອນສຸດທ້າຍກະຄື ນຸ່ງເຄື່ອງ, ແຕ່ໜ້າ, ໃສ່ເກີບໃຫ້ໂຕລະຄອນຂອງເຮົາ ໂຕນີ້ປຽບທຽບເປັນ CSS DOM ຫຼັງຈາກນັ້ນ ເຮົາກໍ່ໄດ້ໂຕລະຄອນຕາມທີ່ເຮົາຕ້ອງການແລ້ວ ເລີ່ມຫຼິ້ນໄດ້!
ກັບໆ ກັບມາ ສະໝົງສະໝອງ ກັບມາເຂົ້າບົດຮຽນຂອງເຮົາຕໍ່
ໃນຂະນະທີ່ browser ຂອງເຮົາກຳລັງສ້າງຮູບແບບຂອງ DOM tree ຢູ່ນັ້ນ, ມັນຊ້ຳພັດຫຼຽວໄປເຫັນ link tag ໃນສ່ວນຂອງ head (<header>) ໃນ code ຂອງ HTML ຂອງເຮົາ ເຊິ່ງ tag ດັ່ງກ່າວບົ່ງບອກເຖິງ (reference, ບອກໃຫ້ມັນຮູ້ວ່າ) ມີ CSS stylesheet ມາຈາກຂ້າງນອກໄດ໋ນິ (ບໍ່ໃຜ ຄົນໃກ້ຄົນໄກນິລະ ນັ້ນຄື ຟາຍ css ນັ້ນເອງ (style.css)). ລອງນຶກພາບເບິ່ງວ່າ browser ຂອງເຮົາຕ້ອງການຟາຍນີ້ເພື່ອ render ໜ້າເວັບຂອງເຮົາ, ມັນເລີຍບໍ່ຖ້າຫຍັງຫຼາຍ ແລ່ນເຂົ້າໄປອ່ານຟາຍນັ້ນເລີຍ ແລະ ສິ່ງທີ່ມັນອ່ານໄດ້ຈະເປັນປະມານນີ້:
body { font-size: 16px }
p { font-weight: bold }
span { color: red }
p span { display: none }
img { float: right }
ແລ້ວຕ້ອງມີຄົນຕັ້ງຄຳຖາມຂຶ້ນມາແຫຼະວ່າ ອ້າວເປັນຫຍັງຕ້ອງເຮັດຟາຍ CSS ແຍກ ທີ່ຈິງແລ້ວເຮົາບໍ່ຈຳເປັນຕ້ອງເຮັດແຍກກະໄດ້ ຍັດມັນໄປພ້ອມຟາຍ HTML ໂລດນ່າ?
ຕອບ: ບໍ່ຈຳເປັນຕ້ອງເຮັດຟາຍ CSS ແຍກຈາກຟາຍ HTML ກະໄດ້ ຍັດມັນ (inline) ໃສ່ HTML ເລີຍ. ແຕ່ໃຫ້ເຮົາລອງນຶກພາບເບິ່ງວ່າ ການທີ່ເຮົາແຍກຟາຍ HTML ແລະ CSS ໄວ້ຕ່າງຫາກ ຈະເຮັດໃຫ້ການຂຽນໂຄດຂອງເຮົາ ແລະ ການອ່ານໂຄດຂອງເຮົາເປັນລະບຽບ ແລະ ສະບາຍຕາ, ອີກຢ່າງຄືການອອກແບບ (design) ແລະ ເນື້ອຫາ (content) ນັ້ນມັນກະຄົນລະສ່ວນກັນ. ຖ້າເຮົາເຮັດວຽກເປັນທີມ ກະປຽບເໝືອນ ນັກອອກແບບ (designer) ກະອອກແບບໄປເຮັດວຽກແຕ່ໃນສ່ວນຂອງ CSS, ສ່ວນນັກພັດທະນາ (developer) ກະມີໜ້າທີເຮັດເນື້ອຫາລູກດຽວ (HTML) ມັນຈະສະດວກບໍ່ວ່າບໍ່ສັບສົນໜ້າວຽກຂອງກັນ ແລະ ກັນ.
CSS ມັນກະຄືກັນກັບ HTML ຫັ້ນລະ ມັນກໍ່ຈະມີກົດ ແລະ ວິທີການຂອງມັນທີ່ຈະເຮັດໃຫ້ browser ຂອງເຮົາສາມາດເຂົ້າໃຈ ແລະ ເຮັດວຽກຮ່ວມກັບມັນໄດ້, ຫຼັກການ ແລະ ຂັ້ນຕອນກໍຈະຄ້າຍໆກັບ HTML ຕ່າງແຕ່ວ່າປ່ຽນຈາກ HTML ເປັນ CSS
ຮູບແບບງ່າໄມ້ຂອງມັນຈະເປັນປະມານຄືຮູບດ້ານລຸ່ມ
ເປັນຫຍັງ CSSOM ຈຶ່ງມີ tree structure?
ຕອບ: CSS ແມ່ນຫຍໍ້ມາຈາກ Cascading Style Sheets ແນ່ນອນຊື່ມັນກະບອກຢູ່ແລ້ວວ່າ Cascade ມັນກະຕ້ອງເຮັດວຽກຄືກັບນ້ຳຕົກ ກະຄືເປັນຂັ້ນໆຕັ້ງແຕ່ເທິງຈົນຕົກມາຮອດລຸ່ມ ເຮົາຕ້ອງ CSS ໃສ່ object ໃດໜຶ່ງ ສິ່ງທີ່ browser ເຮົາຈະເຮັດກໍຄືມັນຈະນຳເອົາ CSS ໂຕທີ່ເຮົາຕັ້ງໃນໃສ່ object ດັ່ງກ່າວ ເຊັ່ນຕົວຢ່າງ ຖ້າເຮົາຕັ້ງ CSS ໃສ່ node ທີ່ເປັນ parent (<body>) ແລ້ວ node ທັງຫຼາຍທີ່ເປັນ node ລູກຂອງ <body> ກໍ່ຈະຖືກໃສ່ CSS ທີ່ເຮົາຕັ້ງໄວ້ຄືກັນກັບຂອງ parent ນັ້ນໆ ຫຼັກການແບບນີ້ກະເຈົ້າເອີ້ນວ່າ “cascade down”.
ເພື່ອໃຫ້ເຮົາເຫັນພາບຫຼາຍຍິ່ງຂຶ້ນ ແລະ ຊັດເຈນຍິ່ງຂຶ້ນ ໃຫ້ເຮົາເບິ່ງຮູບຮ່າງງ່າໄມ້ຂ້າງເທິງ. ທຸກໂຕໜັງສື (text) ທີ່ຢູ່ໃນ span tag ແລະ ເປັນ tag ລູກຂອງ body ໂຕໜັງສືຈະແມ່ນຂະໜາດ 16 pixel ແລະ ໜັງສືສີແດງ, ເຮົາຈະສັງເກດເຫັນວ່າເຮົາຕັ້ງ CSS ໃສ່ parent tag body ເປັນໂຕໜັງສືຂະໜາດ 16 pixel ແນ່ນອນວ່າ ໂຕໜັງສືທີ່ຢູ່ພາຍໃຕ້ tag ລູກຂອງ body ກໍຈະເປັນຂະໜາດ 16 pixel ຄືກັນ (cascade down). ແຕ່ວ່າ, ຖ້າເຮົາມາເບິ່ງ span tag ທີ່ເປັນ tag ລູກຂອງ paragraph (p) ເນື້ອຫາຈະບໍ່ຖືກສະແດງ ຍ້ອນຫຍັງ? ອ່ານຕໍ່ຂ້າງລຸ່ມ.
ເຮົາຕ້ອງເຂົ້າໃຈວ່າ CSS cascade rule ນັ້ນຈະຕ້ອງເບິ່ງວ່າ ໂຕໃດປະກາດຫຼັງສຸດແມ່ນຈະເອົາໂຕນັ້ນເຊັ່ນ
h1 {
color: red;
}
h1 {
color: bule;
}
ຈາກຂ້າງເທິງ CSS ຈະສະແດງ h1 ເປັນສີຟ້າ.
ອີກກໍລະນີໜຶ່ງກໍແມ່ນໂຕໃດເຈາະຈົງກ່ວາ ຈະເອົາໂຕນັ້ນ
body h1 {
color: red
}
h1 {
color: blue
}
ໂຕໜັງສືຈະເປັນສີແດງ ເພາະເຮົາໃຊ້ຄຳສັ່ງທີ່ເຈາະຈົງກ່ວາ.
ແລະ ທີ່ສຳຄັນໃຫ້ເຮົາຈື່ໄວ້ວ່າ ໂຕຮູບຮ່າງງ່າໄມ້ຂ້າງເທິງນັ້ນບໍ່ແມ່ນ CSSOM tree ທີ່ສົມບູນ ມັນໂຊແຕ່ CSS style ທີ່ເຮົາຕ້ອງການຈະປັບປ່ຽນມັນຈະ ຄ່າເລີ່ມຕົ້ນ (default) ຂອງ browser ເທົ່ານັ້ນ. ທຸກໆ browser ຈະມີຄ່າເລີ່ມຕົ້ນຂອງຕົນໃນການຕັ້ງຄ່າ CSS style ທີ່ເຮົາເອີ້ນວ່າ “user agent styles”.
ຖ້າເຮົາຕ້ອງການຢາກຮູ້ວ່າ CSS ເຮົາໃຊ້ເວລາໃນການປະມວນຜົນດົນເທົ່າໃດ ເຮົາກໍສາມາດເບິ່ງໄດ້ຈາກ DevTools ແລະ ຊອກຫາ event ຊື່ວ່າ “Recalculate Style”.
2.2.2 The render tree
render tree ຈະເປັນການເຮັດວຽກໜຶ່ງຂອງ browser ຫຼັງຈາກທີ່ browser ຂອງເຮົາໄດ້ DOM ແລະ CSSOM ມາເປັນທີ່ຮຽບຮ້ອຍແລ້ວ ແລະ ຖ້າເຮົາເບິ່ງຢູ່ DevTools ເຮົາຈະບໍ່ເຫັນການເຮັດວຽກຂອງໂຕນີ້ ເພາະ browser ບໍ່ສະແດງໃຫ້ເບິ່ງ. ທັງ DOM ແລະ CSSOM ລວມກັນກໍ່ຈະໄດ້ render tree ເປັນຂັ້ນຕອນສຸດທ້າຍ ແທ້ ທ້າຍວ່າ ກ່ອນ ມັນຈະສະແດງໜ້າຕາເວັບເຮົາອອກມາ.
ດຽວເຮົາຈະມາເບິ່ງວີດີໂອກັນວ່າ browser ຂອງເຮົາມັນສ້າງ render tree ໄດ້ແນວໃດ ຫຼັງຈາກທີ່ໄດ້ DOM ແລະ CSSOM ມາແລ້ວ
[0:50] ອະທີບາຍວ່າ ເຮົາຈະຕ້ອງມາເບິ່ງ DOM ກັບ CSSOM ທຽບກັນວ່າມີ node ໃດແນ່ທີ່ DOM ແລະ CSSOM ມັນມີຄືກັນ. ກໍລະນີນີ້ຄື node <p> ເຊິ່ງຢູ່ paragraph ເຮົາໄດ້ ຕັ້ງ CSS ໄວ້ຄື font-size: 16px ແລະ font-weight: bold.
[1:20] ເຮົາເຫັນວ່າ node (p) ມີ child node ຄື span, ພໍເຮົາມາສັງເກດເບິ່ງ span ໃນ CSS ເຮົາໄດ້ຕັ້ງຄ່າມັນໄວ້ວ່າ display: none ໝາຍຄວາມວ່າ ເນື້ອຫາໃນ span ໃນ node ຂອງ p ນັ້ນຈະບໍ່ຖືກສະແດງ ເນື່ອງຈາກວ່າ render tree ຈະຈັບ (capture) ເອົາແຕ່ສ່ວນທີ່ສາມາດສະແດງໄດ້. ດັ່ງນັ້ນ, span node ໃນ node ຂອງ p ຈຶ່ງບໍ່ຖືກນຳເອົາໄປສະແດງ ແລະ ບໍ່ຖືກນຳໄປໃສ່ render tree.
2.2.3 The layout
ຫຼັງຈາກທີ່ເຮົາສຳເລັດການສ້າງ render tree ແລ້ວ, ຂັ້ນຕອນຕໍ່ໄປຈາກນີ້ແມ່ນການຈັດ layout ວ່າ node ແຕ່ລະໂຕຈະສະແດງໃນຕຳແໜ່ງໃດ ແລະ ຂະໜາດເທົ່າໃດ.
ບັນຫາໜຶ່ງທີ່ຫຼາຍຄົນມັກພົບເຫັນກໍຄື ການທີ່ layout ເຮົາຈັດມັນບໍ່ responsive ກັບໜ້າຈໍ ບາງເທື່ອເຮົາເຂົ້າເວັບໃດໜຶ່ງແລ້ວ ໂຕໜັງສືມັນກາຍໜ້າຈໍຂອງເຮົາ ເຮົາຕ້ອງໄດ້ເລື່ອນໄປທາງຂ້າງເພື່ອອ່ານສ່ວນທີ່ເຫຼືອ ດັ່ງນັ້ນການທີ່ເຮົາຕັ້ງ “viewpoint” ໃຫ້ກັບເວັບເຮົາຈະເຮັດໃຫ້ມັນ responsive ກັບໜ້າຈໍທຸກໆໜ້າຈໍ.
ອ່ານເພີ່ມຕື່ມ viewpoint | Progressive web app
ແຖມເທັກນິກ່ຽວກັບ responsive website
ເປັນຫຍັງ px ຈຶ່ງບໍ່ຄວນໃຊ້ ແລະ ຄວນໃຊ້ %?
ເພາະວ່າດຽວນີ້ໜ້າຈໍທີ່ເຮົາໃຊ້ທ່ອງເວັບຂອງເຮົາ ມັນມີຫຼາກຫຼາຍຂະໜາດ ການທີ່ເຮົາຕັ້ງ CSS ຂອງເຮົາໃຫ້ມັນເປັນ px ເຊັ່ນ ຂະໜາດຮູບ ເປັນຕົ້ນ ເພາະຖ້າເຮົາຕັ້ງຂະໜາດຮູບໃນ px ທີ່ນ້ອຍ ເວລາໄປສະແດງ ໃນໜ້າຈໍທີ່ມີຂະໜາດ pixel ທີ່ໃຫຍ່ ຮູບເຮົາກໍຈະນ້ອຍທັນທີເລີຍສະນັ້ນ ເຮົາຄວນໃຊ້ % ໃນການຕັ້ງຂະໜາດເຊັ່ນ width: 100% ສະແດງວ່າ ຍາມໃດມັນກະສະແດງຂະໜາດ 100% ຕາມຂະໜາດໜ້າຈໍ.
ສ່ວນຂະໜາດ font ດຽວນີ້ແມ່ນກະເຈົ້າຈະໃຊ້ຫົວໜ່ວຍເປັນ em, 1em = 12pt = 16px = 100%
2.2.4 ວິເຄາະ Critical Render Path ຂັ້ນຕອນທັງໝົດໃນ DevTools
2.2.5 ປັບປຸງປະສິຕິພາບ critical render path
ຖ້າເຮົາຢາກໄດ້ການ render ໃນຄັ້ງທຳອິດ (first render) ທີ່ໄວ ເຮົາຄວນເຮັດໃຫ້ຕົວປ່ຽນທັງສາມຕົງຂ້າງລຸ່ມນີ້ມີຄ່າທີ່ນ້ອຍສຸດ:
- The number of critical resource.
- The critical path length.
- The number of critical bytes.
Critical resource ໝາຍເຖິງ ຊັບພະຍາກອນ (resource) ທີ່ອາດຈະໄປບັລອກ (block) ການ render ໜ້າເວັບຕອນທຳອິດ. ຊັບພະຍາກອນໜ້ອຍສ່ຳໃດ ຍິ່ງເຮັດໃຫ້ browser, CPU ແລະ ຊັບພະຍາກອນອື່ນໆຂອງຄອມເຮົາ ຫຼື ຢູ່ໂທລະສັບເຮົາ ເຮັດວຽກໜ້ອຍລົງ.
Critical path length ໝາຍເຖິງ ໄລຍະເວລາຂອງການໂຫຼດ critical resource ສະແດງເປັນ dependency graph ລະຫວ່າງ critical resource ແລະ bytesize.
Critical byte ໜ້ອຍເທົ່າໃດ ຈະເຮັດໃຫ້ browser ຂອງເຮົາປະມວນຜົນ ຂໍ້ມູນ ແລະ render ແລ້ວສະແດງຢູ່ໜ້າຈໍຂອງເຮົາໄດ້ໄວເທົ່ານັ້ນ. ໃນການທີ່ເຮົາຈະຫຼຸດຈຳນວນ critical byte ເຮົາສາມາດຫຼຸດໄດ້ ໂດຍການຫຼຸດຈຳນວນຂອງຊັບພະຍາກອນ (resource) ລົງ.
ຂັ້ນຕອນທົ່ວໄປຂອງການປັບປຸງປະສິດຕິພາບຂອງ critical render path ມີດັ່ງນີ້:
- ວິເຄາະ ແລະ ລະບຸດ critical path ຂອງເຮົາ: ຈຳນວນ resource, byte, length.
- ຫຼຸດຈຳນວນຂອງ critical resource ລົງ: ລຶບອອກ, ຮູ້ຈັກວ່າມັນເຮັດວຽກແນວໃດ, ໃຊ້ attribute tag “async” ແລະ ອື່ນ.
- ປັບປຸງຈຳນວນຂອງ critical byte ເພື່ອຫຼຸດຜ່ອນໄລຍະເວລາການດາວໂຫຼດລົງ (number of roundtrip).
- ປັບປຸງອັນດັບຄວາມສຳຄັນໃນການດາວໂຫຼດ critical resource ເຊັ່ນ ດາວໂຫຼດໂຕ critical ທີ່ສຳຄັນໄວເທົ່າທີ່ຈະໄວໄດ້ ເພື່ອຫຼຸດເວລາຂອງ critical path.
2.3 ປັບປຸງປະສິດຕິພາບຂອງເນື້ອຫາ
2.3.1 ລຶບການດາວໂຫຼດທີ່ບໍ່ຈຳເປັນ
ຫຼັກໆແລ້ວເຮົາຈະຕ້ອງເບິ່ງວ່າ resource ຕ່າງໆທີ່ເຮົາໃຊ້ໃນເວັບເຮົາມັນຈຳເປັນບໍ່? ມັນມີຄ່າຫຼາຍສ່ຳໃດຕໍ່ເວັບເຮົາ.
ຫຼາຍໆເວັບສ່ວນຫຼາຍ ຈະຍັດສິ່ງທີ່ບໍ່ຈຳເປັນເຂົ້າໄປໃນເວັບ ແລະ ເຮັດໃຫ້ປະສິດຕິພາບຕຳລົງ, ນອກຈາກນັ້ນມັນຍັງໄດ້ນຳເອົາຄວາມສະດວກສະບາຍ ຫຼື ສິ່ງທີ່ຈຳເປັນໃຫ້ແກ່ຜູ່ເຂົ້າເວັບເຮົາເລີຍ.
ຕົວຢ່າງ:
ເວັບ ກ ໄດ້ສະແດງຮູບແບບ carousel ຢຸ່ໜ້າຫຼັກຂອງເວັບ ເພື່ອໃຫ້ຄົນທີ່ເຂົ້າມາເບິ່ງສາມາດເບິ່ງຮູບຫຼາຍຮູບໄດ້. ຮູບທັງໝົດໄດ້ຖືກໂຫຼດມາໄວ້ຮ້ອຍແລ້ວພ້ອມກັບໜ້າເວັບ ແລະ ຜູ່ຊົມສາມາດເຂົ້າເບິ່ງໄດ້ເລີຍໂດຍບໍ່ຈຳເປັນຕ້ອງຖ້າໂຫຼດອີກ.
ຄຳຖາມ: ທ່ານເຄີຍໄດ້ເກັບກຳຈຳນວນຄົນທີ່ເຂົາເບິ່ງຮູບຂອງເຮົາບໍ່ວ່າມີຫຼາຍສ່ຳໃດ?
ເວັບ ຂ ໃຊ້ widget ຈາກພາຍນອກ (third-party) ເພື່ອສະແດງເນື້ອຫາທີ່ກ່ຽວຂ້ອງກັນ, ເພື່ອເພີ່ມການໂຕ້ຕອບ ແລະ ສະເໜີການບໍລິການອື່ນໆ.
ຄຳຖາມ: ທ່ານໄດ້ຕິດຕາມເບິ່ງບໍ່ວ່າ ຈະມີຜູ່ໃຊ້ງານຈັກຄົນໃຊ້ widget ໂຕນັ້ນ?
2.3.2 ປັບປຸງການ encoding ແລະ transfer size
ການບີບອັດ (compression) ຄືທາງອອກຂອງການແກ້ໄຂບັນຫານີ້. ການບີບອັດໝາຍເຖິງ ການເຮັດໃຫ້ຟາຍປະຈຸບັນມີຂະໜາດນ້ອຍລົງໂດຍບໍ່ສູນເສຍຄວາມສາມາດ ຫຼື ຄຸນສົມບັດໃດໆ ເຊິ່ງແຕ່ລະຄົນກໍຈະມີ ເຕັກນິກ, algorithm, optimization ແຕກຕ່າງກັນໄປ ເພື່ອປັປຸງອັດຕາສ່ວນ, ຄວາມໄວ ແລະ ຄວາມຈຳຂອງການບີບອັດຂອງມູນດີຂຶ້ນ (ເວົ້າມາລະຄິດຮອດ Pied Piper) ແຕ່ເຮົາຈະບໍ່ລົງເລິກເຖິງສາດຂອງມັນໃນບົດຄວາມນນີ້ ເຮົາຈະມາເວົ້າພື້ນຖານເລັກໆນ້ອຍໆກັນ.
ຕົວຢ່າງ:
ເຮົາມີຂໍ້ຄວາມອັນໜຶ່ງມີຂະໜາດຕົວອັດສອນປະມານ 200 ຄຳມາປະມານນີ້ ແລ້ວເຮົາຈະບີບອັດຂໍ້ມູນມັນແນວໃດ?
# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA
1. ຄຳຄິດເຫັນ (#) ບໍ່ໄດ້ມີຜົນກະທົບຕໍ່ໃຈຄວາມຂອງຈົດໝາຍ ເຮົາສາມາລຶບຖິ້ມໄດ້ ເວລາສົ່ງຜ່ານຂໍ້ຄວາມ.
2. ເຮົາອາດຈະ encode header ສ່ວນຂອງ “format” ແລະ “date” ປ່ຽນທັງສອງໃຫ້ເປັນໄອດີຕົວເລກ, ແຕ່ວ່າມັນອາດຈະບໍ່ແມ່ນ ໃນຫຼາຍກໍລະນີ. ສະນັ້ນ, ໃນກໍລະນີນີ້ ປະໄວ້ດີກ່ວາ.
3. ເຮົາສາມາດປ່ຽນຕົວອັກສອນທີ່ໃຊ້ຊ້ຳກັນເຊັ່ນ AAA ມີສາມຕົວມາເປັນ 3A.
ຫຼັງຈາກນັ້ນເຮົາກໍຈະໄດ້ຂໍ້ຄວາມທີ່ຖືກບີບອັດໃນຮູບແບບນີ້
format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A
ຄວາມຂໍ້ໃໝ່ນີ້ ມີພຽງແຕ່ 56 ອັກສອນ ນັ້ນໝາຍຄວາມວ່າເຮົາສາມາດບີບອັດຂໍ້ມູນໄດ້ເຖິງ 72% ພຸ້ນ.
ຕົວຢ່າງທີ 2:
ໃຫ້ HTML + CSS + JavaScript
<html>
<head>
<style>
/* awesome-container is only used on the landing page */
.awesome-container { font-size: 120% }
.awesome-container { width: 50% }
</style>
</head>
<body>
<!-- awesome container content: START -->
<div>…</div>
<!-- awesome container content: END -->
<script>
awesomeAnalytics(); // beacon conversion metrics
</script>
</body>
</html>
ເຮົາຈະບີບອັດແນວໃດ?
1. Comment code CSS(*/ … */), HTML (<!– … –>), JavaScript (// …)ເປັນສິ່ງທີ່ດີສຳລັບນັກພັດທະນາ, ແຕ່ວ່າ ຕອນນີ້ browser ບໍ່ຈຳເປັນ comment ພວກນີ້ ເພາະຖ້າເຮົາເພີ່ມເຂົ້າໄປ ມັນຈະໄປເພີ່ມຂະໜາດຂອງຟາຍເຮົາ.
2. “smart” CSS compressor ທີ່ດີຈະຕ້ອງນຳສິ່ງທີ່ຄືກັນໃສ່ລວມເປັນອັນດຽວ “.awesome-container”.
3. ຍະຫວ່າງ ແລະ tab ເຮັດໃຫ້ນັກພັດທະນາເຮົາເບິ່ງ code ສະບາຍຕາ, ແຕ່ເຮົາສາມາດບີບອັດໄດ້ໂດຍການລຶບຍະຫວ່າງ ແລະ tab ອອກ (ຖ້າຈຳເປັນ).
ຜົນທີ່ໄດ້:
<html><head><style>.awesome-container{font-size:120%;width: 50%}
</style></head><body><div>…</div><script>awesomeAnalytics();
</script></body></html>
ເຮົາສາມາດບີບອັດຂໍ້ມູນຈາກ 406 ຕົວອັກສອນມາເປັນ 150 ຫຼື ເທົ່າກັບ 63%.
ສິ່ງທີ່ຄວນຮູ້: ຟາຍ library JQuery ທີ່ບໍ່ຖືກບີບອັດປະຈຸບັນຈະມີຂະໜາດເກືອບວ່າປະມານ 300KB, ແຕ່ຖ້າເຮົາບີບອັດໂດຍການລຶບ comment ແລະ ອື່ນໆ ຈະເຮັດໃຫ້ຂະໜາດຂອງມັນນ້ອຍລົງເຖິງ 3 ເທົ່າໂຕ ຫຼື ປະມານ 100KB.
2.3.3 ປັບປຸງປະສິດຕິພາບຮູບພາບ (Image optimization)
ຮູບທີ່ເຮົາໃສ່ລົງໄປໃນໜ້າເວັບເຮົາກໍເປັນອີກປັດໄຈໜຶ່ງທີ່ສົ່ງຜົນກະທົບໃຫ້ກັບຄວາມໄວໃນການສະແດງຜົນ ແລະ ມັນຍັງໄດ້ຍຶດເອົາພື້ນທີ່ໜ່ວຍຄວາມຈຳນຳອີກ (virtual space).
ການປັບປຸງປະສິດຕິພາບຂອງຮູບພາຍນັ້ນ ຈະຕ້ອງໄດ້ອາໄສຄວາມຮູ້ດ້ານສິນລະປະ ແລະ ວິທະຍາສາດ ເຂົ້າປະສົມປະສານກັນ. ເຮົາຈະຕ້ອງຮູ້ດ້ານສິນ ເພາະຮູບແຕ່ລະຮູບ ເວລາຖືກບີບອັດ ຜົນໄດ້ຮັບຂອງມັນຈະແຕກຕ່າງກັນ ສະນັ້ນເຮົາຈຶ່ງຕ້ອງຮູບວ່າ ເຮົາຄວນບີບອັດສ່ຳໃດຈຶ່ງເໝາະສົມ ເພື່ອບໍ່ໃຫ້ຮູບເບິ່ງແລ້ວບໍ່ເສຍລາຍລະອຽດຫຼາຍ. ຄວາມຮູ້ດ້ານວິທະຍາສາດ ແມ່ນການທີ່ເຮົາຮູ້ ເຕັກນິກ ຫຼັກການ algorithm ໃນການຫຼຸດຂະໜາດຂອງຮູບລົງ.
ອ່ານຂໍ້ມູນເພີ່ມຕື່ມ Image Optimization | Web Fundamentals | Google Developer
ລິບ ແລະ ປ່ຽນຮູບພາບ
- ລຶບຮູບພາບທີ່ບໍ່ຈຳເປັນ
- ຈຳກັດການໃຊ້ effect CSS3 ເທົ່າທີ່ຈະເຮັດໄດ້
- ໃຊ້ Web font ແທນທີ່ຈະໃຊ້ encoding text ໃນຮູບພາບ
ເຄີຍໄດ້ຍິນບໍ່ວ່າ ຮູບໜຶ່ງຮູບສາມາດສື່ຄວາມໝາຍໄດ້ຫຼາຍກ່ວາພັນຄຳ ດັ່ງນັ້ນ ເຮົາຈຶ່ງນິຍົມໃຊ້ຮູບໃນການທີ່ເຮົາຈະສື່ອີ່ຫຍັງຈັກຢ່າງໃຫ້ຜູ່ອ່ານເຮົາເຫັນພາບຫຼາຍຍິ່ງຂຶ້ນ ແຕ່ເຮົາກະຕ້ອງແລກມາດ້ວຍການທີ່ຈຳນວນການດາວໂຫຼດຂອງ browser ທີ່ຫຼາຍຂຶ້ນ ແລະ ມັນນຳໄປສູ່ບັນຫາທີ່ເຮັດໃຫ້ເວັບໂຫຼດດົນ. ສະຫຼຸບ ແລ້ວຖ້າເຮົາຈະໃຊ້ຮູບກໍ່ໃຊ້ແຕ່ ຫາກເຮົາຮູ້ວິທີ່ການປັບປຸງປະສິດຕິພາບຂອງມັນແລ້ວແຮງເປັນການດີ ສຳລັບນັກພັດທະນາທັງຫຼາຍ.
Vector vs. Raster images
- ຮູບ Vector ແມ່ນຮູບທີ່ປະກອບໄປດ້ວຍ ເສັ້ນຊື່ ແລະ ເສັ້ນໂຄ້ງ ນ້ອຍໆ ປະກອບກັນເປັນຮູບ.
- ຮູບ Vector ສາມາດຂະຫຍາຍ (zoom) ແລະ ຄວາມລະອຽດບໍ່ຕາຍໂຕ (resolution- independent.
- ຮູບ Raster ປະກອບດ້ວຍ pixel (ຈະຕຸລັດ) ນ້ອຍໆ (irregular shapes and details) ລວມກັນເປັນຮູບ.
Zoomed-in Vector image
Zoomed-in Raster image
ຮູບທັງສອງປະເພດນີ້ຈະມີຈຸດດີ ແລະ ຈຸດເສຍ ແຕກຕ່າງກັນ ຄື:
ຮູບທີ່ເປັນ Vector format (SVG) ຈະເໝາະສຳລັບໃຊ້ໃນວຽກງານທີ່ຕ້ອງການລາຍລະອຽດສູງ ເຊັ່ນ logo, text, icon ແລະ ອື່ນໆ. ແຕ່ວ່າ Vector ຈະມີຈຸດເສບຢູ່ບ່ອນວ່າ ຖ້າຮູບທີ່ມີສັບຊ້ອນ ເຊັ່ນ ຮູບຖ່າຍ ມັນຈະເຮັດໃຫ້ພາບຖ່າຍຂອງເຮົາເບິ່ງຄືບໍ່ສົມຈິງ (ຄືຮູບກາຕູນ). ສະນັ້ນ, ໃນກໍລະນີນີ້ ເຮົາຈະຕ້ອງໄດ້ໃຊ້ raster image format ເຊ່ນ: GIF, PNG, JPEG ຫຼື format ທີ່ມາໃໝ່ JPEG-XR ແລະ WebP (ພັດທະນາໂດຍ Google ມີຂະໜາດນ້ອຍກ່ວາ PNG ແລະ JPEG ແຕ່ ຍັງບໍ່ເປັນ universal).
ສ່ວນຈຸດເສຍຂອງ Raster format ເວລາທີ່ເຮົາເພີ່ມຂະໜາດຂອງຮູບພາບ ເຮົາຈະເຫັນວ່າຮູບມັນບໍ່ຄົມ, ເຫັນເປັນເມັດພິກເຊວ. ຈາກບັນຫາດັ່ງກ່າວ, ນັກພັດທະນາເຮົາ ຈະຕ້ອງໃຊ້ເຮັດຮູບ raster format ໃນຫຼາຍໆຂະໜາດ ໃນຫຼາຍ version ເພື່ອສະໜອງປະສົບການທີ່ດີທີ່ສຸດໃຫ້ຜູ່ເບິ່ງຂອງເຮົາ.
ສິ່ງທີ່ເຮົາຄວນຮູ້:
- Perfect vector formats: ໃຊ້ vector format ຍ້ອນມັນສະແດງຜົນດີທີ່ສຸດສຳລັບຫຼາຍໆອຸປະກອນ ແລະ ມີຄວາມລະອຽດສູງ.
- Minify and compress SVG asset: ໃຊ້ GZIP compression ສຳລັບ SVG ເພື່ອລຶບ metadata ທີ່ບໍ່ຈຳເປັນ.
- Pick best raster image format: ຕ້ອງຮູ້ວ່າຮູບທີ່ເຮົາຈະໃຊ້ແມ່ນມີຈຸດປະສົງເພື່ອຫຍັງ ເຮົາຈຶ່ງຈະສາມາດເລືອກຮູບທີ່ເໝາະກັບຈຸດປະສົງຂອງເຮົາໄດ້.
- Experiment with optimal quality setting for raster formats: ບໍ່ຕ້ອງຢ້ານທີ່ຈະຫຼຸດ ຄຸນນະພາບຂອງຮູບເຮົາລົງ ເພາະມັນຈະຊ່ວຍໃຫ້ເຮົາປະຢັດ byte ຂອງຊັບພະຍາກອນຂອງເຮົາໄດ້ຫຼາຍເຕີບ.
- Remove unnecessary image metadata: raster image ສ່ວນຫຼາຍຈະມີຂໍ້ມູນ meta ທີ່ບໍ່ຈຳເປັນເຊັ່ນ: ຂໍ້ມູນກ່ຽວທີ່ສະຖານທີ່ຂອງຮູບ (geo information), ລາຍລະອຽດກ່ຽວກັບຮູບຖ່າຍ (camera information) ເປັນຕົ້ນ. ເຮົາສາມາດໃຊ້ເຄື່ອງມືເພື່ອເອົາຂໍ້ມູນເຫຼົ່ານີ້ອອກໄດ້.
- Serve scaled image: ນັກພັດທະນາສ່ວນຫຼາຍ ຈະອາໄສ browser ໃນການ scale ຮູບຈາກຕົ້ນສະບັບໃຫ້ ເຊິ່ງຄວາມຈິງແລ້ວ browser ກະຍັງຕ້ອງໄດ້ໂຫຼດເອົາຮູບຂະໜາດເຕັມຂອງມັນຢູ່ດີ ແຕ່ຊ້ຳພັດສະແດງໃນ scale ທີ່ຕ່ຳລົງມາ. ສະນັ້ນ, ເຮົາຈະຕ້ອງເລືອກຮູບທີ່ scale ໃຫ້ໃກ້ຄຽງກັບຮູບທີ່ເຮົາຕ້ອງການຈະສະແດງ ໃຫ້ຫຼາຍທີ່ສຸດ. ຖ້າບໍ່ດັ່ງນັ້ນ, ເຮົາຈະເສຍ pixel ທີ່ບໍ່ຈຳເປັນໄປຊື່ໆ.
- Automate, automate, automate: ເຮົາຄວນໃຊ້ເຄື່ອງມືຊ່ວຍ ເພື່ອໃຫ້ແນ່ໃຈວ່າຮູບທີ່ເຮົາໃຊ້ຈະຕ້ອງຖືກປັບປຸງປະສິດຕິພາບຢ່າງດີທີ່ສຸດຢູ່ແລ້ວ.
2.3.4 Web font optimization
ອ່ານລາຍລະອຽດເພີ່ມຕື່ມໄດ້ທີ່ Web Font Optimization | Web Fundamentals | Google Developer
2.3.5 HTTP Caching
ອ່ານລາຍລະອຽດເພີ່ມຕື່ມໄດ້ທີ່ HTTP Caching | Web Fundamentals | Google Developer
ຂອບໃຈຂໍ້ມູນຈາກ Mobile Site Certificate Assessment study guide
