Lobsters

This is a modern motherfucking website

이것이 현대적인 웹사이트입니다

이 글은 블로그·문서·홍보 페이지에 프레임워크와 대규모 도구 체인을 얹기보다 HTML과 CSS의 기본 기능부터 쓰자고 주장합니다. 시맨틱 태그, 메타데이터, 리소스 힌트, 반응형 이미지 등 브라우저가 이미 제공하는 기능을 사례로 들며, 필요한 만큼만 도구를 더하자고 권합니다.

AI 요약

이 글은 단락 하나를 화면에 표시하는 데 Node.js, 패키지 관리자, 수많은 의존성, 번들러, 트랜스파일러, 메타 프레임워크와 하이드레이션까지 동원하는 웹 개발 관행을 비판합니다. 블로그나 문서처럼 본질이 문서인 사이트라면 HTML에 이미 있는 기능을 먼저 쓰고, 실제로 필요한 경우에만 도구를 추가하자는 주장입니다.

브라우저에 이미 있는 기능

접근성을 위해 별도 라이브러리를 설치하기 전에 <nav>, <main>, <article>, <footer> 같은 시맨틱 요소를 쓰라고 제안합니다. 이 요소들은 문서 구조와 랜드마크를 제공하며, 스크린 리더와 검색 엔진이 콘텐츠를 파악하는 데 도움을 줍니다. 간단한 아코디언에는 키보드 조작과 스크린 리더 지원을 갖춘 <details>를 쓰고, <dialog>, popover, 날짜 입력, 기본 폼 검증도 브라우저 기능으로 처리할 수 있다고 설명합니다. Gecko, Blink, WebKit이 이런 기능을 구현하는 주요 브라우저 엔진입니다.

검색 엔진용 구조화 데이터는 schema.org 유형에 맞춘 JSON-LD를 <script type="application/ld+json"> 안에 직접 작성하면 된다고 합니다. 소셜 미디어 링크 미리보기에는 Open Graph 메타 태그와 Twitter 카드 태그를 사용합니다. 이 정보가 처음부터 HTML에 들어 있으면 크롤러가 JavaScript 실행을 기다리지 않아도 됩니다. 글은 클라이언트 렌더링 SPA가 메타데이터를 나중에 삽입하면 크롤러가 이를 놓칠 수 있고, 그 문제를 해결하려고 서버 사이드 렌더링을 추가하는 상황도 지적합니다.

성능과 이미지도 HTML에서 지정

외부 연결을 미리 여는 <link rel="preconnect">, DNS 조회를 미리 하는 <link rel="dns-prefetch">, 글꼴을 미리 가져오는 preload를 소개합니다. 주요 이미지에는 fetchpriority="high"를, 중요하지 않은 이미지에는 loading="lazy"와 decoding="async"를 지정할 수 있습니다. 다만 preload를 남용하면 우선순위가 흐려지므로 실제로 중요한 리소스만 지정해야 한다고 경고합니다.

페이지 이동을 빠르게 보이게 하려고 클라이언트 라우터를 도입하는 대신, 지원 브라우저에서 다음 페이지를 미리 렌더링하는 speculation rules를 활용할 수 있다고 제안합니다. CSS의 View Transitions 기능을 함께 쓰면 여러 페이지로 구성된 사이트에서도 화면 전환 효과를 적용할 수 있습니다. 지원하지 않는 브라우저는 해당 기능을 무시하므로 뒤로 가기 동작을 깨뜨리지 않는다는 설명입니다.

이미지는 <picture>와 <source>로 AVIF, WebP, JPEG 후보를 제공하면 브라우저가 지원 형식과 화면 크기에 맞는 파일을 고른다고 설명합니다. <img>에 너비와 높이를 지정하면 표시 공간을 미리 확보해 레이아웃 이동을 줄입니다. AVIF와 WebP 파일을 만드는 작업도 이미지 추가 시 명령 한 번 실행하는 정도라면 전체 빌드 시스템을 도입할 이유가 되지 않는다고 주장합니다.

문서 사이트와 애플리케이션을 구분

글에서 소개한 페이지는 Open Graph 이미지와 WCAG 배지를 제외하면 약 23KB짜리 HTML 파일 하나로 구성되며, 의존성이나 쿠키 배너, 하이드레이션 오류가 없다고 밝힙니다. 배포 역시 파일을 서비스 디렉터리에 복사하는 방식이라고 설명합니다. 여러 페이지에 공통 헤더를 넣어야 한다면 정적 사이트 생성기나 서버 사이드 인클루드를 쓰면 됩니다. 다만 방문자 기기에 큰 런타임을 내려보내 헤더를 조립할 필요는 없다고 선을 긋습니다.

스프레드시트, 동영상 편집기, 디자인 도구처럼 실제 애플리케이션을 만든다면 애플리케이션 프레임워크를 쓰는 편이 맞다고 인정합니다. 반면 홍보 사이트, 블로그, 문서, 식당 메뉴는 문서에 가깝다고 구분합니다. 글의 방법론은 HTML에서 시작하고, 필요한 기능을 더한 뒤 작업이 끝나면 멈추는 것입니다. 도구를 쓰지 말자는 뜻이 아니라, 각 바이트가 필요한 이유를 알고 추가하자는 주장입니다.

Lobsters 반응

  • @technomancy — 거의 완벽합니다. 원래 글은 CSS가 전혀 없으니 텍스트가 화면 전체 너비를 차지해도 봐줄 수 있었습니다. 하지만 이 글은 그런 변명을 할 수 없습니다. max-width를 지정하세요. 읽기 편해집니다.

원문: Lobsters / 번역·요약: Trawling