เว็บเร็วต้องรักษาได้ทุกครั้งที่ปล่อยงาน

743e4881aa7966bb06de5bb4c9b8d133d41069ec9189c5d90347a6d9fa8eaa37

ตั้งงบประมาณให้คนออกแบบและคนอนุมัติเห็นต้นทุนเดียวกัน

Performance budget คือเพดานที่ทีมตกลงก่อนเพิ่มของเข้าหน้าเว็บ เช่น เวลาแสดงเนื้อหา งานที่ขวางการตอบสนอง และปริมาณ JavaScript ที่ต้องรับส่ง การตัดสินใจเรื่องภาพหรือ widget จะชัดขึ้นเมื่อเห็นว่าของใหม่ใช้พื้นที่ในงบเท่าไร

ค่าตารางต่อไปนี้เข้มกว่า policy จริงด้านบน เป็นตัวอย่างสำหรับเริ่มคุย ต้องวัด baseline ในสภาพแวดล้อมที่กำหนดก่อนนำไปใช้ ไม่ใช่ค่าที่ตรวจพบจาก production ของ Enersys

ค่า LCP 3,500 ms ใน lab ตัวอย่างนี้เป็นเกณฑ์ของการทดสอบเฉพาะชุด ไม่ใช่การเปลี่ยนเกณฑ์ good ของ Core Web Vitals ที่ 2.5 วินาที และการผ่าน CLS ระหว่างโหลดหน้าก็ยังไม่ยืนยันว่าจะไม่มีการขยับหลังคนเลื่อนอ่านหรือเปิดส่วนอื่น

งบ 250 KiB ต้องระบุด้วยว่ารวมไฟล์อะไรบ้าง หากรายงานหนึ่งนับขนาดไฟล์ก่อนบีบอัด แต่อีกรายงานนับข้อมูลที่รับส่งจริง สองตัวเลขนั้นนำมาเทียบเป็น regression โดยตรงไม่ได้

เริ่มจากเพดานที่ทีมรักษาได้ แล้วกำหนดวันที่จะทบทวนเพื่อลดงบลง การตั้งเกณฑ์สูงจนทุกคนต้องขอยกเว้นทุกครั้งจะทำให้ gate เสียหน้าที่ตั้งแต่ต้น

อ่านค่าตั้งให้เห็นว่าระบบตัดสินอย่างไร

ด้านล่างเป็นตัวอย่าง lighthouserc.cjs สำหรับงานที่เตรียม static export ไว้แล้ว ค่าที่เข้มขึ้นทั้งหมดเป็นข้อเสนอ ควรตรึงเวอร์ชัน Lighthouse CI, Chrome และ dependencies ในการใช้งานจริง

module.exports = {
  ci: {
    collect: {
      staticDistDir: './out',
      url: [
        'http://localhost/th',
        'http://localhost/en',
      ],
      numberOfRuns: 3,
    },
    assert: {
      assertions: {
        'categories:performance': ['error', {
          minScore: 0.85,
          aggregationMethod: 'median',
        }],
        'largest-contentful-paint': ['error', {
          maxNumericValue: 3500,
          aggregationMethod: 'median',
        }],
        'total-blocking-time': ['error', {
          maxNumericValue: 300,
          aggregationMethod: 'median',
        }],
        'cumulative-layout-shift': ['error', {
          maxNumericValue: 0.1,
          aggregationMethod: 'median',
        }],
        'categories:accessibility': ['error', {
          minScore: 0.80,
          aggregationMethod: 'median',
        }],
      },
    },
    upload: {
      target: 'filesystem',
      outputDir: './lighthouse-results',
    },
  },
};

ตัวอย่างใช้ error ให้การผิดเกณฑ์จบด้วย exit code ที่ไม่เป็นศูนย์ และระบุ median ให้ใช้ค่ากลางของแต่ละตัวชี้วัดจาก 3 รอบอย่างชัดเจน อย่าอ่านค่าจาก run สุดท้ายใน manifest แล้วถือว่าเป็นผลตัดสินรวม เอกสารการตั้งค่า Lighthouse CI

