การปรับปรุง INP ของ Fotocasa ช่วยให้เมตริกหลักเติบโตขึ้น 27% ได้อย่างไร

เผยแพร่: 14 ตุลาคม 2025

Interaction to Next Paint (INP) เป็นเมตริก Core Web Vitals ที่สำคัญสำหรับการวัดการตอบสนอง ใน Fotocasa นั้น Google Search Console ได้ไฮไลต์หน้าเว็บจำนวนมากที่เปลี่ยนไปเป็น "ต้องปรับปรุง" และ "ไม่ดี" เมื่อ INP มาแทนที่ First Input Delay (FID) ในปี 2024 กรณีศึกษานี้อธิบายเครื่องมือและกลยุทธ์ที่ใช้ในการวินิจฉัยและแก้ไขปัญหาเหล่านี้ ซึ่งในท้ายที่สุดจะช่วยปรับปรุง INP ได้อย่างมาก

จุดเริ่มต้นของทีม Fotocasa

ก่อนที่จะเปลี่ยนจาก FID เป็น INP เกือบทุกหน้าเว็บทั้งบนเดสก์ท็อปและอุปกรณ์เคลื่อนที่อยู่ภายในเกณฑ์ "ดี" ซึ่งหมายความว่า Core Web Vitals ทั้งหมดในขณะนั้น (LCP, CLS และ FID) ทำงานได้ดี อย่างไรก็ตาม หลังจากเปลี่ยนไปใช้ INP เกือบทุกหน้าเว็บก็เปลี่ยนไปเป็น "ต้องปรับปรุง" และบางหน้าเว็บก็เปลี่ยนไปเป็น "ไม่ดี" เนื่องจากค่า INP เกิน 200 มิลลิวินาทีอย่างต่อเนื่องสำหรับการโต้ตอบของผู้ใช้ส่วนใหญ่

Google Search Console แสดงการกระจาย URL ของ Fotocasa บนเดสก์ท็อป โดยมีหลายหน้าที่เปลี่ยนจาก "ดี" เป็น "ต้องปรับปรุง" หลังจากที่ INP กลายเป็น Core Web Vitals
รูปที่ 1 Google Search Console - การกระจาย URL ของ Fotocasa บนเดสก์ท็อป: เมื่อ INP มีผลบังคับใช้ URL จำนวนมากที่ก่อนหน้านี้จัดอยู่ในประเภท "ดี" จะย้ายไปอยู่ในหมวดหมู่ "ต้องปรับปรุง"

การเปลี่ยนแปลงนี้ทำให้ทีม Fotocasa ตระหนักว่าตนเองมองข้ามแง่มุมที่สำคัญของประสบการณ์ของผู้ใช้ไป ในขณะที่ FID วัดเฉพาะความล่าช้าของการโต้ตอบครั้งแรกเท่านั้น แต่ INP จะประเมินการตอบสนองของการโต้ตอบทั้งหมด โดยพิจารณาถึงความล่าช้าในการประมวลผลอินพุตและการนำเสนอ การวัดผลที่ครอบคลุมมากขึ้นนี้เป็นตัวแทนที่ดีกว่ามากสำหรับการโต้ตอบที่แท้จริง (ตามที่ Google ระบุ) และโอกาสที่พลาดไป

แม้ว่า Google Search Console จะให้ข้อมูลประสิทธิภาพภาคสนาม แต่ก็ไม่ได้ให้ข้อมูลเชิงลึกแบบเรียลไทม์ ข้อมูลของรายงานนี้จะรวบรวมในช่วง 28 วัน ซึ่งทำให้ระบุการโต้ตอบที่ทำให้เกิดปัญหาในขณะนั้นได้ยาก

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

ด้วยเหตุนี้ เราจึงใช้ชุดเครื่องมือเพื่อช่วยวินิจฉัยและแก้ไขปัญหา โดยมีข้อกำหนดที่สำคัญที่สุดดังนี้

  • เครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome โดยเฉพาะแท็บประสิทธิภาพ
  • ระบบ RUM (Real User Monitoring) ที่กำหนดเองซึ่งสร้างโดยทีม Fotocasa ใน Datadog โดยใช้ไลบรารี web-vitals
  • เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React

เครื่องมือในการวินิจฉัยปัญหา

