▲

GN⁺: WebP: 웹페이지 압축 형식

 (purplesyringa.moe)
1P by neo 3달전 | favorite | 댓글 1개

WebP: 웹페이지 압축 형식

장애물

  • 웹사이트의 접근성을 높이고 페이지 로드 시간을 줄이기 위해 HTML을 최소화함
  • GitHub Pages는 Brotli 압축을 지원하지 않음
  • gzip은 기본적으로 사용되지만, Brotli는 더 나은 압축률을 제공함

단순한 아이디어

  • GitHub Pages가 Brotli를 지원하지 않으므로, 클라이언트 측에서 JavaScript로 압축 해제하는 방법을 고려함
  • brotli-dec-wasm과 tiny-brotli-dec-wasm을 사용하여 Brotli 압축 해제 가능

두 번째 시도

  • Compression Streams API를 사용하여 gzip과 DEFLATE 형식을 지원하지만, Brotli는 지원하지 않음
  • Zopfli 라이브러리를 사용하여 gzip을 더 효율적으로 압축할 수 있지만, 여전히 Brotli보다 성능이 떨어짐

법을 어기다

  • 이미지 압축을 사용하여 데이터를 압축하는 방법을 고려함
  • PNG와 GIF는 DEFLATE 알고리듬을 사용하지만, WebP는 더 나은 성능을 제공함

WebP의 장점

  • WebP는 PNG와 유사한 예측 변환을 사용하지만, DEFLATE 대신 Google이 개발한 방법을 사용함
  • 다양한 허프만 트리를 사용하여 더 효율적인 압축을 제공함
  • 색상 캐시를 사용하여 반복되는 색상을 효율적으로 저장함

실험

  • webp 크레이트를 사용하여 HTML 파일을 압축해 봄
  • 초기 결과는 gzip보다 2배 더 작은 크기를 보여줌

추가 최적화

  • 이미지의 크기를 조정하여 더 나은 압축 성능을 얻음
  • 다양한 압축 방법을 시도하여 최적의 결과를 찾음

벤치마크

  • 다양한 파일 형식에 대해 gzip, bzip2, Brotli, WebP를 비교함
  • WebP는 대부분의 경우 gzip보다 더 나은 성능을 보여줌
  • Brotli보다는 성능이 떨어지지만, 여전히 유의미한 개선을 제공함

JavaScript로 디코딩

  • Canvas API를 사용하여 WebP를 디코딩하는 방법을 설명함
  • WebGL을 사용하여 반지문 방지 기술을 우회함

최종 조정

  • 페이지 로드 시 깜박임을 줄이기 위해 스타일링과 상단 부분을 gzip으로 유지함
  • 스크롤 위치를 유지하기 위한 임시 해결책을 제안함

임베딩

  • WebP를 JavaScript에 직접 임베딩하여 지연 시간을 줄임
  • base64 데이터 URL을 사용하여 크기를 최소화함

예제

  • 실제 웹 페이지에서 WebP를 사용하여 압축한 예제를 제공함
  • 압축 후 페이지 크기가 줄어드는 것을 확인함

GN⁺의 정리

  • 이 글은 웹페이지의 압축 성능을 개선하기 위한 다양한 방법을 탐구함
  • WebP 형식이 gzip보다 더 나은 성능을 제공하지만, Brotli보다는 성능이 떨어짐
  • JavaScript와 WebGL을 사용하여 클라이언트 측에서 WebP를 디코딩하는 방법을 설명함
  • 페이지 로드 시간을 줄이기 위한 다양한 최적화 기법을 제안함
  • 유사한 기능을 제공하는 다른 프로젝트로는 Brotli와 Zopfli가 있음
▲
neo 3달전  [-]
Hacker News 의견

  • 긴 게시물의 크기가 92 KiB에서 37 KiB로 줄어들었음에도 불구하고, 실제 로드 시간 증가율은 0.001%에 불과함

    • 압축 해제 시간 때문에 사용자 경험이 더 나빠질 수 있음

  • readPixels가 반지문 방지 기능을 적용받지 않는 이유를 이해할 수 없음

    • 페이지 상단의 스타일링을 유지하고, 뷰포트 아래의 콘텐츠만 WebP로 압축하는 기술이 있음
    • LibreWolf에서 WebGL을 비활성화하면 페이지가 잘리지 않음

  • zstd가 Chrome에 도입되었으며, Safari에도 적용해야 함

  • Google Fonts를 제거하면 페이지 로드 시간이 개선될 수 있음

    • 원격 서버에서 로드되기 때문에 추가적인 핸드셰이크가 필요함

  • 소스 코드를 확인해보니 doctype 선언에 공백이 없음

    • 현재는 <!doctypehtml>로 되어있지만, <!doctype html>로 수정해야 함

  • HTML 페이지를 자체 추출 ZIP 파일로 패키징할 수 있음

    • PNG 이미지를 포함하여 HTML, ZIP, PNG와 호환되는 파일을 생성할 수 있음
    • 예를 들어, HTML 페이지에서 PNG 이미지를 표시할 수 있음

  • Sailfish OS 브라우저에서 페이지가 깨짐

    • 단락 뒤에 긴 빈 공간이 있음
    • gzip과 brotli HTML 압축의 오버헤드는 현재 웹사이트에서 사용하는 JS/이미지/비디오 양에 비하면 미미함

  • Brotli가 큰 사전(dictionary)을 가지고 있음에도 불구하고 gzip과 비슷한 성능을 보임

    • 압축 알고리즘이 더 나쁜지, 아니면 사전의 중요성이 생각보다 적은지 궁금함

  • Brotli가 CompressionStream API에서 사용되지 않는 이유는 브라우저 크기를 크게 증가시키기 때문임

    • 압축 사전이 더 큰 이유는 사전이 미리 계산된 가장 효율적인 표현을 포함하고 있기 때문일 가능성이 있음
답변달기