Firefox เร็วขึ้นสำหรับผู้ใช้จริงในปี 2023

 (hacks.mozilla.org)
1 คะแนน โดย GN⁺ 2023-11-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังการปรับแต่งประสิทธิภาพในปี 2023 Firefox ไม่ได้ดีขึ้นแค่ในเบนช์มาร์กเท่านั้น แต่ยังปรับปรุงทั้ง การโหลดหน้า, การตอบสนองต่ออินพุต และเวลาในการรัน JavaScript ในเทเลเมทรีของผู้ใช้จริงด้วย
  • Mozilla กำลังผลักดัน Speedometer 3 ร่วมกับเบราว์เซอร์อื่น ๆ เพื่อสร้างการทดสอบที่สะท้อนประสิทธิภาพที่ผู้ใช้รับรู้บนเว็บเพจจริงได้ดียิ่งขึ้น
  • เวลาตั้งแต่รับ ไบต์แรก จนถึง First Contentful Paint ลดลงจากราว 250ms เมื่อต้นปี เหลือ 215ms ในเดือนตุลาคม ทำให้การตอบสนองระหว่างการโหลดเร็วขึ้นเกือบ 15%
  • เวลาในการรัน JavaScript ระหว่างโหลดหน้าในเปอร์เซ็นไทล์ที่ 95 ลดลง 300ms จากราว 1560ms เหลือราว 1260ms และเชื่อมโยงกับการปรับแต่ง SpiderMonkey
  • หลังการออก Firefox 116 และ 117 ความหน่วงของการพิมพ์คีย์ที่ช้าที่สุดก็ลดจากราว 65ms เหลือต่ำกว่า 59ms เป็นการปรับปรุง 10% ที่ช่วยลดอาการสะดุดระหว่างพิมพ์

ทำไมการวัดประสิทธิภาพของผู้ใช้จริงจึงทำได้ยาก

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

การปรับปรุงการโหลดหน้าและเวลาในการรัน JavaScript

  • สำหรับประสิทธิภาพการโหลดหน้าที่ผู้ใช้รับรู้ First Contentful Paint ถูกใช้เป็นตัวชี้วัดที่เหมาะสมกว่าเหตุการณ์ onload
  • เกณฑ์การวัดคือเวลาตั้งแต่ได้รับ ไบต์แรก จากเครือข่ายจนถึง FCP
    • ค่านี้แสดงว่าผู้ใช้ได้รับสัญญาณตอบกลับว่าหน้ากำลังโหลดสำเร็จเร็วแค่ไหน
    • แม้ตัวเว็บเพจเองจะมีผลมาก แต่หากประสิทธิภาพโดยรวมของเบราว์เซอร์ดีขึ้น ตัวเลขนี้ก็อาจลดลงได้
  • เวลาที่เกี่ยวข้องกับ FCP ลดลงจากราว 250ms เมื่อต้นปี เหลือ 215ms ในเดือนตุลาคม
    • ความเร็วที่ผู้ใช้ได้รับสัญญาณตอบกลับระหว่างโหลดหน้าเร็วขึ้นเกือบ 15% เมื่อเทียบกับต้นปี
    • การปรับปรุงนี้มาจากงานเพิ่มประสิทธิภาพที่ไม่ได้เล็งเป้าไปที่การโหลดหน้าโดยตรง
  • เวลาในการรันโค้ด JavaScript ระหว่างโหลดหน้าถูกเปรียบเทียบโดยดูที่เปอร์เซ็นไทล์ที่ 95
    • ตัวชี้วัดนี้แสดงให้เห็นช่องทางในการลดแรงเสียดทานของผู้ใช้บนหน้าที่ใช้ JavaScript หนัก
    • ลดลงจากราว 1560ms เมื่อต้นปี เหลือราว 1260ms ในเดือนตุลาคม
    • ลดลง 300ms หรือเกือบ 20% และมีแนวโน้มว่าเกี่ยวข้องกับการลดลงของเวลา FCP อยู่ไม่น้อย
  • เอนจิน JavaScript SpiderMonkey ได้รับการปรับแต่งอย่างมากผ่านงานของ Speedometer 3 และนำไปสู่การปรับปรุงเวลาในการรัน JavaScript

