ในปี 2021 ทีม Chrome Aurora ได้เปิดตัวสคริปต์ คอมโพเนนต์เพื่อปรับปรุง ประสิทธิภาพการโหลดสคริปต์ของบุคคลที่สามใน Next.js ตั้งแต่ที่เปิดตัวมา เราก็ได้ ได้ขยายขีดความสามารถเพื่อทำให้การโหลดทรัพยากรของบุคคลที่สามง่ายขึ้น เร็วขึ้นสำหรับนักพัฒนาซอฟต์แวร์
บล็อกโพสต์นี้ให้ภาพรวมเกี่ยวกับฟีเจอร์ใหม่ที่เราเปิดตัว ซึ่งส่วนใหญ่ โดยเฉพาะ @next/third-parties รวมถึงเค้าโครงของโครงการริเริ่มในอนาคตตามแผนกลยุทธ์ของเรา
ผลกระทบด้านประสิทธิภาพของสคริปต์บุคคลที่สาม
41% ของคำขอของบุคคลที่สามทั้งหมดในเว็บไซต์ Next.js เป็นสคริปต์ แตกต่างจากเนื้อหาอื่น สคริปต์ อาจใช้เวลานานในการดาวน์โหลดและเรียกใช้ ซึ่งจะบล็อกการแสดงผลและหน่วงเวลาการโต้ตอบของผู้ใช้ได้ ข้อมูลจาก Chrome รายงานประสบการณ์ของผู้ใช้ (CrUX) แสดงให้เห็นว่าเว็บไซต์ Next.js ที่โหลดเว็บไซต์ของบุคคลที่สามมากกว่า สคริปต์มีการโต้ตอบกับ Next Paint ต่ำกว่า (INP) และ Largest Contentful Paint (LCP) อัตราการผ่าน
ความสัมพันธ์ที่สังเกตได้ในแผนภูมินี้ไม่ได้แสดงนัยถึงสาเหตุ อย่างไรก็ตาม ท้องถิ่น การทดสอบจะให้หลักฐานเพิ่มเติมว่าสคริปต์ของบุคคลที่สาม ส่งผลต่อประสิทธิภาพของหน้าเว็บ เช่น แผนภูมิด้านล่างเปรียบเทียบห้องทดลองต่างๆ เมตริกต่างๆ เมื่อคอนเทนเนอร์ Google Tag Manager ซึ่งประกอบด้วย 18 รายการที่เลือกแบบสุ่ม แท็ก — จะถูกเพิ่มลงใน Taxonomy ซึ่งเป็นตัวอย่าง Next.js ที่ได้รับความนิยม แอป
เอกสาร WebPageTest ให้รายละเอียดเกี่ยวกับวิธีวัดเวลาเหล่านี้ เมื่อมองผ่านๆ ชัดเจนว่าเมตริกในห้องทดลองเหล่านี้ได้รับผลกระทบจากคอนเทนเนอร์ GTM สำหรับ เช่น Total Blocked Time (TBT) ซึ่งเป็นห้องทดลองที่มีประโยชน์ ที่มี INP โดยประมาณ เห็นการเพิ่มขึ้นเกือบ 20 เท่า
คอมโพเนนต์สคริปต์
เมื่อส่งคอมโพเนนต์ <Script> ใน Next.js เราก็ได้แนะนำ
ผ่าน API ที่ใช้ง่ายซึ่งมีลักษณะคล้ายกับ <script> แบบดั้งเดิม
การใช้งานนี้ช่วยให้นักพัฒนาซอฟต์แวร์ค้นหาสคริปต์ของบุคคลที่สามร่วมกันได้ใน
ในแอปพลิเคชันของตน และ Next.js จะดูแลการจัดลำดับ
สคริปต์หลังจากที่โหลดทรัพยากรที่สำคัญแล้ว
<!-- By default, script will load after page becomes interactive -->
<Script src="https://example.com/sample.js" />
<!-- Script is injected server-side and fetched before any page hydration occurs -->
<Script strategy=”beforeInteractive” src="https://example.com/sample.js" />
<!-- Script is fetched later during browser idle time -->
<Script strategy=”lazyOnload” src="https://example.com/sample.js" />
แอปพลิเคชัน Next.js นับหมื่นรายการ รวมถึงไซต์ยอดนิยมต่างๆ เช่น
Patreon, เป้าหมาย และ
แนวคิด - ใช้คอมโพเนนต์ <Script> แม้จะมีปัญหา
ประสิทธิภาพ นักพัฒนาซอฟต์แวร์บางรายได้เพิ่มความกังวลเกี่ยวกับ
สิ่งต่างๆ:
- ตำแหน่งที่จะวางคอมโพเนนต์
<Script>ในแอป Next.js ขณะที่ปฏิบัติตาม คำแนะนำการติดตั้งที่แตกต่างกันของผู้ให้บริการบุคคลที่สามต่างๆ (ประสบการณ์สำหรับนักพัฒนาแอป) - กลยุทธ์การโหลดใดเหมาะสมที่สุดที่จะใช้สำหรับ สคริปต์ของบุคคลที่สาม (ประสบการณ์ของผู้ใช้)
เพื่อแก้ไขข้อกังวลทั้งสองข้อนี้ เราจึงได้เปิดตัว @next/third-parties
ไลบรารีเฉพาะทางที่มีชุดคอมโพเนนต์และยูทิลิตีที่ได้รับการเพิ่มประสิทธิภาพ
ปรับแต่งสำหรับบุคคลที่สามที่ได้รับความนิยม
ประสบการณ์ของนักพัฒนาซอฟต์แวร์: ทำให้จัดการไลบรารีของบุคคลที่สามได้ง่ายขึ้น
สคริปต์ของบุคคลที่สามจำนวนมากมีการใช้ในเปอร์เซ็นต์ที่สูงของเว็บไซต์ Next.js โดย
Google Tag Manager ได้รับความนิยมมากที่สุด ซึ่งใช้โดย
66% ของเว็บไซต์ตามลำดับ
@next/third-parties บิลด์เพิ่มเติมจาก <Script>
ด้วยการแนะนำ Wrapper ระดับที่สูงกว่าที่ออกแบบมาเพื่อให้ใช้งาน
กรณีการใช้งานที่พบบ่อยเหล่านี้
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleTagManager gtmId="GTM-XYZ" />
</html>
);
}
Google Analytics ซึ่งเป็นสคริปต์ของบุคคลที่สามอีกประเภทหนึ่งที่ใช้กันอย่างแพร่หลาย (52% ของเว็บไซต์ Next.js) มีคอมโพเนนต์เฉพาะของตัวเองเช่นกัน
import { GoogleAnalytics } from "@next/third-parties/google";
export default function RootLayout({ children }) {
return (
<html lang="en">
<body>{children}</body>
<GoogleAnalytics gaId="G-XYZ" />
</html>
);
}
@next/third-parties ช่วยลดความซับซ้อนของกระบวนการโหลดสคริปต์ที่ใช้กันทั่วไป
แต่ยังทำให้เราสามารถพัฒนายูทิลิตี้สำหรับบุคคลที่สาม
เช่น การฝัง เช่น การฝัง Google Maps และ YouTube
ใช้ใน
8%
และ
4%
เว็บไซต์ Next.js ตามลำดับ และเรายังได้จัดส่งองค์ประกอบเพื่อให้
โหลดง่ายขึ้น
import { GoogleMapsEmbed } from "@next/third-parties/google";
import { YouTubeEmbed } from "@next/third-parties/google";
export default function Page() {
return (
<>
<GoogleMapsEmbed
apiKey="XYZ"
height={200}
width="100%"
mode="place"
q="Brooklyn+Bridge,New+York,NY"
/>
<YouTubeEmbed videoid="ogfYd705cRs" height={400} params="controls=0" />
</>
);
}
ประสบการณ์ของผู้ใช้: ทำให้โหลดไลบรารีของบุคคลที่สามได้เร็วขึ้น
ในโลกที่สมบูรณ์แบบ ไลบรารีของบุคคลที่สามที่ใช้กันอย่างแพร่หลายทั้งหมด ทำให้ข้อมูลการปรับปรุงประสิทธิภาพ กลายเป็นเรื่องไม่จำเป็น อย่างไรก็ตาม เราจะพยายามปรับปรุงผู้ใช้ของพวกเขาจนกว่าการเปลี่ยนแปลงนี้จะกลายเป็นจริง เมื่อผสานรวมผ่านเฟรมเวิร์กยอดนิยมอย่าง Next.js เราสามารถ ทดลองด้วยเทคนิคการโหลดแบบต่างๆ ดูให้แน่ใจว่าสคริปต์มีลำดับ ในลักษณะที่เหมาะสม และแชร์ความคิดเห็นของเรากับบุคคลที่สาม ของผู้ให้บริการเครือข่าย เพื่อกระตุ้นการเปลี่ยนแปลงอัปสตรีม
ดูตัวอย่างจากการฝังใน YouTube ในกรณีที่การติดตั้งใช้งานแบบอื่น
ประสิทธิภาพที่ดีกว่าการฝังตัวแบบเนทีฟ ปัจจุบันช่อง <YouTubeEmbed>
ส่งออกคอมโพเนนต์โดยการใช้งานของ @next/third-parties
lite-youtube-embed ซึ่ง
เมื่อแสดงในส่วน "สวัสดีทุกคน" การเปรียบเทียบ Next.js โหลดอย่างมาก
ได้เร็วขึ้น
ในทำนองเดียวกัน สำหรับ Google Maps เรารวม loading="lazy" เป็นแอตทริบิวต์เริ่มต้นสำหรับ
เพื่อให้มั่นใจว่าแผนที่จะโหลดเฉพาะเมื่อแผนที่อยู่ห่างจาก
วิวพอร์ต ซึ่งอาจดูเป็นแอตทริบิวต์ที่ชัดเจน โดยเฉพาะอย่างยิ่ง
ตั้งแต่ Google Maps
เอกสารประกอบ
ไว้ในข้อมูลโค้ดตัวอย่าง แต่จะมี
45% ของเว็บไซต์ Next.js ที่ฝัง Google Maps ใช้ loading="lazy"
การเรียกใช้สคริปต์ของบุคคลที่สามใน Web Worker
เทคนิคขั้นสูงอย่างหนึ่งที่เรากำลังสำรวจใน @next/third-parties ก็คือการทำให้
ย้ายสคริปต์ของบุคคลที่สามไปยัง Web Worker ได้ง่ายขึ้น เป็นที่นิยมโดย
เช่น Partytown วิธีนี้สามารถ
ผลกระทบของสคริปต์ของบุคคลที่สามที่มีต่อประสิทธิภาพของหน้าเว็บอย่างมาก โดย
กำลังย้ายทั้งหมดออกจากชุดข้อความหลัก
GIF แบบเคลื่อนไหวต่อไปนี้แสดงรูปแบบต่างๆ ของงานที่ใช้เวลานานและเทรดหลัก
เวลาในการบล็อกเมื่อใช้กลยุทธ์ <Script> ที่แตกต่างกันในคอนเทนเนอร์ GTM
ภายในเว็บไซต์ Next.js โปรดทราบว่าแม้จะสลับระหว่างตัวเลือกกลยุทธ์ต่างๆ เท่านั้น
ทำให้สคริปต์เหล่านี้ทำงานล่าช้าออกไปโดยย้ายสคริปต์ไปยัง Web Worker
ช่วยลดเวลาในชุดข้อความหลักได้ทั้งหมด
ในตัวอย่างนี้ การย้ายการดำเนินการของคอนเทนเนอร์ GTM และคอนเทนเนอร์ สคริปต์แท็กที่เชื่อมโยงกับเว็บเวิร์กลดลง TBT ลง 92%
ทั้งนี้เป็นที่น่าสังเกตว่า ถ้าคุณไม่ได้จัดการอย่างระมัดระวัง เทคนิคนี้ก็อาจทำงานอย่างเงียบๆ ได้
ทำลายสคริปต์ของบุคคลที่สามจำนวนมาก ทำให้การแก้ไขข้อบกพร่องเป็นเรื่องท้าทาย ในเร็วๆ นี้
เดือน เราจะตรวจสอบว่าได้ให้บริการคอมโพเนนต์ของบุคคลที่สามโดย
@next/third-parties ทำงานได้อย่างถูกต้องเมื่อทำงานใน Web Worker หากเป็นเช่นนั้น เราจะ
หาวิธีมอบวิธีที่ง่ายและไม่บังคับให้นักพัฒนาซอฟต์แวร์ใช้
ขั้นตอนถัดไป
ในกระบวนการพัฒนาแพ็กเกจนี้ เห็นได้ชัดว่ามี
ต้องรวมคำแนะนำการโหลดของบุคคลที่สามไว้ในที่เดียว เพื่อให้เฟรมเวิร์กอื่นๆ
ก็อาจได้รับประโยชน์จากเทคนิคพื้นฐานเดียวกันกับที่ใช้ ซึ่งนำเราไปสู่
สร้างบุคคลที่สาม
Capital (ห้องสมุด)
ที่ใช้ JSON เพื่ออธิบายเทคนิคการโหลดของบุคคลที่สาม ซึ่งในปัจจุบัน
เป็นรากฐานของ @next/third-parties
ในขั้นตอนถัดไป เราจะเน้นปรับปรุงองค์ประกอบที่จัดเตรียมไว้ให้ สำหรับ Next.js ตลอดจนขยายความพยายามในการรวมยูทิลิตี้ที่คล้ายกันใน เฟรมเวิร์กและแพลตฟอร์ม CMS ยอดนิยม ขณะนี้เรากำลังร่วมมือกับ Nuxt บำรุงรักษาระบบ และวางแผนที่จะเปิดตัวยูทิลิตีของบุคคลที่สามที่คล้ายกันซึ่งปรับแต่งมา ต่อระบบนิเวศในอนาคตอันใกล้
หากบุคคลที่สามที่คุณใช้ในแอป Next.js ได้รับการสนับสนุนโดย
@next/third-parties,
ติดตั้งแพ็กเกจ
แล้วลองลงมือทำดู เรายินดีรับฟังความคิดเห็นจากคุณเกี่ยวกับ
GitHub