Removing Next.js Got My Blog to 100 on Every Lighthouse Category
Next.js를 제거하자 블로그의 Lighthouse 점수가 모든 항목에서 100점이 됐습니다
정적 블로그에서 Next.js 런타임이 불필요한 JavaScript와 긴 작업을 만든다고 보고 Hono로 옮긴 과정입니다. 글쓴이는 Lighthouse 점수 100점, 빌드 시간 약 40% 단축을 확인했지만 댓글에서는 Next.js의 정적 내보내기와 다른 정적 사이트 생성기도 대안으로 거론됩니다.
- 주제
에디터 노트
정적 블로그에 Next.js가 필수였는지가 이 글의 실제 쟁점입니다. 글쓴이는 사용하지 않는 JavaScript 230,460바이트와 긴 작업 시간 309.3ms를 확인한 뒤 Hono로 옮겼고, 같은 페이지에서 각각 407바이트와 68.01ms를 기록했습니다. 정적 페이지에서 프레임워크 런타임이 성능 비용이 됐다는 근거는 구체적입니다. 다만 Lighthouse 100점이 Next.js를 쓸 수 없다는 뜻은 아닙니다. 댓글에는 Next.js의 정적 내보내기로 100점을 받은 사례가 있고, 동적 청크와 미리 불러오기 같은 기능도 언급됩니다. 글쓴이도 상호작용이 많은 관리 앱에는 Next.js를 계속 씁니다. 따라서 이 사례가 보여주는 건 프레임워크의 보편적 한계라기보다 정적 블로그에 필요한 기능과 실제로 포함된 런타임 사이의 불일치입니다. Hugo, Astro, Zola 등 대안을 두고 선택하는 댓글도 성능만큼 운영 방식과 개발 경험이 결정 기준임을 드러냅니다.
AI 요약
글쓴이는 가볍고 빠르며 여러 블로그를 운영하고 접근성도 갖춘 서비스를 만들려다 직접 블로깅 플랫폼을 개발했습니다. 성능 측정은 pagespeed.web.dev에서 진행했습니다. Vercel의 편리함에도 Pro 요금, 서버리스 콜드 스타트, 생태계 종속성이 부담이었고 Cloudflare CDN을 쓰기로 하면서 정적 사이트에는 Next.js의 캐시가 필요하지 않다고 판단했습니다. 게시할 때 Next.js 캐시와 CDN 캐시를 모두 무효화해야 하는 점도 관리 부담으로 들었습니다. 이미지 처리는 Cloudflare Image Transformations를 사용했습니다.
Next.js 제거와 측정 결과
사용한 Next.js 버전은 16.1.6입니다. 페이지는 ISR로 미리 생성했고 상호작용도 없었지만 Lighthouse는 프레임워크가 제공하는 레거시 JavaScript를 지적했습니다. 클라이언트 컴포넌트를 모두 제거해도 점수는 달라지지 않았습니다. 글쓴이는 next/link와 next/image가 클라이언트 컴포넌트이며, App Router의 라우터와 오류 경계도 런타임에 남는다고 설명합니다. 렌더링된 HTML에서 스크립트를 제거하는 우회까지 검토한 뒤 Next.js를 걷어내고 Hono로 옮겼습니다.
이후 해당 페이지의 JavaScript는 사라졌고 사용되지 않는 코드는 230,460바이트에서 407바이트로 줄었습니다. 빌드 시간은 약 40% 감소했고, 화면에 표시되기 전 실행되는 긴 작업은 309.3ms에서 68.01ms로 약 78% 줄었습니다. Lighthouse SEO 점수는 69점인데 검색 색인을 의도적으로 차단한 테스트 사이트이기 때문이라고 덧붙입니다. 글쓴이는 정적 사이트에는 JavaScript가 필요하지 않은 경우가 많다고 주장하면서도, 상호작용이 많은 관리 앱에는 Next.js가 적합하다며 자기 블로그의 관리 앱도 Next.js로 만들었다고 설명합니다.
Hacker News 반응
- @SwellJoe — Hugo를 GitHub Pages에 올려 블로그를 운영합니다. 성능을 따로 고민한 적이 없는데도 Lighthouse에서 100점을 받았습니다. 정적 HTML 블로그를 쓰면 성능 문제 한 종류가 사라집니다.
- @mceachen — Hugo Pipes를 사용하면 큰 이미지에 필요한 srcset을 자동으로 만들 수 있습니다. 같은 이미지를 여러 너비로 생성하고 브라우저가 화면 크기와 픽셀 밀도에 맞는 파일을 고릅니다.
- @sampli — Next.js도 제대로 사용하면 Lighthouse 100점을 받을 수 있습니다. 도구는 복잡성을 더할 수도 있지만 성능을 잘 다듬을 수도 있습니다.
- @tkzed49 — Next.js 정적 생성 블로그에서 쉽게 100점을 받고 거의 즉시 로드됩니다.
- @altmanaltman — Next.js를 사용한 웹사이트도 다듬기를 계속하면 Lighthouse 100점을 받을 수 있습니다.
- @pigbearpig — 정적 블로그에 Next.js가 필요하지 않았다는 이야기로 들립니다. 출퇴근에 페라리를 쓰지 않아 돈을 아꼈다는 말과 비슷합니다.
- @littlecranky67 — Next.js는 완전한 정적 내보내기를 지원합니다. 동적 청크 분할, 링크에 마우스를 올렸을 때 청크를 미리 불러오는 기능, 라우팅도 제공합니다. 플러그인을 쓰면 화면 크기에 맞춘 이미지 최적화도 가능합니다.
- @ogou — 대부분의 웹사이트에는 Next.js나 React가 필요하지 않습니다. 동적 업데이트나 상태 관리가 필요한 경우에 유용하지만 이름값과 관성 때문에 기본 선택이 됐습니다.
- @aftbit — 요즘 블로그에 가장 좋은 정적 사이트 생성기는 무엇인가요?
- @dotnetcarpenter — Astro입니다.
- @danpalmer — Hugo를 씁니다. 단순하고 기능이 충분하며 문서가 좋고 LLM도 잘 이해합니다. Node 기반 생성기를 쓸 때는 업데이트마다 깨지고 의존성도 많았습니다.
- @esperent — 블로그에는 Astro의 서버 아일랜드 기능이 과도합니다. 에이전트 코딩 시대에는 백엔드와 라우터, Markdown 생성기만으로도 충분합니다.
- @woutr_be — 서버 아일랜드는 선택 기능입니다. 간단한 블로그라면 컬렉션과 일반 HTML, CSS만 쓰면 됩니다.
- @4pkjai — HTML과 바닐라 JavaScript로 만든 CRUD 앱이 다른 웹사이트보다 훨씬 빨리 로드됩니다.
- @smt88 — 빠른 개발 경험을 유지하면서 성능도 지키는 방법이 쟁점입니다. AI가 프레임워크 없이 바닐라 웹페이지를 빠르게 만들면서 그 질문은 덜 중요해졌습니다.
- @LoganDark — 페이지를 충분히 빨리 만들 수 있다면 캐시는 필수가 아닙니다. 거리 같은 요인으로 CDN이 필요할 때는 예외입니다.
- @reassess_blind — 에이전트가 개발을 맡으면서 편리한 기본 기능을 제공하던 대형 프레임워크의 장점이 줄고, 큰 코드베이스의 취약점 부담은 커질 수 있다고 봅니다.
- @Exoristos — 기술 인플루언서들은 자기 분야의 무능함을 공개하는 데 지치지 않는 것 같습니다.
원문: Hacker News / 번역·요약: Trawling