การเปลี่ยนแปลงที่เห็นได้ในด้านการตอบสนองต่ออินพุต

  • การตอบสนองหลังโหลดหน้าเสร็จวัดด้วย “keypress present latency”
    • คือเวลาตั้งแต่กดปุ่มบนคีย์บอร์ดจนผลลัพธ์นั้นแสดงบนหน้าจอ
    • เว็บเพจอาจต้องรัน JavaScript บนเมนเธรดเพื่อตอบสนองต่ออีเวนต์ keypress ทำให้มีงานมากกว่าแค่การเรนเดอร์ข้อความธรรมดา
  • การพิมพ์ส่วนใหญ่รวดเร็วและมักถูกจำกัดด้วยฮาร์ดแวร์อย่างอัตรารีเฟรชของจอภาพ แต่กรณีอินพุตที่ช้าสามารถรบกวนประสบการณ์ใช้งานได้มาก
  • เนื่องจากการบรรเทากรณีที่แย่ที่สุดมีความสำคัญ ตัวชี้วัดนี้จึงดูที่ เปอร์เซ็นไทล์ที่ 95 เช่นกัน
  • keypress present latency ที่เปอร์เซ็นไทล์ 95 อยู่ที่ราว 65ms ตลอดเกือบทั้งปี และลดลงเหลือต่ำกว่า 59ms หลังการออก Firefox 116 และ 117 ในเดือนสิงหาคม
    • กรณีการกดคีย์ที่ช้าที่สุดดีขึ้นราว 10%
    • ผู้ใช้จะได้รับการตอบสนองที่ฉับไวขึ้นและถูกรบกวนน้อยลงระหว่างการพิมพ์
  • การปรับปรุงในเทเลเมทรีแสดงให้เห็นว่างานด้านประสิทธิภาพในปี 2023 ส่งผลเชิงบวกต่อผู้ใช้ Firefox จริง และยังมีพื้นที่ให้ปรับแต่งเพิ่มเติมได้อีก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-11-01
