Trong những năm gần đây, các framework đã tiếp quản phát triển web và React đang dẫn đầu xu hướng này. Ngày nay, khá hiếm khi bắt gặp một trang web hoặc ứng dụng web mới không dựa trên một số framework hoặc nền tảng như CMS.
Và trong khi khẩu hiệu của React là "một thư viện JavaScript để xây dựng giao diện người dùng" thay vì một framework, tôi nghĩ rằng con tàu đó đã ra khơi: hầu hết các nhà phát triển React coi nó là một framework và sử dụng nó như vậy. Hoặc họ sử dụng nó như một phần của một framework ứng dụng lớn hơn như NextJS, Gatsby hoặc RemixJS.
Nhưng chúng ta, với tư cách là nhà phát triển web, phải trả giá nào cho trải nghiệm nhà phát triển được cải thiện do các framework như vậy cung cấp? Và quan trọng hơn, người dùng của chúng ta phải trả giá nào, nếu có, cho sự lựa chọn này mà chúng ta đang thực hiện?
Gần đây, Noam Rosenthal đã xuất bản hai bài viết phân tích các lợi ích và khả năng chung do các framework khác nhau cung cấp, cũng như các chi phí liên quan của chúng. Tôi thực sự khuyên bạn nên xem qua các bài viết này. Một trong những chi phí mà Noam đề cập đến là kích thước tải xuống tăng lên, đặc biệt là kích thước gói JavaScript, bắt nguồn từ việc sử dụng các khuôn khổ và thư viện khác. Cụ thể, việc tăng lượng JavaScript được tải xuống có thể tác động trực tiếp đến hiệu suất của trang web. Và còn có những khía cạnh khác của việc sử dụng khuôn khổ cũng có thể tác động đến hiệu suất.
Trong bài viết này, tôi sẽ phân tích chi phí hiệu suất liên quan đến nhiều khuôn khổ khác nhau, dựa trên dữ liệu thực tế do Báo cáo trải nghiệm người dùng Google Chrome, hay viết tắt là CrUX, thu thập. Tôi nghĩ rằng thông tin này vừa thú vị vừa hữu ích, đặc biệt là khi xét đến sự đa dạng của các lựa chọn khuôn khổ và nền tảng hiện có sẵn cho các nhà phát triển front-end và fullstack.
Tuy nhiên, khi xem xét dữ liệu này, điều quan trọng là không nên gộp chung mối tương quan và quan hệ nhân quả. Chỉ vì các trang web được xây dựng bằng một khuôn khổ cụ thể thường có hiệu suất tốt hơn hoặc kém hơn so với một khuôn khổ khác không có nghĩa là bản thân khuôn khổ đó luôn có lỗi. Ví dụ, có thể là do một số khuôn khổ nhất định thường được sử dụng để xây dựng các trang web nặng hơn.
Tuy nhiên, dữ liệu này có thể hỗ trợ đưa ra quyết định sáng suốt về việc chọn khuôn khổ nào khi triển khai các dự án front-end. Khi có thể, tôi muốn các khuôn khổ có tỷ lệ hiệu suất tốt cao hơn.
Trong những năm gần đây, các số liệu này đã trở thành nền tảng của phân tích hiệu suất Web hiện đại:
Đối với mỗi số liệu như vậy, Google đã xác định các phạm vi có thể được coi là tốt (màu xanh lá cây), trung bình / cần cải thiện (màu cam) và kém (màu đỏ).
Bắt đầu từ tháng 6 năm 2021, các số liệu này đã trở thành yếu tố xếp hạng cho tìm kiếm trên Google. Điều này cũng làm tăng tầm quan trọng của chúng.
Ngoài việc thu thập dữ liệu thực địa cho mỗi phiên như vậy, các phép đo tổng hợp được thực hiện trên các trang web, bằng cách sử dụng công cụ WebPageTest. Các phép đo trong phòng thí nghiệm này được thu thập vào một kho lưu trữ trực tuyến khác có tên là Lưu trữ HTTP. Điều này bao gồm việc phân tích công nghệ mà một trang web sử dụng, bao gồm cả các khuôn khổ JavaScript nào, bằng cách sử dụng dịch vụ Wappalyzer.
Google giúp thực hiện các truy vấn trên cả hai bộ sưu tập này bằng dự án BigQuery của mình. Tuy nhiên, cách dễ nhất để có được thông tin chi tiết từ dữ liệu này là sử dụng Báo cáo công nghệ Core Web Vitals do Rick Viscomi tạo ra. (Rick là Kỹ sư DevRel tại Google và quản lý cả CrUX và HTTP Archive.) Báo cáo này cung cấp phương tiện để lập biểu đồ tương tác dữ liệu liên quan đến hiệu suất cho nhiều nền tảng và công nghệ dựa trên web khác nhau và dễ dàng so sánh chúng với nhau.
Đối với bài viết này, tôi chủ yếu dựa vào thông tin chi tiết thu được từ việc phân tích dữ liệu được trình bày bằng Báo cáo công nghệ Core Web Vitals.
Có một số lưu ý khi phân tích dữ liệu này:
Tôi đã lọc dữ liệu để chỉ bao gồm các phiên ở Hoa Kỳ nhằm loại bỏ tác động của các phân phối địa lý khác nhau giữa các khuôn khổ khác nhau. Dòng ALL trong biểu đồ đề cập đến tất cả các trang web trong CrUX, không chỉ những trang web sử dụng khuôn khổ và được sử dụng làm tài liệu tham khảo để so sánh.
Lưu ý: Trong trường hợp này, thiết bị di động không bao gồm các thiết bị iOS, chẳng hạn như iPhone. Điều này là do Chrome trên iOS chỉ là một lớp bao bọc mỏng xung quanh lõi Safari và không đo lường hoặc báo cáo CWV. (Điều này đúng với tất cả các trình duyệt trên iOS — tất cả chúng đều chỉ là Safari ở bên trong.)
Trước hết, chúng ta có thể thấy rằng các khung khác nhau tạo ra các kết quả khác nhau đáng kể. Hơn nữa, dù tốt hay xấu, những kết quả này phần lớn đều ổn định trong toàn bộ năm qua. (Preact là một ngoại lệ đối với điều này và tôi sẽ giải thích nguyên nhân của sự thay đổi này ngay sau đây.) Điều này cho thấy rằng điểm số có ý nghĩa chứ không phải là sự may rủi hoặc kết quả của các bất thường về mặt thống kê.
Dựa trên các phép đo này, như bài viết của Noam Rosenthal chỉ ra, việc sử dụng các khuôn khổ phải trả giá bằng hiệu suất: khi so sánh với đường cơ sở ALL, chúng ta thấy rằng các trang web được xây dựng bằng bất kỳ khuôn khổ nào trong số này thường ít có khả năng có CWV tốt hơn các trang web được xây dựng mà không có khuôn khổ. Mặc dù một số khuôn khổ như React, Preact và Svelte gần đạt được mức trung bình chung, nhưng điều thú vị cần lưu ý là không có khuôn khổ nào cung cấp hiệu suất tốt hơn đáng kể so với các khuôn khổ khác.
React và Preact về cơ bản là ngang ngửa nhau — một số người có thể ngạc nhiên về điều này vì Preact nhỏ hơn React rất nhiều: tải xuống khoảng 4KB so với 32KB (đã thu nhỏ và nén trong cả hai trường hợp). Rõ ràng là sự khác biệt về tải xuống 28KB không quá đáng kể trong hầu hết các trường hợp. Jason Miller, người tạo ra Preact gần đây đã nói như sau về nó:
Vue và AngularJS đều ở hạng hai — khả năng đạt được CWV tốt trên thiết bị di động thấp hơn khoảng 20-25% và khả năng đạt được CWV tốt trên máy tính để bàn thấp hơn khoảng 15-20%. (Một lần nữa, không tính iOS.) Điều đó nói rằng, Vue dường như đang giành được lợi thế và dần thu hẹp khoảng cách với React về mặt hiệu suất.
Sự sụt giảm lớn về hiệu suất của Preact không liên quan đến bất kỳ thay đổi nào trong chính khuôn khổ hoặc cách sử dụng của nó. Thay vào đó, nó liên quan đến việc Wappalyzer xác định Preact. Thật không may, dịch vụ này đã bỏ lỡ hầu hết các lần sử dụng Preact trước tháng 11 năm 2021. Do đó, các kết quả trước đó cho Preact nên bị bỏ qua vì không hợp lệ.
Và chúng ta thấy hành vi tương tự với 100.000 trang web hàng đầu, với tỷ lệ của React thực sự giảm xuống thấp hơn để Vue vượt qua nó một chút. Tôi không cố gắng hạn chế kết quả nhiều hơn nữa vì số lượng sử dụng cho một số khuôn khổ đã giảm xuống quá thấp đến mức chúng không còn đủ ý nghĩa thống kê nữa.
Nhưng khi xem xét các con số chúng ta có, thực tế là hiệu suất Vue được cải thiện đối với các trang web có lưu lượng truy cập cao hơn có lẽ chỉ ra rằng để đạt được hiệu suất tốt với Vue đòi hỏi nhiều chuyên môn hơn trong khuôn khổ đó hơn là chỉ có thể sử dụng nó? Điều này là do các trang web có lưu lượng truy cập cao hơn có nhiều khả năng được xây dựng bởi các tổ chức có đủ khả năng thuê các nhà phát triển có chuyên môn cao hơn. Hơn nữa, các tổ chức lớn hơn có thể chi nhiều hơn cho cơ sở hạ tầng được tối ưu hóa cho hiệu suất.
Mặt khác, các trang web React thực sự giảm xuống khi giới hạn số lượng trang web được đo bằng lưu lượng truy cập.
Bạn có thể mong đợi rằng các trang web sử dụng framework sẽ phải chịu một hình phạt trong số liệu phản hồi, vì đây là trang web bị ảnh hưởng nhiều nhất bởi việc sử dụng JavaScript đáng kể. Nhưng trên thực tế, điều này không đúng. Trên thực tế, số liệu FID về cơ bản là vô nghĩa, với tất cả các framework đều đạt điểm gần như hoàn hảo.
Điều tương tự cũng đúng ngay cả khi xem xét tổng hợp tất cả các trang web trong bộ sưu tập. Vì lý do này, Google đang nghiên cứu một số liệu phản hồi tốt hơn và đang yêu cầu phản hồi cho số liệu thử nghiệm mà họ đang thử nghiệm.
Việc xem xét số liệu LCP có ý nghĩa hơn nhiều:
Điều thú vị là điểm LCP rất phù hợp với CWV nói chung, nhưng lại phân tán hơn: ALL, React, Preact và Svelte cao hơn khoảng 10%, trong khi Vue và AngularJS về cơ bản vẫn giữ nguyên. Nhưng khi chúng tôi giới hạn trong 1.000.000 trang web hàng đầu, chúng tôi thấy Preact và Svelte cải thiện thêm một chút, nhưng React thì không. Kết quả là Vue đã bắt kịp nó.
Cuối cùng, chúng ta hãy xem xét CLS, bắt đầu với tất cả các trang web:
Và đối với 1.000.000 trang web hàng đầu:
Ở đây chúng ta thấy cả React và Preact, đặc biệt là React, đều giảm đáng kể, dẫn đến Vue vượt qua cả hai.
Nói cách khác, đối với Vue, cả tỷ lệ LCP và CLS tốt đều được cải thiện khi chúng ta chỉ kiểm tra các trang web hàng đầu. Mặt khác, đối với React, LCP vẫn gần như giữ nguyên, trong khi CLS thực sự bị suy giảm.
Điều này có thể chỉ ra rằng lý do khiến hiệu suất giảm ở các trang web hàng đầu sử dụng React là do lượng quảng cáo trên các trang tăng lên. Quảng cáo thường ảnh hưởng xấu đến CLS vì khi xuất hiện, chúng sẽ đẩy nội dung khác xuống. Tuy nhiên, tôi không nghĩ vậy vì nó không giải thích được sự khác biệt về hành vi giữa React và các khuôn khổ khác. Ngoài ra, bạn sẽ mong đợi quảng cáo cũng ảnh hưởng đến LCP, nhưng chúng ta thấy rằng LCP về cơ bản vẫn giữ nguyên.
Để cố gắng hiểu rõ hơn về hành vi này, chúng ta hãy kiểm tra các khía cạnh khác của trang web được Báo cáo công nghệ trực quan hóa.
Không có gì ngạc nhiên khi các trang web sử dụng framework tải xuống nhiều JavaScript hơn đáng kể so với các trang web nói chung. Điều này là do tất cả các chức năng cần thiết cho Ứng dụng trang đơn (SPA), chẳng hạn như định tuyến và kết xuất phía máy khách.
Cũng không có gì ngạc nhiên khi các trang web được xây dựng bằng Svelte tải xuống ít JavaScript hơn bất kỳ framework nào khác. Điều này là do trình biên dịch Svelte xử lý rất nhiều chức năng tại thời điểm xây dựng mà các khuôn khổ khác cần thực hiện tại thời điểm chạy. Do đó, Svelte không cần triển khai mã cần thiết cho chức năng đó. Cũng có thể các nhà phát triển sử dụng Svelte coi trọng việc cung cấp các trang web tinh gọn và hiệu quả hơn so với các nhà phát triển sử dụng các nền tảng khác.
Tuy nhiên, sự khác biệt 226KB giữa giá trị trung bình của các trang web Svelte và các trang web React chỉ chuyển thành mức tăng 2,4% về số lượng các trang web có CWV tốt. Điều này làm nổi bật sự cải thiện đáng kinh ngạc mà các trình duyệt có thể đạt được khi xử lý các tải trọng JavaScript lớn hơn, ví dụ như bằng cách phân tích cú pháp JavaScript khỏi luồng chính trong quá trình tải xuống. Tôi cho rằng bộ nhớ đệm, cả trong trình duyệt và CDN, cũng góp phần vào điều này.
Cũng thú vị khi lưu ý rằng các trang web và ứng dụng sử dụng Preact thực sự tải xuống nhiều JavaScript hơn so với các trang web và ứng dụng sử dụng React. Có lẽ các trang web này đã chọn Preact để giảm tổng trọng lượng của chúng. Trong mọi trường hợp, điều này có thể giải thích tại sao chúng ta không thấy cải thiện hiệu suất đáng kể cho Preact so với React: bất kỳ lợi ích nào mà Preact cung cấp đều bị bù đắp bởi chính mã ứng dụng.
Khi chúng ta xem xét 1.000.000 hàng đầu, chúng ta thấy rằng lượng JavaScript tăng lên, ngoại trừ Vue.
Điều này có thể giải thích tại sao chúng ta thấy Vue cải thiện đáng kể như vậy đối với các trang web hàng đầu, so với các khuôn khổ khác. Trong trường hợp của các khuôn khổ khác, có vẻ như bất kể các nhà phát triển làm việc trên các trang web hàng đầu có chuyên môn cao hơn như thế nào, thì điều đó không có nghĩa là kích thước tải xuống JavaScript giảm. Trên thực tế, điều ngược lại mới đúng — có lẽ là do các chức năng bổ sung được cung cấp bởi các trang web như vậy.
Một so sánh rất thú vị khác là lượng dữ liệu hình ảnh được tải xuống:
Ở đây chúng ta thấy rằng các trang web được xây dựng bằng React, Svelte và Angular tải xuống ít dữ liệu hình ảnh hơn đáng kể so với các trang web nói chung. Điều này có thể liên quan đến các trang web như vậy tận dụng các kỹ thuật hiện đại để giảm tải xuống hình ảnh, chẳng hạn như tải chậm và các định dạng hình ảnh mới hơn. Điều thú vị là các trang Angular tải xuống ít dữ liệu hình ảnh hơn đáng kể so với bất kỳ khuôn khổ nào khác.
Khi xem xét các trang web hàng đầu, chúng ta thấy lượng tải xuống hình ảnh tăng đáng kể trên mọi phương diện.
Điều này có thể liên quan đến việc các trang web hàng đầu có nhiều nội dung hơn. Đặc biệt, các trang web hàng đầu có nhiều khả năng có nhiều quảng cáo hơn, chủ yếu là hình ảnh. Và, như chúng ta sẽ thấy, cũng có những lời giải thích khác.
Với tất cả những điều này, chúng tôi mong đợi các trang web được xây dựng bằng các khuôn khổ ứng dụng web này sẽ có tỷ lệ số liệu CWV tốt cao hơn đáng kể so với các trang web chỉ được xây dựng bằng các khuôn khổ hoặc thư viện JavaScript.
Để xác định xem đây có thực sự là trường hợp hay không, tôi đã sử dụng Báo cáo công nghệ Core Web Vitals để so sánh tỷ lệ các trang web có CWV tốt cho React, Vue và Svelte nói chung với cùng tỷ lệ đó cho các khuôn khổ ứng dụng web hàng đầu được xây dựng trên chúng:
Chúng tôi ngay lập tức nhận thấy rằng SvelteKit có thể cung cấp hiệu suất cao hơn nhiều so với mọi thứ khác. Tuy nhiên, chỉ có 33 trang web trong tập dữ liệu này sử dụng SvelteKit. Con số này quá thấp để đưa ra kết luận về khả năng cung cấp hiệu suất tốt một cách nhất quán của nó. Nhưng sẽ rất thú vị khi xem hiệu suất của nó có giữ vững khi mức sử dụng tăng lên hay không.
Chúng ta có thể thấy rằng trong khi khung Gatsby thực sự cung cấp tỷ lệ CWV tốt cao hơn đáng kể so với React nói chung, thì điều này không đúng với NextJS. Và trong khi NuxtJS cung cấp tỷ lệ tốt hơn Vue nói chung, thì tỷ lệ đó vẫn thấp hơn so với React.
Ngoài ra, tại sao tôi lại đưa Wix vào biểu đồ này? Xét cho cùng, Wix không phải là một khung ứng dụng web được xây dựng trên một khung JavaScript. Hay là có?
Trên thực tế, Wix được triển khai bằng React và do đó, mọi trang web Wix cũng được xác định là một trang web React, giống như Gatsby và NextJS. Nói cách khác, ngay cả khi bạn không viết rõ mã React khi sử dụng Wix — xét cho cùng, đây là trình xây dựng trang web kéo và thả — thì nó vẫn tạo ra một trang web React cho bạn. Hơn nữa, Wix cũng sử dụng SSR giống như Next.js và sử dụng CDN giống như cả NextJS và Gatsby. Và nó có tỷ lệ hiệu suất tốt cao hơn cả hai công nghệ trên.
Bây giờ chúng ta hãy xem xét số lượng trang web được xây dựng bằng từng công nghệ sau:
Wix không chỉ vượt trội hơn đáng kể so với các nền tảng ứng dụng web phổ biến mà trên thực tế khoảng một phần ba số trang web React tại Hoa Kỳ thực sự là các trang web Wix!
Điều này rất quan trọng vì với tỷ lệ cao như vậy, hiệu suất của Wix tác động đáng kể đến hiệu suất được đo lường cho toàn bộ các trang web React. May mắn thay, như chúng ta đã thấy trong biểu đồ hiệu suất, Wix thực sự có tỷ lệ CWV tốt cao hơn so với các trang web React nói chung. Nói cách khác, Wix thực sự nâng cao điểm hiệu suất được đo cho React.
Nhưng khi chúng tôi giới hạn ở 1.000.000 trang web hàng đầu tại Hoa Kỳ, tỷ lệ thay đổi đáng kể:
Tỷ lệ Wix và tất cả các nền tảng ứng dụng web khác trong tổng số các trang web React giảm đáng kể khi chỉ xem xét 1.000.000 trang web hàng đầu. Trong tập dữ liệu này, chỉ có 14% các trang web React được xây dựng bằng Wix. Điều này có nghĩa là tác động của Wix đối với hiệu suất chung của React giảm đáng kể khi chỉ xem xét các trang web hàng đầu. Đây là lý do quan trọng tại sao tỷ lệ hiệu suất tốt của React thực sự giảm khi chỉ kiểm tra các trang web hàng đầu, không giống như các nền tảng JavaScript khác.
Nói cách khác, Wix là giải pháp cho bí ẩn về hồ sơ hiệu suất bất ngờ của React.
Như trước đây, số liệu FID về cơ bản không ảnh hưởng đến tỷ lệ hiệu suất chung vì tất cả các khuôn khổ đều đạt tỷ lệ FID tốt trên 97%.
Mọi thứ trở nên thú vị hơn khi chúng ta so sánh các tỷ lệ CLS:
Chúng ta có thể thấy rằng NextJS thực sự vượt trội hơn React, nhưng Gatsby vẫn dẫn trước. Ngoài ra, NuxtJS nằm ngay giữa Vue và React.
Vì tất cả các khuôn khổ này về cơ bản đều có cùng tỷ lệ FID tốt và tỷ lệ CLS gần tốt, điều này cho thấy nguyên nhân chính gây ra sự khác biệt giữa các khuôn khổ này là LCP:
Đúng như dự đoán, chúng ta thấy Gatsby vượt trội hơn React đáng kể, và React nói chung cũng vượt trội hơn Next.js. Vì NextJS sử dụng SSR / SSG và các định dạng hình ảnh hiện đại nên điều này thật đáng ngạc nhiên. Chắc chắn, đây là điều cần lưu ý khi sử dụng khuôn khổ đó.
NuxtJS đã có những tiến bộ đáng kể về mặt này trong những tháng gần đây và đã vượt qua NextJS về LCP tốt, về cơ bản giống như React nói chung.
Chúng ta hãy xem liệu sự khác biệt về LCP có thể được giải thích bằng kích thước tải xuống hình ảnh hay không vì hình ảnh lớn hơn thường gây bất lợi cho LCP:
Thật thú vị khi thấy các trang web sử dụng NuxtJS và Vue tải xuống nhiều dữ liệu hình ảnh hơn đáng kể so với các trang web sử dụng React và NuxtJS có thể đạt được tỷ lệ LCP khá tốt mặc dù vậy.
Gatsby và NextJS đều hiệu quả về mặt lượng dữ liệu hình ảnh được tải xuống. Điều này có nghĩa là tỷ lệ LCP tốt được cải thiện mà Gatsby cung cấp không chỉ bắt nguồn từ việc giảm kích thước hình ảnh. Với tôi, điều này cho thấy Gatsby có khả năng bắt đầu tải xuống hình ảnh lớn nhất sớm hơn và ưu tiên hình ảnh đó tốt hơn so với các tài nguyên trang khác.
Điều thú vị là trang chủ Gatsby sử dụng WebP cho hình ảnh và trang chủ NextJS sử dụng AVIF.
Điều đó nói rằng, chúng tôi đã thấy sự khác biệt đáng kể giữa các tỷ lệ hiệu suất tốt của các khuôn khổ khác nhau. Điều này có nghĩa là khả năng một trang web được xây dựng bằng một khuôn khổ cụ thể sẽ có hiệu suất tốt có thể rất khác so với một khuôn khổ khác. Chắc chắn, đây là điều cần cân nhắc khi quyết định sử dụng khuôn khổ nào.
Mặt khác, chúng tôi cũng thấy rằng những khác biệt như vậy có thể gây hiểu lầm — ví dụ, ban đầu có vẻ như React có tỷ lệ hiệu suất tốt cao hơn đáng kể so với Vue. Nhưng khi chúng tôi loại trừ hiệu quả hầu hết các trang web Wix, được đưa vào số liệu thống kê của React, bằng cách chỉ xem xét các trang web có lưu lượng truy cập cao hơn, thì Vue thực sự bắt kịp React.
Ngoài ra, một số khuôn khổ có uy tín về việc chú trọng nhiều hơn vào hiệu suất, chẳng hạn như Preact và Svelte, không nhất thiết có lợi thế đối với CWV. Sẽ rất thú vị khi xem tác động của chúng có tăng lên hay không khi Google giới thiệu một số liệu phản hồi mới để thay thế FID trong CWV.
Thậm chí còn đáng ngạc nhiên hơn, một số khuôn khổ Ứng dụng Web cũng không có lợi thế, mặc dù chúng có hỗ trợ tích hợp cho SSG / SSR và sử dụng CDN. Nói cách khác, sử dụng khuôn khổ Ứng dụng Web không phải là giải pháp tối ưu cho hiệu suất.
Đặc biệt, có vẻ như NextJS và NuxtJS còn phải đi một chặng đường dài nữa để tăng khả năng các trang web được xây dựng bằng chúng có CWV tốt. Biểu đồ của họ đang có xu hướng tăng đáng kể, đặc biệt là NuxtJS, nhưng vẫn thấp hơn đáng kể so với Gatsby hoặc Wix hoặc thậm chí là tỷ lệ cho tất cả các trang web nói chung. Hy vọng rằng, những cải tiến của họ sẽ tiếp tục và họ sẽ thành công trong việc bắt kịp.
Và trong khi khẩu hiệu của React là "một thư viện JavaScript để xây dựng giao diện người dùng" thay vì một framework, tôi nghĩ rằng con tàu đó đã ra khơi: hầu hết các nhà phát triển React coi nó là một framework và sử dụng nó như vậy. Hoặc họ sử dụng nó như một phần của một framework ứng dụng lớn hơn như NextJS, Gatsby hoặc RemixJS.
Nhưng chúng ta, với tư cách là nhà phát triển web, phải trả giá nào cho trải nghiệm nhà phát triển được cải thiện do các framework như vậy cung cấp? Và quan trọng hơn, người dùng của chúng ta phải trả giá nào, nếu có, cho sự lựa chọn này mà chúng ta đang thực hiện?
Gần đây, Noam Rosenthal đã xuất bản hai bài viết phân tích các lợi ích và khả năng chung do các framework khác nhau cung cấp, cũng như các chi phí liên quan của chúng. Tôi thực sự khuyên bạn nên xem qua các bài viết này. Một trong những chi phí mà Noam đề cập đến là kích thước tải xuống tăng lên, đặc biệt là kích thước gói JavaScript, bắt nguồn từ việc sử dụng các khuôn khổ và thư viện khác. Cụ thể, việc tăng lượng JavaScript được tải xuống có thể tác động trực tiếp đến hiệu suất của trang web. Và còn có những khía cạnh khác của việc sử dụng khuôn khổ cũng có thể tác động đến hiệu suất.
Trong bài viết này, tôi sẽ phân tích chi phí hiệu suất liên quan đến nhiều khuôn khổ khác nhau, dựa trên dữ liệu thực tế do Báo cáo trải nghiệm người dùng Google Chrome, hay viết tắt là CrUX, thu thập. Tôi nghĩ rằng thông tin này vừa thú vị vừa hữu ích, đặc biệt là khi xét đến sự đa dạng của các lựa chọn khuôn khổ và nền tảng hiện có sẵn cho các nhà phát triển front-end và fullstack.
Tuy nhiên, khi xem xét dữ liệu này, điều quan trọng là không nên gộp chung mối tương quan và quan hệ nhân quả. Chỉ vì các trang web được xây dựng bằng một khuôn khổ cụ thể thường có hiệu suất tốt hơn hoặc kém hơn so với một khuôn khổ khác không có nghĩa là bản thân khuôn khổ đó luôn có lỗi. Ví dụ, có thể là do một số khuôn khổ nhất định thường được sử dụng để xây dựng các trang web nặng hơn.
Tuy nhiên, dữ liệu này có thể hỗ trợ đưa ra quyết định sáng suốt về việc chọn khuôn khổ nào khi triển khai các dự án front-end. Khi có thể, tôi muốn các khuôn khổ có tỷ lệ hiệu suất tốt cao hơn.
Thu thập Core Web Vitals từ thực tế
Như tôi đã đề cập trước đó, nguồn dữ liệu chính của tôi cho phân tích này là Google CrUX. CrUX là cơ sở dữ liệu dựa trên đám mây, trong đó Real User Measurements (RUM) được thu thập từ các phiên trình duyệt Chrome trực tiếp. Nếu bạn đã chọn đồng bộ hóa lịch sử duyệt web, chưa thiết lập cụm mật khẩu Đồng bộ hóa và đã bật báo cáo thống kê sử dụng thì bất cứ khi nào bạn tải trang web bằng Chrome, thông tin về phiên của bạn sẽ tự động được báo cáo cho CrUX. Đặc biệt, các phép đo được thu thập bao gồm ba số liệu Core Web Vitals được đo cho mỗi phiên.Trong những năm gần đây, các số liệu này đã trở thành nền tảng của phân tích hiệu suất Web hiện đại:
Đối với mỗi số liệu như vậy, Google đã xác định các phạm vi có thể được coi là tốt (màu xanh lá cây), trung bình / cần cải thiện (màu cam) và kém (màu đỏ).
Bắt đầu từ tháng 6 năm 2021, các số liệu này đã trở thành yếu tố xếp hạng cho tìm kiếm trên Google. Điều này cũng làm tăng tầm quan trọng của chúng.
Ngoài việc thu thập dữ liệu thực địa cho mỗi phiên như vậy, các phép đo tổng hợp được thực hiện trên các trang web, bằng cách sử dụng công cụ WebPageTest. Các phép đo trong phòng thí nghiệm này được thu thập vào một kho lưu trữ trực tuyến khác có tên là Lưu trữ HTTP. Điều này bao gồm việc phân tích công nghệ mà một trang web sử dụng, bao gồm cả các khuôn khổ JavaScript nào, bằng cách sử dụng dịch vụ Wappalyzer.
Google giúp thực hiện các truy vấn trên cả hai bộ sưu tập này bằng dự án BigQuery của mình. Tuy nhiên, cách dễ nhất để có được thông tin chi tiết từ dữ liệu này là sử dụng Báo cáo công nghệ Core Web Vitals do Rick Viscomi tạo ra. (Rick là Kỹ sư DevRel tại Google và quản lý cả CrUX và HTTP Archive.) Báo cáo này cung cấp phương tiện để lập biểu đồ tương tác dữ liệu liên quan đến hiệu suất cho nhiều nền tảng và công nghệ dựa trên web khác nhau và dễ dàng so sánh chúng với nhau.
Đối với bài viết này, tôi chủ yếu dựa vào thông tin chi tiết thu được từ việc phân tích dữ liệu được trình bày bằng Báo cáo công nghệ Core Web Vitals.
Có một số lưu ý khi phân tích dữ liệu này:
- Trong khi dữ liệu thực địa được thu thập theo trang, Báo cáo công nghệ hiển thị dữ liệu theo nguồn gốc. Giá trị nguồn gốc là tổng hợp các giá trị của tất cả các trang cho nguồn gốc đó, được tính dưới dạng trung bình có trọng số dựa trên lưu lượng truy cập trang.
- Mặt khác, tỷ lệ nguồn gốc tốt không được tính trọng số. Điều này có nghĩa là một nguồn có lưu lượng truy cập tương đối ít, nhưng đủ để được đưa vào tập dữ liệu, được tính ngang bằng với một nguồn rất phổ biến, có lưu lượng truy cập cao. Khía cạnh tính toán này có thể được giảm thiểu bằng cách lọc nguồn theo thứ hạng phổ biến
- HTTP Archive chỉ phân tích trang chủ cho mỗi nguồn. Điều này có nghĩa là việc xác định khung chỉ được thực hiện cho trang chủ và tất cả các trang khác thuộc về nguồn đó đều được tổng hợp cho nguồn đó, bất kể chúng có sử dụng hay không, hoặc thậm chí nếu chúng sử dụng một số khung khác.
- Các tên miền phụ được đo là các nguồn riêng biệt.
So sánh CWV của các khung JavaScript
Chúng ta hãy bắt đầu bằng cách so sánh hiệu suất của nhiều khung JavaScript khác nhau. Cụ thể là tỷ lệ các trang web được xây dựng bằng từng khung này có điểm tốt (màu xanh lá cây) cho cả ba số liệu CWV trong tổng số các trang web được xây dựng bằng chúng. Các trang web có điểm số tốt cho cả ba số liệu CWV sẽ mang lại trải nghiệm người dùng tốt hơn về mặt hiệu suất và cũng đủ điều kiện để tăng thứ hạng tìm kiếm trên Google tối đa.Tôi đã lọc dữ liệu để chỉ bao gồm các phiên ở Hoa Kỳ nhằm loại bỏ tác động của các phân phối địa lý khác nhau giữa các khuôn khổ khác nhau. Dòng ALL trong biểu đồ đề cập đến tất cả các trang web trong CrUX, không chỉ những trang web sử dụng khuôn khổ và được sử dụng làm tài liệu tham khảo để so sánh.
Lưu ý: Trong trường hợp này, thiết bị di động không bao gồm các thiết bị iOS, chẳng hạn như iPhone. Điều này là do Chrome trên iOS chỉ là một lớp bao bọc mỏng xung quanh lõi Safari và không đo lường hoặc báo cáo CWV. (Điều này đúng với tất cả các trình duyệt trên iOS — tất cả chúng đều chỉ là Safari ở bên trong.)
Trước hết, chúng ta có thể thấy rằng các khung khác nhau tạo ra các kết quả khác nhau đáng kể. Hơn nữa, dù tốt hay xấu, những kết quả này phần lớn đều ổn định trong toàn bộ năm qua. (Preact là một ngoại lệ đối với điều này và tôi sẽ giải thích nguyên nhân của sự thay đổi này ngay sau đây.) Điều này cho thấy rằng điểm số có ý nghĩa chứ không phải là sự may rủi hoặc kết quả của các bất thường về mặt thống kê.
Dựa trên các phép đo này, như bài viết của Noam Rosenthal chỉ ra, việc sử dụng các khuôn khổ phải trả giá bằng hiệu suất: khi so sánh với đường cơ sở ALL, chúng ta thấy rằng các trang web được xây dựng bằng bất kỳ khuôn khổ nào trong số này thường ít có khả năng có CWV tốt hơn các trang web được xây dựng mà không có khuôn khổ. Mặc dù một số khuôn khổ như React, Preact và Svelte gần đạt được mức trung bình chung, nhưng điều thú vị cần lưu ý là không có khuôn khổ nào cung cấp hiệu suất tốt hơn đáng kể so với các khuôn khổ khác.
React và Preact về cơ bản là ngang ngửa nhau — một số người có thể ngạc nhiên về điều này vì Preact nhỏ hơn React rất nhiều: tải xuống khoảng 4KB so với 32KB (đã thu nhỏ và nén trong cả hai trường hợp). Rõ ràng là sự khác biệt về tải xuống 28KB không quá đáng kể trong hầu hết các trường hợp. Jason Miller, người tạo ra Preact gần đây đã nói như sau về nó:
Tôi sẽ xem xét tác động của Kết xuất phía máy chủ (SSR) và Tạo trang tĩnh (SSG) như các tùy chọn tạo/phân phối trang chi tiết hơn ở phần sau của bài viết này.Preact không liên quan đến bất kỳ SSR hoặc giải pháp phục vụ cụ thể nào, những giải pháp chi phối tác động lên CWV. Mặc dù việc sử dụng Preact có thể có một số mối tương quan với CWV (thực ra chỉ là FID), nhưng nó không hề trực tiếp như các lựa chọn công nghệ liên quan đến việc phân phối trang.
— Jason Miller⚛ (@_developit) 11 tháng 2 năm 2022
Vue và AngularJS đều ở hạng hai — khả năng đạt được CWV tốt trên thiết bị di động thấp hơn khoảng 20-25% và khả năng đạt được CWV tốt trên máy tính để bàn thấp hơn khoảng 15-20%. (Một lần nữa, không tính iOS.) Điều đó nói rằng, Vue dường như đang giành được lợi thế và dần thu hẹp khoảng cách với React về mặt hiệu suất.
Sự sụt giảm lớn về hiệu suất của Preact không liên quan đến bất kỳ thay đổi nào trong chính khuôn khổ hoặc cách sử dụng của nó. Thay vào đó, nó liên quan đến việc Wappalyzer xác định Preact. Thật không may, dịch vụ này đã bỏ lỡ hầu hết các lần sử dụng Preact trước tháng 11 năm 2021. Do đó, các kết quả trước đó cho Preact nên bị bỏ qua vì không hợp lệ.
Kiểm tra các trang web hàng đầu
Khi chúng tôi giới hạn chế độ xem của mình chỉ ở 1.000.000 trang web hàng đầu tại Hoa Kỳ (dựa trên lưu lượng truy cập), một thay đổi thú vị là Vue gần như bắt kịp React vì tỷ lệ các trang web có hiệu suất tốt khi sử dụng Vue tăng lên và đối với React, tỷ lệ này lại giảm xuống một cách đáng ngạc nhiên:
Và chúng ta thấy hành vi tương tự với 100.000 trang web hàng đầu, với tỷ lệ của React thực sự giảm xuống thấp hơn để Vue vượt qua nó một chút. Tôi không cố gắng hạn chế kết quả nhiều hơn nữa vì số lượng sử dụng cho một số khuôn khổ đã giảm xuống quá thấp đến mức chúng không còn đủ ý nghĩa thống kê nữa.
Nhưng khi xem xét các con số chúng ta có, thực tế là hiệu suất Vue được cải thiện đối với các trang web có lưu lượng truy cập cao hơn có lẽ chỉ ra rằng để đạt được hiệu suất tốt với Vue đòi hỏi nhiều chuyên môn hơn trong khuôn khổ đó hơn là chỉ có thể sử dụng nó? Điều này là do các trang web có lưu lượng truy cập cao hơn có nhiều khả năng được xây dựng bởi các tổ chức có đủ khả năng thuê các nhà phát triển có chuyên môn cao hơn. Hơn nữa, các tổ chức lớn hơn có thể chi nhiều hơn cho cơ sở hạ tầng được tối ưu hóa cho hiệu suất.
Mặt khác, các trang web React thực sự giảm xuống khi giới hạn số lượng trang web được đo bằng lưu lượng truy cập.
Vâng, đó là một bí ẩn rất thú vị mà tôi sẽ cố gắng giải quyết.
Phân tích theo số liệu
Ngoài việc xem xét CWV nói chung, Báo cáo công nghệ còn cho phép xem xét từng số liệu riêng lẻ. Chúng ta hãy bắt đầu bằng cách xem xét FID:
Bạn có thể mong đợi rằng các trang web sử dụng framework sẽ phải chịu một hình phạt trong số liệu phản hồi, vì đây là trang web bị ảnh hưởng nhiều nhất bởi việc sử dụng JavaScript đáng kể. Nhưng trên thực tế, điều này không đúng. Trên thực tế, số liệu FID về cơ bản là vô nghĩa, với tất cả các framework đều đạt điểm gần như hoàn hảo.
Điều tương tự cũng đúng ngay cả khi xem xét tổng hợp tất cả các trang web trong bộ sưu tập. Vì lý do này, Google đang nghiên cứu một số liệu phản hồi tốt hơn và đang yêu cầu phản hồi cho số liệu thử nghiệm mà họ đang thử nghiệm.
Việc xem xét số liệu LCP có ý nghĩa hơn nhiều:
Điều thú vị là điểm LCP rất phù hợp với CWV nói chung, nhưng lại phân tán hơn: ALL, React, Preact và Svelte cao hơn khoảng 10%, trong khi Vue và AngularJS về cơ bản vẫn giữ nguyên. Nhưng khi chúng tôi giới hạn trong 1.000.000 trang web hàng đầu, chúng tôi thấy Preact và Svelte cải thiện thêm một chút, nhưng React thì không. Kết quả là Vue đã bắt kịp nó.
Cuối cùng, chúng ta hãy xem xét CLS, bắt đầu với tất cả các trang web:
Và đối với 1.000.000 trang web hàng đầu:
Ở đây chúng ta thấy cả React và Preact, đặc biệt là React, đều giảm đáng kể, dẫn đến Vue vượt qua cả hai.
Nói cách khác, đối với Vue, cả tỷ lệ LCP và CLS tốt đều được cải thiện khi chúng ta chỉ kiểm tra các trang web hàng đầu. Mặt khác, đối với React, LCP vẫn gần như giữ nguyên, trong khi CLS thực sự bị suy giảm.
Điều này có thể chỉ ra rằng lý do khiến hiệu suất giảm ở các trang web hàng đầu sử dụng React là do lượng quảng cáo trên các trang tăng lên. Quảng cáo thường ảnh hưởng xấu đến CLS vì khi xuất hiện, chúng sẽ đẩy nội dung khác xuống. Tuy nhiên, tôi không nghĩ vậy vì nó không giải thích được sự khác biệt về hành vi giữa React và các khuôn khổ khác. Ngoài ra, bạn sẽ mong đợi quảng cáo cũng ảnh hưởng đến LCP, nhưng chúng ta thấy rằng LCP về cơ bản vẫn giữ nguyên.
Để cố gắng hiểu rõ hơn về hành vi này, chúng ta hãy kiểm tra các khía cạnh khác của trang web được Báo cáo công nghệ trực quan hóa.
Phân tích các khía cạnh bổ sung của trang web
Ngoài điểm hiệu suất, Báo cáo công nghệ còn cho phép phân tích kích thước tải xuống tài nguyên. Người ta đều biết rằng lượng JavaScript được một trang sử dụng có thể có tác động trực tiếp đến hiệu suất của trang đó vì tất cả mã cần được tải xuống, phân tích cú pháp và thực thi. Hãy so sánh lượng JavaScript được tải xuống bởi các khung khác nhau:
Không có gì ngạc nhiên khi các trang web sử dụng framework tải xuống nhiều JavaScript hơn đáng kể so với các trang web nói chung. Điều này là do tất cả các chức năng cần thiết cho Ứng dụng trang đơn (SPA), chẳng hạn như định tuyến và kết xuất phía máy khách.
Cũng không có gì ngạc nhiên khi các trang web được xây dựng bằng Svelte tải xuống ít JavaScript hơn bất kỳ framework nào khác. Điều này là do trình biên dịch Svelte xử lý rất nhiều chức năng tại thời điểm xây dựng mà các khuôn khổ khác cần thực hiện tại thời điểm chạy. Do đó, Svelte không cần triển khai mã cần thiết cho chức năng đó. Cũng có thể các nhà phát triển sử dụng Svelte coi trọng việc cung cấp các trang web tinh gọn và hiệu quả hơn so với các nhà phát triển sử dụng các nền tảng khác.
Tuy nhiên, sự khác biệt 226KB giữa giá trị trung bình của các trang web Svelte và các trang web React chỉ chuyển thành mức tăng 2,4% về số lượng các trang web có CWV tốt. Điều này làm nổi bật sự cải thiện đáng kinh ngạc mà các trình duyệt có thể đạt được khi xử lý các tải trọng JavaScript lớn hơn, ví dụ như bằng cách phân tích cú pháp JavaScript khỏi luồng chính trong quá trình tải xuống. Tôi cho rằng bộ nhớ đệm, cả trong trình duyệt và CDN, cũng góp phần vào điều này.
Cũng thú vị khi lưu ý rằng các trang web và ứng dụng sử dụng Preact thực sự tải xuống nhiều JavaScript hơn so với các trang web và ứng dụng sử dụng React. Có lẽ các trang web này đã chọn Preact để giảm tổng trọng lượng của chúng. Trong mọi trường hợp, điều này có thể giải thích tại sao chúng ta không thấy cải thiện hiệu suất đáng kể cho Preact so với React: bất kỳ lợi ích nào mà Preact cung cấp đều bị bù đắp bởi chính mã ứng dụng.
Khi chúng ta xem xét 1.000.000 hàng đầu, chúng ta thấy rằng lượng JavaScript tăng lên, ngoại trừ Vue.
Điều này có thể giải thích tại sao chúng ta thấy Vue cải thiện đáng kể như vậy đối với các trang web hàng đầu, so với các khuôn khổ khác. Trong trường hợp của các khuôn khổ khác, có vẻ như bất kể các nhà phát triển làm việc trên các trang web hàng đầu có chuyên môn cao hơn như thế nào, thì điều đó không có nghĩa là kích thước tải xuống JavaScript giảm. Trên thực tế, điều ngược lại mới đúng — có lẽ là do các chức năng bổ sung được cung cấp bởi các trang web như vậy.
Một so sánh rất thú vị khác là lượng dữ liệu hình ảnh được tải xuống:
Ở đây chúng ta thấy rằng các trang web được xây dựng bằng React, Svelte và Angular tải xuống ít dữ liệu hình ảnh hơn đáng kể so với các trang web nói chung. Điều này có thể liên quan đến các trang web như vậy tận dụng các kỹ thuật hiện đại để giảm tải xuống hình ảnh, chẳng hạn như tải chậm và các định dạng hình ảnh mới hơn. Điều thú vị là các trang Angular tải xuống ít dữ liệu hình ảnh hơn đáng kể so với bất kỳ khuôn khổ nào khác.
Khi xem xét các trang web hàng đầu, chúng ta thấy lượng tải xuống hình ảnh tăng đáng kể trên mọi phương diện.
Điều này có thể liên quan đến việc các trang web hàng đầu có nhiều nội dung hơn. Đặc biệt, các trang web hàng đầu có nhiều khả năng có nhiều quảng cáo hơn, chủ yếu là hình ảnh. Và, như chúng ta sẽ thấy, cũng có những lời giải thích khác.
Tác động của SSR và SSG
Như Jason Miller đã nêu trong dòng tweet mà tôi đã trích dẫn trước đó, các lựa chọn kỹ thuật liên quan đến việc phân phối trang web có tác động lớn nhất đến số liệu CWV, đặc biệt là trên LCP. Các kỹ thuật như Server-Side Rendering (SSR) và Static Site Generation (SSG) phân phối HTML có nội dung đến trình duyệt ngay từ đầu, cho phép trình duyệt hiển thị nội dung ngay khi nội dung đó đến. Điều này thường sớm hơn nhiều so với nội dung trực quan có thể được tạo ra bằng các kỹ thuật kết xuất phía máy khách, đặc biệt là khi HTML có nội dung được lưu trong bộ nhớ đệm trong CDN hoặc chính trình duyệt. Tuy nhiên, việc triển khai đúng cơ sở hạ tầng cần thiết cho phương pháp hoạt động này có thể là một thách thức khi sử dụng một khuôn khổ JavaScript. Do đó, trong những năm gần đây, chúng ta đã chứng kiến sự ra đời của nhiều khuôn khổ ứng dụng web cung cấp chức năng này ngay lập tức cho các khuôn khổ JavaScript và thư viện UI hàng đầu.Với tất cả những điều này, chúng tôi mong đợi các trang web được xây dựng bằng các khuôn khổ ứng dụng web này sẽ có tỷ lệ số liệu CWV tốt cao hơn đáng kể so với các trang web chỉ được xây dựng bằng các khuôn khổ hoặc thư viện JavaScript.
Để xác định xem đây có thực sự là trường hợp hay không, tôi đã sử dụng Báo cáo công nghệ Core Web Vitals để so sánh tỷ lệ các trang web có CWV tốt cho React, Vue và Svelte nói chung với cùng tỷ lệ đó cho các khuôn khổ ứng dụng web hàng đầu được xây dựng trên chúng:
Chúng tôi ngay lập tức nhận thấy rằng SvelteKit có thể cung cấp hiệu suất cao hơn nhiều so với mọi thứ khác. Tuy nhiên, chỉ có 33 trang web trong tập dữ liệu này sử dụng SvelteKit. Con số này quá thấp để đưa ra kết luận về khả năng cung cấp hiệu suất tốt một cách nhất quán của nó. Nhưng sẽ rất thú vị khi xem hiệu suất của nó có giữ vững khi mức sử dụng tăng lên hay không.
Chúng ta có thể thấy rằng trong khi khung Gatsby thực sự cung cấp tỷ lệ CWV tốt cao hơn đáng kể so với React nói chung, thì điều này không đúng với NextJS. Và trong khi NuxtJS cung cấp tỷ lệ tốt hơn Vue nói chung, thì tỷ lệ đó vẫn thấp hơn so với React.
Ngoài ra, tại sao tôi lại đưa Wix vào biểu đồ này? Xét cho cùng, Wix không phải là một khung ứng dụng web được xây dựng trên một khung JavaScript. Hay là có?
Trên thực tế, Wix được triển khai bằng React và do đó, mọi trang web Wix cũng được xác định là một trang web React, giống như Gatsby và NextJS. Nói cách khác, ngay cả khi bạn không viết rõ mã React khi sử dụng Wix — xét cho cùng, đây là trình xây dựng trang web kéo và thả — thì nó vẫn tạo ra một trang web React cho bạn. Hơn nữa, Wix cũng sử dụng SSR giống như Next.js và sử dụng CDN giống như cả NextJS và Gatsby. Và nó có tỷ lệ hiệu suất tốt cao hơn cả hai công nghệ trên.
Bây giờ chúng ta hãy xem xét số lượng trang web được xây dựng bằng từng công nghệ sau:
Wix không chỉ vượt trội hơn đáng kể so với các nền tảng ứng dụng web phổ biến mà trên thực tế khoảng một phần ba số trang web React tại Hoa Kỳ thực sự là các trang web Wix!
Điều này rất quan trọng vì với tỷ lệ cao như vậy, hiệu suất của Wix tác động đáng kể đến hiệu suất được đo lường cho toàn bộ các trang web React. May mắn thay, như chúng ta đã thấy trong biểu đồ hiệu suất, Wix thực sự có tỷ lệ CWV tốt cao hơn so với các trang web React nói chung. Nói cách khác, Wix thực sự nâng cao điểm hiệu suất được đo cho React.
Nhưng khi chúng tôi giới hạn ở 1.000.000 trang web hàng đầu tại Hoa Kỳ, tỷ lệ thay đổi đáng kể:
Tỷ lệ Wix và tất cả các nền tảng ứng dụng web khác trong tổng số các trang web React giảm đáng kể khi chỉ xem xét 1.000.000 trang web hàng đầu. Trong tập dữ liệu này, chỉ có 14% các trang web React được xây dựng bằng Wix. Điều này có nghĩa là tác động của Wix đối với hiệu suất chung của React giảm đáng kể khi chỉ xem xét các trang web hàng đầu. Đây là lý do quan trọng tại sao tỷ lệ hiệu suất tốt của React thực sự giảm khi chỉ kiểm tra các trang web hàng đầu, không giống như các nền tảng JavaScript khác.
Nói cách khác, Wix là giải pháp cho bí ẩn về hồ sơ hiệu suất bất ngờ của React.
Chỉ số hiệu suất cho các nền tảng ứng dụng web
Nhưng còn NextJS và NuxtJS thì sao? Tại sao chúng không cung cấp các lợi ích hiệu suất mong đợi trên mọi phương diện mà chúng ta thấy với Gatsby (và cả với Wix)? Phân tích từng số liệu riêng lẻ có thể tiết lộ nguyên nhân gốc rễ cho hành vi này.Như trước đây, số liệu FID về cơ bản không ảnh hưởng đến tỷ lệ hiệu suất chung vì tất cả các khuôn khổ đều đạt tỷ lệ FID tốt trên 97%.
Mọi thứ trở nên thú vị hơn khi chúng ta so sánh các tỷ lệ CLS:
Chúng ta có thể thấy rằng NextJS thực sự vượt trội hơn React, nhưng Gatsby vẫn dẫn trước. Ngoài ra, NuxtJS nằm ngay giữa Vue và React.
Vì tất cả các khuôn khổ này về cơ bản đều có cùng tỷ lệ FID tốt và tỷ lệ CLS gần tốt, điều này cho thấy nguyên nhân chính gây ra sự khác biệt giữa các khuôn khổ này là LCP:
Đúng như dự đoán, chúng ta thấy Gatsby vượt trội hơn React đáng kể, và React nói chung cũng vượt trội hơn Next.js. Vì NextJS sử dụng SSR / SSG và các định dạng hình ảnh hiện đại nên điều này thật đáng ngạc nhiên. Chắc chắn, đây là điều cần lưu ý khi sử dụng khuôn khổ đó.
NuxtJS đã có những tiến bộ đáng kể về mặt này trong những tháng gần đây và đã vượt qua NextJS về LCP tốt, về cơ bản giống như React nói chung.
Chúng ta hãy xem liệu sự khác biệt về LCP có thể được giải thích bằng kích thước tải xuống hình ảnh hay không vì hình ảnh lớn hơn thường gây bất lợi cho LCP:
Thật thú vị khi thấy các trang web sử dụng NuxtJS và Vue tải xuống nhiều dữ liệu hình ảnh hơn đáng kể so với các trang web sử dụng React và NuxtJS có thể đạt được tỷ lệ LCP khá tốt mặc dù vậy.
Gatsby và NextJS đều hiệu quả về mặt lượng dữ liệu hình ảnh được tải xuống. Điều này có nghĩa là tỷ lệ LCP tốt được cải thiện mà Gatsby cung cấp không chỉ bắt nguồn từ việc giảm kích thước hình ảnh. Với tôi, điều này cho thấy Gatsby có khả năng bắt đầu tải xuống hình ảnh lớn nhất sớm hơn và ưu tiên hình ảnh đó tốt hơn so với các tài nguyên trang khác.
Điều thú vị là trang chủ Gatsby sử dụng WebP cho hình ảnh và trang chủ NextJS sử dụng AVIF.
Tóm tắt
Tất cả các khuôn khổ mà tôi đã đánh giá trong bài viết này đều có tỷ lệ hiệu suất tốt cao hơn 0%, điều đó có nghĩa là bạn có thể xây dựng các trang web tải nhanh, được đo bằng CWV, bằng bất kỳ khuôn khổ nào trong số chúng. Tương tự như vậy, tất cả các khuôn khổ này đều có tỷ lệ hiệu suất tốt thấp hơn 100%, điều đó có nghĩa là bạn cũng có thể xây dựng các trang web tải chậm bằng bất kỳ khuôn khổ nào trong số chúng.Điều đó nói rằng, chúng tôi đã thấy sự khác biệt đáng kể giữa các tỷ lệ hiệu suất tốt của các khuôn khổ khác nhau. Điều này có nghĩa là khả năng một trang web được xây dựng bằng một khuôn khổ cụ thể sẽ có hiệu suất tốt có thể rất khác so với một khuôn khổ khác. Chắc chắn, đây là điều cần cân nhắc khi quyết định sử dụng khuôn khổ nào.
Mặt khác, chúng tôi cũng thấy rằng những khác biệt như vậy có thể gây hiểu lầm — ví dụ, ban đầu có vẻ như React có tỷ lệ hiệu suất tốt cao hơn đáng kể so với Vue. Nhưng khi chúng tôi loại trừ hiệu quả hầu hết các trang web Wix, được đưa vào số liệu thống kê của React, bằng cách chỉ xem xét các trang web có lưu lượng truy cập cao hơn, thì Vue thực sự bắt kịp React.
Ngoài ra, một số khuôn khổ có uy tín về việc chú trọng nhiều hơn vào hiệu suất, chẳng hạn như Preact và Svelte, không nhất thiết có lợi thế đối với CWV. Sẽ rất thú vị khi xem tác động của chúng có tăng lên hay không khi Google giới thiệu một số liệu phản hồi mới để thay thế FID trong CWV.
Thậm chí còn đáng ngạc nhiên hơn, một số khuôn khổ Ứng dụng Web cũng không có lợi thế, mặc dù chúng có hỗ trợ tích hợp cho SSG / SSR và sử dụng CDN. Nói cách khác, sử dụng khuôn khổ Ứng dụng Web không phải là giải pháp tối ưu cho hiệu suất.
Đặc biệt, có vẻ như NextJS và NuxtJS còn phải đi một chặng đường dài nữa để tăng khả năng các trang web được xây dựng bằng chúng có CWV tốt. Biểu đồ của họ đang có xu hướng tăng đáng kể, đặc biệt là NuxtJS, nhưng vẫn thấp hơn đáng kể so với Gatsby hoặc Wix hoặc thậm chí là tỷ lệ cho tất cả các trang web nói chung. Hy vọng rằng, những cải tiến của họ sẽ tiếp tục và họ sẽ thành công trong việc bắt kịp.
Đọc thêm
- Chế độ chặt chẽ: Tại sao trình duyệt tạo ra kết quả hiệu suất khác nhau
- Cách xây dựng trang web đa ngôn ngữ bằng Nuxt.js
- Chuyển đổi văn bản thuần túy sang HTML được mã hóa bằng JavaScript thuần túy
- Cách đưa ra lập luận mạnh mẽ về khả năng truy cập
