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 ສ່ວນ​ຄື:

  1. AMP HTML ກະ​ຄື HTML ທຳ​ມະ​ດາ​ນິ​ລະ​ຕ່າງ​ແຕ່​ວ່າ​ຈະ​ຈຳ​ກັດ​ບາງ​ຢ່າງເພື່ອ​ປະ​ສິດ​ຕິ​ພາບ​ທີ່​ເຮົາ​ໄວ້​ວາງ​ໃຈ​ໄດ້ ແລະ ຕັດບາງ​ສ່ວນ​ເສີ​ມເພື່ອ​ສ້າງເນື້​ອ​ຫາ​ທີ່​ດີ​ກ່​ວາ HTML ທ​ຳ​ມະ​ດາ.
  2. AMP JS library ເພື່ອ​ໝັ້ນ​ໃຈ​ວ່າ render ໜ້າ​ທີ່​ເປັນ AMP HTML ໄດ້​ໄວ.
  3. ໃຊ້ 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?)

ດຽວ​ເຮົາ​ຈະ​ມາ​ຮູ້​ກັນ​ວ່າ ເຮົາ​ຈະ​ໃຊ້​ການ​ແຈ້ງ​ເຕືອນ​ແນວ​ໃດ​ໃຫ້​ຖືກວິ​ທີ ເຖິງວ່າ​ການ​ແຈ້ງ​ເຕືອນ​ຈະ​ມີ​ປະ​ໂຫຍດ​ຕໍ່​ຜູ່​ໃຊ້​ເຮົາ ແຕ່​ເຮົາ​ກໍ​ຈະ​ຕ້ອງ​ເບິ່ງ​ກາ​ລະ​ເທ​ສະ​ນຳ ບໍ່​ແມ່ນ​ວ່າ ມີ​ຫຍັງ​ໜ້ອຍ​ໜຶ່ງ​ກໍ​ແຈ້ງ​ເຕືອນ​ໂລດ ເພາະ​ມັນ​ຈະ​ເຮັດ​ໃຫ້​ຜູ່​ໃຊ້​ຂອງ​ເຮົາ​ລຳ​ຄານ ລະ​ກະ​ຈາກ​ໄປ​ໂດຍບໍ່​ມ​ີ​ວັນ​ກັບ​ຄືນ​ມາ. ເຮົາ​ຈະ​ຕ້ອງ​ມາ​ເບິ່ງວ່າ​ຄວ​າມ​ສົມ​ດຸນ​ຂອງ​ການ​ແຈ້ງ​ເຕືນ​ມີ​ຫຍັງ​ແນ່?

  1. ເວ​ລາ(Timely): ເວ​ລາ​ທີ່​ການ​ແຈ້ງ​ເຕືອນ​ຂອງ​ເຮົາ​ຈະ​ໂຊ ແມ່ນ​ກໍ​ຄື​ເວ​ລາ​ທີ່​ຜູ່​ໃຊ້​ງານ​ຂອງ​ເຮົາ​ຕ້ອງ​ການ ແລະ ເວ​ລາ​ທີ່​ມັນ​ຈຳ​ເປັນ​ສຳ​ລັບ​ເຂົາ.
  2. ຊັດ​ເຈນ-ແຈມ​ແຈ້ງ (Precise): ການ​ແຈ້ງ​ເຕືອນ​ທີ່​ຊັດ​ເຈນ ຊັດ​ເຈນ​ໃນ​ນິ​ຍາມນີ້​ຈະ​ຕ້ອງ​ປະ​ກອບ​ດ້ວຍ ຂໍ້​ມູນ​ທີ່​ເຈາະ​ຈົງ​ທີ່​ສາ​ມາດ​ຮູ້​ໄດ້​ທັນ​ທີ​ທັນ​ໃດ.
  3. ສຳ​ພັນ​ກັນ (Relevant): ຂໍ້​ມູນ​ທີ່​ສຳ​ພັນ ກ່ຽວ​ຂ້ອງ​ກັນ ໃນ​ນີ້​ກໍ​ຄື ຄົນ ຫຼື ອົງ​ກະ​ກອບ​ໃດ​ໜຶ່ງ ທີ່​ຜູ່​ໃຊ້​ຂອງ​ເຮົາ​ສົນ​ໃຈ.

ຈະ​ລອງຫຼິ້ນ​ໄດ້​ແນວ​ໃດ?

ທ່ານ​ສາ​ມາ​ຫຼິ້ນ​ໄດ້​ຜ່ານ Google Chrome GitHub ຫຼື ຂອງ Peter Beverloo Notification Generator

4.3.2 ວິ​ທີ​ຂັ້ນ​ຕອນ​ຂະ​ບວນການ​ຈ່າຍ​ເງິນ (Payment integration)

ຜູ່​ໃຊ້​ໂທ​ລະ​ສັບ​ມື​ຖື​ຈະ​ບໍ່​ຈ່າຍ​ເງິນ ຫຼື ຊື້​ສິນ​ຄ້າ​ຜ່ານ​ໂທ​ລະ​ສັບ ຫຼາຍ​ກ່​ວາ 2 ເທ່າ ຂອງ​ການ​ຈ່າຍ​ຜ່ານ​ຄອມ​ພິວ​ເຕີ​ຍ້ອນ

ແນະ​ນຳ Payment Request API

ຂັ້ນ​ຕອນ​ການ​ຈ່າ​ຍ​ເງິນ

 

ຂອບ​ໃຈ​ຂໍ້​ມູນ Mobile Site Certificate Assessment Guideline | Google Partner

Douangtavanh Kongphaly

Douangtavanh Kongphaly