เราใช้เครื่องมือต่อไปนี้เพื่อวินิจฉัยและแก้ไขข้อบกพร่องเกี่ยวกับปัญหาด้านประสิทธิภาพของ INP

เครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome

วิธีที่ยอดเยี่ยมในการตรวจหาและทำซ้ำปัญหาที่เกี่ยวข้องกับ Core Web Vitals ในเว็บแอปพลิเคชันคือการใช้แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome แท็บประสิทธิภาพจะวัดเมตริก Core Web Vitals โดยอัตโนมัติ ซึ่งจะให้ความคิดเห็นทันทีเกี่ยวกับเมตริกการโหลด การโต้ตอบ และการเปลี่ยนเลย์เอาต์ โดยจะสอดคล้องกับวิธีที่ระบบรายงานเมตริกเหล่านี้ไปยังเครื่องมืออื่นๆ ของ Google โดยรวม

แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บของ Google Chrome ซึ่งแสดงไทม์ไลน์ที่มีเมตริกประสิทธิภาพต่างๆ เช่น LCP, FID และ CLS พร้อมด้วยกิจกรรมของ CPU และเครือข่าย
รูปที่ 2 แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome

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

แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บของ Google Chrome แสดงเมนูแบบเลื่อนลงการชะลอตัวของ CPU พร้อมตัวเลือกต่างๆ เช่น "ชะลอตัว 4 เท่า" และ "ชะลอตัว 6 เท่า"
รูปที่ 3 แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome แสดงเมนูแบบเลื่อนลงการชะลอตัวของ CPU

เมื่อระบุคอขวด การตรวจสอบส่วนย่อยของ INP และงานที่เบราว์เซอร์ดำเนินการภายในแต่ละส่วนจะมีประโยชน์อย่างยิ่ง ตัวอย่างเช่น ในรูปภาพต่อไปนี้ คุณจะเห็นว่า INP ค่อนข้างสูงเนื่องจากการคำนวณรูปแบบ 2 ครั้งที่เกิดจากการเปลี่ยนแปลงรูปแบบในเนื้อหาของเอกสาร

แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บใน Google Chrome แสดงงานที่ใช้เวลานานในโปรไฟล์เลอร์ โดยมีรายละเอียดที่ระบุการคำนวณรูปแบบ 2 รายการที่ทำให้เกิด INP สูง
รูปที่ 4 แท็บประสิทธิภาพในเครื่องมือสำหรับนักพัฒนาเว็บของ Google Chrome ที่แสดงโปรไฟล์เลอร์ที่สร้างขึ้น

Fotocasa ตั้งค่าระบบเพื่อติดตาม INP และเมตริกอื่นๆ ของ Core Web Vitals เพื่อให้มั่นใจว่าปัญหาด้านประสิทธิภาพจะได้รับการระบุและแก้ไขอย่างรวดเร็ว เมื่อเมตริกเกินเกณฑ์ที่เฉพาะเจาะจง (อิงตามช่วงที่ Google กําหนด) ระบบจะบันทึกการระบุแหล่งที่มาเพื่อให้วิเคราะห์และแก้ไขปัญหาได้

สำหรับระบบดังกล่าว เราใช้ไลบรารี web-vitals เพื่อบันทึกเมตริกเหล่านี้จากผู้ใช้จริงในลักษณะที่ตรงกับวิธีที่ Chrome วัดและรายงานไปยังเครื่องมืออื่นๆ ของ Google (เช่น รายงานประสบการณ์ของผู้ใช้ Chrome, PageSpeed Insights, รายงานความเร็วของ Search Console และอื่นๆ) อย่างถูกต้อง

Fotocasa ใช้ Datadog เพื่อรวบรวมและแสดงภาพข้อมูลเพื่อให้ได้มุมมองที่ครอบคลุมและการติดตามแบบรวมศูนย์ ซึ่งช่วยให้ทีมตัดสินใจได้อย่างมีข้อมูลและอิงตามข้อมูล เมตริกที่กําหนดเองช่วยให้ประหยัดค่าใช้จ่ายและติดตามผู้ใช้เกือบทั้งหมดในเว็บไซต์ Fotocasa ได้ดียิ่งขึ้น

