Next.js 정적 블로그에도 JavaScript가 남는 이유

HTML을 미리 만들어도 브라우저의 일은 남는다

정적 export는 JavaScript 제거 옵션이 아니다. Next.js 공식 문서는 output: 'export'로 빌드하면 HTML·CSS·JS 자산을 만든다고 설명한다. App Router의 서버 컴포넌트는 빌드 때 실행되지만, 결과에는 첫 화면의 HTML뿐 아니라 페이지 사이를 이동할 때 사용할 데이터도 포함된다.

여기에 검색창이나 메뉴처럼 상호작용하는 클라이언트 컴포넌트가 있으면 브라우저에서 동작할 코드가 필요하다. 하이드레이션은 미리 받은 HTML에 이런 동작을 연결하는 과정이다. 서버에서 매 요청마다 HTML을 생성하지 않는다는 것과 브라우저가 실행할 코드가 없다는 것은 서로 다른 조건이다.

Hono로 옮긴 이유는 블로그에 필요한 기능이 적었기 때문이다

10월 26일 Hacker News에 등장한 Bloffy 개발자의 경험담은 이 차이를 보여 준다. 개발자는 상호작용이 거의 없는 글 페이지에서 클라이언트 런타임을 덜어내는 방향을 택했다.

결국 JSX를 사용할 수 있는 Hono로 옮겼고 Lighthouse 네 부문에서 100점을 얻었다고 보고했다. 핵심 선택은 ‘100점이 가능한 프레임워크’를 찾는 것보다 앞으로도 필요하지 않을 기능의 비용을 덜어내는 데 있었다.

먼저 클라이언트 경계와 스크립트 적용 범위를 좁힌다

기존 Next.js 프로젝트에도 코드 부담을 줄일 선택이 있다. 공식 컴포넌트 안내는 큰 UI 전체보다 상호작용이 필요한 파일에 'use client'를 붙이도록 권한다. 예를 들어 검색창만 클라이언트 컴포넌트로 두고 주변 레이아웃은 서버 컴포넌트로 남길 수 있다.

Next.js 스크립트 가이드에서 루트 레이아웃의 스크립트는 모든 경로에 적용된다. 특정 화면에만 필요하다면 그 범위를 좁힐 수 있다. lazyOnload는 브라우저가 한가할 때 늦게 읽는 선택이지, 코드를 없애는 기능은 아니다.

최종 HTML에서 스크립트 태그를 일괄 삭제하는 것은 기능 보존을 확인한 최적화와 다르다. 검색창·메뉴·페이지 이동처럼 필요한 동작을 남긴 상태로 크기를 줄여야, 글을 빠르게 보여 주면서도 사이트를 계속 사용할 수 있다.

읽는 페이지와 조작하는 영역을 나눌 수 있다

글이 대부분이고 일부 위젯만 움직인다면 Astro의 아일랜드 구조도 비교 대상이다. 기본 UI를 HTML과 CSS로 렌더링하고, 상호작용이 필요한 컴포넌트에 client:* 지시자를 붙여 JavaScript를 보낸다. 예를 들어 화면 아래의 무거운 위젯을 client:visible로 표시될 때 불러올 수 있다.

어떤 구조든 외부 스크립트나 위젯을 추가하면 실제 페이지가 보내는 코드는 달라진다. Lighthouse 문서도 장치·광고·네트워크·브라우저 확장에 따라 점수가 흔들린다고 설명한다.

먼저 글 페이지에 필요한 상호작용을 적고, 코드 범위를 줄인 버전을 같은 장치와 조건에서 비교하는 편이 낫다. 남는 기능이 적고 현재 런타임을 유지할 이유도 작다면, 그때 HTML 중심 구조로 옮기는 비용을 검토할 수 있다.