GN⁺: Show HN: Jampack – 정적 웹사이트 최적화를 위한 사후 처리 단계
(github.com/divriots)jampack
이란 무엇인가?
-
jampack
은 번들러도, 프레임워크도 아닌, 정적 사이트 생성기(SSG)의 출력물을 최적화하여 사용자 경험과 Core Web Vitals 점수를 향상시키는 후처리 도구임.
jampack
이 할 수 있는 일은?
-
<img>
태그의 이미지가 반응형으로 변환되어 다양한 해상도를 지원하게 되며,loading="lazy"
와decoding="async"
속성이 추가되어 성능이 향상됨. -
<picture>
태그를 사용하여 여러 형식의 이미지를 포함하는 반응형 이미지로 변환되며, AVIF 포맷도 지원함. - CDN 이미지가 반응형으로 변환되어, 다양한 해상도의 이미지를
srcset
을 통해 제공함. - 외부 이미지를 다운로드하여 최적화할 수 있으며,
_jampack
폴더 내에 최적화된 이미지 파일을 저장함. - 화면에 바로 보이는 이미지(above-the-fold)는 높은 우선순위로 로드되고, 아래로 스크롤할 때 보이는 이미지(below-the-fold)는 지연 로딩됨.
인라인 중요 CSS
- 스타일시트가 다운로드되고 파싱되는 동안 발생할 수 있는 FOUC(Flash of Unstyled Content)를 방지하기 위해,
jampack
은 중요한 CSS를 인라인 처리하고 나머지 CSS는 지연 로딩함.
링크 사전 가져오기
- 페이지 내 링크를 사전에 가져와 미래 페이지 탐색 속도를 향상시킴. quicklink 덕분에 뷰포트에 들어오는 링크를 동적으로 사전 가져오기가 가능함.
모든 자산 압축
-
jampack
은 2차 패스에서 모든 건드리지 않은 자산을 압축하고, 동일한 이름과 형식을 유지함. 다양한 파일 확장자에 대해 각각의 압축 도구를 사용함.
그리고 더 많은 기능들!
-
jampack
은npx @divriots/jampack ./dist
명령어를 통해dist
폴더 내의 정적 웹사이트를 최적화할 수 있음.
jampack
이 사용된 사례
- ‹div›RIOTS' 웹사이트, keycloak.ch, bayjs.org 등 다양한 웹사이트에서
jampack
이 사용되고 있음.
jampack
이라는 이름의 유래
-
jam
: Jamstack에서 유래함. -
pack
: 90년대의 실행 파일 패커(Executable Packers)를 연상시킴.
라이선스
- 이 소프트웨어는 MIT 라이선스의 조건 하에 공개됨.
GN⁺의 의견
-
jampack
은 웹 성능 최적화에 관심이 많은 초급 소프트웨어 엔지니어들에게 유용한 도구가 될 수 있음. 특히 Core Web Vitals와 같은 성능 지표를 중요시하는 개발자들에게 도움이 될 것으로 보임. - 이 도구는 이미지 최적화뿐만 아니라 CSS와 자바스크립트 압축 등 다양한 웹 최적화 기능을 제공하여 페이지 로드 시간을 단축시키고 사용자 경험을 개선할 수 있음.
- 비판적인 시각에서 볼 때,
jampack
과 같은 도구의 사용은 웹사이트의 복잡성을 증가시킬 수 있으며, 잘못 사용하면 오히려 성능 문제를 야기할 수도 있음. 따라서 도구를 사용하기 전에 충분한 테스트와 검토가 필요함. - 웹 성능 최적화를 위해 이미 많은 도구들이 존재하는데, 예를 들어 Google의 Lighthouse나 WebPageTest와 같은 도구들이 있음. 이러한 도구들과 함께
jampack
을 사용하여 웹사이트의 성능을 종합적으로 분석하고 개선할 수 있음. -
jampack
을 도입할 때는 웹사이트의 구조와 사용하는 기술 스택을 고려하여 최적화 전략을 세워야 함. 또한, 오픈소스 도구를 사용함으로써 커뮤니티의 지원을 받을 수 있는 장점이 있지만, 프로젝트의 지속성과 유지 보수에 대한 책임도 고려해야 함.
Hacker News 의견
-
이 사용자는 자신이 찾던 것을 발견했다고 언급함. Sharp를 사용한 자체 스크립트로 이미지 최적화를 진행했었는데, Jampack을 사용한 후에는 그럴 필요가 없어졌다고 함. Quarto 정적 사이트를 빌드한 후 Jampack을 실행하니 폴더 크기가 32% 줄었고, 아직 눈에 띄는 단점은 없다고 함. PageSpeed Insights를 사용하여 Jampack 사용 전후의 성능 지표를 공유함.
-
모바일 성능 지표
- Jampack 사용 전: 성능 52, 접근성 73, 모범 사례 100, SEO 85
- Jampack 사용 후: 성능 49, 접근성 80, 모범 사례 100, SEO 92
-
데스크톱 성능 지표
- Jampack 사용 전: 성능 90, 접근성 75, 모범 사례 100, SEO 82
- Jampack 사용 후: 성능 85, 접근성 82, 모범 사례 100, SEO 91
-
모바일 성능 지표
-
다른 사용자는 이 기능이 Apache와 Nginx를 위한 PageSpeed 모듈을 떠올리게 한다고 언급함.
-
한 사용자는 Jampack이 마음에 들어 사용할 의향이 있으며, 비판적인 의견을 가진 사람들이 어떤 결점을 지적할 수 있는지 물어봄. 이 사용자는 Jampack이 C 코드를 최적화된 어셈블리로 컴파일하는 것과 같은 일을 하며, 개인적으로 하고 싶지 않은 작업을 수행한다고 생각함.
-
또 다른 사용자는 "중요한" CSS를 식별하고 인라인으로 처리하는 개념에 관심이 있음. 중요하지 않은 CSS를 식별하는 원칙적인 방법이 있기를 바랐지만, 사용된 라이브러리는 페이지를 렌더링하여 어떤 규칙이 중요한지 최선을 다해 감지하는 방식을 사용하는 것으로 보임.
-
한 사용자는 SSG 출력의 유니코드 범위에 따라 폰트를 부분적으로 선택하고, CSS에서 정의된 font-feature-settings에 따라 오픈타입 축을 고정하는 방법을 보고 싶어함.
-
Jampack이 매우 멋지다고 생각하는 사용자는 노드(Node.js)를 사용하는 것이 두려운 사람들을 위해 Docker 컨테이너를 만들어 사용을 단순화할 수 있는지 물어봄.
-
웹페이지 레이아웃을 싫어하고 배우기를 거부하지만 때때로 해야 하는 사용자는 Jampack이 훌륭해 보인다고 언급함.
-
실제 생산 환경에서 사용되는 정적 사이트 생성기에 대해 묻는 사용자가 있음. 이러한 도구를 사용하여 출력을 더 최적화할 수 있다고 생각함. 예를 들어, Divjoy React 웹사이트를 S3 버킷에서 제공할 수 있는 간단한 HTML로 변환하는 데 하루 종일 시도했지만 어려움을 겪고 있음. 자동으로 S3 버킷에 배포하고 도메인을 가리킬 수 있는 도구가 필요함.
-
Jampack이 SSG와 그 플러그인으로 처리하려는 여러 사용 사례를 커버하는 것처럼 보인다고 언급하는 사용자가 있음. Astro나 Eleventy를 선택하는 이유가 별도의 포스트-빌드 단계로 선호되는지 궁금해함. 개발 중 빠른 재빌드와 이미지의 너비 선언과 같은 것들을 도입함으로써 발생할 수 있는 미묘한 버그를 놓칠 가능성 사이의 트레이드오프가 있을 수 있음.
-
실제 예제를 이메일로 보내주는 사람들에게 감사함을 표현하는 사용자가 있음. 이러한 지원에 대해 매우 감사하다고 함.