Nghiên cứu điển hình về một số thay đổi lớn được triển khai tại Wix để cải thiện hiệu suất tải trang web cho hàng triệu trang web, giúp các trang web này nhận được điểm số tốt trong PageSpeed Insights và Các chỉ số quan trọng về trang web.
Nhờ tận dụng các tiêu chuẩn trong ngành, nhà cung cấp dịch vụ đám mây và khả năng CDN, cùng với việc viết lại đáng kể thời gian chạy trang web, tỷ lệ phần trăm trang web Wix đạt điểm tốt ở phân vị thứ 75 trên tất cả các chỉ số Core Web Vitals đã tăng hơn gấp ba lần so với cùng kỳ năm trước, theo dữ liệu của CrUX và HTTPArchive.
Wix đã áp dụng văn hoá tập trung vào hiệu suất và sẽ tiếp tục triển khai các điểm cải tiến khác cho người dùng. Khi tập trung vào các KPI về hiệu suất, chúng tôi dự kiến số lượng trang web vượt qua ngưỡng Các chỉ số quan trọng về trang web sẽ tăng lên.
Tổng quan
Thế giới hiệu suất phức tạp một cách tuyệt vời, với nhiều biến và sự phức tạp. Nghiên cứu cho thấy tốc độ trang web có tác động trực tiếp đến tỷ lệ chuyển đổi và doanh thu của các doanh nghiệp. Trong những năm gần đây, ngành công nghiệp này đã chú trọng nhiều hơn vào khả năng hiển thị hiệu suất và tăng tốc độ web. Kể từ tháng 5 năm 2021, các tín hiệu về trải nghiệm trên trang sẽ được đưa vào quy trình xếp hạng trên Google Tìm kiếm.
Thách thức riêng biệt tại Wix là hỗ trợ hàng triệu trang web, một số trang web trong số đó được tạo nhiều năm trước và chưa được cập nhật kể từ đó. Chúng tôi có nhiều công cụ và bài viết để hỗ trợ người dùng về những việc họ có thể làm để phân tích và cải thiện hiệu suất của trang web.
Wix là một môi trường được quản lý và không phải mọi thứ đều do người dùng quyết định. Việc chia sẻ cơ sở hạ tầng chung đặt ra nhiều thách thức cho tất cả các trang web này, nhưng cũng mở ra cơ hội để cải tiến lớn trên toàn bộ trang web, tức là tận dụng kinh tế theo quy mô.
Nói bằng ngôn ngữ chung
Một trong những khó khăn cốt lõi về hiệu suất là tìm một thuật ngữ chung để thảo luận về các khía cạnh khác nhau của trải nghiệm người dùng, đồng thời xem xét cả hiệu suất kỹ thuật và hiệu suất được cảm nhận. Việc sử dụng ngôn ngữ chung, được xác định rõ ràng trong tổ chức cho phép chúng tôi dễ dàng thảo luận và phân loại các phần kỹ thuật và sự đánh đổi khác nhau, làm rõ báo cáo hiệu suất và giúp chúng tôi hiểu rõ những khía cạnh mà chúng tôi nên tập trung cải thiện trước tiên.
Chúng tôi đã điều chỉnh tất cả hoạt động giám sát và thảo luận nội bộ để đưa vào các chỉ số tiêu chuẩn của ngành như Web Vitals, bao gồm:
Mức độ phức tạp của trang web và điểm hiệu suất
Bạn có thể dễ dàng tạo một trang web tải tức thì, miễn là bạn giúp trang web đó trở nên rất đơn giản bằng cách chỉ sử dụng HTML và phân phát trang web đó qua CDN.
Tuy nhiên, thực tế là các trang web ngày càng trở nên phức tạp và tinh vi hơn, hoạt động giống như các ứng dụng hơn là tài liệu và hỗ trợ các chức năng như blog, giải pháp thương mại điện tử, mã tuỳ chỉnh, v.v.
Wix cung cấp một nhiều mẫu rất lớn, cho phép người dùng dễ dàng tạo một trang web có nhiều chức năng kinh doanh. Những tính năng bổ sung đó thường đi kèm với một số chi phí hiệu suất.
Hành trình
Ban đầu, có HTML
Mỗi khi tải trang web, trang web luôn bắt đầu bằng một yêu cầu ban đầu đến một URL để truy xuất tài liệu HTML. Phản hồi HTML này kích hoạt tất cả các yêu cầu bổ sung của ứng dụng và logic trình duyệt để chạy và hiển thị trang web của bạn. Đây là phần quan trọng nhất của quá trình tải trang, vì không có gì xảy ra cho đến khi bắt đầu nhận được phản hồi (còn gọi là TTFB – thời gian tải byte đầu tiên).
Trước đây: kết xuất phía máy khách (CSR)
Khi vận hành các hệ thống quy mô lớn, bạn luôn phải cân nhắc các yếu tố đánh đổi, chẳng hạn như hiệu suất, độ tin cậy và chi phí. Vài năm trước, Wix sử dụng tính năng hiển thị phía máy khách (CSR), trong đó nội dung HTML thực tế được tạo thông qua JavaScript ở phía máy khách (tức là trong trình duyệt). Nhờ đó, chúng tôi có thể hỗ trợ nhiều trang web mà không phải chịu chi phí vận hành phụ trợ quá lớn.
CSR cho phép chúng tôi sử dụng một tài liệu HTML phổ biến, về cơ bản là trống. Tất cả những gì ứng dụng này làm là kích hoạt quá trình tải mã và dữ liệu bắt buộc xuống, sau đó dùng để tạo HTML đầy đủ trên thiết bị khách.
Hôm nay: kết xuất phía máy chủ (SSR)
Vài năm trước, chúng tôi đã chuyển sang chế độ kết xuất phía máy chủ (SSR) vì điều này mang lại lợi ích cho cả SEO và hiệu suất, cải thiện thời gian hiển thị trang ban đầu và đảm bảo việc lập chỉ mục hiệu quả hơn cho những công cụ tìm kiếm không hỗ trợ đầy đủ việc chạy JavaScript.
Phương pháp này đã cải thiện trải nghiệm hiển thị, đặc biệt là trên các thiết bị/kết nối chậm hơn, đồng thời mở ra cơ hội để tối ưu hoá hiệu suất hơn nữa. Tuy nhiên, điều này cũng có nghĩa là đối với mỗi yêu cầu trang web, một phản hồi HTML duy nhất sẽ được tạo ngay lập tức, điều này còn cách tối ưu rất xa, đặc biệt là đối với các trang web có số lượng lượt xem lớn.
Giới thiệu tính năng lưu vào bộ nhớ đệm ở nhiều vị trí
HTML cho mỗi trang web chủ yếu là tĩnh, nhưng có một vài lưu ý:
- Thông tin này thường xuyên thay đổi. Mỗi khi người dùng chỉnh sửa trang web hoặc thực hiện thay đổi đối với dữ liệu trang web, chẳng hạn như trên kho hàng của trang web.
- Trang web này có một số dữ liệu và cookie dành riêng cho khách truy cập, nghĩa là hai người truy cập vào cùng một trang web sẽ thấy HTML hơi khác nhau. Ví dụ: để hỗ trợ các tính năng của sản phẩm như ghi nhớ những mặt hàng mà khách truy cập đã đặt vào giỏ hàng, hoặc cuộc trò chuyện mà khách truy cập đã bắt đầu với doanh nghiệp trước đó, v.v.
- Không phải trang nào cũng có thể lưu vào bộ nhớ đệm. Ví dụ: một trang có mã tuỳ chỉnh của người dùng, hiển thị thời gian hiện tại trong tài liệu, sẽ không đủ điều kiện để lưu vào bộ nhớ đệm.
Ban đầu, chúng tôi đã sử dụng phương pháp tương đối an toàn là lưu HTML vào bộ nhớ đệm không có dữ liệu khách truy cập, sau đó chỉ chỉnh sửa nhanh các phần cụ thể của phản hồi HTML cho từng khách truy cập, cho từng lượt truy cập vào bộ nhớ đệm.
Giải pháp CDN nội bộ
Chúng tôi đã thực hiện việc này bằng cách triển khai một giải pháp nội bộ: Sử dụng Bộ nhớ đệm HTTP Varnish để proxy và lưu vào bộ nhớ đệm, Kafka cho các thông báo vô hiệu hoá và một dịch vụ dựa trên Scala/Netty sẽ proxy các phản hồi HTML này, nhưng thay đổi HTML và thêm dữ liệu và cookie dành riêng cho khách truy cập vào phản hồi được lưu vào bộ nhớ đệm.
Giải pháp này cho phép chúng tôi triển khai các thành phần mỏng này ở nhiều vị trí địa lý và nhiều khu vực của nhà cung cấp dịch vụ đám mây hơn, trải dài trên toàn thế giới. Trong năm 2019, chúng tôi đã ra mắt hơn 15 khu vực mới và từng bước bật tính năng lưu vào bộ nhớ đệm cho hơn 90% số lượt xem trang đủ điều kiện lưu vào bộ nhớ đệm. Việc phân phát trang web từ các vị trí bổ sung đã làm giảm độ trễ mạng giữa ứng dụng và máy chủ phân phát phản hồi HTML, bằng cách đưa nội dung đến gần hơn với khách truy cập trang web.
Chúng tôi cũng bắt đầu lưu một số phản hồi API chỉ có thể đọc vào bộ nhớ đệm bằng cách sử dụng cùng một giải pháp và vô hiệu hoá bộ nhớ đệm khi có bất kỳ thay đổi nào đối với nội dung trang web. Ví dụ: danh sách bài đăng trên blog trên trang web được lưu vào bộ nhớ đệm và mất hiệu lực khi một bài đăng được xuất bản/sửa đổi.
Giảm độ phức tạp
Việc triển khai lưu vào bộ nhớ đệm đã cải thiện đáng kể hiệu suất, chủ yếu là ở các giai đoạn TTFB và FCP, đồng thời cải thiện độ tin cậy bằng cách phân phát nội dung từ một vị trí gần người dùng cuối hơn.
Tuy nhiên, việc cần phải sửa đổi HTML cho mỗi phản hồi đã tạo ra một độ phức tạp không cần thiết. Nếu loại bỏ được điều này, bạn sẽ có cơ hội cải thiện hiệu suất hơn nữa.
Lưu vào bộ nhớ đệm của trình duyệt (và chuẩn bị cho CDN)
~ 13%
Các yêu cầu HTML được phân phát trực tiếp từ bộ nhớ đệm của trình duyệt, giúp tiết kiệm nhiều băng thông và giảm thời gian tải cho các lượt xem lặp lại
Bước tiếp theo là thực sự xoá hoàn toàn dữ liệu dành riêng cho khách truy cập này khỏi HTML và truy xuất dữ liệu đó từ một điểm cuối riêng biệt do ứng dụng gọi cho mục đích này sau khi HTML đã đến.
Chúng tôi đã di chuyển cẩn thận dữ liệu và cookie này sang một điểm cuối mới. Điểm cuối này được gọi trong mỗi lần tải trang, nhưng trả về một JSON nhỏ gọn, chỉ cần thiết cho quá trình hydrat hoá để đạt được khả năng tương tác đầy đủ trên trang.
Điều này cho phép chúng tôi bật tính năng lưu HTML vào bộ nhớ đệm của trình duyệt, nghĩa là trình duyệt hiện lưu phản hồi HTML cho các lượt truy cập lặp lại và chỉ gọi máy chủ để xác thực rằng nội dung không thay đổi. Việc này được thực hiện bằng cách sử dụng ETag HTTP, về cơ bản là một giá trị nhận dạng được gán cho một phiên bản cụ thể của tài nguyên HTML. Nếu nội dung vẫn giống nhau, máy chủ của chúng tôi sẽ gửi phản hồi 304 Không được sửa đổi đến ứng dụng mà không có nội dung.
Ngoài ra, thay đổi này có nghĩa là HTML của chúng ta không còn dành riêng cho khách truy cập và không chứa cookie. Nói cách khác, về cơ bản, bạn có thể lưu vào bộ nhớ đệm ở bất kỳ đâu, mở ra cơ hội sử dụng các nhà cung cấp CDN có vị trí địa lý tốt hơn nhiều ở hàng trăm vị trí trên toàn thế giới.
DNS, SSL và HTTP/2
Khi bật tính năng lưu vào bộ nhớ đệm, thời gian chờ sẽ giảm và các phần quan trọng khác của kết nối ban đầu sẽ trở nên đáng kể hơn. Việc tăng cường cơ sở hạ tầng mạng và hoạt động giám sát đã giúp chúng tôi cải thiện thời gian DNS, kết nối và SSL.
HTTP/2 đã được bật cho tất cả miền người dùng, giảm cả số lượng kết nối cần thiết và hao tổn đi kèm với mỗi kết nối mới. Đây là một thay đổi tương đối dễ triển khai, đồng thời tận dụng các lợi ích về hiệu suất và khả năng phục hồi đi kèm với HTTP/2.
Nén Brotli (so với gzip)
21 – 25%
Giảm kích thước trung bình của tệp được chuyển
Theo truyền thống, tất cả tệp của chúng tôi đều được nén bằng phương thức nén gzip. Đây là tuỳ chọn nén HTML phổ biến nhất trên web. Giao thức nén này ban đầu được triển khai cách đây gần 30 năm!
Nén Brotli mới hơn mang đến các cải tiến về khả năng nén mà hầu như không có sự đánh đổi nào, đồng thời đang dần trở nên phổ biến hơn, như mô tả trong chương Nén của cuốn Web Almanac hằng năm. Tất cả trình duyệt chính đều hỗ trợ tính năng này trong một thời gian.
Chúng tôi đã bật tính năng hỗ trợ Brotli trên các proxy nginx ở các cạnh cho tất cả các ứng dụng hỗ trợ tính năng này.
Việc chuyển sang sử dụng tính năng nén Brotli đã làm giảm kích thước trung bình của tệp truyền xuống 21% đến 25%, nhờ đó giảm mức sử dụng băng thông và cải thiện thời gian tải.
Mạng phân phối nội dung (CDN)
Chọn CDN động
Tại Wix, chúng tôi luôn sử dụng CDN để phân phát tất cả mã JavaScript và hình ảnh trên trang web của người dùng.
Gần đây, chúng tôi đã tích hợp với một giải pháp của nhà cung cấp DNS để tự động chọn CDN hoạt động hiệu quả nhất theo mạng và nguồn gốc của ứng dụng. Điều này cho phép chúng tôi phân phát các tệp tĩnh từ vị trí tốt nhất cho từng người truy cập và tránh các vấn đề về tình trạng sẵn có trên một CDN nhất định.
Sắp ra mắt… miền của người dùng do CDN phân phát
Phần cuối cùng của câu đố là phân phát phần cuối cùng và quan trọng nhất thông qua CDN: HTML từ miền của người dùng.
Như mô tả ở trên, chúng tôi đã tạo giải pháp nội bộ để lưu vào bộ nhớ đệm và phân phát kết quả API và HTML dành riêng cho trang web. Việc duy trì giải pháp này ở nhiều khu vực mới cũng có chi phí vận hành, đồng thời việc thêm vị trí mới trở thành một quy trình mà chúng tôi cần quản lý và liên tục tối ưu hoá.
Chúng tôi hiện đang tích hợp với nhiều nhà cung cấp CDN để hỗ trợ phân phát toàn bộ trang web Wix ngay từ các vị trí CDN nhằm cải thiện việc phân phối máy chủ trên toàn cầu, từ đó cải thiện thêm thời gian phản hồi. Đây là một thách thức do số lượng lớn miền mà chúng tôi phân phát, đòi hỏi phải chấm dứt SSL ở rìa.
Việc tích hợp với CDN giúp các trang web của Wix đến gần khách hàng hơn bao giờ hết và mang đến nhiều điểm cải tiến hơn cho trải nghiệm tải, bao gồm cả các công nghệ mới hơn như HTTP/3 mà chúng tôi không cần phải nỗ lực thêm.
Một vài lời về việc theo dõi hiệu suất
Nếu đang chạy một trang web Wix, có thể bạn sẽ thắc mắc điều này ảnh hưởng như thế nào đến kết quả hiệu suất của trang web Wix và chúng tôi so sánh như thế nào với các nền tảng trang web khác.
Hầu hết các công việc đã thực hiện ở trên đã được triển khai trong năm qua và một số công việc khác vẫn đang được triển khai.
Gần đây, The Web Almanac của HTTPArchive đã phát hành ấn bản năm 2020, trong đó có một chương tuyệt vời về trải nghiệm người dùng CMS. Xin lưu ý rằng nhiều con số được mô tả trong bài viết này là từ giữa năm 2020.
Chúng tôi rất mong được xem báo cáo cập nhật trong năm 2021 và đang tích cực giám sát các báo cáo CrUX cho các trang web của mình cũng như các chỉ số hiệu suất nội bộ.
Chúng tôi cam kết không ngừng cải thiện thời gian tải và cung cấp cho người dùng một nền tảng để họ có thể xây dựng trang web theo ý tưởng của mình mà không ảnh hưởng đến hiệu suất.
Gần đây, DebugBear đã phát hành một Bài đánh giá hiệu suất của trình tạo trang web rất thú vị, đề cập đến một số khía cạnh mà tôi đã đề cập ở trên và kiểm tra hiệu suất của các trang web rất đơn giản được tạo trên mỗi nền tảng. Trang web này được xây dựng cách đây gần 2 năm và chưa được sửa đổi kể từ đó, nhưng nền tảng này liên tục cải thiện và hiệu suất trang web cũng theo đó mà tăng lên. Bạn có thể thấy điều này bằng cách xem dữ liệu của trang web trong vòng 1,5 năm qua.
Kết luận
Chúng tôi hy vọng kinh nghiệm của mình sẽ truyền cảm hứng để bạn áp dụng văn hoá hướng đến hiệu suất tại tổ chức của mình. Đồng thời, chúng tôi hy vọng thông tin chi tiết ở trên sẽ hữu ích và có thể áp dụng cho nền tảng hoặc trang web của bạn.
Tóm lại:
- Chọn một bộ chỉ số mà bạn có thể theo dõi một cách nhất quán bằng các công cụ được ngành công nghiệp chứng thực. Bạn nên sử dụng Các chỉ số quan trọng về trang web.
- Tận dụng tính năng lưu vào bộ nhớ đệm của trình duyệt và CDN.
- Di chuyển sang HTTP/2 (hoặc HTTP/3 nếu có thể).
- Sử dụng tính năng nén Brotli.
Cảm ơn bạn đã tìm hiểu câu chuyện của chúng tôi. Bạn có thể đặt câu hỏi, chia sẻ ý tưởng trên Twitter và GitHub, cũng như tham gia cuộc trò chuyện về hiệu suất trang web trên các kênh mà bạn yêu thích.