แดชบอร์ด Datadog ของ Fotocasa แสดงเมตริกประสิทธิภาพต่างๆ รวมถึง INP, LCP และ CLS เมื่อเวลาผ่านไป
รูปที่ 5 แดชบอร์ด RUM ประสิทธิภาพของ Fotocasa Datadog
แดชบอร์ด Datadog แสดงกราฟสำหรับเมตริกความล่าช้าในการป้อนข้อมูล ระยะเวลาการประมวลผล และความล่าช้าในการนำเสนอ
รูปที่ 6 เมตริกความล่าช้าของอินพุต ระยะเวลาการประมวลผล และความล่าช้าในการนำเสนอ

ระบบนี้ช่วยให้ทีม Fotocase ตรวจสอบได้อย่างรวดเร็วว่าการแก้ไขส่งผลต่อเมตริกหรือไม่ หรือมีการเปลี่ยนแปลงที่ไม่คาดคิดเกิดขึ้น ซึ่งอาจทำให้เมตริกมีความเสี่ยง จากนั้นจึงจะวิเคราะห์เมตริก INP ออกเป็นส่วนต่างๆ เช่น ความล่าช้าของอินพุต ระยะเวลาการประมวลผล และความล่าช้าในการนำเสนอ เพื่อระบุได้อย่างแม่นยำว่าส่วนใดของการโต้ตอบเป็นสาเหตุหลักที่ทำให้เกิดระยะเวลาการโต้ตอบนาน

กราฟจาก Datadog แสดงค่า INP ที่เพิ่มขึ้นอย่างฉับพลัน ซึ่งบ่งบอกถึงความผิดปกติ
รูปที่ 7 ตรวจพบความผิดปกติของ INP ในแดชบอร์ด
การปลุกของมอนิเตอร์ใน Datadog แสดงความผิดปกติของ INP ที่ตรวจพบ
รูปที่ 8 ตรวจพบความผิดปกติของ INP ในการแจ้งเตือนของเครื่องมือตรวจสอบ

เมื่อตรวจพบความผิดปกติ เช่น ความผิดปกติที่แสดงในรูปที่ 7 และ 8 Fotocasa ได้ตอบสนองทันทีและใช้ OpenSearch ซึ่งเป็นอีกเครื่องมือหนึ่งที่ช่วยระบุตำแหน่งที่อาจเกิดการดัดแปลง ข้อมูลที่ได้จากไลบรารี Web Vitals ช่วยในการระบุเป้าหมาย (องค์ประกอบ DOM ที่อาจเป็นสาเหตุของค่าเมตริกที่สูงขึ้น) และช่วยให้ทีมมุ่งเน้นการแก้ไขปัญหาได้มากขึ้น

แดชบอร์ด OpenSearch ที่แสดงข้อมูลจากไลบรารี web-vitals ซึ่งใช้เพื่อระบุองค์ประกอบ DOM ที่ส่งผลต่อเมตริก INP
รูปที่ 9 แดชบอร์ด OpenSearch เพื่อแก้ไขข้อบกพร่องว่าเป้าหมายใดส่งผลต่อเมตริก INP

นอกจากนี้ ยังกําหนดตัวกรองต่างๆ ได้ เช่น ประเภทหน้าเว็บ อุปกรณ์ หรือสถานะการโหลด เพื่อเพิ่มประสิทธิภาพสถานการณ์ และทําความเข้าใจผลกระทบของ INP ได้อย่างแม่นยํายิ่งขึ้น

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ React ถูกนำมาใช้เพื่อเพิ่มความสามารถในการแก้ไขข้อบกพร่องของ Fotocasa ซึ่งเป็นฟีเจอร์ที่มีประสิทธิภาพที่ช่วยให้คุณไฮไลต์คอมโพเนนต์ที่ได้รับการแสดงผลซ้ำได้ด้วยภาพ

คุณเปิดใช้ฟีเจอร์นี้ได้โดยไปที่แท็บ Profiler จากนั้นคลิกไอคอนรูปเฟืองทางด้านขวาของแถบด้านบน ไปที่แท็บทั่วไป แล้วเลือกช่องทําเครื่องหมายไฮไลต์การอัปเดตเมื่อคอมโพเนนต์แสดงผล เมื่อเปิดใช้งานแล้ว ระบบจะไฮไลต์คอมโพเนนต์เมื่อมีการแสดงผลซ้ำ ซึ่งจะแสดงภาพแบบไดนามิก

