Module 4: Advanced web technologies
ໃນ module ນີ້ເຮົາຈະມາຮຽນຮູ້ກ່ຽວກັບການໃຊ້ເທັກໂນໂລຢີຂັ້ນສູງຂອງເວັບເຊັ່ນ Accelerated Mobile Pages (AMP) ແລະ Progressive Web Apps (PWA).
4.1 ແນະນຳກ່ຽວກັບ Accelerated Mobile Pages
4.1.1 Accelerated Mobile Pages (AMP) ມັນແມ່ນຫຍັງ?
AMP ເປັນອີກວິທີໜຶ່ງໃນການສ້າງເວັບສຳລັບເນື້ອຫາທີ່ບໍ່ມີການປ່ຽນແປງ (static content) ໃຫ້ render ໄວຂຶ້ນ. ການເຮັດວຽກຂອງ AMP ປະກອບມີ 3 ສ່ວນຄື:
- AMP HTML ກະຄື HTML ທຳມະດານິລະຕ່າງແຕ່ວ່າຈະຈຳກັດບາງຢ່າງເພື່ອປະສິດຕິພາບທີ່ເຮົາໄວ້ວາງໃຈໄດ້ ແລະ ຕັດບາງສ່ວນເສີມເພື່ອສ້າງເນື້ອຫາທີ່ດີກ່ວາ HTML ທຳມະດາ.
- AMP JS library ເພື່ອໝັ້ນໃຈວ່າ render ໜ້າທີ່ເປັນ AMP HTML ໄດ້ໄວ.
- ໃຊ້ Google AMP cache ເພື່ອ cahce ໜ້າເວັບທີ່ເປັນ AMP HTML.
AMP HTML
AMP HTML ກະຄື HTML ທຳມະດານິລະຕ່າງແຕ່ວ່າມັນຈະເພີ່ມ custom AMP properties ເຂົ້າໄປ. Code ພື້ນຖານຂອງ AMP ຈະເປັນປະມານນີ້ (ຈະມີສາຍຟ້າບອກ):
<!doctype html>
<html ⚡>
<head>
<meta charset=”utf-8″>
<link rel=”canonical” href=”hello-world.html”>
<meta name=”viewport” content=”width=device-width,minimum-scale=1,initial-scale=1″>
<style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
<script async src=”https://cdn.ampproject.org/v0.js”></script>
</head>
<body>Hello World!</body>
</html>
ຈາກທີ່ເບິ່ງ code ຜ່ານໆເຮົາຈະເຫັນວ່າ AMP HTML ນັ້ນບໍ່ຕ່າງຫຍັງກັບ HTML ທົ່ວໄປເລີຍ, ແຕ່ວ່າຈະມີບາງ tag ທີ່ຖືກປ່ຽນໄປເປັນ AMP tag (ເບິ່ງ tag AMP). ສ່ວນທີ່ຖືກປັບແຕ່ງມານີ້ ຈະເອີ້ນວ່າ AMP component ເພື່ອມັນຈະເປັນຊ່ວຍໃນການ render ໃຫ້ໄວຂຶ້ນ.
ຕົວຢ່າງ tag ທີ່ຖືກປ່ຽນກໍ່ຈະມີ tag ຮູບ img => amp-img ທີ່ຮອງຮັບ attribute srcset (ໃຊ້ໄວ້ສະແດວຂະໜາດຮູບໃຫ້ເໝາະສຳລັບແຕ່ລະໜ້າຈໍ ສຳລັບເຮັດ responsive web).
AMP JS
AMP JS library ຈະມາຈັດການ ປະສິດຕິພາບການເຮັດວຽກຂອງໜ້າເວັບ AMP ເຊັ່ນ ຈະມາບໍລິຫານຈັດການຊັບພະຍາກອນເວລາໂຫຼດ ແລະ ໃຫ້ເຮົາໃຊ້ tag AMP ທີ່ໄດ້ເວົ້ສຂ້າງເທິງ ວ່າມັນຈະມາຊ່ວຍໃຫ້ເຮົາ render ໜ້າເວັບເຮົາໄວຂຶ້ນ.
ໂດຍການທີ່ AMP ຈະໃຊ້ຮູບແບບການ request ແບບ asynchronous (ເຮັດວຽກບໍ່ເປັນໄປຕາມລຳດັບ ຈະບໍ່ຖ້າໂຕໃດໂຕໜຶ່ງເຮັດແລ້ວກ່ອນ =/ synchronous) ເພາະສະນັ້ນຈະບໍ່ມີອີ່ຫຍັງມາຂັ້ນການ render ໄດ້ ເພື່ອໃຫ້ໄດ້ປະສິດຕິພາບສູງສຸດຂອງການ render ອອກມາ.
ແລະ ເຕັກນິກອື່ນໆເຊັ່ນ sandboxing of all iframes, ຄິດໄລ່ໂຄງຮ່າງຂອງແຕ່ລະສ່ວນໄວ້ລວງໜ້າ (pre-calculation of the layout of every element) ກ່ອນຊັບພະຍາກອນຂອງໜ້າເວັບຈະຖືກໂຫຼດ ແລະ ປິດ CSS ທີ່ຊ້າ.
ອ່ານເພີ່ມກ່ຽວກັບການ optimization ແລະ limitation AMP HTML specification.
Google AMP Cache
Google AMP Cache ກະຄືເຄື່ອຂ່າຍ proxy-based ໃຫ້ການນຳສົ່ງເນື້ອຫາ AMP ທີ່ໄດ້ຮັບກັນຢືນຢັນແລ້ວວ່າຖືກຕ້ອງການຫຼັກການຂໍ້ກຳນົດຮູບແບບທີ່ໄດ້ກຳນົດໄວ້. ໂດຍການໂຫຼດໜ້າ AMP HTML ໄວ້ ແລ້ວ cache ຫຼັງຈາກນັ້ນກໍຈະປັບປຸງປະສິດຕິພາບຂອງໜ້າເວັບດັ່ງກ່າວອັດຕະໂນມັດ. ເວລາທີ່ເຮົາໃຊ້ Google AMP cache, ຂໍ້ມູນ (document), ຟາຍ JS ແລະ ຮູບພາບຂອງເຮົາຕ່າງໆຈະຖືກໂຫຼດມາຈາກບ່ອນຢູ່ຕົ້ນສະບັບໂດຍການໃຊ້ HTTP 2.0 ເພື່ອໃຫ້ປະສິດຕິຜົນທີ່ໄດ້ມາສູງສຸດ.
4.1.2 AMP ເຮັດວຽກແນວໃດ?
ຖ້າໃຜໄດ້ລອງໃຊ້ເຄື່ອງມືຄົ້ນຫາ Google search ຈະເຫັນວ່າບາງເວັບ ຂ້າງລິ້ງຈະເຫັນວ່າມັນຈະມີຮູບ ສາຍຟ້າ ຢູ່ ນັ້ນສະແດງວ່າໜ້າເວັບດັ່ງກ່າວແມ່ນຮອງຮັບ AMP ແລະ ເວລາທີ່ເຮົາກົດເຂົ້າໄປ ເຮົາຈະຮູ້ສຶກວ່າໜ້າເວັບໂຫຼດໄວຫຼາຍ ແບບຫາຍໃຈເຂົ້າ-ອອກ ເທື່ອໜຶ່ງຍັງວ່າດົນກ່ວາຊ້ຳ.
ອະນຸຍາດແຕ່ asynchronous script
ຈຸດເສຍທີ່ສຳຄັນທີ່ສຸດຂອງ JavaScript ກະຄືມັນອາດຈະໄປໂຈະການເຮັດວຽກຂອງ DOM construction ແລະ ເຮັດໃຫ້ໜ້າດເວັບ render ຊ້າ. ດັ່ງນັ້ນ, ເພື່ອບໍ່ໃຫ້ JavaScript ໄປເຮັດໃຫ້ການໃຊ້ເວລາໃນການ render ໜ້າດົນ, AMP ຈຶ່ງອະນຸຍາດໃຫ້ແຕ່ asynchronous JavaScript.
AMP page ຈະບໍ່ສາມາດໃສ່ JavaScript ຂອງຜູ່ຂຽນເລີຍ. ດັ່ງນັ້ນ, ແທນທີ່ຈະໃຊ້ JavaScript ຂອງເຮົາເອງ ເຮົາສາມາດໃຊ້ AMP element ໄດ້ ບາງອັນອາດຈະປະກອບມີ JavaScript ຢູ່ນຳແຕ່ ກໍເປັນໂຕທີ່ຖືກອອກແບບມາບໍ່ໃຫ້ມັນໄປກວນການເຮັດວຽກໃຫ້ຫຼຸດລົງ.
ເຮົາສາມາດໃສ່ third-party JS ໄດ້ໃນ iframe, ໂດຍມັນຈະບໍ່ໄດ້ໄປກັນການເຮັດວຽກໃນສ່ວນຂອງ render.
ລະບຸຂະໜາດຊັບຳພຍາກອນທັງໝົດໃຫ້ຄົງທີ Size all resources statically)
ຊັບພະຍາກອນທີ່ມາຈາກພາຍນອກເຊັ່ນ ຮູບ, ໂຄສະນາ (ads) ຫຼື iframe ແມ່ນຈະເອົາມາໃສ່ໄດ້ ແຕ່ AMP ຈະລະບຸຂະໜາດຂອງມັນຢ່າງຊັດເຈນວ່າ ມັນຈະຕ້ອງຂະໜາດເທົ່າໃດ ເຊິ່ງເຮົາບໍ່ສາມາດປັບແຕ່ງຂະໜາດໄດ້ຕາມໃຈໄດ້ ເນື່ອງຈາກວ່າ ການທີ່ AMP ໄດ້ຮູ້ຂະໜາດຂອງແຕ່ລະຊັບຍາກອນໄວ້ກ່ອນແລ້ວ AMP ຈະຈັດ layout ໄວ້ກ່ອນ ກ່ອນທີ່ຊັບພະຍາກອນຕ່າງໆຈະຖືກດາວໂຫຼດແລ້ວ. ເຮັດໃຫ້ render ໜ້າເວັບໄວ.
Don’t let extension mechanisms block rendering
AMP ຮອງຮັບພຽງແຕ່ extension mechanism ເຊັ່ນ lightboxes, instagram embed, tweet ເປັນຕົ້ນ.
Keep all third-party JavaScript out of critical path
Third-party JS ສ່ວນຫຼາຍຈະເຮັດວຽກ ແລະ ຂຽນໃນຮູບແບບຂອງ synchronous ແລະ ມັນຈະໄປກະທົບ critical render path. ຍົກຕົວຢ່າງ ໜ້າເວັບຂອງທ່ານມີ ປ້າຍໂຄສະນາຢູ່ 5ປ້າຍ, ແຕ່ລະປ້າຍເກີດ synchronous ຢູ່ສາມບ່ອນ, ແຕ່ລະບ່ອນແມ່ນໃຊ້ເວລາ 3ວິນາທີ, ສະຫຼຸບ ທ່ານຈະຕ້ອງເສຍເວລາໃນການໂຫຼດໄປ 15ວິນາທີ ເພື່ອພຽງແຕ່ຖ້າໂຫຼດ JS.
Third-party ທຸກໂຕໃນໜ້າ AMP ຈະຢູ່ໃນຮູບແບບຂອງ sandboxed iframe ດັ່ງນັ້ນ, ມັນບໍ່ສາມາດໄປກັນການເຮັດວຽກຂອງໜ້າຫຼັກ ເຖິງວ່າມັນຈະຂໍ style re-calculation ຫຼາຍໆຄັ້ງກໍຕາມ.
All CSS must be inline and size-bound
CSS ກໍເປັນອີກປັດໄຈໜຶ່ງໃນການກັນການ render, ດັ່ງນັ້ນ AMP ຈະອະນຸຍາດແຕ່ CSS ທີ່ຂຽນໃນຮູບແບບ inline ແລະ ຈຳກັດຂະໜາດຂອງ CSS ສູງສຸດ 50KB.
Font triggering must be efficient
ປົກກະຕິແລ້ວ Web font ຖຶເປັນຊັບພະຍາກອນທີ່ໜັກອັນໜຶ່ງທີ່ເຮັດໃຫ້ໜ້າເວັບເຮົາໂຫຼດຊ້າ ເພາະມັນຈະຕ້ອງໄດ້ຖ້າ synchronous script ແລະ CSS ເຮັດແລ້ວກ່ອນຈຶ່ງດາວໂຫຼດ font. ດັ່ງນັ້ນ ໃນ AMP JS ບໍ່ຈຳເປັນຕ້ອງຖ້າພວກນີ້ເຮັດແລ້ວ ມັນສາມາດດາວໂຫຼດຟອນໄດ້ເລີຍ.
Minimize style re-calculations
ການເຮັດວຽກຂອງ re-calculation ເປັນອີ່ຫຍັງທີ່ບໍ່ຈຳເປັນຫຼາຍຖ້າ browser ຂອງເຮົາຕ້ອງ re ຫຼາຍເທື່ອ ເນື່ອງຈາກວ່າ ການ re-calculation ນີ້ແມ່ນ browser ຂອງເຮົາຈະຕ້ອງໄດ້ວາງໂຄງຮ່າງໃໝ່ໝົດທັງໜ້າເລີຍ. ໃນ AMP DOM ທັງໝົດຈະຖືກອ່ານກ່ອນຈະຖືກຂຽນລົງໄປ ໝາຍຄວາມວ່າຈະມີພຽງແຕ່ການ re-calculation ຄັ້ງດຽວຕໍ່ 1 ເຟຣມ (frame).
Only run GPU-accelerated animations
AMP ອະນຸຍາດໃຫ້ແຕ່ animating ແລະ transitioning ໃນ transform ແລະ opacity.
Prioritize resource loading
AMP ຈະຄວບຄຸມການດາວໂຫຼດຊັບພະຍາກອນທັງໝົດ ມັນຈະຈັດອັນດັບຄວາມສຳຄັນຂອງແຕ່ລະຊັບພະຍາກອນວ່າ ອັນໃດຈະຕ້ອງໂຫຼດກ່ອນ ອັນໃດຈະຕ້ອງໂຫຼດຕາມຫຼັງ ແລະ ຈະໂຫຼດກໍຕໍ່ເມື່ອມັນຕ້ອງການ.
ເວລາທີ່ AMP ດາວໂຫຼດຊັບພະຍາກອນທີ່ສຳຄັນນະຕອນໆນັ້ນກ່ອນ. ຍົກຕົວຢ່າງ ຮູບ ແລະ ໂຄສະນາຈະຖືກໂຫຼດມາເວລາທີ່ຜູ່ໃຊ້ຕ້ອງການຢາກເຫັນ ຫຼື ຜູ່ໃຊ້ເລື່ອນໜ້າໄປໄວໆ, ສະແດງເທົ່າທີ່ເຫັນ (above the fold).
Load pages in an instant
4.2 ແນະນຳ Progressive Web Apps
Progressive Web Apps (PWAs) ແມ່ນປະສົບການຜູ່ໃຊ້ງານ (User experience) ທີ່ຄວນທີ່ເປັນເວລາທີ່ເຂົາເຂົ້າເວັບໂດຍມີກົດເກນ 3 ຢ່າງຄື:
- ໝັ້ນໃຈ-ເຊື່ອຖືໄດ້ (Reliable): ໝັ້ນໃຈໄດ້ໃນນີ້ໝາຍຄວາມວ່າ ໝັ້ນໃຈວ່າໂຫຼດໄວ ແລະ ບໍ່ເຄີຍໂຊໂຕໄດໂນເສົາ (ໝາຍເຖິງ ເນັດເຊື່ອຕໍ່ບໍ່ໄດ້) ເຖິງວ່າ ເຮົາຈະໃຊ້ເນັດບໍ່ສະຖຽນກໍຕາມ.
- ໄວ (Fast): ຕອບສະໜອງໄວເມື່ອຜູ່ໃຊ້ກົດພ້ອມກັບສະແດງການເຄື່ອນໄຫວທີ່ມື່ນຈົນເກືອບລົ້ມຫົວແຕກ.
- ຜູ່ໃຊ້ມີສ່ວນຮ່ວມ (Engaging): ເບິ່ງຄືກັບ app ໃນໂທລະສັບມືຖືໂດຍຍັງຄົງໄວ້ປະສົບການຜູ່ໃຊ້ທີ່ດີ.
ແລະ ຍ້ອນຄຸນນະພາບທີ່ເໜືອໄປອີກຂັ້ນໜຶ່ງຂອງເວັບທຳມະດາ PWA ຈຶ່ງສາມາດໄປຢູ່ເທິງໜ້າຈໍໂທລະສັບຂອງທ່ານໄດ້ (home screen).
ໝັ້ນໃຈ-ໄວ້ໃຈໄດ້
ເວລທີ່ເຮົາເປີດໃຊ້ງານ PWA ຈາກໜ້າຈໍໂທລະສັບຂອງເຮົາ (home screen) service worker ຈະເປີດນຳໃຊ້ເພື່ອໃຫ້ໂຫຼດໄວທັນທີທັນໃດ ເຖິງວ່າສັນຍານເນັດບໍ່ສະຖຽນກໍຕາມ.
Service worker ກໍຄ້າຍຄືກັບ client-side proxy, ຂຽນດ້ວຍພາສາ JavaScript ແລະ ບັນທຶກລົງໃນສ່ວນຄວບຄຸມຂອງ cache (control of cache) ແລະ ໃຊ້ເພື່ອວ່າຈະຕອບສະໜອງການຂໍ request ແນວໃດ.
ໄວ
53% ຂອງຜູ່ໃຊ້ຈະບໍ່ເຂົ້າເວັບນັ້ນເລີຍ ຖ້າເວັບນັ້ນໃຊ້ເວລາດົນກ່ວາ 3ວິນາທີ ໃນການໂຫຼດ.
Engaging
PWAs ສາມາດຕິດຕັ້ງ ແລະ ເຂົ້າໃຊ້ງານໄດ້ຜ່ານໜ້າຈໍໂທລະສັບເຮົາໄດ້ໂດຍກົງ (home screen) ແລະ ມັນກະຍັງໃຊ້ຄືກັນກັບ native app ທີ່ຢູ່ໃນມືຖືຂອງເຮົານັ້ນລະ ເຊັ່ນ ມັນສາມາດສົ່ງການແຈ້ງເຕືອນໄດ້ຄືກັນກັບ app ເປັນຕົ້ນ (push notification).
4.2.1 ເປັນຫຍັງເຮົາຄືສ້າງ PWAs
PWAs ຈະມາເປັນພື້ນຖານໃໝ່ຂອງ mobile web ໃນອະນາຄົດ ຍ້ອນໜ້າຕາທີ່ທັນສະໄໝ (modern), ສາມາດໃຊ້ງານ offline ໄດ້ຄືກັບກັບເຮົາຕິດຕັ້ງ app ຢູ່ໃນມືຖືຂອງເຮົາ. ຖ້າເວົ້າໃນອີກຄວາມໝາຍໜຶ່ງກໍຄື PWAs ເປັນການລະບົບການເຮັດວຽກແມ່ນ ຈະຮ່ວມກັນລະຫວ່າງ native app ແລະ web. ໝາຍຄວາມວ່າ ເຮົາ PWAs ຈະໃຫ້ຄວາມຮູ້ສຶກວ່າເຮົາໃຊ້ native app ເພື່ອເຂົ້າເຖິງການໃຊ້ງານ website.
ຜົນປະໂຫຍດທີ່ເຮົາຈະໄດ້ຮັບ ຫຼັງຈາກທີ່ເຮົາໃຊ້ PWAs:
- Worthy of being on the home screen: ຖ້າ Chrome ລະບຸໄດ້ວ່າເວັບເຮົາໃຊ້ PWAs chrome ຈະບອກໃຫ້ຜູ່ໃຊ້ງານຮູ້ວ່າ ເຂົາສາມາດເພີ່ມ PWAs ຂອງເຮົາເຂົ້າໃນໜ້າຈໍໂທລະສັບເຂົາ (home screen) ເຮັດໃຫ້ເວັບເຮົາມີໂອກາດທີ່ເຂົາຈະກັບມາໃຊ້ຫຼາຍຂຶ້ນ.
- Work reliable, no matter the network condition: Service workers ຈະເປີດ Konga ເພື່ອສົ່ງຂໍ້ມູນໜ້ອຍລົງ 63% ໃນແຕ່ລະໜ້າເວັບເວລາໂຫຼດ ແລະ ໃຊ້ການສົ່ງຂໍ້ມູນໜ້ອຍລົງ 84% ເພື່ອສຳເລັດການເຮັດທຸລະກຳໃນຄັ້ງທຳອິດ.
- Increased engagement: Web push notification ຈະຊ່ວຍໃຫ້ຜູ່ໃຊ້ງານຂອງເຮົາໃຊ້ເວັບເຮົາຫຼາຍຂຶ້ນເກືອບ 2 ເທົ່າ.
- Improved conversion: ຊ່ວຍໃຫ້ການຂາຍເຮົາດີຂຶ້ນ ເຊັ່ນ AliExpress ສາມາດເພີ່ມໂອກາດທີ່ຜູ່ໃຊ້ຈະຊື້ສິນຄ້າເພີ່ມຂຶ້ນ 104% ແລະ 82% ມາຈາກ iOS.
4.2.2 ແນະນຳສະຖາປະຕິຍະກຳ app shell (Introduction to the app shell architecture)
Application shell (app shell) ແມ່ນ minimal HTML, CSS ແລະ JavaScript ທັງສາມອັນນີ້ແມ່ນເປັນໂຕຂັບເຄື່ອນໜ້າຕ່າງຜູ່ໃຊ້ງານ (user interface), app ນິຈະຕ້ອງ ໂຫຼດໄວ (load fast), ສາມາດ cache ໄດ້ (be cached) , ເຄື່ອນເໜັງການສະແດງເນື້ອຫາໄດ້ (dynamically display content).
ສະຖາປະຕິຍະກຳ app shell ກໍຄື ມັນຈະແຍກ core application infrastructure ກັບ UI ອອກຈາກຂໍ້ມູນ (data). UI ແລະ infrastructure ທັງໝົດຈະຖືກ cached ຢູ່ພາຍໃນເຄື່ອງ (local) ໂດຍການໃຊ້ service worker. ດັ່ງນັ້ນ, ເວລາທີ່ເຮົາເປີດ PWAs ໃນພາຍຫຼັງ ມັນຈະຕ້ອງການພຽງແຕ່ຂໍ້ມູນທີ່ຈຳເປັນເທົ່ານັ້ນ (ຂໍ້ມູນທີ່ອັບເດດໃໝ່) ແທນທີ່ວ່າ ມັນຈະໂຫຼດໝົດທຸກຢ່າງມາໃໝ່ໝົດ.
ໃຫ້ເຮົາຈິນຕະນາການວ່າ App shell ຄືກັນກັບ code ຊຸດໜຶ່ງ (bundle of code) ທີ່ທ່ານຈະເຜີຍແຜ່ມັນຢູ່ໃຊ້ app store (ຄິດວ່າທ່ານກຳລັງສ້າງ native app). ມັນຕ້ອງຖືກດາວໂຫຼດມາ:, ແຕ່ອາດຈະບໍ່ໄດ້ໂຫຼດມາໝົດທຸກອັນ, ມັນຈະຮັກສາ UI ໄວ້ໃນເຄື່ອງຂອງເຮົາ (local) ແລະ ດຶງເອົາເນື້ອຫາທີ່ມີການປ່ຽນແປງໂດຍຜ່ານ API.
ເປັນຫຍັງຄືໃຊ້ app shell architecture
ການໃຊ້ app shell architecture ເຮັດໃຫ້ເຮົາຫຼຽວໄປສົນໃຈເລື່ອງຄວມໄວ, ມັນຈະເຮັດໃຫ້ PWAs ເຮົາຄ້າຍຄືກັນກັບ native app. ໂຫຼດໄວທັນທີທັນໃດ ແລະ ອັບເດດຕະຫຼອດເວລາ ໂດຍບໍ່ຈຳເປັນຕ້ອງໂຫຼດ app ປະໄວ້ໃນອຸປະກອນຂອງເຮົາ.
ການອອກແບບ app shell
ທຳອິດກ່ອນເຮົາຈະອອກແບບ app shell ເຮົາຈະຕ້ອງ ແບ່ງມັນອອກເປັນສ່ວນໆ (component).
ເຮົາລອງຖາມຕົນເອງເບິ່ງວ່າ:
- ອີ່ຫຍັງທີ່ຕ້ອງການຈະສະແດງຢູ່ໜ້າຈໍໃນທັນທີທັນໃດ? (what needs to be on screen immediately?)
- ມີ UI component ໃດແນ່ທີ່ເປັນສ່ວນຫຼັກຂອງ app ເຮົາ? (what other UI compoment are key to our app?)
- ຊັບພະຍາກອນຊ່ວຍ (supporting resource) ຫຍັງທີ່ app shell ເຮົາຕ້ອງການ? (ຕົວຢ່າງ: ຮູບ, JavaScript, style, ອື່ນໆ). (what supporting resources are needed for the app shell? For example images, JavaScript, styles, etc.)
ຕົວຢ່າງ
ສົມມຸດວ່າ ທ່ານຈະສ້າງ ແອັບສະພາບອາກາດ (weather app) ແບບ WPA. component ຫຼັກທີ່ຈະຕ້ອງມີໃນຫັ້ນກໍຈະປະກອບດ້ວຍ:
- Header with a title, and add/refresh buttons
- Container for forecast cards
- A forecast card template
- A dialog box for adding new cities
- A loading indicator
4.2.3 ແນະນຳ service workers
Service worker lifecycle
ອ່ານເພີ່ມ Introduction to Service worker | Web Fundamentals | Google Developer
4.3 User engagement and APIs
ເຊື່ອຕໍ່ຫາຜູ່ໃຊ້ຂອງທ່ານ ແລະ ໃຫ້ຜູ່ໃຊ້ຂອງທ່ານກັບມາໃຊ້ເວັບເຮົາເລື້ອຍ ດ້ວຍວິທີທີ່ງ່າຍສຳລັບເຂົາຄື ໃຫ້ເຂົາເພີ່ມເວັບເຮົາໃສ່ໜ້າຈໍໂທລະສັບ (home screen) ຂອງເຂົາ, ຫຼັງຈາກນັ້ນ ພະຍາຍາມປະຕິສຳພັນກັບກະເຈົ້າໂດຍການສົ່ງ push notification ແລະ ໃຫ້ເຂົາຈ່າຍເງິນຊື້ເຄື່ອງຂອງເຮົາງ່າຍໆຜ່ານໂທລະສັບມືຖື.
Web app manifest ແມ່ນຟາຍ JSON ທຳມະດາ ທີ່ໃຫ້ຄວາມສາມາຂອງນັກພັດທະນາເຮົາ ສາມາດຄວບຄຸມວ່າ app ຂອງເຮົາວ່າຈະສະແດງຜົນໃນຮູບແບບໃດໃນພື້ນທີ່ທີ່ມັນຄວນຈະໄດ້ເຫັນຈາກຜູ່ໃຊ້ຂອງເຮົາ. ນອກຈາກນີ້, ມັນຍັງມີໜ້າທີ່ສຳຄັນຂອງຫຼາຍ feature.
Web app manifest ສາມາດ:
- ຄວບຄຸມວ່າເວັບເຮົາຈະສະແດງຜົນໃຫ້ຜູ່ໃຊ້ຂອງເຮົາເຫັນໃນພື້ນທີ່ທີ່ເຂົາຄາດວ່າຈະເຫັນໄດ້ແນວໃດ ຕົວຢ່າງ ຢູ່ໜ້າຈໍຫຼັກຂອງໂທລະສັບ (mobile home screen)
- ບອກໃຫ້ຜູ່ໃຊ້ຮູ້ວ່າແມ່ນຫຍັງທີ່ເຂົາສາມາດໃຊ້ງານໄດ້
- ກຳນົດການສະແດງຜົນຂອງມັນວ່າມັນຈະສະແດງຜົນແນວໃດໃນຂະນະທີ່ມັນກຳລັງເປີດ
4.3.1 ແນະນຳ web push ແລະ ການແຈ້ງເຕືອນ (Intro to web push and notification)
Push notification ເປັນລະບົບທີ່ ນັກພັດທະນາ ທັງຫຼາຍຝັນວ່າຢາກໃຫ້ມີແຕ່ດົນ ເພາະຜົນປະໂຫຍດຂອງມັນມີຄ່າຫຼາຍຕໍ່ ນັກພັດທະນາຂອງເຮົາ ມັນຊ່ວຍໃຫ້ ຜູ່ໃຊ້ ກັບເຂົ້າມາເວັບໃຊ້ເຮົາຄືນ, ສາມາດແຈ້ງເຕືອນ ເຫດການຕ່າງໆທີ່ສຳຄັນ ໂດຍທີ່ຜູ່ໃຊ້ບໍ່ໄດ້ເປີດເວັບເຮົາ ຫຼື browser ຢູ່.
2 ເຕັກໂນໂລຢີທີ່ອັນດຽວກັນ ແຕ່ ຕ່າງກັນ.
Push ແລະ notification ໃຊ້ຕ່າງການ ແຕ່ ໃຊ້ເຮົາກັນໄດ້. APIs: push ຈະເຂົ້າມາມີສ່ວນຮ່ວມ (ໃຊ້ງານ) ເວລາທີ່ server ສະໜອງຂໍ້ມູນໃຫ້ກັບ service worker; notification ແມ່ນການກະທຳ (action) ຂອງ service worker ຫຼື web page script ເພື່ອສະແດງຂໍ້ມູນນັ້ນໃຫ້ກັບຜູ່ໃຊ້.
ແລ້ວ Service worker ມີສ່ວນຮ່ວມບໍ່?
ມີແນ່ນອນ! Push ແມ່ນພື້ນຖານທີນອນຢູ່ໃນ service worker ເພາະ service work ເຮັດວຽກຢູ່ເບື້ອງຫຼັງ (background). ໝາຍຄວາມວ່າ ມີເວລາດຽວເທົ່ານັ້ນທີ່ code ມັນຈະເຮັດວຽກ (ເວົ້າອີກຢ່າງໜຶ່ງກໍຄື ເວລາດຽວເທົ່ານັ້ນທີ່ແບັດເຕີຣີຈະຖືກໃຊ້) ກໍ່ຕໍ່ເມື່ອຜູ່ໃຊ້ງານໂຕ້ຕອບກັບມັນ ກໍ່ຄືໂຕ້ຕອບກັບການແຈ້ງເຕືອນດັ່ງກ່າວໂດຍການ ກົດມັນ ຫຼື ປິດມັນ.
ຮູ້ຈັກກັບລະບົບ notification ຈັກໜ້ອຍໜຶ່ງ
ທ່ານເອີ້ນໃຊ້ showNotification ໃນ service worker notification registration object:
serviceWorkerRegistration.showNotification(titile, options);
{
"body": "Did you make a $1,000,000 purchase at Dr. Evil...",
"icon": "images/ccard.png",
"vibrate": [200, 100, 200, 100, 200, 100, 400],
"tag": "request",
"actions": [
{ "action": "yes", "title": "Yes", "icon": "images/yes.png" },
{ "action": "no", "title": "No", "icon": "images/no.png" }
]
}
Code ຂ້າງເທິງຈະສ້າງການແຈ້ງເຕືອນຄືກັບຮູບຂ້າງເທິງນີ້ ເຮົາຈະເຫັນວ່າ ການແຈ້ງເຕືອນຂອງມັນຈະຄືກັບການແຈ້ງເຕືອນ native app ເລີຍ.
ມັນຫຍັງທີ່ເປັນການແຈ້ງເຕືອນທີ່ດີ? (what make a good notification?)
ດຽວເຮົາຈະມາຮູ້ກັນວ່າ ເຮົາຈະໃຊ້ການແຈ້ງເຕືອນແນວໃດໃຫ້ຖືກວິທີ ເຖິງວ່າການແຈ້ງເຕືອນຈະມີປະໂຫຍດຕໍ່ຜູ່ໃຊ້ເຮົາ ແຕ່ເຮົາກໍຈະຕ້ອງເບິ່ງກາລະເທສະນຳ ບໍ່ແມ່ນວ່າ ມີຫຍັງໜ້ອຍໜຶ່ງກໍແຈ້ງເຕືອນໂລດ ເພາະມັນຈະເຮັດໃຫ້ຜູ່ໃຊ້ຂອງເຮົາລຳຄານ ລະກະຈາກໄປໂດຍບໍ່ມີວັນກັບຄືນມາ. ເຮົາຈະຕ້ອງມາເບິ່ງວ່າຄວາມສົມດຸນຂອງການແຈ້ງເຕືນມີຫຍັງແນ່?
- ເວລາ(Timely): ເວລາທີ່ການແຈ້ງເຕືອນຂອງເຮົາຈະໂຊ ແມ່ນກໍຄືເວລາທີ່ຜູ່ໃຊ້ງານຂອງເຮົາຕ້ອງການ ແລະ ເວລາທີ່ມັນຈຳເປັນສຳລັບເຂົາ.
- ຊັດເຈນ-ແຈມແຈ້ງ (Precise): ການແຈ້ງເຕືອນທີ່ຊັດເຈນ ຊັດເຈນໃນນິຍາມນີ້ຈະຕ້ອງປະກອບດ້ວຍ ຂໍ້ມູນທີ່ເຈາະຈົງທີ່ສາມາດຮູ້ໄດ້ທັນທີທັນໃດ.
- ສຳພັນກັນ (Relevant): ຂໍ້ມູນທີ່ສຳພັນ ກ່ຽວຂ້ອງກັນ ໃນນີ້ກໍຄື ຄົນ ຫຼື ອົງກະກອບໃດໜຶ່ງ ທີ່ຜູ່ໃຊ້ຂອງເຮົາສົນໃຈ.
ຈະລອງຫຼິ້ນໄດ້ແນວໃດ?
ທ່ານສາມາຫຼິ້ນໄດ້ຜ່ານ Google Chrome GitHub ຫຼື ຂອງ Peter Beverloo Notification Generator
4.3.2 ວິທີຂັ້ນຕອນຂະບວນການຈ່າຍເງິນ (Payment integration)
ຜູ່ໃຊ້ໂທລະສັບມືຖືຈະບໍ່ຈ່າຍເງິນ ຫຼື ຊື້ສິນຄ້າຜ່ານໂທລະສັບ ຫຼາຍກ່ວາ 2 ເທ່າ ຂອງການຈ່າຍຜ່ານຄອມພິວເຕີຍ້ອນ
ແນະນຳ Payment Request API
ຂັ້ນຕອນການຈ່າຍເງິນ
ຂອບໃຈຂໍ້ມູນ Mobile Site Certificate Assessment Guideline | Google Partner