ความคิดเห็นจาก Hacker News

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

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

  • ดีใจที่เห็น Mozilla ปรับปรุง Firefox จริง ๆ แทนที่จะย้ายองค์ประกอบ UI ไปมาเท่านั้น
    ในฐานะผู้ใช้มานาน อยากเชียร์ฝ่ายที่เป็นรองเพื่อช่วยรักษาสมดุลอำนาจของเว็บไว้แม้เพียงเล็กน้อย การที่ Mozilla โฟกัสกับเทคโนโลยีมากกว่าการเมืองเป็นเรื่องดี และอย่างไร Firefox ก็เป็นซอฟต์แวร์ที่ดี จึงไม่ได้มีเรื่องให้บ่นมากนัก

    • Mozilla จะเปลี่ยน UI ต่อไปก็ไม่เป็นไร ถ้าสิ่งนั้นช่วยเพิ่มผู้ใช้ได้ก็เป็นเรื่องดี และถ้า Mozilla ไม่อยากตามหลังอยู่เสมอ ก็ต้องมี อิสระในการรับความเสี่ยง
      เช่น FirefoxOS ดูเหมือนจะล้มเหลว แต่ความท้าทายใหญ่ ๆ ส่วนมากก็ล้มเหลวเป็นธรรมดา ถ้ามัวแต่เสียดายไม่ทำความท้าทายระยะยาวแบบนั้น สุดท้ายก็จะเป็นเหมือน Microsoft ที่เพิ่งมารู้ตัวทีหลังว่าเด็กสมัยนี้จำนวนหนึ่งไม่มีแม้แต่แล็ปท็อป และโทรศัพท์ก็แน่นอนว่าไม่ได้รัน Windows ผมคิดว่ามีโปรเจกต์แบบ FirefoxOS เพิ่มอีกก็ไม่เสียหาย
    • ไม่ใช่แค่การโฟกัสกับเทคโนโลยีเท่านั้น แต่การโฟกัสกับ ผลิตภัณฑ์ อย่าง Firefox ก็สำคัญเช่นกัน
      เพราะอาจอ้างว่าโฟกัสกับเทคโนโลยีอย่างเดียว แล้วทุ่มทรัพยากรทั้งหมดไปให้ Firefox OS ก็ได้
    • เห็นด้วยกับการสนับสนุนฝ่ายที่เป็นรองเพื่อสมดุลอำนาจของเว็บ และหลังจากเปลี่ยนมาใช้เมื่อไม่กี่ปีก่อน ก็ พอใจกับการย้ายมาใช้ จริง ๆ

  • หลังอัปเกรดเป็น 118 Firefox ค้างแบบสุ่มทุก ๆ ไม่กี่วัน ไม่ใช่ปัญหา CPU หรือ swap แต่หน้าต่างทั้งหมดจะค้าง และต้องใช้ killall firefox ถึงอย่างนั้น Firefox ก็ยังปิดตัวได้อย่างเรียบร้อย
    เพราะสแปมจากเสิร์ชเอนจินเลยหาข้อมูลที่เกี่ยวข้องได้ยาก และก่อน 118 ก็ใช้งานได้ดีมาหลายปี มันเกิดน้อยเกินไปจนยากจะทดลองทำซ้ำ เช่น ปิดส่วนขยายหรือสร้างโปรไฟล์ใหม่ คงต้องยอมทนไป

    • เป็นนักพัฒนา Firefox ครับ มีวิธีวินิจฉัยหลายอย่างขึ้นอยู่กับสภาพแวดล้อม ถ้าบน Linux ทุกอย่างค้างทั้งหมด มีโอกาสสูงว่าปัญหาอยู่ที่ parent process ซึ่งเป็นโปรเซสระดับบนสุดที่จัดการแท็บต่าง ๆ
      ถ้าเปิด crash reporter ไว้ ก็ส่ง SIGABRT ไปยัง parent process ได้ และหลังรีสตาร์ตจะมีรายการใน about:crashes ให้ส่งรายงานได้
      ถ้าใช้ Firefox จากดิสโทรและมี gdb กับ debuginfod ก็แนบ gdb เข้ากับ parent process ของ Firefox รับสัญลักษณ์ แล้วรัน thread all apply bt เพื่อ dump สแตกของทุกเธรดใน parent process ได้
      ถ้าใช้บิลด์ของ Mozilla ก็ใช้ https://firefox-source-docs.mozilla.org/toolkit/crashreporte... เพื่อเชื่อมกับ symbol server ของตัวเองได้ ทั้งนี้ขึ้นอยู่กับดิสโทร อาจใช้กับ Firefox จากดิสโทรได้หรือไม่ได้
      เมื่อได้ข้อมูลการแครชแล้ว ให้นำ stack, เวอร์ชัน Firefox, รายงานแครช, about:support และข้อมูลที่เกี่ยวข้องไปแนบใน bug tracker ของดิสโทร หรือที่ https://bugzilla.mozilla.org/enter_bug.cgi?product=Core
      อาการค้างแบบนี้บน Linux มักเป็นบั๊กระหว่าง Firefox กับสภาพแวดล้อมเดสก์ท็อป หรือปัญหาไดรเวอร์กราฟิก และถ้ามี stack ก็จะช่วยจำกัดสาเหตุได้มาก บางครั้งแก้ได้ด้วยการอัปเดตแพ็กเกจหรือปรับตั้งค่าเพียงอย่างเดียว
    • เคยมีอาการคล้ายกันใน Brave บนคอมพิวเตอร์สองเครื่อง และแก้ได้ด้วยการปิด hardware acceleration ทั้งสองเครื่องใช้กราฟิก Intel
    • สงสัยว่าใช้รุ่นที่ไม่ใช่ stable หรือ long-term support ของดิสโทร Linux อยู่หรือเปล่า
      ข้อร้องเรียนเรื่องความไม่เสถียรของ Firefox ที่เห็นใน HN ดูเหมือนโดยมากมาจากผู้ใช้ Windows หรือผู้ใช้ Linux ที่อัปเป็นเวอร์ชันล่าสุดนอกระบบแพ็กเกจของดิสโทร ในทางกลับกัน ผมใช้ Firefox บน Debian stable มาหลายปี และไม่เคยเจอบั๊กที่อธิบายไว้ในเธรดแบบนี้เลย
    • ถ้าเกิดตอนกำลังพิมพ์ อาจเป็น https://bugzilla.mozilla.org/show_bug.cgi?id=1844505 ผมก็ได้รับผลกระทบจากบั๊กนี้เหมือนกัน แต่จนถึงตอนนี้ยังไม่เคยคิดจะค้นหา ticket เลย
      ถ้าจะทำซ้ำ คงต้องลองใช้ binary ตรงจาก Mozilla แบบเดิม ๆ

  • เป็นข่าวดี และทำให้อยากกลับไปลองใช้อีกครั้ง
    ผมใช้มาเกือบ 20 ปีตั้งแต่ยุค Phoenix/Firebird ที่ติดตั้งแบบ “แตกไฟล์ไว้ที่ไหนสักที่” แต่ย้ายไปใช้เบราว์เซอร์ฐาน Chromium เพราะความต่างของความเร็วที่รู้สึกได้
    ผมไม่ได้รันเบนช์มาร์กเพื่อยืนยันข้อสงสัย หรือจับเวลาว่าใน Firefox การทำงานไหนช้ากว่ากี่มิลลิวินาที แต่ถ้าเป็นเครื่องมือที่ใช้ทั้งวันทุกวันรวมถึงงาน ก็รู้สึกถึงความต่างได้ง่าย
    ช่วงนี้เห็น รายงานการปรับปรุงประสิทธิภาพ หลายฉบับและตัวชี้วัดจากการใช้งานจริง เลยคิดว่าจะกลับไปลองใช้อีกสักไม่กี่วัน ถ้าไม่รู้สึกต่าง หรือรู้สึกว่าเร็วขึ้นจริง ก็จะย้ายกลับไป
    เหตุผลที่อยากกลับไปคือ เราจำเป็นต้องมีเอนจินเบราว์เซอร์ทางเลือก ผมไม่อยากให้คณะกรรมการมาตรฐานกลายเป็นงานแบบ “ปีนี้ Google กำหนดให้ทำแบบนี้”

    • ถ้ารวมประสิทธิภาพที่ดีเข้ากับส่วนเสริมยอดเยี่ยมอย่าง Multi Account Containers และ Tree Style Tabs ก็จะกลายเป็นเบราว์เซอร์ที่ยอดเยี่ยม

  • ฟีเจอร์เด็ดของ Firefox ยังคงเป็นการเปิดให้มี ความยืดหยุ่นในการจัดการแท็บ ได้ ด้วย Sidebery และ TreeStyleTab ทำให้ผมยังอยู่ในอีโคซิสเต็มของ Firefox ต่อไป
    สำหรับวิธีใช้งานที่สะสมแท็บไว้เยอะ ๆ หรือใช้แท็บเหมือนรายการสิ่งที่ต้องทำ ประสบการณ์ใช้งานดีกว่าอย่างท่วมท้นจนยากจะจินตนาการว่าตัวเองไปใช้อย่างอื่น
    บน Android ก็ใช้ Firefox เพราะมีส่วนเสริม uBlock Origin และ Dark Reader ทำให้การท่องเว็บบนมือถือดีขึ้นมาก ไม่ใช่ว่าผมภักดีกับ Firefox มากเป็นพิเศษ แค่ยังหาเบราว์เซอร์ฐาน Chromium ที่เข้ากับผมได้ดีเท่านี้ไม่เจอ

    • แท็บแนวตั้ง พื้นฐานของ Edge ก็ค่อนข้างดี แม้ฟีเจอร์ไม่ได้เยอะมาก เป็นแค่แท็บแนวตั้งที่มีการ unload อัตโนมัติและกลุ่มแท็บ แต่แลกกับความเสถียรมากและแทบไม่มีบั๊ก
    • ในฐานะคนที่สะสมแท็บไว้เยอะ ๆ Auto Tab Discard จำเป็นมาก มันช่วยพักแท็บเบื้องหลังที่ไม่ได้ใช้ไม่ให้กินทรัพยากร
      และยังชอบตรงที่ใช้ CSS เปลี่ยนแถบแท็บให้เป็นเช่นสามแถวที่เลื่อนได้
    • สงสัยว่าเวลาใช้ TreeStyleTab ได้ซ่อนแท็บด้านบนไปไหม หรือแสดงทั้งสองแบบไว้บนหน้าจอ
      บนจอเล็ก ถ้ามีทั้งคู่จะรู้สึกว่าเสียพื้นที่หน้าจอไปค่อนข้างมาก
    • เคยลองทั้งสองแบบแล้ว แต่สุดท้ายชอบ กลุ่มแท็บของ Safari มากกว่า เพราะผสานเข้ากับประสบการณ์เบราว์เซอร์ได้ลื่นไหลกว่า

  • ใช้ Firefox เป็นเบราว์เซอร์หลักมาหลายปีแล้วและดีมาก อาจเพราะส่วนใหญ่รันบนเครื่องสเปกสูง แต่ทั้ง Linux, Windows, Mac ก็แทบไม่มีอะไรให้บ่น

    • ผมก็เหมือนกันแม้ไม่ได้ใช้เครื่องสเปกสูง อุปกรณ์ที่ใช้ทุกวันทั้งหมดอายุเกิน 5 ปีแล้ว แต่พอใจกับชุด Firefox + uBlock Origin อย่างเต็มที่
    • ใช้มาหลายปีแล้วและเห็นด้วยแทบทั้งหมด แต่จุดที่เคยมีปัญหามีแค่ เครื่องมือนักพัฒนา
      เวลาเปิดไฟล์ JS ขนาดใหญ่ ดีบักเกอร์จะช้าลงค่อนข้างมาก และ source map ก็ยิ่งทำให้ช้าลงไปอีก บางครั้งเมื่อใช้ source map ก็ตรวจค่าตัวแปรไม่ได้เสมอไป ซึ่งอาจเป็นปัญหาการตั้งค่าเครื่องมือ build ก็ได้

  • ใน Speedometer 2 Firefox ช้ากว่า Chrome มาก และ Chrome ช้ากว่า Edge เล็กน้อย ถึงอย่างนั้นในชีวิตจริงผมคิดว่าไม่ได้ต่างกันมาก
    ผมเคารพและเชื่อถือ การคุ้มครองความเป็นส่วนตัว ของ Mozilla ส่วนความสามารถอย่าง container และการรัน Ublock กับ Tampermonkey บนมือถือประเมินค่าได้ยากมาก

    • สำหรับคนที่ใช้คอมพิวเตอร์สเปกต่ำ เรื่องนี้ยังสำคัญอยู่ ตอนเดินทาง หน้าจอ MacBook แตก เลยรีบซื้อโน้ตบุ๊ก Celeron 6305 RAM 4GB มา พอติดตั้ง Firefox ตามปกติ กลับช้าและกระตุกมากจนใช้ไม่ได้
      พอเปลี่ยนเป็น Edge ก็เร็วขึ้นมากและใช้ RAM 4GB น้อยลงด้วย ไม่คิดว่าความต่างจะมากขนาดนี้ แต่ปฏิเสธไม่ได้ว่าใน พีซีสเปกต่ำ Edge ทำงานได้ดีกว่าเบราว์เซอร์อื่นมาก
    • ตอนนี้เบราว์เซอร์หลัก ๆ ดูเหมือนจะเร็วเพียงพอกันหมดแล้ว ต่อไปอยากให้โฟกัสที่ การลดการใช้พลังงาน มากขึ้น
    • เกี่ยวกับเรื่องนี้ยังมี https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b... ด้วย
    • บนการเชื่อมต่อ 75Mbps Firefox โหลดทุกอย่างที่ต้องการได้ทันที
      เลยสงสัยว่าเบนช์มาร์กมีความหมายอะไร

  • ผมเชื่อว่าทีม Firefox รู้ว่ากำลังทำอะไรเรื่องประสิทธิภาพ และได้ข้อสรุปที่ถูกต้องแล้ว
    แต่สิ่งเล็ก ๆ ที่เสียดายคือ อยากเห็นการเปลี่ยนแปลงประสิทธิภาพเทียบกับช่วงเดียวกันของปีก่อนด้วย เพื่อควบคุม ผลกระทบตามฤดูกาล ภาพที่ 1 เป็นการเปลี่ยนแปลงในระดับ 1/100 วินาที ดังนั้นเมื่อดูสัญญาณระดับนี้ การควบคุม noise ดูจะสำคัญกว่า
    เสริมว่า ผมเป็นผู้ใช้ที่พอใจกับ Firefox

    • นั่นน่าจะเป็น arewefastyet ไม่ใช่เหรอ
      https://arewefastyet.com/
      เพิ่มเติมยังมี https://wiki.mozilla.org/Areweyet ด้วย
    • สงสัยว่าที่นี่กำลังสมมติผลกระทบตามฤดูกาลแบบไหน ผมไม่ค่อยรู้ด้านประสิทธิภาพเบราว์เซอร์ เลยไม่รู้ว่าองค์ประกอบของเทคโนโลยีเว็บที่ผู้คนบริโภคนั้นเปลี่ยนไปตามฤดูกาลจริง ๆ หรือไม่
      ถ้ามองแบบซื่อตรง เทรนด์ตรงนี้ดูสม่ำเสมอ และสัญญาณดูใหญ่กว่าการกระจายตัว เหมือนเป็นผลจากวิศวกรเก่ง ๆ ที่ปรับแต่งตัวชี้วัดดังกล่าวในช่วงเวลาที่วัด
      ขณะเดียวกันก็เห็นด้วยว่า ถ้ามีแกนเวลาที่ยาวกว่านี้ก็คงดี เพราะการปรับปรุงครั้งใหญ่ในเดือนสิงหาคมอาจไม่ได้เป็นเพราะ Firefox 116 ออกวันที่ 1 สิงหาคม แต่เป็นผลจากคนในซีกโลกเหนือดูเนื้อหาอ่านเล่นที่เบากว่าในช่วงฤดูพักร้อนก็ได้

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

    • ตอนนี้ผมใช้ Brave โดยปิด rewards, VPN, wallet แล้วปรับแฟล็กราว 20 ตัว สำหรับผมมันเร็วกว่า รองรับส่วนขยายได้ดีกว่า บั๊กน้อยกว่า และตอนเปิดแท็บน้อย ๆ ก็กินหน่วยความจำน้อยกว่า ผมเลือก Brave เพราะซิงก์ได้
      Firefox ก็น่าประทับใจ และผมก็เคยลองฟอร์กชื่อ Floorp ด้วย มีฟีเจอร์เสริมที่มีประโยชน์อยู่หลายอย่าง รองรับการซิงก์ และรู้สึกว่าดีกว่า Firefox ปกติ ผมเคยใช้ ungoogled-chromium มาก่อน
      https://github.com/Floorp-Projects/Floorp/releases
      น่าเสียดายที่จากประสบการณ์ของผม บางเว็บไซต์ยังทำงานได้ดีกว่าบนเบราว์เซอร์ Chromium แม้จะเป็นแค่ประสบการณ์ส่วนตัว แต่ผมรู้สึกเหมือนมีการ fingerprinting เชิงลบต่อ Firefox บนเว็บไซต์ของ Google และดูเหมือนจะมี memory leak มากกว่าด้วย เพราะ Manifest V3 สุดท้ายผมคงย้ายไป Firefox แต่ตอนนี้จะอยู่กับ Brave ไปก่อน

  • บอกตามตรงไม่แน่ใจเลยว่ามันดีขึ้นไหม แต่มีปัญหาอยู่สองอย่างที่แก้ไม่หายสักที
    อย่างแรก บนวิดีโอ VP9 การถอดรหัสวิดีโอด้วยฮาร์ดแวร์ ทำงานแปลก ๆ ต่อให้ปิดหรือบังคับใช้ AV1 ก็ยังกระตุกเป็นบางครั้ง
    อย่างที่สอง ถ้าอยู่ในสภาพแวดล้อมกราฟิกแบบไฮบริดแล้วเล่นเกมไปด้วยพร้อมเปิดวิดีโอไว้เบื้องหลัง kWin จะค้าง วิดีโอที่กำลังเล่นในเบราว์เซอร์จะกลายเป็นสีเขียว และทุกอย่างที่ใช้ iGPU หรือ dGPU จะกระตุกอย่างหนัก สุดท้ายต้อง logout แล้ว login ใหม่เพื่อรีสตาร์ตเซสชันเอง
    ปัญหาที่สองอาจเกิดจาก Nvidia prime offload บน Wayland ก็ได้ เป็นความผิดของผมเองที่ใช้การ์ด Nvidia แต่ผมหาหัวข้อที่เกี่ยวข้องซึ่งยังไม่ถูกแก้ใน Bugzilla ไม่เจอ และพูดตรง ๆ ก็กลัวนิดหน่อยว่าจะไปรายงานแล้วโดนถามจี้กลับ อยากดีบักต่อ แต่ไม่มีความอดทนแล้ว
    ยังไม่ถึงขั้นจะเลิกใช้ Firefox แต่เป็นปัญหากวนใจที่ยืดเยื้อสองอย่าง อย่างไรก็ขอแสดงความยินดีกับทีมด้วย วันนี้ผมเปลี่ยนคน 5 คนมาใช้ Firefox ได้สำเร็จ

    • บน Linux การถอดรหัสด้วยฮาร์ดแวร์น่าเสียดายที่ค่อนข้างวุ่นวาย ปัญหาส่วนใหญ่แบบนี้มีแนวโน้มว่า Firefox เชื่อมต่อกับ API การเข้ารหัสวิดีโอต่าง ๆ ได้ถูกต้องแล้ว แต่ฝั่งอย่างไดรเวอร์บางตัวต่างหากที่มีบั๊ก
      ถ้าเป็นเดสก์ท็อป การลองปิด การถอดรหัสวิดีโอด้วยฮาร์ดแวร์ ทั้งหมดก็น่าลอง
    • ทิป: มีส่วนขยาย Firefox ที่บังคับให้ YouTube ใช้ H.264 ได้
      เครื่องของผมรองรับการเร่งฮาร์ดแวร์ VP9 แต่ความเสถียรไม่ดี พอเปลี่ยนเป็น H.264 วิดีโอ YouTube ก็เล่นได้ลื่นขึ้น เว็บไซต์วิดีโออื่น ๆ โดยพื้นฐานใช้ H.264 อยู่แล้ว จึงจำเป็นจริง ๆ แค่กับ YouTube
    • ปัญหาที่สองนี่ทำเอาจะบ้าจริง ๆ หลายปีที่ผ่านมาผมมักเปิด YouTube หรือสตรีม Twitch ไว้บนจอที่สอง แต่ตอนนี้เจอเฟรมตก วิดีโอกระตุก และค้างอยู่ตลอด
      เป็น performance regression ที่แปลกมากจริง ๆ