แผงการตั้งค่าใน React Developer Tools โดยเลือกช่องทำเครื่องหมาย "ไฮไลต์การอัปเดตเมื่อคอมโพเนนต์แสดงผล"
รูปที่ 10 การกำหนดค่าโปรไฟล์เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React

การหาสาเหตุของการแสดงผลซ้ำ

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

หากต้องการเข้าถึงข้อมูลนี้ ให้บันทึกเซสชันโปรไฟล์ การวิเคราะห์เอาต์พุตของโปรไฟล์จะช่วยให้คุณพบข้อมูลที่เป็นประโยชน์ดังนี้

  • ที่มุมขวาบนจะแสดงจำนวนการคอมมิตของ React
  • กราฟเปลวไฟแสดงโครงสร้างคอมโพเนนต์ด้วยภาพ โดยสีเทาจะระบุคอมโพเนนต์ที่ไม่ได้แสดงผลซ้ำ แต่ละแท่งแสดงช่วงเวลาที่ทรีคอมโพเนนต์ React เปลี่ยนแปลง และช่วงเวลาที่มีการเปลี่ยนแปลงที่เกี่ยวข้องกับ DOM
  • การวางเมาส์เหนือคอมโพเนนต์แต่ละรายการในกราฟเปลวไฟจะแสดงเหตุผลในการแสดงผลซ้ำภายใต้ส่วนหัวย่อย Why did this render?

สาเหตุที่ทำให้คอมโพเนนต์แสดงผลอีกครั้งอาจรวมถึง

  • นี่เป็นครั้งแรกที่คอมโพเนนต์ได้รับการแสดงผล
  • เปลี่ยนบริบทแล้ว
  • เปลี่ยนฮุกแล้ว
  • เปลี่ยนพร็อพแล้ว
  • เปลี่ยนรัฐแล้ว
  • คอมโพเนนต์หลักที่แสดง
Profiler ของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React แสดงกราฟเปลวไฟ โดยมีเคล็ดลับเครื่องมือเปิดอยู่บนคอมโพเนนต์ที่อธิบายว่ามีการแสดงผลซ้ำเนื่องจาก "Hooks เปลี่ยนแปลง"
รูปที่ 11 แผงการแสดงผลในโปรไฟล์ React Developer Tools

การดูเวลาการแสดงผล

สีในกราฟเปลวไฟจะสื่อถึงข้อมูลที่มีความหมาย สี เช่น สีน้ำเงินเฉดต่างๆ แสดงว่าคอมโพเนนต์ต้องใช้เวลาในการแสดงผลค่อนข้างสั้นเมื่อเทียบกับคอมโพเนนต์อื่นๆ ในทางกลับกัน สีส้มและสีแดงแสดงว่าคอมโพเนนต์ใช้เวลาในการแสดงผลนานขึ้น

Profiler ของเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React แสดงกราฟเปลวไฟที่สีบ่งบอกถึงเวลาในการแสดงผล โดยเฉดสีน้ำเงินแสดงถึงเวลาที่สั้นกว่า และเฉดสีส้ม/แดงแสดงถึงเวลาที่นานกว่า
รูปที่ 12 เวลาในการแสดงผลตามที่แสดงในโปรไฟล์เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React

วิธีที่ทีม Fotocasa แก้ปัญหา

นำการแสดงผลซ้ำที่ไม่จำเป็นออก

การแสดงผลซ้ำจะเกิดขึ้นทุกครั้งที่ React ต้องอัปเดต UI ด้วยข้อมูลใหม่ โดยปกติแล้ว การดำเนินการนี้จะมาจากการกระทำของผู้ใช้ การตอบกลับของ API หรือเหตุการณ์สำคัญอื่นๆ ที่ต้องมีการอัปเดตอินเทอร์เฟซผู้ใช้ เนื่องจากการแสดงผลซ้ำแต่ละครั้งจะเรียกใช้ JavaScript การแสดงผลซ้ำพร้อมกันหลายครั้ง (โดยเฉพาะในแผนผังคอมโพเนนต์ขนาดใหญ่) อาจบล็อกเธรดหลักและทำให้เกิดปัญหาด้านประสิทธิภาพ

