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