ໃນ 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  ເຊິ່ງ​ມັນ​ຈະ​ເປັນ​ສີ​ຟ​້າ​ຖ້າ​ຖືກ​ເປີດ​ໃຊ້​ງານ​ແລ້​ວ. DevTools ຈະ​ຖ່າຍ​ຮູບ​ໜ້າ​ຈໍ​ໃນ​ຂະ​ນະ​ທີ່ໜ້າ​ເວັບ​ເຮົາ​ກຳ​ລັງ​ໂຫຼດ

ຂັ້ນ​ຕອນ​ທີ 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 ມີ​ດັ່ງ​ນີ້:

  1. ວິ​ເຄາະ ແລະ ລະ​ບຸດ critical path ຂອງ​ເຮົາ: ຈຳ​ນວນ resource, byte, length.
  2. ຫຼ​ຸດ​ຈຳ​ນວນ​ຂອງ critical resource ລົງ: ລຶບ​ອອກ, ຮູ້​ຈັກ​ວ່າ​ມັນເຮັດວ​ຽກ​ແນວ​ໃດ​, ໃຊ້  attribute tag “async” ແລະ ອື່ນ.
  3. ປັບ​ປ​ຸງ​ຈຳ​ນວນ​ຂອງ critical byte ເພື່ອຫຼຸດ​ຜ່ອນ​ໄລ​ຍະ​ເວ​ລາ​ການ​ດາວ​ໂຫຼດ​ລົງ (number of roundtrip).
  4. ປັບ​ປ​ຸງ​ອັນ​ດັບ​ຄວາມ​ສຳ​ຄັນ​ໃນ​ການ​ດາວ​ໂຫຼດ 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