การแสดงผลซ้ำมี 2 ประเภท ได้แก่

  • การแสดงผลซ้ำที่จำเป็น: เมื่อคอมโพเนนต์จำเป็นต้องอัปเดตจริงๆ เนื่องจากเป็นเจ้าของหรือใช้ข้อมูลล่าสุด
  • การแสดงผลซ้ำที่ไม่จำเป็น: เมื่อคอมโพเนนต์อัปเดตโดยไม่มีการเปลี่ยนแปลงที่มีความหมาย มักเกิดจากการจัดการสถานะที่ไม่มีประสิทธิภาพหรือการจัดการพร็อพที่ไม่เหมาะสม

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

ซึ่งเป็นกรณีของทีม Fotocasa และพบว่าเว็บไซต์มีการแสดงผลซ้ำที่ไม่จำเป็นจำนวนมาก โดยเกิดขึ้นใน 2 สถานการณ์หลักๆ ดังนี้

  • ระหว่างการโหลดหน้าเว็บ: การเพิ่มจำนวนงานที่ใช้เวลานานในเทรดหลักและการหน่วงเวลาการโต้ตอบครั้งแรก ซึ่งส่งผลเสียต่อ INP ของหน้าเว็บ
  • ในระหว่างการโต้ตอบของผู้ใช้: การเพิ่มเวลาในการประมวลผลของการโต้ตอบส่วนใหญ่ ซึ่งส่งผลเสียต่อ INP ด้วย

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

  • มีงานที่ใช้เวลานานน้อยลง (ดูรูปที่ 1)
  • เวลาทั้งหมดในการบล็อกน้อยลง (เปรียบเทียบรูปที่ 14 และ 15)
ภาพรวมของเธรดหลัก 2 รายการจากเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome สแนปชอตด้านบนแสดงงานที่ใช้เวลานานมากขึ้นก่อนการเพิ่มประสิทธิภาพ ส่วนสแนปชอตด้านล่างแสดงงานที่ใช้เวลานานน้อยลงหลังจากนำการแสดงผลซ้ำที่ไม่จำเป็นออก
รูปที่ 13 ภาพรวมของเทรดหลักที่มีและไม่มีการแสดงผลซ้ำที่ไม่จำเป็น
รายงานประสิทธิภาพบนอุปกรณ์เคลื่อนที่ของ Lighthouse แสดงเวลาในการบล็อกทั้งหมด 1,080 มิลลิวินาที ซึ่งบ่งบอกถึงปัญหาด้านประสิทธิภาพที่เกิดจากการแสดงผลซ้ำที่ไม่จำเป็น
รูปที่ 14 รายงานประสิทธิภาพในอุปกรณ์เคลื่อนที่ของ Lighthouse ที่แสดงการแสดงผลซ้ำที่ไม่จำเป็น
รายงานประสิทธิภาพบนอุปกรณ์เคลื่อนที่ของ Lighthouse แสดงเวลาในการบล็อกทั้งหมดที่ลดลงอย่างมากหลังจากนำการแสดงผลซ้ำที่ไม่จำเป็นออก
รูปที่ 15 รายงานประสิทธิภาพของอุปกรณ์เคลื่อนที่ของ Lighthouse โดยไม่มีการแสดงผลซ้ำที่ไม่จำเป็น

การจัดวางเซิร์ฟเวอร์ร่วมในรัฐ

การวางสถานะ React อย่างไม่เหมาะสมอาจทำให้แอปพลิเคชันทำงานช้าลงและทำให้ UI ดูไม่ตอบสนอง เมื่อสถานะของคอมโพเนนต์เปลี่ยนแปลง คอมโพเนนต์ย่อยจะแสดงผลอีกครั้งโดยค่าเริ่มต้น เว้นแต่จะใช้การหลีกเลี่ยง (เช่น memo)

ตามที่อธิบายไว้ในส่วนก่อนหน้า การแสดงผลซ้ำไม่ได้แย่โดยเนื้อแท้ แต่การแสดงผลทั้งหน้าซ้ำเนื่องจากการอัปเดตสถานะที่เฉพาะเจาะจงอาจทําให้การโต้ตอบช้าลง เนื่องจากมีการอัปเดต DOM หลังจากการแสดงผล

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

