When to Use Base64 Encoded Images (And When Not To)

Ba năm trước, tôi đã chứng kiến một lập trình viên trẻ trong đội của mình thêm hình ảnh mã hóa Base64 vào từng thành phần trong ứng dụng React của chúng tôi. "Nó nhanh hơn!" anh ta khăng khăng, chỉ về một bài viết mà anh ta tìm thấy, tuyên bố rằng hình ảnh nội tuyến loại bỏ các yêu cầu HTTP. Hai tuần sau, kích thước gói của chúng tôi đã phình to lên 8.7MB, thời gian tải trang ban đầu của chúng tôi mất 14 giây trên 3G, và chi phí CDN của chúng tôi đã tăng gấp ba mà không rõ lý do. Cái sai lầm tốn kém đó đã dạy tôi một điều quý giá: Mã hóa Base64 là một trong những công cụ nghe có vẻ thông minh trong lý thuyết nhưng trở thành gánh nặng khi bị áp dụng sai.

Tôi là Sarah Chen, và tôi đã dành 12 năm qua với vai trò kỹ sư hiệu suất tại các công ty từ các startup nhỏ đến các tập đoàn Fortune 500. Tôi đã tối ưu hóa mọi thứ từ các nền tảng thương mại điện tử phục vụ 50 triệu người dùng mỗi tháng đến các bảng điều khiển nội bộ mà không ai nghĩ là cần tối ưu hóa (thực ra là có). Trong khoảng thời gian đó, tôi đã thấy mã hóa Base64 được sử dụng một cách xuất sắc, và tôi cũng thấy nó phá hủy hiệu suất ứng dụng. Sự khác biệt luôn nằm ở chỗ hiểu không chỉ cách nó hoạt động, mà còn khi nào nó thực sự có ý nghĩa.

Bài viết này là nỗ lực của tôi để cung cấp cho bạn khung tư duy mà tôi ước mình đã có khi bắt đầu. Chúng ta sẽ khám phá thực tế kỹ thuật của mã hóa Base64, khám phá những kịch bản cụ thể mà nó nổi bật, và quan trọng hơn, xác định các tình huống mà nó thực sự gây hại. Đến cuối bài, bạn sẽ có một quy trình ra quyết định vượt ra ngoài "Tôi đã đọc rằng nó nhanh hơn" đến lý do thực sự, có thể đo lường được.

Sự Thật Kỹ Thuật: Mã Hóa Base64 Thực Sự Tác Động Đến Hình Ảnh Của Bạn Như Thế Nào

Hãy bắt đầu với sự thật khó chịu mà nhiều lập trình viên bỏ qua: mã hóa Base64 làm cho hình ảnh của bạn lớn hơn khoảng 33%. Không phải đôi khi. Mà luôn luôn. Đây không phải là một lỗi hay chi tiết triển khai - đây là toán học cơ bản.

Khi bạn mã hóa dữ liệu hình ảnh nhị phân thành Base64, bạn đang chuyển đổi các byte 8 bit thành các ký tự 6 bit từ một tập hợp ASCII an toàn. Ba byte dữ liệu nhị phân trở thành bốn ký tự Base64. Đó là lý do tại sao có 33% chi phí bổ sung: 4/3 = 1.33. Một tập tin JPEG 30KB trở thành một chuỗi Base64 40KB. Một tập tin PNG 100KB phình lên đến 133KB. Sự gia tăng kích thước này xảy ra trước khi có bất kỳ nén nào, trước khi bất kỳ chuyển giao mạng nào xảy ra, trước khi bất kỳ điều gì khác xảy ra.

Đây là điều thực sự xảy ra khi bạn mã hóa một hình ảnh bằng Base64. Tệp nhị phân gốc của bạn - hãy nói rằng là một bức ảnh sản phẩm 45KB - được đọc như các byte thô. Mỗi byte là một số từ 0 đến 255. Thuật toán mã hóa lấy những byte này theo nhóm ba (tổng cộng 24 bit) và chia chúng thành bốn phần 6 bit. Mỗi phần 6 bit ánh xạ tới một trong 64 ký tự ASCII an toàn (A-Z, a-z, 0-9, +, /). Kết quả là một chuỗi dài trông như thế này: "/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a..."

Chuỗi này giờ đây an toàn để nhúng trực tiếp vào HTML, CSS hoặc JavaScript. Đó là lợi ích. Nhưng bạn đang phải trả giá cho sự an toàn đó bằng kích thước. Và kích thước quan trọng hơn những gì hầu hết lập trình viên nhận ra, đặc biệt là trên các mạng di động, nơi mỗi kilobyte chuyển thành số mili giây thực tế của thời gian tải trang.

Sự thật kỹ thuật thứ hai: các chuỗi Base64 không thể được nén hiệu quả như dữ liệu nhị phân. Khi bạn phục vụ một JPEG bình thường qua HTTP với nén gzip, bạn có thể thấy mức giảm kích thước 15-20%. Khi bạn nén gzip một phiên bản JPEG mã hóa Base64 của cùng một tệp đó, bạn sẽ thấy có lẽ giảm 5-10%. Quá trình mã hóa tạo ra các mẫu ít có thể nén hơn. Vì vậy, khoản chi phí kích thước 33% thường trở thành khoản chi phí 40-45% sau khi tính toán đến việc nén.

Tôi đã thực hiện các bài kiểm tra về vấn đề này vào năm ngoái với một tập dữ liệu gồm 500 hình ảnh sản phẩm có kích thước từ 10KB đến 200KB. Mức tăng kích thước trung bình sau khi mã hóa Base64 và nén gzip là 37%. Đối với các hình ảnh dưới 5KB, mức phí gần 42%. Đối với các hình ảnh trên 100KB, nó vẫn là 35%. Không có cách nào để tránh toán học này.

