เทคนิคเพื่อทำให้เว็บแอปโหลดเร็วแม้ในฟีเจอร์โฟน

การใช้โปรแกรมแสดงผลล่วงหน้าทำได้หลายวิธี ใน PROXX เราเลือกที่จะใช้ Puppeteer ซึ่งจะเปิด Chrome โดยไม่แสดง UI และให้คุณควบคุมอินสแตนซ์นั้นจากระยะไกลด้วย Node API ได้ เราใช้วิธีนี้เพื่อแทรกมาร์กอัปและ JavaScript จากนั้นอ่าน DOM กลับเป็นสตริง HTML เนื่องจากเราใช้ CSS Modules เราจึงได้รับ CSS แทรกในบรรทัดของสไตล์ที่ต้องการได้แบบไม่มีค่าใช้จ่าย

  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setContent(rawIndexHTML);
  await page.evaluate(codeToRun);
  const renderedHTML = await page.content();
  browser.close();
  await writeFile("index.html", renderedHTML);

เมื่อใช้ฟีเจอร์นี้ เราคาดว่า FMP จะมีประสิทธิภาพดีขึ้น เรายังคงต้องโหลดและเรียกใช้ JavaScript ในจํานวนเท่าเดิมกับก่อนหน้านี้ จึงไม่น่าที่ TTI จะเปลี่ยนแปลงมากนัก index.html ของเรามีขนาดใหญ่ขึ้นและอาจทำให้ TTI ล่าช้าออกไปเล็กน้อย วิธีเดียวที่จะทราบคือเรียกใช้ WebPageTest

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

การฝัง

เมตริกอีกรายการที่ทั้ง DevTools และ WebPageTest แสดงให้เราเห็นคือ Time To First Byte (TTFB) คือเวลาที่ใช้ในการส่งไบต์แรกของคําขอไปจนถึงการรับไบต์แรกของคําตอบ เวลานี้มักเรียกว่า Round Trip Time (RTT) ด้วย แม้ว่าในทางเทคนิคแล้วตัวเลข 2 ตัวนี้จะแตกต่างกัน โดย RTT จะไม่รวมเวลาประมวลผลคําขอฝั่งเซิร์ฟเวอร์ เครื่องมือสำหรับนักพัฒนาเว็บและ WebPageTest จะแสดงภาพ TTFB ด้วยสีอ่อนภายในบล็อกคำขอ/การตอบกลับ

เมื่อดูที่ Waterfall แล้ว เราพบว่าคำขอทั้งหมดใช้เวลาส่วนใหญ่ในการรอไบต์แรก

ปัญหานี้เป็นสิ่งที่ HTTP/2 Push สร้างขึ้นเพื่อแก้ปัญหาตั้งแต่แรก นักพัฒนาแอปทราบว่าต้องใช้ทรัพยากรบางอย่างและสามารถส่งทรัพยากรเหล่านั้นได้ เมื่อไคลเอ็นต์ทราบว่าต้องดึงข้อมูลอื่นๆ เพิ่มเติม ข้อมูลเหล่านั้นจะอยู่ในแคชของเบราว์เซอร์อยู่แล้ว ปรากฏว่า Push ของ HTTP/2 นั้นใช้งานยากเกินไปและเราไม่แนะนำให้ใช้ เราจะกลับมาพิจารณาปัญหานี้อีกครั้งในระหว่างการกำหนดมาตรฐาน HTTP/3 ในตอนนี้ วิธีแก้ไขที่ง่ายที่สุดคือแทรกทรัพยากรที่สำคัญทั้งหมดโดยลดทอนประสิทธิภาพในการแคช

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

ซึ่งทำให้ TTI ลดลง 1 วินาที ตอนนี้เรามาถึงจุดที่ index.html ของเรามีทุกอย่างที่จำเป็นสำหรับการแสดงผลครั้งแรกและกลายเป็นแบบอินเทอร์แอกทีฟแล้ว HTML สามารถแสดงผลได้ขณะที่ยังดาวน์โหลดอยู่ ซึ่งจะเป็นการสร้าง FMP ของเรา เมื่อ HTML แยกวิเคราะห์และดำเนินการเสร็จแล้ว แอปจะโต้ตอบได้

การแยกโค้ดอย่างหนัก

ใช่ index.html ของเรามีทุกอย่างที่จำเป็นต่อการสร้างการโต้ตอบ แต่จากการตรวจสอบอย่างละเอียดกลับพบว่ามีทุกอย่างอยู่ในนั้นด้วย index.html ของเรามีขนาดประมาณ 43 KB เรามาลองพิจารณาถึงสิ่งที่ผู้ใช้สามารถโต้ตอบด้วยได้ตั้งแต่เริ่มต้น เรามีแบบฟอร์มสำหรับกำหนดค่าเกมที่ประกอบด้วยองค์ประกอบ 2 อย่าง ปุ่มเริ่มต้น และอาจโค้ดบางอย่างเพื่อคงการทำงานและโหลดการตั้งค่าผู้ใช้ เท่านี้แหละ 43 KB ดูเหมือนว่าจะมีขนาดใหญ่