แถบตัวกรองในหน้าค้นหาของ Fotocasa ซึ่งแสดงปุ่มเพื่อเปิดกล่องโต้ตอบที่มีตัวกรองทั้งหมด
รูปที่ 16 แถบตัวกรองของ Fotocasa

สถานะที่ควบคุมสถานะเปิดของกล่องโต้ตอบในกรณีนี้จะอยู่ในหน้าค้นหา เมื่อสถานะนี้เปลี่ยนไป ระบบจะแสดงผลหน้าเว็บทั้งหมดอีกครั้ง ซึ่งทำให้ INP ไม่ดี โดยเฉพาะในอุปกรณ์ที่ช้ากว่า ดังที่เห็นเมื่อใช้การควบคุมปริมาณ CPU ใน DevTools

การควบคุม CPU INP
ช้าลง 4 เท่า 440 มิลลิวินาที (ต้องปรับปรุง)
ช้าลง 6 เท่า 832 มิลลิวินาที (แย่)

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

การควบคุม CPU INP
ช้าลง 4 เท่า 64 มิลลิวินาที (ดี)
ช้าลง 6 เท่า 232 มิลลิวินาที (ต้องปรับปรุง)

นำสถานะที่ไม่จำเป็นออก

สถานะไม่ควรมีข้อมูลที่ซ้ำซ้อน หากทำเช่นนั้น อาจทำให้เกิดการแสดงผลซ้ำโดยไม่จำเป็นและทำให้เกิดปัญหาได้

เช่น ในแถบตัวกรองของ Fotocasa จะมีข้อความที่แสดงจำนวนตัวกรองที่ใช้สำหรับการค้นหาที่กำหนด

แถบตัวกรอง Fotocasa แสดงปุ่มที่มีป้ายกำกับว่า "ตัวกรอง" พร้อมตัวเลขที่ระบุจำนวนตัวกรองที่ใช้
รูปที่ 17 ปุ่มและตัวนับตัวกรองของ Fotocasa

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

const [filtersCount, setFiltersCount] = useState(DEFAULT_COUNTER)

useEffect(() => {
  const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER

  setFiltersCount(counter)
}, [searchParams]);

หากต้องการแก้ปัญหานี้ ค่าได้มาจากออบเจ็กต์ตัวกรองโดยใช้ตัวแปรแทนการใช้สถานะ

const counter = filters
    ? Object.keys(filters)
        ?.reduce(reducerCounter, [])
        ?.filter((param) => searchParams?.[param]).length
    : DEFAULT_COUNTER;

ลดการแสดงผลที่มีค่าใช้จ่ายสูง

เมื่อเกิดการโต้ตอบในแอปพลิเคชัน React โดยปกติแล้วการโต้ตอบจะทําให้เกิดการเปลี่ยนแปลงสถานะ ดังที่อธิบายไว้ก่อนหน้านี้ เมื่อสถานะของคอมโพเนนต์เปลี่ยนแปลง ระบบจะแสดงคอมโพเนนต์อีกครั้งพร้อมกับคอมโพเนนต์ย่อยทั้งหมด

หากฟังก์ชันการแสดงผลของคอมโพเนนต์ใดคอมโพเนนต์หนึ่งเหล่านี้ทำงานช้า ก็จะส่งผลเสียต่อ INP ของหน้าเว็บ เนื่องจากอาจมีการสร้าง Long Task และ DOM จะใช้เวลาในการอัปเดตนานขึ้น

ทีม Fotocasa พยายามลดการคำนวณที่ใช้เวลานานภายในฟังก์ชันการแสดงผลของคอมโพเนนต์ให้ได้มากที่สุด Chrome DevTools และเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ React มีประโยชน์อย่างมากในการตรวจหาการดำเนินการแสดงผลที่ช้า

หน่วงเวลาการเรียกใช้โค้ด

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