Lợi Thế Đích Thực: Loại Bỏ Các Yêu Cầu HTTP

Vậy tại sao ai đó lại sử dụng mã hóa Base64? Bởi vì trong những kịch bản cụ thể, việc loại bỏ một yêu cầu HTTP có giá trị hơn mức phí kích thước. Hãy để tôi nói rõ khi nào điều này thực sự đúng.

"Mã hóa Base64 không loại bỏ các yêu cầu HTTP - nó chỉ ẩn chúng bên trong gói JavaScript của bạn, nơi mà chúng ảnh hưởng đến hiệu suất theo những cách khó tối ưu hơn."

Mỗi yêu cầu HTTP đều có chi phí bổ sung. Trình duyệt phải thực hiện một tìm kiếm DNS (nếu chưa được lưu vào bộ nhớ cache), thiết lập một kết nối TCP, thực hiện một thủ tục bắt tay TLS (đối với HTTPS), gửi các tiêu đề yêu cầu, chờ máy chủ phản hồi, nhận các tiêu đề phản hồi, và cuối cùng tải nội dung. Đối với HTTP/1.1, chi phí bổ sung này là đáng kể - thường từ 100 đến 300ms trên một kết nối tốt, và từ 500 đến 1000ms trên các mạng di động có độ trễ cao.

Khi bạn chèn một hình ảnh nhỏ dưới dạng Base64, bạn đã loại bỏ tất cả những điều đó. Dữ liệu hình ảnh đến cùng với HTML, CSS hoặc tệp JavaScript chứa nó. Không có yêu cầu riêng rẽ, không có chuyến đi bổ sung, không có chi phí kết nối. Đối với những hình ảnh nhỏ - biểu tượng, logo nhỏ, yếu tố UI - điều này có thể dẫn đến việc kịp thời hơn, đặc biệt là trên các kết nối có độ trễ cao.

Tôi đã đo hiệu ứng này trên một ứng dụng bảng điều khiển có 23 biểu tượng nhỏ (trung bình 2.1KB mỗi biểu tượng) được tải dưới dạng các tệp PNG riêng biệt. Trên một kết nối giả lập 3G với độ trễ 300ms, tổng thời gian tải tất cả các biểu tượng là 4.7 giây do chi phí kết nối và hàng đợi yêu cầu của trình duyệt. Sau khi chuyển đổi chúng thành Base64 và chèn chúng vào CSS, các biểu tượng giống nhau được tải trong 1.2 giây như một phần của tải xuống stylesheet. Đó là một cải thiện 3.5 giây bất chấp mức tăng kích thước 33%.

Nhưng đây là chi tiết quan trọng: lợi thế này chỉ tồn tại khi chi phí bổ sung của yêu cầu HTTP vượt quá chi phí của các byte bổ sung. Đối với một biểu tượng 2KB, số byte 667 ở dạng Base64 là không đáng kể so với 300ms độ trễ. Đối với một hình ảnh 200KB, chi phí 66KB là tàn khốc, và không có tiết kiệm độ trễ nào có thể bù đắp lại.

Điểm giao cắt, dựa trên các thử nghiệm của tôi qua nhiều điều kiện mạng khác nhau, ở đâu đó giữa 4KB và 10KB. Dưới 4KB, mã hóa Base64 thường thắng. Trên 10KB, nó gần như luôn thua. Giữa 4KB và 10KB, điều đó phụ thuộc vào hồ sơ độ trễ cụ thể và chiến lược bộ nhớ cache của bạn.

Trường Hợp Sử Dụng Quan Trọng: Data URIs Cho Các Yếu Tố Giao Diện Nhỏ

Việc sử dụng hợp pháp nhất của mã hóa Base64 là cho các yếu tố giao diện nhỏ, thường được sử dụng mà rất quan trọng cho lần render đầu tiên. Tôi đang nói về các biểu tượng, logo nhỏ, vòng quay tải, và các đồ họa thiết yếu mà người dùng cần phải thấy ngay lập tức.

Trong một dự án mà tôi tham gia cho một công ty dịch vụ tài chính, chúng tôi đã có một bảng điều khiển với 15 biểu tượng nhỏ xuất hiện ở trên cùng. Những biểu tượng này là một phần của điều hướng cốt lõi và cần phải được nhìn thấy trong vòng 1.5 giây đầu tiên của việc tải trang (ngân sách hiệu suất của chúng tôi). Mỗi biểu tượng có kích thước khoảng 1.8KB dưới dạng tệp SVG.

Chúng tôi có ba lựa chọn: phục vụ chúng dưới dạng các tệp riêng lẻ, kết hợp chúng thành một bảng sprite, hoặc chèn chúng dưới dạng các Data URI mã hóa Base64. Chúng tôi đã thử nghiệm cả ba phương pháp trên 50 hồ sơ mạng khác nhau bằng cách sử dụng WebPageTest. Kết quả rất rõ ràng: các Data URI mã hóa Base64 trong CSS thiết yếu đã giảm Chỉ số Tốc độ của chúng tôi trung bình 0.4 giây, với những cải thiện lớn nhất trên các kết nối di động có độ trễ cao.

Các yếu tố chính đã làm cho điều này thành công là kích thước (dưới 2KB mỗi biểu tượng), tính thiết yếu (cần cho việc render đầu tiên), và tần suất (sử dụng trên mỗi trang). Nếu bất kỳ yếu tố nào trong số này khác đi, quyết định sẽ thay đổi.