งบ JavaScript ในตารางยังไม่ได้ถูกตรวจด้วยโค้ดชุดนี้ ต้องเพิ่มการตรวจขนาดที่ตกลงนิยามตรงกัน ส่วน Accessibility 0.80 เป็นเพียงค่าขั้นต่ำที่นำมาจาก workflow เดิม ไม่ใช่คำรับรองว่าเว็บไซต์เข้าถึงได้ตามมาตรฐานหรือใช้ keyboard และ screen reader ได้ครบทุกงาน

การตรึงเวอร์ชันช่วยให้รู้ว่าตัวเลขเปลี่ยนจากหน้าเว็บหรือเครื่องมือ เมื่อจะอัปเกรดเครื่องมือ ให้รัน baseline เก่าและใหม่เทียบกันก่อนปรับเกณฑ์ อย่าอัปเกรดและลดความเข้มของเกณฑ์ในงานเดียวจนแยกสาเหตุไม่ได้

ตัวอย่างเมื่อภาพใหม่ทำให้ release ติด gate

สมมติว่าหน้าบริการจะเปลี่ยนภาพหลักและเพิ่ม widget ภายนอก ตัวเลขทั้งหมดในส่วนนี้สร้างขึ้นเพื่ออธิบายการตัดสินใจ ไม่ใช่ผลของเว็บ Enersys

candidate ไม่ผ่านตัวอย่างเกณฑ์ Performance และ LCP แม้รอบที่คะแนนดีที่สุดจะได้ 0.87 การเลือกภาพรายงานรอบนั้นมาแสดงอย่างเดียวทำให้คนอนุมัติเห็นข้อมูลไม่ครบ ส่วน TBT ยังอยู่ในงบ จึงไม่มีเหตุผลพอจะบอกว่า JavaScript เป็นสาเหตุหลักจากตารางนี้เพียงอย่างเดียว

ขั้นถัดไปคือเปิดรายงาน LCP และ network waterfall ดูว่า element ที่ถูกนับเป็นเนื้อหาหลักเปลี่ยนหรือไม่ ไฟล์ภาพใช้ขนาดเท่าไร browser เริ่มร้องขอเมื่อไร และ widget เข้ามาแย่งทรัพยากรช่วงใด ตั้งสมมติฐานแล้วเปลี่ยนทีละปัจจัย เช่น ทำภาพให้เหมาะกับขนาดที่แสดง จากนั้นวัดใหม่ด้วยเงื่อนไขเดิม

ในงานของนักพัฒนา ให้เริ่มจากจับคู่ LCP element กับ URL ของทรัพยากร แล้วแยกเวลารอ HTML เวลาก่อนเริ่มร้องขอทรัพยากร เวลาโหลด และเวลารอก่อนแสดงผล ถ้าร้องขอภาพช้า ให้ตรวจว่าหน้าเริ่มต้นเปิดเผยภาพให้ browser พบหรือยัง ถ้าไฟล์ใหญ่ ให้ปรับขนาดและการบีบอัด ถ้าโหลดเสร็จแล้วแต่ยังไม่แสดง ให้ตรวจงาน JavaScript หรือเงื่อนไขที่ซ่อนเนื้อหา แก้ส่วนที่รายงานชี้ วัดซ้ำ แล้วแนบ diff กับรายงานของ candidate ใหม่ วิธีแยกส่วนเวลาของ LCP

หากผลแก้ไขกลับเข้าเกณฑ์ ให้แนบรายงานใหม่เข้ากับ candidate ใหม่ด้วย ไม่ควรนำผลของไฟล์ชุดเก่ามาประกบโค้ดที่แก้ตามหลัง แม้แก้เพียงบรรทัดเดียว

ผลไม่ผ่านต้องแยกออกจากการตรวจที่ใช้ไม่ได้

เครื่องทดสอบที่แย่ง CPU กับงาน build อื่น อาจทำให้ผลแกว่ง ส่วน Chrome ที่เปิดไม่ได้หรือหน้าเว็บตอบ 404 ทำให้การตรวจใช้ยืนยันคุณภาพไม่ได้เลย ในข้อเสนอนี้ทั้งสองกรณีหยุดการปล่อยงานไว้ก่อน แต่ส่งต่อให้คนรับผิดชอบต่างกัน

เมื่อผิดเกณฑ์จริง เจ้าของการเปลี่ยนแปลงต้องตรวจ regression เมื่อเครื่องมือมีปัญหา ผู้ดูแลระบบทดสอบต้องคืนสภาพแวดล้อมให้พร้อม แล้วรัน candidate เดิมใหม่

