ในโลกของเทคโนโลยีที่เปลี่ยนไวมากมาย การจะทําเว็ปที่ได้ประสิทธิภาพดีๆๆไม่ใช่เรื่องง่ายๆเลย ไหนจะ ต้อง follow best practise ต่างๆ, แล้วถ้าเป็น progressive web app ก็จะอีกแบบเลย, loading time ที่มากมาย, SEO และอื่นๆมากมาย ….. การที่จะหามาตราฐานตามหน้าเว็ปก็ค่อนข้างยากที่จะอัพเดตตลอดเวลาอีกด้วย ถ้าเรามีโปรแกรมเล็กๆที่ทําการทดสอบได้ภายในที่เดียวละ จะดีกว่าแค่ไหนนน? เจ้า Lighthouse เลยเข้ามาช่วยเหลือนั้นเองงงงงงงงงงงงงงงงง 🙂

Lighthouse คืออะไร?

Official website Lighthouse  : Lighthouse คือ open-source, automated tool ของ google ที่ช่วยให้เราพัฒนาคุณภาพของเว็ปได้โดยมันะจะทําการวัดคุณภาพของเว็ปเราด้วย Best practise,SEO หรือหลากหลาย metrics ที่เราสามารถเพิ่มขึ้นมาเองได้ โดยเราจะเรียกมันง่ายๆว่า audits ซึ่งสามารถรันได้ทั้ง public และ private web (authentication)

โดยเราสามารถรัน lighthouse ได้หลากลหายวิธีมาก เช่น Chrome dev tool, cli หรือแม้แต่กระทั่ง Node module เพราะฉะนั้นมันจะทําให้เราสามารถใช้งานได้หลากหลายวิธีมากๆๆๆ (เอาไปรันกับ CI เป็นต้น หรือ เขียนแอพเพิ่ม)

Chrome dev tool

เข้าไปลองรันได้ง่ายๆเลยที่ tab “Audits” ซึ่งในนั้นจะมี options มากมายให้เราเลือกทําการทดสอง web application ของเรา

Cli

เป็น Node package ใช้ง่ายๆๆแค่สั่ง install แบบ global module “lighthouse” เลย .. ทีนี้เราจะสามารถใช้ผ่าน CLI ได้ละ

Programmatically

แต่ที่ชอบที่สุดคงไม่พ้น Node module ที่สามารถเรียกขึ้นมาใช้ได้เลย เพียงแค่ระบุ chrome port ให้มัน เพราะด้วยวิธีนี้เราจะสามารถประยุกต์ไปใช้ได้อีกหลายหลายวิธีเลย

ซึ่งเราสามารถอ่านและเข้าใจตัวอย่างได้ที่ github ของ Lighthouse

ตัวอย่างรายงานผล Lighthouse 

ตัว report จะออกมาตามหมวดหมู่ที่เราเลือกต้องการให้ทําการ audit และแสดงผลออกมาเป็น score scale โดยระบุว่ามันอยู่ใน range ที่รับได้หรือไม่นั้นเอง (ซึ่งเว็ปนี้ช้าน่าดูเลย แหะๆ)

โดยถ้าเลือกหมวด Performance เราจะสามารถเห็น trace ว่าเราใช้เวลาไปกับการโหลดอะไรมากที่สุด และเราจะสามารถแก้ไขได้ เพื่อเพิ่มประสิทธิ์ภาพของเว็ปเรา

ถ้าใครเป็นสาย dev จะต้องเคยใช้ inspector tool (F12) ของ chrome อยู่แล้ว จะคุ้นๆๆกับช่อง network ซึ่งพวกนี้คือข้อมูลเดียวกันนั้นเอง

Metrics ที่น่าสนใจของ Lighthouse 

สิ่งที่น่าใจคือการใช้ metric กับเว็ปเดี๋ยวนี้มันไม่เหมือนเดิมอีกแล้ว เพราะว่าโลกของเว็ปไม่เหมือนเดิมที่แค่ใช้ response time ของแต่ละเพจมาวัดได้ เช่น

  1. สมัยนี้มันมีสิ่งที่เรียกว่า server-side rendering (render ui จาก server ใส่) หรือ เทคนิคอื่นๆที่อนาคตจะเพิ่มมาขึ้นอีกเรื่อยๆๆๆๆ ดังนั้น response time จากฝั่ง server จะต้องใช้เวลาแน่นอน ซึ่งถ้าเรานําไปเปรียบเทียบกับเว็ปที่มัน render ฝั่ง FE ละ? มันก็จะกลายเป็นเว็ปเราแย่กว่าหรอ? ซึ่งด้วยวิธีนี้มันจะทําให้เราเทียบกันไม่ได้
  2. หรือถ้าเป็นเรื่องขนาดละ? ในสมัยก่อนเราชอบบอกยิ่งเล็กยิ่งดี (หรอ?) เพราะว่าหน้าเว็ปจะได้โหลดได้เร็วขึ้น แต่ถ้าเราต้องการให้มันใหญ่ขึ้นหน่อย เพื่อที่เราจะได้ perf. ที่ดีขึ้นละ แบบที่ไม่ต้องไป compute บนมือถือ … เห็นมะ เรื่องของขนาดมันก็ใช้วัดกันไม่ได้นั้นเองเมื่อไปเปรียบเทียบกับเว็ปที่มัน compress ทุกอย่างให้เล็กที่สุด แต่ไป compute หนักๆๆบนมือถือ เพราะฉะนั้นมันอยู่ที่ลีลา (ลีลาในการออกแบบของโปรแกรม)

