WEB Log

Lighthouse 100% 달성하기

Sat, 27 Jun 2026 01:13:32 GMT

Astro를 이용한 블로그를 만들기 시작한지도 엄청나게 오래 걸린듯합니다.

WordPress를 CMS로 이용하여 사이트를 관리하고 있으며, Astro로 구현하려고 노력 중입니다. 하지만 예상보다 쉽게 진행되지 않고 있습니다. 스크립트 사용을 최소화하고 CSS로 구현하려는 목표도 있지만, 모든 브라우저를 지원하지 않는 CSS 기능들이 많아서 도입을 망설이는 경우도 많았습니다. 이번 글에서는 이러한 과정 속에서 이루고 싶었던 목표 중 하나인 Lighthouse 100% 달성에 관해 이야기해보겠습니다.

성능

집에서 사용 중인 NAS에서 서비스를 제공하고 Cloudflare 터널로 연결을 구성했으나, 성능이 기대만큼 좋지 못했습니다. 100점을 받기는 거의 불가능했고, 집의 인터넷 상태가 양호할 때만 높은 점수가 나올 정도였기에 아쉬움이 컸습니다.

접근성

접근성은 언제나 최우선 과제였으나 쉽지 않은 부분이 많은거 같습니다.

Syntax Highlighter

Shikijs를 이용한 Syntax Highlighter는 언제나 텍스트 컬러 같은 부분이 대비 부족등으로 점수를 잃어버렸기 때문에 테마를 직접 구현하거나 사이트와 어울리지 않는 테마를 사용해야 하는 문제가 있어 지금은 어울리지 않는 테마를 사용하고 있고 언젠가 꼭 직접 사이트와 어울리는 테마로 구현해야 하는 과제를 가지고 있습니다.

CSS scroll-driven animations

scroll-timeline이나 position-anchor와 같은 CSS 속성의 발전으로 JavaScript의 도움 없이 페이지 스크롤 애니메이션 구현이 가능해졌습니다. 또한 기존에는 문맥을 유지하면서 배치할 수 없던 위치에 요소를 배치할 수 있게 되었습니다. 다만 아직 모든 브라우저가 완벽하게 지원하지 않아 깜빡임 등의 접근성 문제가 많이 발생하고 있어 아쉬움이 남습니다.

권장사항

개인 블로그이다 보니 특별히 강조할 개선 사항이 없습니다. Lighthouse에서 제시한 권장사항들이 이미 반영되어 있으며, 현재 상태에서 추가적인 최적화가 필요할지 미지수입니다.

검색엔진 최적화

사이트맵, JSON-LD 등 검색엔진 최적화를 위한 기능들을 가능한 한 모두 적용했습니다. 다만 개인 블로그의 특성상 대규모 트래픽을 기대하기 어렵고 현재 콘텐츠 양도 많지 않아, 이러한 기능들을 완비했다는 것 자체에 의의를 두고 있습니다.

llms.txt

AI 기술이 빠르게 발전하면서 새로운 기술들이 계속 등장하고 있습니다. 이에 발맞춰 루트 디렉토리에 llms.txt 파일을 생성하고 각 포스트에 대한 링크를 추가했습니다. 추가로 각 포스트 주소 뒤에 .md 확장자를 붙이면 마크다운 문서로 볼 수 있도록 기능도 구현했습니다. AI가 이 사이트를 크롤링하여 활용할지는 미지수이지만, 대비할 수 있는 기능을 미리 준비해두었습니다.

이 부분은 차후 다시 한번 글을 작성하는게 좋을꺼 같아 말을 아끼도록 하겠습니다.

2025-05-17

Mon, 27 Apr 2026 10:53:42 GMT

CSS 컬러 시스템: LAB, LCH, OKLAB, OKLCH

Wed, 08 Apr 2026 11:45:08 GMT

LAB vs LCH

둘 다 지각적으로 균일한(perceptually uniform) 색공간이라는 공통점이 있습니다. 사람 눈이 색을 인식하는 방식을 수학적으로 모델링한 것입니다.

차이는 좌표계입니다.

LAB는 직교 좌표계입니다.

L — 밝기 (0=검정, 100=흰색)
A — 초록↔빨강 축
B — 파랑↔노랑 축

LCH는 원통 좌표계로, LAB를 극좌표로 변환한 것입니다.

L — 밝기 (동일)
C — 채도(Chroma). 원점에서의 거리
H — 색상(Hue). 각도 0°~360°

css

/* 같은 색을 표현하는 두 방식 */
color: lab(55% -30 40);
color: lch(55% 50 127deg); /* C = √(a²+b²), H = atan2(b,a) */

LCH가 실용적으로 훨씬 쓰기 편합니다. Hue 값을 직접 조작하는 것이 직관적이고, hsl()에 익숙하다면 자연스럽게 넘어올 수 있습니다.

OK가 붙으면?

LAB/LCH는 1976년 CIE 표준인데, 두 가지 알려진 결함이 있었습니다.

1. 파란색 영역의 Hue 왜곡

채도가 높은 파란색에서 C(채도)를 올리면 Hue가 보라 쪽으로 밀립니다. 색상이 변하지 않아야 하는데 실제로는 바뀌어 보이는 문제가 있습니다.