นโยบาย retry ควรตกลงไว้ล่วงหน้า เช่น อนุญาตให้รันซ้ำ 1 ชุดเมื่อมีหลักฐานว่าเครื่องทดสอบผิดปกติ เก็บรายงานเดิมและเหตุผลไว้ด้วย หากผลชุดใหม่ยังแกว่งมาก ให้พักการตัดสินใจและแก้ความน่าเชื่อถือของการวัด การกดรันจนกว่าจะเจอสีเขียวทำให้เกณฑ์ที่ตั้งไว้ไม่มีความหมาย

ขั้นเก็บรายงานควรทำงานแม้ assertion ไม่ผ่าน และผลสุดท้ายยังต้องส่งสถานะไม่ผ่านกลับไป การเก็บ artifact สำเร็จไม่ได้แปลว่าการตรวจสำเร็จ เช่นเดียวกับงานที่ถูก skip หรือไม่มีรายงาน ไม่ควรถูกนับเป็น pass

จุดเชื่อมที่ทำให้รายงานกลายเป็นเงื่อนไขปล่อยงาน

ข้อเสนอของเราคือให้หลักฐานเดินไปกับ build ตั้งแต่สร้าง candidate จนขึ้น production

1. ระบุ source commit, lockfile และเวอร์ชันเครื่องมือ แล้วสร้าง release candidate
2. ให้ขั้นตรวจ performance อ่าน output ของ candidate นั้น ถ้า build เป็น container ให้ตรวจไฟล์ที่ดึงจาก image เดียวกัน หรือรัน image นั้นในสภาพแวดล้อมทดสอบ
3. เก็บผลตรวจทุก URL พร้อม commit และ artifact หรือ image digest
4. เปิดให้อนุมัติ production ต่อเมื่อผลตรวจที่ต้องใช้ครบและผ่าน แล้วปล่อย artifact เดิมตาม digest ที่ตรวจ
5. ตรวจหน้าเว็บหลังปล่อยงาน และเชื่อมข้อมูลจากผู้ใช้จริงกลับมาที่ release

ใน GitHub Actions ถ้าออกแบบให้ขั้นตรวจและขั้น deploy อยู่ใน workflow เดียวกัน สามารถใช้ needs สร้างความสัมพันธ์ของงานได้ แต่รายละเอียดต้องรวมการส่งต่อ artifact และการตรวจตัวตนของ candidate ด้วย การตั้งชื่องานว่า Lighthouse เฉย ๆ ไม่ได้สร้างความสัมพันธ์นั้น ความสัมพันธ์ระหว่าง jobs ใน GitHub Actions

ถ้าปล่อยงานผ่านอีกระบบหนึ่ง เช่นเส้นทาง manual ที่มีอยู่ในปัจจุบัน ระบบนั้นต้องตรวจผลที่ผูกกับ digest เดียวกันก่อนอนุมัติด้วย มิฉะนั้นผลใน pull request จะเป็นเพียงข้อมูลประกอบที่ข้ามได้

ขั้นตอนเร่งด่วนควรมีช่องทางยกเว้นที่บันทึกชื่อผู้อนุมัติ เหตุผล ความเสี่ยง ระยะเวลายกเว้น และงานแก้ไขตามหลัง การยกเว้นต้องปรากฏใน release record ว่ายังไม่ผ่าน gate ตามปกติ จะได้ไม่กลายเป็นเรื่องเล่าว่า release นั้นผ่านทุกเงื่อนไข

เฝ้าต่อเมื่อ production เริ่มรับคนใช้

การตรวจ output ในเครื่องช่วยจับสิ่งที่เราส่งออกไป แต่ยังไม่ครอบคลุม DNS, CDN, cache, third-party service และอุปกรณ์ของคนใช้ ข้อเสนอจึงมีการตรวจ URL production หลังปล่อยงานเพื่อจับความต่างของสภาพแวดล้อมอีกชั้น

ระหว่าง release ควรตรวจตามกำหนดด้วย เพราะ third-party เปลี่ยนพฤติกรรมได้โดยไม่มี commit ของเรา กำหนดหน้าที่ตรวจ profile เวลา และเจ้าของการแจ้งเตือนให้คงที่พอจะเปรียบเทียบได้ ก่อนส่งเตือนควรแยกปัญหาหน้าล่มกับ regression ที่ต้องตรวจเพิ่ม

