정적 페이지에서 어떤 UI만 자바스크립트로 살릴까?

아일랜드 아키텍처는 페이지 대부분을 서버 렌더링 HTML로 제공하고, 상호작용이나 개인화가 필요한 부분만 작은 클라이언트 컴포넌트로 수화(hydrate)하는 접근입니다. “아일랜드”라는 용어는 Etsy의 Katie Sylor-Miller가 2019년에 만들었고 Jason Miller가 2020년 글에서 설명을 확장했습니다. Astro 아일랜드 개념 문서, Jason Miller 원문

페이지를 나눌 때의 판단

  • 1. 자바스크립트 없이도 의미가 전달되는 콘텐츠와 탐색을 HTML로 남깁니다. 기사 본문, 제목, 기본 링크는 초기 HTML에서 읽을 수 있어야 합니다.
  • 2. 브라우저 동작이 필요한 위젯만 섬으로 선택합니다. 예를 들어 검색 자동완성은 상호작용이 필요하지만, 정적 목차나 작성자 정보는 보통 서버 렌더링으로 충분합니다.
  • 3. 각 위젯이 언제 로드되어야 하는지 정합니다. Astro의 client:load는 페이지 로드 때, client:idle은 브라우저가 한가할 때, client:visible은 화면에 나타날 때 로드하도록 설정합니다. 즉시 필요한 구매·내비게이션 기능과 아래쪽 보조 위젯을 같은 우선순위로 두지 마세요.
  • 4. 독립 섬 사이 데이터 공유와 상호작용을 점검합니다. 컴포넌트가 나뉘어도 로그인 상태나 장바구니 상태를 공유해야 할 수 있습니다. 섬 개수가 늘면 별도 번들·통신·상태 연결도 늘 수 있습니다.

예: 기사 페이지와 댓글 창

긴 기사를 빌드 시 정적 HTML로 제공하고, 댓글 입력·정렬 UI만 인터랙티브 컴포넌트로 둔다고 가정합니다. 화면 상단의 기사는 스크립트 로딩 전에도 읽을 수 있어야 합니다. 댓글은 사용자가 아래로 이동하면 client:visible 같은 지연 로딩을 고려할 수 있지만, 접근성·검색 가능성·댓글 표시 정책을 함께 확인해야 합니다. 페이지의 실제 응답 바이트, 자바스크립트 실행 시간, 상호작용 지연을 측정해 이 구성이 유리한지 검증합니다.

SSG와 성능은 별개로 점검

정적 사이트 생성(SSG)은 빌드 때 HTML을 만들어 배포하는 방식이고, 아일랜드는 그 HTML 안에서 클라이언트 상호작용을 나누는 방식입니다. 함께 쓸 수 있지만 같은 개념은 아닙니다. 정적 HTML의 양, 이미지, CSS, 위젯 코드, 서버 개인화 방식에 따라 체감 성능이 달라집니다. 아일랜드가 자동으로 빠른 점수나 더 나은 접근성을 보장하지는 않습니다. 키보드·스크린리더 동작과 JavaScript 비활성 상태도 시험하세요.

출처