เลยทําให้เป็นที่มาของ Perf Metrics 4 ตัวนี้

  1. FP (First Paint)
  2. FCP (First Contentful Paint)
  3. FMP (First Meaningful Paint)
  4. TTI (Time to interactive)

ซึ่งแต่ละตัวเป็นการวัด Metrics แบบใหม่

First Paint (FP)

คือ เมื่อ Pixel เม็ดแรกกเปลี่ยนไปบนหน้าจอ หรือพูดง่ายๆคือเมื่อจากหน้าขาวๆกลายเป็นมีสีหรือมีอะไรขึ้นมา background color เป็นต้น

First Contentful Paint (FCP)

เมื่อมี content ขึ้นมาบน screen เช่นแบบช่อง search ขึ้นมาบางส่วนเป็นต้น อาจจะไม่ใช่ส่วนสําคัญขึ้นมา

First Meaningful Paint (FMP)

อันนี้คือตัวหลักเลย คือ Primary content ขึ้นมา หรือแบบโครงสร้างขึ้นมา พูดง่ายๆก็น่าจะเป็นแบบเว็ปเพจโหลดขึ้นมาและแสดงเนื้อหาที่ผู้ใช้ต้องการเป็นต้น

Time To Interactive (TTI)

อันนี้ชัดเจนคือสามารถใช้ได้แล้ว แบบกดปุ่ม search ได้แล้วถึงแม้จะโหลดไม่ครบก็ตามที

มาดูตัวอย่างกับ Howtoautomate.in.th บน “มือถือ” กันดีกว่า 🙂

จะเห็นว่าหน้าจอเราขาวมาเรื่อยๆเลย แปลว่า FP มันจะเกิดเอาตอนรูปที่ 5 นั้นเอง แล้วถึงค่อยเป็น FMP

ซึ่งเมื่อเทียบกับ trace เลยเห็นได้เลยว่าเราเจอ FP/FCP/FMP เกิดในเวลาเดียวกัน นั้นเป็นเพราะว่าเว็ป HTA มันใช้วิธี render จาก server ก่อนแล้วค่อยแสดงผลทีเดียวเลยย

ถ้าบน Desktop จะอีกแบบนะ มันจะ FP,FCP แยกต่างหากกัน ทีนี้จะเห็นว่ามันขึ้นกับลีลาการออกแบบจริงๆนั้นเอง

มาเขียน Custom Metrics Lighthouse กันเองดีกว่า

ตอนนี้ทุกคนน่าจะเข้าใจว่า Lighthouse คืออะไรแล้วละ ทีนี้มาดูกันดีกว่าเราจะเขียน custom metrics กันยังไง โดยเริ่มต้นเราต้องเข้าใจถึง Architecuter ของ Lighthouse ก่อน จากรูปนี้

ซึ่งง่ายมากๆๆคือ lighthouse แบ่งเป็น 3 ส่วนนั้นก็คือ

  1. Gatherers
    • ทําหน้าที่รวบรวมข้อมูลต่างๆๆผ่าน chrome driver (devtools protocol) เพราะว่าบางทีเรา Inject JavaScript เข้าไปในเพจหลายที เพื่อทดลองต่างๆเช่น web offline services เป็นต้น
    • ได้ผลลัพธ์เป็น artifacts แล้วส่งต่อให้ audits
  2. Audits
    • artifacts ที่ได้มาเป็น json ใหญ่ยักษ์เลย
    • ซึ่งเราก็เอาข้อมูลพวกนี้มา validate นั้นเอง ซึ่งผลลัพธ์จะได้ json ออกมาก้อนใหญ่ๆ
  3. Categories
    • หลังจากนั้นก็เอา json ก้อนใหญ่ๆนั้นมาใช้ในการจัดหมวดหมู่และสร้างออกมาเป็น report นั้นเอง

สรุปการเขียน Custom Metrics

ง่ายๆเลยเขียนแค่ 3 อย่างคือ

  1. สร้าง Gatherer เพื่อเก็บข้อมูล
  2. สร้าง Audit เพื่อ verify ข้อมูล
  3. สร้าง config เพื่อรัน

🙂 🙂 🙂

สุดท้ายมาดูตัวอย่างโค้ด

โดยการทดสอบนี้เราจะใช้ howtoautomate.in.th เหมือนเดิมนะ เอาโค้ดได้จาก github HTA

Custom Config เพื่อรัน

Gather เพื่อเก็บข้อมูล

Audit เพื่อตรวจสอบข้อมูล

 

Leave a Reply

avatar

This site uses Akismet to reduce spam. Learn how your comment data is processed.