ตัวอย่างหนึ่งคือข้อมูลวิเคราะห์ ในกรณีนี้ เราจึงตัดสินใจที่จะชะลอการเรียกใช้โค้ดวิเคราะห์และจัดลําดับความสําคัญของการอัปเดต DOM เมื่อมีการโต้ตอบของผู้ใช้ ทีม Fotocasa จึงใช้ไลบรารีที่ชื่อ idlefy เพื่อให้มั่นใจว่าโค้ดวิเคราะห์จะยังคงทํางานต่อไปแม้ว่าจะปิดเบราว์เซอร์ทันทีหลังจากนั้นก็ตาม

วัฒนธรรมด้านประสิทธิภาพ

การปรับปรุงประสิทธิภาพไม่ใช่การดำเนินการแบบครั้งเดียว แต่เป็นสิ่งที่ต้องพิจารณาเมื่อมีการเปิดตัวฟีเจอร์แต่ละอย่างในเวอร์ชันที่ใช้งานจริง ทุกคนในทีมต้องทำงานร่วมกัน ไม่เช่นนั้น Core Web Vitals จะถดถอยลงอย่างแน่นอน

ทีม Fotocasa จึงแชร์ความรู้ภายในทีมอย่างสม่ำเสมอและสร้างกรอบการทำงานที่ชัดเจนสำหรับการระบุปัญหาด้านประสิทธิภาพโดยอิงตามข้อมูล RUM ของ Datadog ของ Fotocasa รวมถึงวิธีจำลองปัญหาดังกล่าว มีการตั้งค่าการแจ้งเตือนสำหรับ Core Web Vitals โดยเฉพาะ INP ในระบบ RUM เพื่อแจ้งเตือนทีม Fotocasa โดยตรงใน Slack แนวทางนี้ช่วยให้เราคำนึงถึงประสิทธิภาพเป็นอันดับแรกและช่วยตรวจพบปัญหาต่างๆ ก่อนที่จะกลายเป็นปัญหาที่ซับซ้อน

ผลลัพธ์

การปรับปรุง INP ที่ Fotocasa ต้องใช้การเพิ่มประสิทธิภาพทางเทคนิคและการเปลี่ยนแปลงทางวัฒนธรรมร่วมกัน การกำจัดการแสดงผลซ้ำที่ไม่จำเป็น การเพิ่มประสิทธิภาพการวางสถานะ การลดการแสดงผลที่มีค่าใช้จ่ายสูง และการเลื่อนโค้ดที่ไม่สำคัญ ทำให้ทีม Fotocasa ย้ายหน้าเว็บทั้งหมดบนเดสก์ท็อปจาก "ต้องปรับปรุง" เป็น "ดี" ได้สำเร็จ และปรับปรุงหน้าเว็บในอุปกรณ์เคลื่อนที่อย่างมากด้วยการอัปเกรดหน้าเว็บเกือบทั้งหมดที่อยู่ในระดับ "ไม่ดี" และ "ต้องปรับปรุง" เป็น "ดี"

Google Search Console แสดง Core Web Vitals ของ Fotocasa สำหรับเดสก์ท็อปหลังจากปรับปรุง INP
รูปที่ 18 Google Search Console แสดง Core Web Vitals ของ Fotocasa สำหรับเดสก์ท็อปหลังจากปรับปรุง INP

การเปลี่ยนแปลงเหล่านี้ช่วยปรับปรุงประสบการณ์ของผู้ใช้โดยรวมของ Fotocasa และเมื่อรวมกับโครงการริเริ่มอื่นๆ ก็ทําให้โฆษณาที่นําไปสู่โอกาสในการขายที่ได้จากการติดต่อและทางโทรศัพท์เพิ่มขึ้น 27% ซึ่งช่วยเสริมความแข็งแกร่งให้กับเมตริกทางธุรกิจที่สําคัญของบริษัทโดยตรง

การตรวจสอบแบบเรียลไทม์ด้วย Datadog ช่วยให้ทีม Fotocasa ตรวจสอบการปรับปรุง INP ตรวจจับความผิดปกติได้อย่างรวดเร็ว และป้องกันการเกิดปัญหาซ้ำ นอกเหนือจากความสำเร็จเหล่านี้ Fotocasa ยังฝังประสิทธิภาพของเว็บลงในวัฒนธรรมการพัฒนาของตนเองได้ด้วย เพื่อให้มั่นใจว่า INP และ Core Web Vitals จะยังคงเป็นสิ่งสำคัญอันดับแรกในทุกๆ การเปิดตัว