Công cụ dành cho nhà phát triển · Bộ mã hóa và giải mã Base64
Hình ảnh Base64 nội tuyến trong CSS: khi dữ liệu: URI trợ giúp và khi chúng gây tổn hại
· Tại sao nó quan trọng
base64 hiệu suất
Nội tuyến hình ảnh dưới dạng dữ liệu Base64: URI xóa yêu cầu nhưng phát triển tệp và đánh bại bộ nhớ đệm. Bài đăng này đưa ra khi nào giao dịch có giá trị và khi nào một tệp riêng biệt nhanh hơn.
Biểu định kiểu đã tăng lên hàng trăm kilobyte — thói quen nội tuyến của một nhóm và cách nó hiển thị trong thời gian tải
Một nhóm phát triển đã quyết định rằng nội tuyến các biểu tượng nhỏ dưới dạng dữ liệu Base64: URI trong CSS sẽ giảm HTTP yêu cầu và cải thiện tốc độ tải trang. Theo thời gian, khi có nhiều biểu tượng được thêm vào, biểu định kiểu đã tăng lên 400 kilobyte.
Gói CSS vốn phải chứa các quy tắc kiểu, hiện bị chi phối bởi dữ liệu hình ảnh. Nhóm đã đo thời gian tải và nhận thấy rằng trang chậm hơn so với trước khi nội tuyến chứ không nhanh hơn. Vấn đề đã trở nên rõ ràng: biểu định kiểu 400-kilobyte được tải xuống trên mỗi lần tải trang và được lưu vào bộ nhớ đệm trên mỗi trang, trong khi nếu các biểu tượng là các tệp riêng biệt thì một tệp biểu tượng sẽ được lưu vào bộ nhớ đệm và chia sẻ trên mỗi trang.
Thật là một dữ liệu: URI nội tuyến và tại sao nó là Base64 — cú pháp, loại phương tiện và hình phạt về kích thước
Việc thêm nhiều trang hơn vào trang web khiến vấn đề trở nên tồi tệ hơn vì mỗi trang lại tải xuống cùng một biểu định kiểu với tất cả các hình ảnh nội tuyến đó. Bài đăng này giải thích dữ liệu: URI là gì, tại sao lại là Base64, nội tuyến ảnh hưởng như thế nào đến bộ nhớ đệm và hiệu suất cũng như các quy tắc chung để quyết định thời điểm đánh đổi là xứng đáng. Dữ liệu: URL là cách nhúng tài nguyên trực tiếp vào tệp HTML hoặc CSS thay vì liên kết với tệp bên ngoài. Cú pháp là data:mediaType;base64,encoded_bytes.
mediaType khai báo loại tài nguyên theo sau, chẳng hạn như image/svg+xml cho SVG, image/png cho PNG hoặc văn bản/plain cho văn bản. Cờ ;base64 chỉ ra rằng tải trọng được mã hóa Base64 chứ không phải văn bản được mã hóa phần trăm. Encrypted_bytes là dữ liệu thực tế. Khi trình duyệt gặp dữ liệu: URL trong thuộc tính href, src hoặc hình nền, trình duyệt sẽ giải mã Base64 và hiển thị nội tuyến tài nguyên. Không có yêu cầu HTTP nào xảy ra vì tài nguyên đã có sẵn ở đó, được nhúng trong tài liệu gốc. Việc này sẽ lưu một hoặc một vài yêu cầu HTTP, điều này quan trọng trong thế giới HTTP/1.1 trong đó mỗi yêu cầu đều có chi phí chung.
Bộ nhớ đệm và đường dẫn quan trọng - tại sao các byte nội tuyến được tải xuống lại với mọi trang có chứa biểu định kiểu
Trong thế giới HTTP/2 hoặc HTTP/3 nơi nhiều yêu cầu có thể được ghép kênh qua một kết nối thì mức tiết kiệm sẽ nhỏ hơn. Hình phạt về kích thước của mã hóa Base64 là ngay lập tức và đáng kể. Biểu tượng SVG có dung lượng 3 kilobyte khi được lưu dưới dạng tệp XML sẽ trở thành 4 kilobyte khi được mã hóa Base64 và nhúng dưới dạng dữ liệu: URI. Việc tăng kích thước 33% từ mã hóa phải được thêm vào mọi trang có chứa biểu định kiểu. Nếu biểu tượng được sử dụng trên mười trang thì biểu định kiểu sẽ được tải xuống mười lần, mỗi lần bao gồm cùng hình ảnh được mã hóa 4-kilobyte đó.
Nếu biểu tượng là một tệp riêng biệt, bản gốc 3-kilobyte sẽ được tải xuống một lần và được lưu vào bộ nhớ đệm, sau đó được sử dụng từ bộ nhớ đệm trên tất cả mười trang. Sự lựa chọn kinh tế là rõ ràng đối với hầu hết các biểu tượng: các tệp riêng biệt có kích thước tổng thể nhỏ hơn. Lợi ích nội tuyến chỉ áp dụng khi một biểu tượng được sử dụng trên chính xác một trang hoặc rất ít trang và biểu tượng đó thực sự quan trọng đối với trang đó. Một biểu tượng yêu thích xuất hiện trên mọi trang không phải là ứng cử viên phù hợp cho nội tuyến; tốt hơn là nên lưu trữ một tệp riêng biệt.
Chi phí phân tích cú pháp trên máy khách — các chuỗi nội tuyến lớn được xử lý như thế nào bởi các trình phân tích cú pháp CSS và HTML, được mô tả một cách định tính
Hình minh họa một lần chỉ được sử dụng trên trang đích có thể được hưởng lợi từ việc nội tuyến để lưu yêu cầu. Bộ nhớ đệm đánh bại hầu hết các lợi ích của dữ liệu nội tuyến: URI trong biểu định kiểu. Biểu định kiểu thường được lưu trữ trong nhiều ngày hoặc nhiều tuần. Khi biểu định kiểu được tải xuống, mọi tài nguyên có trong đó sẽ được tải xuống lại, ngay cả khi trình duyệt đã lưu hình ảnh đó vào bộ nhớ đệm. Nếu biểu định kiểu được cập nhật thì tất cả dữ liệu nội tuyến phải được xác thực lại hoặc tải xuống lại, ngay cả khi chỉ một quy tắc CSS được thay đổi.
Điều này gây ra hiện tượng phồng lên: các thay đổi về màu sắc hoặc khoảng cách kích hoạt quá trình tải xuống lại toàn bộ biểu định kiểu, bao gồm hàng kilobyte dữ liệu hình ảnh không thay đổi. Một tệp hình ảnh riêng biệt có thể được lưu vào bộ đệm độc lập với các tiêu đề hết hạn của riêng nó, được cập nhật riêng và được sử dụng lại trên các trang và bảng định kiểu. Bộ đệm của trình duyệt hiệu quả hơn nhiều khi tài nguyên là các tệp riêng biệt so với khi chúng được nhúng trong các tài liệu lớn hơn. Chi phí phân tích cú pháp và kết xuất tăng lên khi các chuỗi Base64 lớn được nhúng trong biểu định kiểu. Trình phân tích cú pháp CSS phải đọc toàn bộ biểu định kiểu trước khi áp dụng quy tắc.
Ví dụ đã hoạt động: nội tuyến một biểu tượng SVG nhỏ dưới dạng văn bản — dán đánh dấu vào bộ mã hóa và tập hợp dữ liệu: URI bằng tay
Biểu định kiểu 400-kilobyte có Base64 nội tuyến là 400 kilobyte văn bản phải được phân tích cú pháp trước khi có thể áp dụng bất kỳ quy tắc nào. Trình phân tích cú pháp HTML hiển thị một trang có dữ liệu lớn: URI trong thuộc tính style hoặc thuộc tính hình nền phải giải mã Base64 và xây dựng hình ảnh trước khi phần tử có thể hiển thị. Đối với các biểu tượng SVG đơn giản thì điều này không quan trọng. Đối với những hình ảnh phức tạp hơn hoặc các biểu tượng lớn hơn, quá trình giải mã và hiển thị diễn ra trên luồng chính, có khả năng chặn tính tương tác. Chi phí định tính là có thật nhưng khó đo lường nếu không lập hồ sơ.
Theo quy định, nếu hình ảnh nội tuyến có kích thước lớn hơn vài kilobyte thì các tệp riêng biệt sẽ nhanh hơn. Một ví dụ hoạt động cho thấy sự đánh đổi chính xác. Lấy biểu tượng mũi tên SVG đơn giản, 1.2 kilobyte XML. Được mã hóa Base64, nó trở thành 1600 ký tự hoặc khoảng 1.6 kilobyte với tiền tố data: URL. Một quy tắc CSS riêng biệt với hình nền: url(/icons/arrow.svg) có thể thêm 40 bytes vào biểu định kiểu. Tệp biểu tượng được tải xuống một lần, được lưu vào bộ nhớ đệm và sử dụng lại. Nội tuyến sẽ lưu một yêu cầu HTTP cho một biểu tượng đó nhưng sẽ thêm 1.6 kilobyte vào mỗi lần tải biểu định kiểu.
Các quy tắc chung được tuân thủ - nội tuyến nội dung nhỏ, quan trọng, sử dụng một lần; mọi thứ khác dưới dạng một tệp
Nếu biểu định kiểu là 50 kilobyte và được chia sẻ trên 20 trang, nội tuyến biểu tượng đó sẽ tăng tổng số lượt tải xuống lên 32 kilobyte trên mỗi lượt truy cập trang web. các HTTP yêu cầu nó tiết kiệm tối đa là vài trăm byte chi phí. Yêu cầu cũng được tự động ghép kênh trong HTTP/2, loại bỏ sự khác biệt trên chi phí. Giao dịch nội tuyến sẽ thua nặng trừ khi biểu định kiểu rất nhỏ, biểu tượng rất lớn hoặc biểu tượng xuất hiện trên chính xác một trang và không xuất hiện ở nơi nào khác. Các quy tắc chung tồn tại sau sự xem xét kỹ lưỡng còn hạn chế và cụ thể.
Những nội dung nhỏ, quan trọng, sử dụng một lần có thể được nội tuyến hóa. Mũi tên 200 byte SVG chỉ xuất hiện trên một trang bất thường có thể được đưa vào nội tuyến để lưu chi phí yêu cầu. Mọi thứ khác nên riêng biệt. Logic đường dẫn hiển thị quan trọng có vấn đề: nếu một biểu tượng phải hiển thị ngay lập tức và mỗi mili giây chuyển đổi chi phí thời gian tải thì nội tuyến có thể giành chiến thắng. Đối với các trang điển hình có biểu tượng điển hình, các tệp riêng biệt hầu như luôn tốt hơn. Kiểm tra cả hai phương pháp với nội dung thực tế của bạn và đo lường tải trang, tỷ lệ truy cập bộ đệm và thác yêu cầu.
Điều này không bao gồm - HTTP/2 Và HTTP/3 chi tiết ghép kênh và nén định dạng hình ảnh
Đừng cho rằng nội tuyến là tối ưu hóa mà không cần đo lường. Cách dễ nhất để kết thúc với một biểu định kiểu cồng kềnh là nội tuyến tăng dần mà không cần đo xem mỗi lần bổ sung có thực sự nhanh hơn hay không. Bộ mã hóa & giải mã Base64 giúp bạn đưa ra quyết định này trước khi thực hiện nội tuyến. Dán đánh dấu SVG của bạn hoặc nguồn biểu tượng khác vào công cụ dưới dạng văn bản. Nhấp vào Mã hóa và đặt các tùy chọn để tạo dữ liệu: URI. Công cụ này hiển thị cho bạn độ dài chính xác của dữ liệu: URL. So sánh kích thước đó với kích thước của quy tắc CSS riêng biệt và chính tệp nội dung.
Tính toán số lượng trang cần chia sẻ biểu định kiểu để hòa vốn trên các tệp nội tuyến so với các tệp riêng biệt. Tập hợp dữ liệu: URI và kiểm tra dữ liệu đó trên trang HTML thực tế trước khi bạn đưa dữ liệu đó vào biểu định kiểu. Nếu URI dài hơn vài trăm ký tự thì chi phí nhúng có thể lớn hơn lợi ích của việc lưu yêu cầu. Sử dụng công cụ này để kiểm tra các biểu tượng và nội dung thực tế của bạn, sau đó đo lường tác động lên số liệu tải trang thực tế của bạn trước và sau khi nội tuyến.
Bài học rút ra: nội tuyến một cách tiết kiệm và đo lường — cách bộ mã hóa và giải mã Base64 cho phép bạn mã hóa đánh dấu SVG và xem kích thước chính xác trước khi bạn cam kết
Cách tiếp cận hiệu quả là phải chọn lọc về nội tuyến. Các biểu tượng được sử dụng trên mỗi trang hoặc trên nhiều trang là các tệp được lưu trong bộ nhớ đệm riêng biệt. Các biểu tượng được sử dụng trên đúng một trang hoặc thực sự quan trọng đối với lần vẽ đầu tiên có thể được nội tuyến. Đo lường sự đánh đổi cho nội dung và trang thực tế của bạn thay vì làm theo lời khuyên chung chung. Sử dụng bộ mã hóa và giải mã Base64 để xem kích thước chính xác của bất kỳ nội dung nội tuyến nào trước khi bạn thêm nó vào biểu định kiểu. Hình phạt về kích thước là có thật và nhân lên trên mỗi lượt xem trang.
Bộ nhớ đệm và ghép kênh yêu cầu đã làm cho lợi ích ban đầu của việc nội tuyến trở nên ít quan trọng hơn. Đối với hầu hết các ứng dụng hiện đại, các bảng định kiểu nhỏ hơn và hiệu suất bộ đệm tốt hơn từ các tệp riêng biệt sẽ vượt xa chi phí yêu cầu. Nội tuyến một cách tiết kiệm, đo lường kết quả và đo lường sự tin cậy qua trực giác.