2. 밝기 예측 불일치

특히 보라~파랑 영역에서 L 값이 같아도 눈에 다르게 밝아 보이는 경우가 발생합니다.

Björn Ottosson이 2020년에 이 두 문제를 개선해서 발표한 것이 OKLab / OKLCH입니다.

css

/* 스케일이 다름에 주의 */
lab(55% -30 40)       /* L: 0–100 */
oklab(0.55 -0.1 0.15) /* L: 0–1, a/b 범위도 다름 */

lch(55% 50 127deg)
oklch(0.55 0.2 127deg) /* L: 0–1, C 범위 대략 0–0.4 */

핵심 개선점은 채도를 높여도 Hue가 흔들리지 않는다는 것입니다. 디자인 시스템에서 팔레트를 프로그래밍으로 생성할 때 특히 체감됩니다.

안의

사용에 관하여

Tue, 07 Apr 2026 11:55:17 GMT

사이트를 문서화하던 중 <header> 안에 <h1>이 사용된 구조를 마주쳤습니다. 이어서 콘텐츠 영역인 <section> 안에서도 <h1>으로 헤딩이 시작되고 있었는데, 이 패턴이 과연 올바른 것인지 짚어볼 필요가 있었습니다.

<section> 안에 <h1>을 사용하는 패턴은 HTML5 초기부터 꽤 흔하게 쓰여왔습니다. 섹셔닝 요소마다 독립적인 헤딩 계층을 갖는다는 아웃라인 알고리즘의 개념이 있었고, 실제로 브라우저가 section > h1을 h2처럼 렌더링해줬기 때문에 마크업 구조로서 그럴듯해 보이기도 했습니다.

그러나 이 패턴은 처음부터 문제가 있었습니다. 아웃라인 알고리즘은 명세에만 존재했을 뿐, 브라우저와 스크린리더 어디에도 실제로 구현된 적이 없었습니다. 시각적 렌더링은 단순히 UA 스타일시트의 CSS 규칙 덕분이었고, 접근성 트리에는 전혀 반영되지 않아 스크린리더 사용자에게는 모든 h1이 동등한 최상위 헤딩으로 읽혔습니다.

2022년 HTML 명세에서 아웃라인 알고리즘이 공식 삭제됐고, 2025년부터는 브라우저들이 관련 UA 스타일까지 제거하기 시작했습니다. Chrome 136과 Firefox 138을 기점으로 <section> 안의 <h1>은 Lighthouse 경고 대상이 됐으며, 머지않아 모든 주요 브라우저에서 동일하게 적용될 예정입니다.

이 글에서는 변경 사항의 배경과 영향, 그리고 올바른 헤딩 구조 작성법을 정리합니다.

1. 배경

HTML5에서 아웃라인 알고리즘(Outline Algorithm) 이 도입되면서, <section> 등 섹셔닝 요소 안에 중첩된 <h1>은 깊이에 따라 자동으로 h2, h3처럼 렌더링됐습니다.

브라우저 UA 스타일시트에 다음과 같은 규칙이 적용되고 있었고, 이 때문에 <section> 안에 <h1>을 써도 시각적으로는 계층이 있어 보였습니다.

/* x = article, aside, nav, section */
x h1         { font-size: 1.50em; }  /* h2처럼 */
x x h1       { font-size: 1.17em; }  /* h3처럼 */
x x x h1     { font-size: 1.00em; }  /* h4처럼 */
x x x x h1  { font-size: 0.83em; }  /* h5처럼 */

2. 무엇이 달라졌나?

아웃라인 알고리즘 폐기 (2022)

HTML 명세에서 아웃라인 알고리즘이 공식 제거됨
브라우저와 스크린리더 모두 이 알고리즘을 실제로 구현한 적이 없었음
접근성 트리(Accessibility Tree)에는 암묵적 헤딩 레벨이 반영되지 않아 스크린리더 혼란 유발

UA 스타일 제거 (2025~)

아웃라인 알고리즘이 명세에서 제거됐음에도 남아있던 UA 스타일이 이제 브라우저에서도 제거되기 시작했습니다.

브라우저	대응 내용
Chrome 136+	`<section>` 안 `<h1>`에 `font-size` 미지정 시 DevTools deprecated 경고 + Lighthouse 점수 하락
Firefox 138+	Beta부터 단계적 UA 스타일 제거 시작, Firefox 140에서 전체 적용 예정
Safari	구현 진행 중 (WebKit bug 292765)

3. 영향

UA 스타일 제거 이후, <section> 안의 <h1>은 모두 동일한 크기로 렌더링됩니다.

[이전] section > h1 → h2 크기로 축소되어 보임
[이후] section > h1 → 최상위 h1과 동일한 크기로 렌더링

즉, 기존에 UA 스타일에 의존해 시각적 계층을 표현하던 사이트는 레이아웃이 깨질 수 있습니다.

4. 권장 대응

명시적 헤딩 계층 사용

<!-- 권장 -->
<h1>페이지 제목</h1>
<section>
  <h2>섹션 제목</h2>
  <h3>서브 항목</h3>
