개발자 도구 · Base64 인코더 및 디코더
CSS의 인라인 Base64 이미지: 데이터: URI가 도움이 될 때와 도움이 될 때
· 그것이 중요한 이유
베이스64 실적
이미지를 Base64 데이터로 인라인 처리: URI는 요청을 제거하지만 파일을 늘리고 캐싱을 무효화합니다. 이 게시물에서는 거래가 가치가 있는 경우와 별도의 파일이 더 빠른 경우를 설명합니다.
수백 킬로바이트로 늘어난 스타일시트 - 한 팀의 인라인 습관과 그것이 로드 타이밍에 어떻게 나타나는지
개발 팀은 CSS의 Base64 데이터: URI로 작은 아이콘을 삽입하면 HTTP 요청이 줄어들고 페이지 로드 속도가 향상될 것이라고 결정했습니다. 시간이 지나면서 더 많은 아이콘이 추가되면서 스타일시트가 400킬로바이트로 늘어났습니다.
스타일 규칙을 포함해야 하는 CSS 번들은 이제 이미지 데이터에 의해 지배됩니다. 팀에서는 로드 타이밍을 측정한 결과 페이지가 인라인 처리 전보다 빨라진 것이 아니라 느려졌다는 사실을 발견했습니다. 문제는 명확해졌습니다. 400-킬로바이트 스타일시트는 모든 페이지 로드 시 다운로드되고 페이지별로 캐시되는 반면, 아이콘이 별도의 파일인 경우 단일 아이콘 파일이 모든 페이지에서 캐시되고 공유됩니다.
멋진 데이터: URI 인라인과 이것이 Base64인 이유 — 구문, 미디어 유형 및 크기 패널티
사이트에 더 많은 페이지를 추가하면 각 페이지가 모든 인라인 이미지가 포함된 동일한 스타일시트를 다시 다운로드하기 때문에 문제가 더욱 악화되었습니다. 이 게시물에서는 데이터가 무엇인지, 즉 URI가 Base64인 이유, 인라인이 캐싱과 성능에 미치는 영향, 절충할 가치가 있는 시기를 결정하는 경험적 규칙에 대해 설명합니다. 데이터: URL은 외부 파일에 연결하는 대신 HTML 또는 CSS 파일에 직접 리소스를 포함하는 방법입니다. 구문은 data:mediaType;base64,encoded_bytes입니다.
mediaType은 SVG의 경우 image/svg+xml, PNG의 경우 image/png, 텍스트의 경우 text/plain과 같이 뒤에 오는 리소스 종류를 선언합니다. ;base64 플래그는 페이로드가 백분율로 인코딩된 텍스트가 아니라 Base64로 인코딩되었음을 나타냅니다. Encoded_bytes는 실제 데이터입니다. 브라우저가 href, src 또는 background-image 속성에서 data: URL을 발견하면 Base64를 디코딩하고 리소스를 인라인으로 렌더링합니다. 리소스가 이미 상위 문서에 포함되어 있으므로 HTTP 요청이 발생하지 않습니다. 이렇게 하면 하나 또는 몇 개의 HTTP 요청이 절약되며, 이는 각 요청에 오버헤드가 있는 HTTP/1.1 세계에서 중요합니다.
캐싱 및 주요 경로 — 스타일시트가 포함된 모든 페이지에서 인라인 바이트가 다시 다운로드되는 이유
하나의 연결을 통해 많은 요청이 멀티플렉싱될 수 있는 HTTP/2 또는 HTTP/3 환경에서는 절약 효과가 더 적습니다. Base64 인코딩의 크기 패널티는 즉각적이고 중요합니다. XML 파일로 저장할 때 3킬로바이트인 SVG 아이콘은 Base64로 인코딩되고 데이터 URI로 포함되면 4킬로바이트가 됩니다. 스타일시트를 포함하는 모든 페이지에 인코딩으로 인한 33% 크기 증가를 추가해야 합니다. 아이콘이 10페이지에 걸쳐 사용되는 경우 스타일시트는 10번 다운로드되며 매번 동일한 4킬로바이트 인코딩 이미지가 포함됩니다.
아이콘이 별도의 파일인 경우 3-킬로바이트 원본이 한 번 다운로드되어 캐시된 다음 10개 페이지 모두의 캐시에서 사용됩니다. 대부분의 아이콘에 대한 경제적 선택은 분명합니다. 개별 파일은 전체적으로 더 작습니다. 인라인 이점은 아이콘이 정확히 한 페이지 또는 아주 적은 페이지에서 사용되고 아이콘이 해당 페이지에 실제로 중요한 경우에만 적용됩니다. 모든 페이지에 나타나는 파비콘은 인라인 처리에 적합하지 않습니다. 별도의 캐시 파일로 사용하는 것이 더 좋습니다.
클라이언트의 구문 분석 비용 — CSS 및 HTML 구문 분석기가 처리하는 인라인 문자열의 크기(정성적으로 설명)
랜딩 페이지에만 사용되는 일회성 그림은 요청을 저장하기 위해 인라인 처리하는 것이 도움이 될 수 있습니다. 캐싱은 데이터 인라인의 이점인 스타일시트의 URI의 대부분을 무효화합니다. 스타일시트는 일반적으로 며칠 또는 몇 주 동안 캐시됩니다. 스타일시트가 다운로드되면 브라우저에 해당 이미지가 이미 캐시되어 있더라도 여기에 포함된 모든 리소스가 다시 다운로드됩니다. 스타일시트가 업데이트되면 CSS 규칙이 하나만 변경된 경우에도 인라인된 모든 데이터를 다시 검증하거나 다시 다운로드해야 합니다.
이로 인해 팽창이 발생합니다. 색상이나 간격을 변경하면 변경되지 않은 킬로바이트의 이미지 데이터를 포함하여 스타일시트 전체가 다시 다운로드됩니다. 별도의 이미지 파일은 자체 만료 헤더를 사용하여 독립적으로 캐시되고 별도로 업데이트되며 스타일시트와 페이지 전체에서 재사용될 수 있습니다. 브라우저 캐시는 리소스가 더 큰 문서에 포함되어 있을 때보다 별도의 파일일 때 훨씬 더 효율적입니다. 큰 Base64 문자열이 스타일시트에 포함되어 있으면 구문 분석 및 렌더링 비용이 복잡해집니다. CSS 파서는 규칙을 적용하기 전에 전체 스타일시트를 읽어야 합니다.
작업한 예: 작은 SVG 아이콘을 텍스트로 인라이닝 — 마크업을 인코더에 붙여넣고 데이터 조립: 손으로 URI
인라인 Base64가 포함된 400킬로바이트 스타일시트는 규칙을 적용하기 전에 구문 분석해야 하는 400킬로바이트 텍스트입니다. 큰 데이터가 포함된 페이지를 렌더링하는 HTML 파서: 스타일 속성 또는 배경 이미지 속성의 URI는 요소가 렌더링되기 전에 Base64를 디코딩하고 이미지를 구성해야 합니다. 간단한 SVG 아이콘의 경우 이는 사소한 일입니다. 더 복잡한 이미지나 더 큰 아이콘의 경우 디코딩 및 렌더링이 기본 스레드에서 발생하므로 잠재적으로 상호 작용이 차단됩니다. 질적 비용은 실제적이지만 프로파일링 없이 측정하기는 어렵습니다.
일반적으로 인라인된 이미지가 몇 킬로바이트보다 큰 경우 별도의 파일이 더 빠릅니다. 실제 사례는 정확한 절충안을 보여줍니다. XML의 1.2 킬로바이트에 해당하는 간단한 SVG 화살표 아이콘을 사용합니다. Base64로 인코딩되면 1600 문자 또는 data: URL 접두사가 포함된 약 1.6 킬로바이트가 됩니다. 배경 이미지가 포함된 별도의 CSS 규칙: url(/icons/arrow.svg)은 스타일시트에 40바이트를 추가합니다. 아이콘 파일은 한 번 다운로드되어 캐시되고 재사용됩니다. 인라인은 해당 아이콘에 대한 하나의 HTTP 요청을 저장하지만 모든 스타일시트 로드에 1.6킬로바이트를 추가합니다.
유지되는 경험 법칙 — 작고 중요한 일회용 자산 인라인; 다른 모든 것은 파일로
스타일시트가 50킬로바이트이고 20 페이지에서 공유되는 경우 해당 아이콘을 인라인하면 사이트 방문당 총 다운로드가 32킬로바이트씩 늘어납니다. 이를 통해 저장되는 HTTP 요청은 최대 수백 바이트의 오버헤드입니다. 또한 요청은 HTTP/2,에서 자동으로 다중화되어 오버헤드 차이를 제거합니다. 스타일시트가 작거나, 아이콘이 크거나, 아이콘이 정확히 한 페이지에만 나타나고 다른 곳에 나타나지 않는 한 인라인 거래는 크게 손실됩니다. 조사 후에도 살아남는 경험 법칙은 제한적이고 구체적입니다.
작고 중요한 일회용 자산을 인라인할 수 있습니다. 하나의 특이한 페이지에만 나타나는 200바이트 SVG 화살표는 요청 오버헤드를 절약하기 위해 인라인될 수 있습니다. 다른 것들은 모두 분리되어야 합니다. 중요한 렌더링 경로 논리가 중요합니다. 아이콘이 즉시 표시되어야 하고 로드 시간의 매 밀리초마다 변환 비용이 드는 경우 인라인이 승리할 수 있습니다. 일반적인 아이콘이 있는 일반적인 페이지의 경우 별도의 파일이 거의 항상 더 좋습니다. 실제 자산으로 두 가지 접근 방식을 테스트하고 페이지 로드, 캐시 적중률 및 요청 폭포를 측정합니다.
여기서 다루지 않는 내용 — HTTP/2 및 HTTP/3 다중화 세부 정보 및 이미지 형식 압축
인라인이 측정 없는 최적화라고 가정하지 마십시오. 부풀어 오른 스타일시트로 끝나는 가장 쉬운 방법은 각 추가가 실제로 더 빠른지 여부를 측정하지 않고 점진적으로 인라인하는 것입니다. Base64 인코더 및 디코더는 인라인 처리를 시작하기 전에 이러한 결정을 내리는 데 도움이 됩니다. SVG 마크업이나 기타 아이콘 소스를 도구에 텍스트로 붙여넣습니다. 인코딩을 클릭하고 데이터: URI를 생성하는 옵션을 설정합니다. 이 도구는 데이터의 정확한 길이를 보여줍니다: URL. 이를 별도의 CSS 규칙 및 자산 파일 자체의 크기와 비교해 보세요.
인라인과 개별 파일의 손익분기점을 맞추기 위해 스타일시트를 공유해야 하는 페이지 수를 계산합니다. 데이터: URI를 조합하고 스타일시트에 커밋하기 전에 실제 HTML 페이지에서 테스트합니다. URI가 수백자를 초과하는 경우 요청을 저장하여 얻을 수 있는 이점보다 삽입 비용이 더 클 수 있습니다. 도구를 사용하여 실제 아이콘과 자산을 테스트한 다음 인라인 처리 전후의 실제 페이지 로드 측정항목에 미치는 영향을 측정하세요.
요점: 인라인으로 드물게 측정 — Base64 인코더 및 디코더를 사용하여 SVG 마크업을 인코딩하고 커밋하기 전에 정확한 크기를 확인하는 방법
성능 접근 방식은 인라인에 대해 선택적인 것입니다. 모든 페이지 또는 여러 페이지에 걸쳐 사용되는 아이콘은 별도의 캐시 파일입니다. 정확히 한 페이지에 사용되거나 첫 번째 페인트에 매우 중요한 아이콘은 인라인될 수 있습니다. 일반적인 조언을 따르기보다는 실제 자산과 페이지의 균형을 측정하십시오. Base64 인코더 및 디코더를 사용하면 스타일시트에 추가하기 전에 인라인된 자산의 정확한 크기를 확인할 수 있습니다. 크기 패널티는 실제이며 모든 페이지 보기에 걸쳐 증가합니다.
캐싱 및 요청 멀티플렉싱으로 인해 인라인의 원래 이점이 덜 중요해졌습니다. 대부분의 최신 애플리케이션의 경우 별도 파일의 더 작은 스타일시트와 더 나은 캐시 효율성이 요청 오버헤드보다 중요합니다. 인라인에서는 결과를 드물게 측정하고 직관보다는 측정을 신뢰하세요.