สำหรับ field data ให้ติดตาม p75 แยกตามประเภทหน้าและอุปกรณ์เท่าที่จำนวนตัวอย่างพอ ระบุช่วงเวลาของข้อมูลและวันที่ปล่อยงานไว้บนกราฟเดียวกัน ข้อมูลที่รวมหลาย release จะใช้สรุปผลของ release ล่าสุดทันทีไม่ได้

หากใช้ CrUX ต้องตรวจว่าข้อมูลเป็นระดับ URL หรือระดับ origin และมีข้อมูลพอหรือไม่ CrUX มีเงื่อนไขด้านผู้ใช้และความนิยมของหน้า การไม่พบข้อมูลจึงยังบอกไม่ได้ว่าเว็บเร็วหรือช้า วิธีเก็บข้อมูลของ CrUX

หากต้องเก็บข้อมูลเอง ให้เลือกเฉพาะ metric และบริบทที่ช่วยแก้ปัญหา เช่นกลุ่มหน้าและ release identifier พร้อมกำหนดวิธีจัดการข้อมูลให้เหมาะกับบริการ การเอาข้อความที่คนกรอกในฟอร์มมาติดกับเหตุการณ์ performance ไม่ได้ช่วยให้วัดความเร็วดีขึ้น

ให้ทีมเห็นหลักฐานก่อนคำรับรอง

คนที่อนุมัติ release ควรเปิดบันทึกแล้วตอบได้ว่า ตรวจหน้าไหน ตรวจ candidate ใด ใช้เกณฑ์เวอร์ชันอะไร มีผลไม่ผ่านหรือข้อยกเว้นอะไร และถ้าต้องย้อนกลับจะใช้ artifact ใด เจ้าของเนื้อหาควรรู้ว่าภาพหรือ embed ใหม่ใช้งบส่วนไหน เจ้าของระบบควรรู้ว่า alert แต่ละแบบส่งถึงใคร

ด้านธุรกิจ ความเร็วช่วยให้คนเข้าถึงเนื้อหาและทำงานต่อได้ แต่ตัวเลขที่เร็วขึ้นไม่ใช่หลักฐานว่ารายได้เพิ่มขึ้นเท่าไร หากต้องการเชื่อมกับการติดต่อหรือยอดขาย ต้องวัดผลนั้นต่างหาก Google ระบุเช่นกันว่าผล Core Web Vitals ที่ดีไม่ได้รับประกันอันดับสูงสุดในผลค้นหา คำอธิบายเรื่อง page experience ของ Google Search

สำหรับทีมที่เริ่มวันนี้ งานแรกที่คุ้มค่าคือเลือกหน้าสำคัญหนึ่งหน้า เก็บ baseline ที่ตรวจซ้ำได้ แล้วลองทำให้ candidate ผิดเกณฑ์โดยตั้งใจในสภาพแวดล้อมทดสอบ หากระบบยังเปิดให้ปล่อย candidate นั้นผ่านเส้นทางปกติได้ จุดที่ต้องแก้ก่อนคือการเชื่อมหลักฐานเข้ากับสิทธิ์ปล่อยงาน

ใน 30 วันแรก เราเสนอให้ระบุชื่อเจ้าของงานวิศวกรรมที่ดูแล baseline และทบทวน regression ทุกสัปดาห์ ผู้ดูแลระบบรับผิดชอบการตรวจตามกำหนดที่ขัดข้องและเหตุผิดปกติใน production ส่วนผู้อนุมัติ release บันทึกข้อยกเว้น เจ้าของเนื้อหาช่วยดูภาพและ embed ใหม่เทียบกับงบ เมื่อครบ 30 วัน ให้เจ้าของงานเหล่านี้ทบทวนผลไม่ผ่าน เหตุผลที่ retry เวลาตอบสนอง วันหมดอายุข้อยกเว้น และขอบเขต field data แล้วตัดสินว่าจะลดงบหรือแก้ช่องว่างการวัดก่อน ข้อนี้เป็นแผนแบ่งความรับผิดชอบที่เสนอ ยังไม่ใช่คำยืนยันว่า Enersys มอบหมายหน้าที่เหล่านี้แล้ว