</section>

<!-- 지양 -->
<h1>페이지 제목</h1>
<section>
  <h1>섹션 제목</h1>  ← deprecated
</section>

`h1` 스타일 명시적 선언

UA 스타일에 의존하지 않고, CSS reset 또는 전역 스타일에 직접 지정합니다.

h1 {
  margin-block: 0.67em;
  font-size: 2em;
}

/* specificity 충돌 방지가 필요한 경우 :where() 활용 */
:where(h1) {
  margin-block: 0.67em;
  font-size: 2em;
}

Lighthouse / DevTools 점검

PageSpeed Insights 에서 H1UserAgentFontSizeInSection 경고 여부 확인
Chrome DevTools 콘솔에서 deprecated 경고 확인

5. 정리

상황	결과
`section` 안 `h1`, 스타일 미지정	Lighthouse 경고 + 브라우저 경고 발생
`section` 안 `h1`, `font-size` 직접 지정	경고는 피하지만 접근성·의미론 문제 잔존
`section` 안 `h2`~`h6` 사용	권장 패턴, 문제 없음

결론: <section> 안에서는 <h2>부터 시작하는 명시적 헤딩 계층을 사용하고, <h1>의 font-size와 margin은 CSS에서 직접 선언한다.

참고: MDN Blog – Default styles for h1 elements are changing (2025.04.11)

CSS @container — Optional Query Conditio

Wed, 01 Apr 2026 05:40:23 GMT

기존에는 @container 규칙을 쓸 때 조건(query)이 필수라고 인식하는 경우가 많았지만, 스펙 상 <container-name>과 <container-query> 중 하나 이상만 있으면 됩니다.

즉, 쿼리 조건 없이 컨테이너 이름만으로도 @container 블록을 선언할 수 있습니다.

문법 구조

@container [<container-name>]? [<container-query>]? { ... }

형태	예시	의미
조건만	`@container (width > 400px)`	가장 가까운 컨테이너의 크기 조건
이름 + 조건	`@container sidebar (width > 400px)`	sidebar 컨테이너의 크기 조건
이름만	`@container sidebar`	sidebar 컨테이너 안에 있을 때
조건 리스트	`@container (조건A), style(--x: y)`	여러 조건 중 하나라도 참이면

예시 코드

기본 — 이름만으로 스코핑

/* 컨테이너 선언 */
header   { container: header  / inline-size; }
.sidebar { container: sidebar / inline-size; }
main     { container: main    / inline-size; }
footer   { container: footer  / inline-size; }

/* 이름만으로 스코핑 — 크기 조건 없이 컨텍스트만으로 분기 */
@container sidebar {
  .card { font-size: .875rem; flex-direction: column; }
}

@container main {
  .card { font-size: 1rem; display: grid; }
}

@container footer {
  .card { display: none; }
}

이름 + 크기 조건 조합

/* sidebar 안에서 + 너비 조건 추가 */
@container sidebar (width > 240px) {
  .card { flex-direction: row; }
}

/* main 안에서 + 너비 조건 추가 */
@container main (width > 600px) {
  .card { grid-template-columns: repeat(3, 1fr); }
}

조건 리스트 (OR 동작)

/* 쉼표로 구분 — 하나라도 true면 적용 */
@container card (width > 400px), style(--responsive: true), scroll-state(stuck: top) {
  h2 { font-size: 1.5em; }
}

왜 유용한가?

컴포넌트 재사용 — “컨텍스트 네임스페이스”

같은 .card 컴포넌트 하나를 만들어두면, 어느 컨테이너 안에 놓이느냐에 따라 자동으로 다른 스타일이 적용됩니다.

/* before — 영역별로 클래스를 따로 만들어야 했음 */
  .sidebar__card { ... }
  .main__card    { ... }
  .footer__card  { ... }

/* after — 컴포넌트 하나 + @container 이름 스코핑 */
  .card { ... }  /* 하나만 */
  @container sidebar { .card { ... } }
  @container main    { .card { ... } }

크기를 몰라도 되는 경우

너비/높이 조건 없이 “이 레이아웃 영역 안에 있다”는 사실 자체만으로 스타일을 분기해야 할 때 유용합니다.

예: sidebar는 항상 compact, footer는 항상 숨김 등

브라우저 지원

/* 지원 여부 확인 후 적용 */
@supports (container-type: inline-size) {
  header { container: header / inline-size; }
}

MDN 참고 예시

/* With a <size-query> */
@container (width > 400px) { h2 { font-size: 1.5em; } }

/* With an optional <container-name> */
@container tall (height > 30rem) { p { line-height: 1.6; } }

/* With a <container-name> only (query is optional) */
@container sidebar { h2 { background: blue; } }

/* With a <scroll-state> */
@container scroll-state(scrollable: top) {
  .back-to-top-link { visibility: visible; }
}

/* Multiple queries in a single condition */
@container (width > 400px) and style(--responsive: true) {
  h2 { font-size: 1.5em; }
}

/* Condition list */
@container card (width > 400px), style(--responsive: true), scroll-state(stuck: top) {
  h2 { font-size: 1.5em; }
}