หากต้องการทำความเข้าใจที่มาของขนาดแพ็กเกจ เราสามารถใช้ Source Map Explorer หรือเครื่องมือที่คล้ายกันเพื่อแจกแจงองค์ประกอบของแพ็กเกจ ตามที่ได้คาดไว้ แพ็กเกจของเรามีตรรกะเกม เครื่องมือแสดงผล หน้าจอชนะ หน้าจอแพ้ และยูทิลิตีต่างๆ หน้า Landing Page ต้องใช้โมดูลเหล่านี้เพียงส่วนเล็กๆ เท่านั้น การย้ายทุกอย่างที่ไม่จําเป็นต่อการทำงานแบบอินเทอร์แอกทีฟไปยังโมดูลที่โหลดแบบเลื่อนเวลาไว้จะลด TTI อย่างมาก

สิ่งที่เราต้องทําคือแยกโค้ด การแยกโค้ดจะแยกกลุ่มที่รวมทุกอย่างไว้ด้วยกันออกเป็นส่วนเล็กๆ ที่โหลดแบบ Lazy Loading ได้เมื่อต้องการ Bundler ยอดนิยมอย่าง Webpack, Rollup และ Parcel รองรับการแยกโค้ดโดยใช้ import() แบบไดนามิก เครื่องมือจะวิเคราะห์โค้ดและแทรกโมดูลทั้งหมดที่นําเข้าแบบคงที่ ทุกอย่างที่คุณนําเข้าแบบไดนามิกจะใส่ไว้ในไฟล์ของตัวเองและจะดึงข้อมูลจากเครือข่ายก็ต่อเมื่อมีการเรียกใช้ import() แน่นอนว่าการเข้าร่วมเครือข่ายมีค่าใช้จ่ายและควรทำเฉพาะในกรณีที่คุณมีเวลาว่าง หลักการคือนําเข้าโมดูลที่จําเป็นอย่างยิ่งแบบคงที่ ณ เวลาโหลด และโหลดทุกอย่างที่เหลือแบบไดนามิก แต่คุณไม่ควรรอจนวินาทีสุดท้ายเพื่อโหลดโมดูลแบบ Lazy Load ที่แน่นอนว่าจะใช้ Idle Until Urgent ของ Phil Walton เป็นรูปแบบที่ยอดเยี่ยมสำหรับแนวทางกลางๆ ที่สมเหตุสมผลระหว่างการโหลดแบบ Lazy Loading กับการโหลดอย่างเต็มรูปแบบ

ใน PROXX เราได้สร้างไฟล์ lazy.js ที่นําเข้าแบบคงที่ทุกอย่างที่เราไม่ต้องการ ในไฟล์หลัก เราสามารถนําเข้า lazy.js แบบไดนามิก อย่างไรก็ตาม คอมโพเนนต์ Preact บางรายการของเราไปอยู่ใน lazy.js ซึ่งทำให้เกิดความซับซ้อนเล็กน้อยเนื่องจาก Preact จัดการคอมโพเนนต์ที่โหลดแบบเลื่อนเวลาไว้ล่วงหน้าไม่ได้ ด้วยเหตุนี้ เราจึงเขียน Wrapper ของคอมโพเนนต์ deferred สั้นๆ ที่ช่วยให้เราแสดงผลตัวยึดตำแหน่งได้จนกว่าคอมโพเนนต์จริงจะโหลดขึ้นมา

export default function deferred(componentPromise) {
  return class Deferred extends Component {
    constructor(props) {
      super(props);
      this.state = {
        LoadedComponent: undefined
      };
      componentPromise.then(component => {
        this.setState({ LoadedComponent: component });
      });
    }

    render({ loaded, loading }, { LoadedComponent }) {
      if (LoadedComponent) {
        return loaded(LoadedComponent);
      }
      return loading();
    }
  };
}

เมื่อดำเนินการเสร็จแล้ว เราจะใช้ Promise ของคอมโพเนนต์ในฟังก์ชัน render() ได้ ตัวอย่างเช่น คอมโพเนนต์ <Nebula> ที่แสดงภาพพื้นหลังแบบเคลื่อนไหวจะถูกแทนที่ด้วย <div> ที่ว่างเปล่าระหว่างที่คอมโพเนนต์กำลังโหลด เมื่อโหลดคอมโพเนนต์และพร้อมใช้งานแล้ว <div> จะถูกแทนที่ด้วยคอมโพเนนต์จริง

const NebulaDeferred = deferred(
  import("/components/nebula").then(m => m.default)
);

return (
  // ...
  <NebulaDeferred
    loading={() => <div />}
    loaded={Nebula => <Nebula />}
  />
);

เมื่อทำสิ่งเหล่านี้แล้ว เราลด index.html เหลือเพียง 20 KB ซึ่งน้อยกว่าครึ่งหนึ่งของขนาดเดิม การดำเนินการนี้ส่งผลต่อ FMP และ TTI อย่างไร WebPageTest ช่วยบอกได้

FMP และ TTI ของเราห่างกันเพียง 100 มิลลิวินาที เนื่องจากเป็นเพียงการแยกวิเคราะห์และเรียกใช้ JavaScript ที่ฝังไว้ หลังจากผ่านไปเพียง 5.4 วินาทีบน 2G แอปก็โต้ตอบได้อย่างเต็มที่ ส่วนโมดูลอื่นๆ ทั้งหมดที่ไม่จำเป็นต้องมีการโหลดในเบื้องหลัง

เทคนิคแพรวพราวเพิ่มเติม

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

บทสรุป

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

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

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

โปรดติดตามส่วน 2 ซึ่งเราจะพูดถึงวิธีเพิ่มประสิทธิภาพรันไทม์ในอุปกรณ์ที่มีข้อจำกัดสูง