Trong những năm gần đây, ngày càng có nhiều nền tảng để tối ưu hóa các dự án giao diện người dùng mang đến cơ hội tự lưu trữ hoặc ủy quyền tài nguyên của bên thứ ba. Akamai cho phép bạn thiết lập đối với các URL tự tạo. Cloudflare có công nghệ Edge Workers. Fasterzine có thể URL trên các trang để chúng trỏ đến tài nguyên của bên thứ ba nằm trên miền chính của trang web.
Nếu bạn biết rằng các dịch vụ của bên thứ ba được sử dụng trong dự án của bạn không thay đổi thường xuyên và quá trình cung cấp chúng cho khách hàng có thể được cải thiện thì có lẽ bạn đang nghĩ đến việc ủy quyền các dịch vụ đó. Với phương pháp này, bạn rất có thể mang những tài nguyên này đến gần hơn với người dùng của mình và giành được quyền kiểm soát hoàn toàn hơn đối với bộ nhớ đệm của họ ở phía máy khách. Ngoài ra, điều này còn cho phép bạn bảo vệ người dùng khỏi những rắc rối do dịch vụ của bên thứ ba “sự cố” gây ra hoặc do hiệu suất của dịch vụ đó bị suy giảm.
Tốt: Cải thiện hiệu suất
Việc tự lưu trữ tài nguyên của người khác sẽ cải thiện hiệu suất một cách rất rõ ràng. Trình duyệt không cần truy cập lại DNS, không cần thiết lập kết nối TCP và thực hiện bắt tay TLS trên miền của bên thứ ba. Bạn có thể thấy việc tự lưu trữ tài nguyên của người khác ảnh hưởng như thế nào đến hiệu suất bằng cách so sánh hai số liệu sau.
Tài nguyên của bên thứ ba được tải xuống từ các nguồn bên ngoài (lấy từ )
Tài nguyên của bên thứ ba được lưu trữ ở cùng nơi với phần còn lại của tài liệu trang web (lấy từ )
Tình hình cũng được cải thiện nhờ trình duyệt sẽ sử dụng khả năng ghép kênh và ưu tiên dữ liệu từ kết nối HTTP/2 đã được thiết lập với tên miền chính.
Nếu bạn không lưu trữ tài nguyên của bên thứ ba thì vì chúng sẽ được tải từ một miền khác với miền chính nên chúng không thể được ưu tiên. Điều này sẽ khiến chúng cạnh tranh nhau về băng thông của máy khách. Điều này có thể dẫn đến thời gian tải nội dung quan trọng để xây dựng một trang dài hơn nhiều so với thời gian có thể đạt được trong những trường hợp lý tưởng. nói về mức độ ưu tiên HTTP/2 giải thích rất rõ điều này.
Có thể giả định rằng việc sử dụng các thuộc tính trong các liên kết đến các nguồn tài nguyên bên ngoài preconnect sẽ giúp giải quyết vấn đề. Tuy nhiên, nếu có quá nhiều liên kết này đến các miền khác nhau, nó thực sự có thể làm quá tải đường truyền vào thời điểm quan trọng nhất.
Nếu bạn tự lưu trữ tài nguyên của bên thứ ba, bạn có thể kiểm soát chính xác cách thức cung cấp các tài nguyên này cho khách hàng. Cụ thể, chúng ta đang nói về những điều sau đây:
- Bạn có thể đảm bảo rằng thuật toán nén dữ liệu phù hợp nhất với từng trình duyệt được sử dụng (Brotli/gzip).
- Bạn có thể tăng thời gian lưu vào bộ đệm cho các tài nguyên thường không quá dài, ngay cả với các nhà cung cấp nổi tiếng nhất (ví dụ: giá trị tương ứng cho thẻ GA được đặt thành 30 phút).
Bạn thậm chí có thể kéo dài TTL cho một tài nguyên lên một năm bằng cách kết hợp nội dung có liên quan vào chiến lược quản lý bộ nhớ đệm của mình (băm URL, lập phiên bản, v.v.). Chúng ta sẽ nói về điều này dưới đây.
▍Bảo vệ khỏi sự gián đoạn trong hoạt động của các dịch vụ của bên thứ ba hoặc việc ngừng hoạt động của chúng
Một khía cạnh thú vị khác của việc tự lưu trữ tài nguyên của bên thứ ba là nó cho phép bạn giảm thiểu rủi ro liên quan đến việc ngừng dịch vụ của bên thứ ba. Giả sử rằng giải pháp thử nghiệm A/B của bên thứ ba mà bạn đang sử dụng được triển khai dưới dạng tập lệnh chặn tải trong phần đầu của trang. Tập lệnh này tải chậm. Nếu tập lệnh tương ứng không tải được, trang sẽ trống. Nếu phải mất một thời gian rất dài để tải, trang sẽ xuất hiện với độ trễ lâu. Hoặc giả sử dự án sử dụng thư viện được tải xuống từ tài nguyên CDN của bên thứ ba. Hãy tưởng tượng rằng tài nguyên này bị lỗi hoặc bị chặn ở một quốc gia nhất định. Tình huống như vậy sẽ dẫn đến vi phạm logic của trang web.
Để tìm hiểu cách trang web của bạn hoạt động khi một số dịch vụ bên ngoài không khả dụng, bạn có thể sử dụng phần SPOF trên .
Phần SPOF trên trang webtest.org
▍Còn vấn đề với việc lưu trữ nội dung trong trình duyệt thì sao? (gợi ý: đó là một huyền thoại)
Bạn có thể nghĩ rằng việc sử dụng CDN công cộng sẽ tự động mang lại hiệu suất tài nguyên tốt hơn vì các dịch vụ này có mạng chất lượng khá cao và được phân phối trên toàn thế giới. Nhưng mọi thứ thực sự phức tạp hơn một chút.
Giả sử chúng ta có một số trang web khác nhau: website1.com, website2.com, website3.com. Tất cả các trang web này đều sử dụng thư viện jQuery. Ví dụ: chúng tôi kết nối nó với họ bằng CDN - googleapis.com. Bạn có thể mong đợi trình duyệt tải xuống và lưu vào bộ nhớ đệm thư viện một lần, sau đó sử dụng nó trên cả ba trang web. Điều này có thể làm giảm tải trên mạng. Có lẽ điều này sẽ cho phép bạn tiết kiệm tiền ở đâu đó và giúp cải thiện hiệu suất tài nguyên. Từ quan điểm thực tế, mọi thứ có vẻ khác nhau. Ví dụ: Safari có một tính năng gọi là : Bộ đệm sử dụng khóa kép dựa trên nguồn của tài liệu và nguồn tài nguyên của bên thứ ba. bài viết tốt về chủ đề này
nghiên cứu cũ и , cũng như gần đây hơn Paul Calvano, chỉ ra rằng tài nguyên không được lưu trữ trong bộ nhớ đệm của trình duyệt trong thời gian dài như chúng ta mong đợi: “Có một khoảng cách nghiêm trọng giữa thời gian lưu vào bộ nhớ đệm của tài nguyên của chính dự án và tài nguyên của bên thứ ba. Chúng ta đang nói về CSS và phông chữ web. Cụ thể, 95% phông chữ gốc có thời lượng bộ nhớ đệm hơn một tuần, trong khi 50% phông chữ của bên thứ ba có thời gian lưu trữ bộ đệm ít hơn một tuần! Điều này mang lại cho các nhà phát triển web một lý do thuyết phục để tự mình lưu trữ các tệp phông chữ!”
Do đó, nếu bạn lưu trữ nội dung của người khác, bạn sẽ không nhận thấy bất kỳ vấn đề về hiệu suất nào do bộ nhớ đệm của trình duyệt gây ra.
Bây giờ chúng ta đã đề cập đến những điểm mạnh của việc tự lưu trữ của bên thứ ba, hãy nói về cách phân biệt cách triển khai tốt phương pháp này với phương pháp xấu.
Nhược điểm: Ma quỷ nằm ở chi tiết
Việc di chuyển tài nguyên của bên thứ ba sang miền của riêng bạn không thể được thực hiện tự động nếu không đảm bảo rằng các tài nguyên đó được lưu vào bộ nhớ đệm đúng cách.
Một trong những vấn đề chính ở đây là thời gian lưu vào bộ nhớ đệm. Ví dụ: thông tin phiên bản được bao gồm trong tên tập lệnh của bên thứ ba như sau: jquery-3.4.1.js. Một tệp như vậy sẽ không thay đổi trong tương lai và do đó, điều này sẽ không gây ra bất kỳ vấn đề nào với bộ nhớ đệm của nó.
Nhưng nếu một số sơ đồ phiên bản không được sử dụng khi làm việc với các tệp, các tập lệnh được lưu trong bộ nhớ đệm, nội dung của chúng thay đổi trong khi tên tệp vẫn không thay đổi, có thể trở nên lỗi thời. Đây có thể là một vấn đề nghiêm trọng, chẳng hạn, vì nó không cho phép thêm các bản vá bảo mật tự động vào các tập lệnh mà khách hàng cần nhận càng nhanh càng tốt. Nhà phát triển sẽ phải nỗ lực cập nhật các tập lệnh như vậy trong bộ đệm. Ngoài ra, điều này có thể gây ra lỗi ứng dụng do mã được sử dụng trên máy khách từ bộ đệm khác với phiên bản mã mới nhất mà phần máy chủ của dự án được thiết kế.
Đúng, nếu chúng ta nói về các tài liệu được cập nhật thường xuyên (trình quản lý thẻ, giải pháp kiểm tra A/B), thì việc lưu chúng vào bộ nhớ đệm bằng công cụ CDN là một nhiệm vụ có thể giải quyết được nhưng phức tạp hơn nhiều. Các dịch vụ như Commanders Act, một giải pháp quản lý thẻ, sử dụng webhook khi xuất bản phiên bản mới. Điều này cung cấp cho bạn khả năng buộc xóa bộ đệm trên CDN hoặc tốt hơn là khả năng buộc cập nhật hàm băm hoặc URL.
▍Việc cung cấp vật liệu thích ứng cho khách hàng
Ngoài ra, khi nói về bộ nhớ đệm, chúng ta cần tính đến thực tế là cài đặt bộ đệm được sử dụng trên CDN có thể không phù hợp với một số tài nguyên của bên thứ ba. Ví dụ: các tài nguyên đó có thể sử dụng công nghệ đánh hơi tác nhân người dùng (phân phối thích ứng) để phục vụ các trình duyệt cụ thể với các phiên bản nội dung được tối ưu hóa riêng cho các trình duyệt đó. Các công nghệ này dựa vào biểu thức chính quy hoặc cơ sở dữ liệu về thông tin tiêu đề HTTP để tìm ra khả năng của trình duyệt. User-Agent. Khi họ biết họ đang xử lý trình duyệt nào, họ sẽ cung cấp cho trình duyệt đó những tài liệu được thiết kế cho trình duyệt đó.
Ở đây bạn có thể nhớ hai dịch vụ. Đầu tiên là googlefonts.com. Cái thứ hai là polyfill.io. Dịch vụ Google Fonts cung cấp, cho một tài nguyên nhất định, nhiều mã CSS khác nhau, tùy thuộc vào khả năng của trình duyệt (cung cấp liên kết đến tài nguyên woff2 bằng cách sử dụng unicode-range).
Dưới đây là kết quả của một số truy vấn Google Fonts được thực hiện từ các trình duyệt khác nhau.
Kết quả truy vấn Google Fonts từ Chrome
Kết quả truy vấn Google Fonts được thực thi từ IE10
Polyfill.io chỉ cung cấp cho trình duyệt những polyfill mà nó cần. Điều này được thực hiện vì lý do hiệu suất.
Ví dụ: hãy xem điều gì sẽ xảy ra nếu bạn chạy yêu cầu sau từ các trình duyệt khác nhau:
Để đáp lại yêu cầu như vậy được thực thi từ IE10, sẽ nhận được 34 KB dữ liệu. Và câu trả lời cho nó, được thực thi từ Chrome, sẽ trống.
Tức giận: Một số cân nhắc về quyền riêng tư
Điểm này được xếp cuối cùng nhưng không kém phần quan trọng. Vấn đề là việc tự lưu trữ tài nguyên của bên thứ ba trên tên miền chính của dự án hoặc trên tên miền phụ của nó có thể gây nguy hiểm cho quyền riêng tư của người dùng và ảnh hưởng tiêu cực đến dự án web chính.
Nếu hệ thống CDN của bạn không được định cấu hình chính xác, bạn có thể gửi cookie của miền của mình tới dịch vụ bên thứ ba. Nếu quá trình lọc thích hợp không được tổ chức ở cấp độ CDN thì cookie phiên của bạn, thường không thể sử dụng được trong JavaScript (với httponly), có thể được gửi đến một máy chủ nước ngoài.
Đây chính xác là những gì có thể xảy ra với các trình theo dõi như Eulerian hoặc Criteo. Trình theo dõi của bên thứ ba có thể đã đặt mã nhận dạng duy nhất trong cookie. Nếu chúng là một phần của tài liệu trang web, chúng có thể đọc mã định danh theo ý mình trong khi người dùng đang làm việc với các tài nguyên web khác nhau.
Ngày nay, hầu hết các trình duyệt đều có tính năng bảo vệ chống lại loại hành vi theo dõi này. Kết quả là, những người theo dõi hiện nay sử dụng công nghệ , giả dạng các kịch bản riêng của họ cho các dự án khác nhau. Cụ thể, trình theo dõi cung cấp cho chủ sở hữu trang web thêm CNAME vào cài đặt của họ cho một tên miền nhất định, địa chỉ của tên miền đó thường trông giống như một bộ ký tự ngẫu nhiên.
Mặc dù không nên cung cấp cookie trang web cho tất cả các tên miền phụ (ví dụ - *.website.com), nhiều trang web thực hiện việc này. Trong trường hợp này, những cookie như vậy sẽ tự động được gửi đến trình theo dõi trá hình của bên thứ ba. Kết quả là chúng tôi không còn có thể nói về bất kỳ quyền riêng tư nào nữa.
Ngoài ra, điều tương tự cũng xảy ra với tiêu đề HTTP , chỉ được gửi đến miền chính vì chúng có thể được sử dụng để tạo người dùng. Đảm bảo rằng dịch vụ CDN bạn sử dụng lọc chính xác các tiêu đề này.
Kết quả
Nếu bạn dự định sớm triển khai tính năng tự lưu trữ tài nguyên của bên thứ ba, hãy để tôi cung cấp cho bạn một số mẹo:
- Lưu trữ các thư viện, phông chữ và tệp CSS quan trọng nhất của bạn. Điều này sẽ làm giảm nguy cơ lỗi trang web hoặc suy giảm hiệu suất do tài nguyên quan trọng đối với trang web không khả dụng do lỗi dịch vụ của bên thứ ba.
- Trước khi bạn lưu vào bộ đệm tài nguyên của bên thứ ba trên CDN, hãy đảm bảo rằng một số loại hệ thống tạo phiên bản được sử dụng khi đặt tên tệp của họ hoặc bạn có thể quản lý vòng đời của các tài nguyên này bằng cách đặt lại bộ đệm CDN theo cách thủ công hoặc tự động khi xuất bản phiên bản mới của kịch bản.
- Hãy hết sức cẩn thận về cài đặt CDN, máy chủ proxy và bộ đệm của bạn. Điều này sẽ cho phép bạn ngăn dự án hoặc tiêu đề của bạn bị gửi cookie
Client-Hintsdịch vụ của bên thứ ba.
Gởi bạn đọc! Bạn có lưu trữ tài liệu của người khác trên máy chủ của mình vì tài liệu này cực kỳ quan trọng đối với hoạt động của dự án của bạn không?
Nguồn: www.habr.com