요약
Next.js를 걷어 내고 Hono로 바꾸자 블로그가 Lighthouse 전 항목에서 100점을 받았습니다.
블로그 서비스 Bloffy를 만드는 1인 개발자의 경험담입니다. 기존 블로그 서비스가 무겁거나 쓰기 불편해서, 가볍고 빠르면서 접근성까지 갖춘 블로그를 직접 만들었다고 합니다.
왜 중요한가
- 서버 컴포넌트만 남겨도 Next.js가 늘 내려보내는 자바스크립트 때문에 정적 블로그가 만점에 닿지 못했다는 사례입니다.
- 작성자는 Next.js를 버리지 않았습니다. 상호작용이 많은 블로그 관리 앱에는 계속 쓰고, 정적 페이지에만 다른 도구를 골랐습니다.
핵심 내용
- 캐시와 이미지 최적화를 마친 Next.js 16.1.6 버전도 높은 점수를 받았지만 Lighthouse(웹 페이지 품질 측정 도구) 100점에는 닿지 못했습니다.
- 클라이언트 컴포넌트를 모두 없애도 App Router 런타임이 남았고, 이를 끌 공식 방법은 없었습니다.
- 커버리지 분석에서는 쓰이지 않는 자바스크립트가 230,460바이트 나왔습니다.
- JSX를 지원하고 옮기는 비용이 적은 Hono로 바꾸자 페이지가 자바스크립트를 전혀 보내지 않게 됐고 빌드 시간도 약 40% 줄었습니다.
- 첫 화면을 그리기 전의 긴 작업은 309.3ms에서 68.01ms로 약 78% 줄었습니다.
HN 반응
- 정적 블로그에는 애초에 Next.js가 필요 없었다는 지적이 많았고, 버셀의 마케팅이 이런 선택을 부추겼다는 비판도 나왔습니다.
- Next.js의 정적 내보내기를 쓰면 됐다는 반론에는, 그래도 큰 자바스크립트 묶음이 남으니 Astro 같은 정적 사이트 도구가 낫다는 재반론이 이어졌습니다.
실례지만 저는 이해가 안 됩니다. 정적 블로그에 Next.js가 필요했던 적은 한 번도 없었잖아요.
페라리 없이도 출퇴근할 수 있었고 버스를 타서 돈을 아꼈다는 글을 쓰는 것과 다를 게 없어요.
Next.js는 대부분의 애플리케이션에 어울리지 않습니다. 솔직히 처음부터 그랬어요. 그런데도 Vercel이 끈질기고 과장된 마케팅으로 주니어 개발자들에게 어울린다고 믿게 하려 해 왔죠.
Next.js는 완전한 정적 내보내기를 지원하니까 그 방법을 썼어야 합니다.
저는 nextjs 정적 내보내기로 동적 웹사이트를 운영하고 있습니다. 랜딩 페이지와 문서는 완전히 정적이고, 로그인과 사용자 대시보드는 nextjs가 아닌 백엔드에 REST 호출을 보냅니다. 엄청나게 빠르고, 운영 환경에는 nodejs도 SSR도 없습니다.
Next.js는 완전한 정적 내보내기를 지원하니까 그 방법을 썼어야 합니다.
불필요한 의존성을 과거의 이유로 계속 끌어안는 건 절대 좋은 선택이 아닙니다. 과감하게 걷어내세요. 소프트웨어가 더 나아질 겁니다.
불필요하다고는 못 하겠습니다. Next.js 정적 내보내기에는 동적 청크 분할, 링크에 마우스를 올리면 청크를 미리 불러오는 기능, 라우팅 같은 기능이 있습니다. 플러그인을 쓰면 이미지 최적화(뷰포트 크기에 맞춰 이미지 품질과 크기를 달리하는 것) 등도 됩니다.
하지만 맞습니다, 다른 정적 사이트 블로그 생성기를 써도 되긴 합니다.
그 기능들이 어떤 상황에서는 좋을 수도 있지만, 글쓴이의 블로그가 Lighthouse에서 100점을 못 받은 이유가 바로 그 기능들이기도 합니다.
picture 요소 [1], [2]는 미디어 선택자로 어떤 이미지를 쓸지 정할 수 있어서, 작은 기기나 뷰포트 방향 등에 따라 더 작은 이미지를 제공할 수 있습니다.
[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/picture
[2] https://caniuse.com/picture
좋긴 한데, 고해상도 이미지 하나를 그 모든 중단점 크기로 실제로 줄여 주지는 않잖아요. NextJS는 그걸 빌드 과정에서 해 줍니다.
제 경험상 Next.js는 여러 패러다임을 섞어 놓아서, 그중 어느 하나를 쓰더라도 더 복잡해지고 오류가 나기 쉽습니다.
솔루션을 만드는 개발자뿐 아니라 라이브러리와 패키지 저자도 마찬가지입니다.
Next 12 무렵에 문제를 많이 겪었고 Next 13은 버그투성이여서, Astro로 옮겨 간 뒤로는 한 번도 돌아보지 않았습니다.
정적 내보내기를 해도 대부분 불필요한 큰 JS 번들이 그대로 남습니다.
정적 사이트, 특히 블로그에서는 Astro가 next.js를 압도합니다.
자세히 설명하고, 그 터무니없는 주장을 사실로 뒷받침해 주시겠어요?
최적화된 순수 HTML 사이트가 쓸데없이 거대한 JS 번들이 붙은 사이트보다 정적 블로그에 낫다는 게 어째서 터무니없는 주장이죠?
터무니없는 주장 근처에도 못 갑니다.
이 바닥에 갓 들어온 사람들에게 잘못 가르친 원로들을 탓해야 한다고 생각합니다.
"정적 블로그에 무거운 SPA"는 드문 문제가 아니니까요.
제 초대형 SPA는 localhost에서 150ms에 로드됩니다. 물론 정적 블로그일 뿐이라면 60ms 정도까지 줄일 수 있을 겁니다.
문제는 코드 크기가 아닙니다. 불필요한 프레임워크의 복잡성이죠. 그런데 기업의 자바스크립트 개발자에게 이런 얘기를 하는 건, 자기 얼굴에 산(酸)을 끼얹는 것과 같습니다. 일을 해내는 게 얼마나 불가능한지 투덜대기 시작하니까요.
사람들이 localhost에서만 쓴다면 아주 좋겠네요.
네트워크를 거쳐도 300ms밖에 안 됩니다.
그러면 당신의 APS와 정적 웹사이트의 차이는 "꽤 빠르게 로드된다"와 "즉시 로드된다"의 차이라는 뜻이네요.
맞습니다만, 요점을 놓치고 있어요. 제 대형 SPA는 React 없이도 빠르고, React로 만든 정적 텍스트에 불과해 보이는 블로그보다 아마 더 빠를 겁니다. 물론 몇 문단짜리 정적 텍스트였다면 훨씬 빨랐겠죠. 하지만 그러면 원격 명령 셸 인터페이스나 리소스 사용량 그래프처럼 보여 줘야 할 콘텐츠를 하나도 보여 주지 못합니다.
일리 있는 말씀이지만 저는 그 점이 분명하게 와닿지 않았습니다.
위쪽 스레드에서 나온 요점은 사람들이 정적인 텍스트에 SPA를 쓴다는 것이었으니까요.
원로 탓이 아니라, 이해관계가 걸린 Vercel 자신 탓이에요.
젊은 소프트웨어 개발자들은 원로들 말을 안 듣죠. 자기들이 더 잘 안다고 생각하니까요.
대다수 웹사이트에는 Next.js도 React도 필요하지 않습니다. 그것들은 구조 안에서 동적이고 모듈식으로 갱신해야 하거나 상태 관리가 필요할 때만 쓸모가 있습니다. 우리는 이름값과 단순한 관성 때문에 React를 기본으로 삼아 왔습니다. 웹사이트 전반에 좋은 프레임워크가 아닙니다.
저는 그런 경우에도 React/Next.js가 필요하다고 확신하지 못하겠습니다. 웹 컴포넌트도 충분히 되고, LLM이 웹 컴포넌트를 아주 능숙하게 다루기 때문에 큰 프레임워크의 효용은 점점 줄어든다고 느낍니다.
웹 컴포넌트로 만든 솔루션은 어떤 것이든 아마 React만큼 커질 겁니다.
저는 컴파일 단계 없이 간단하고 빠르게 쓸 수 있는 웹 컴포넌트 솔루션을 원해서 Solarite를 만들었습니다.
https://eric-frost.github.io/solarite/
차이는 이벤트 모델과, React의 훅 기반 모델 대 순수 자바스크립트 방식의 상태 관리 복잡도에 있습니다. 웹 컴포넌트는 JS 콜백이 원래 동작하는 방식과 맞아떨어집니다. 콜백이 컴포넌트 함수를 가리키는 프레임워크는 React뿐입니다.
요즘은 React나 SolidJs, 그러니까 JSX라고 해야겠네요, 그런 걸로 작성해서 자바스크립트 없이 HTML만 나오게 변환할 수 있습니다.
XML/HTML보다 나은 언어를 쓰면서 HTML만 전달할 수 있으니 양쪽의 장점을 다 취하는 셈입니다. 사용자에게는 보통 그 모든 자바스크립트나 SPA 같은 게 필요 없으니까요. 아일랜드 아키텍처가 그런 겁니다.
괜찮은 절충안 같아요. 저한테는 좋은 DX, 사용자에게는 훌륭한 UX가 되고, 대부분 HTML에 자바스크립트를 조금 뿌리고 대비책도 갖춘 형태입니다.
이 의견이 왜 비추천을 받는지 모르겠습니다. 전적으로 맞는 말이고, LLM으로 코딩하는 시대에는 더 그렇거든요.