prefetch는 내려받기만 하고, prerender는 내려받은 뒤 렌더링까지 시작한다.

Tachyon은 <a>에 커서가 50ms 이상 머물면 <link rel="prerender">를 넣어주는 라이브러리.

#performance#tachyon#prefetch#prerender
#268

대용량 리스트에서 selected 아이템 조회 최적화

O(n×m) → O(n+m)로 개선: Map으로 인덱싱

// 기존: 매번 find (느림)
selected.map((key) => items.find((item) => item.key === key))

// 개선: Map 인덱싱 (빠름)
const itemsMap = new Map(items.map((item) => [item.key, item]))
selected.map((key) => itemsMap.get(key)).filter(Boolean)

React에서 백그라운드 인덱싱:

function useItemsIndex(items: Item[]) {
  const [map, setMap] = useState(new Map())
  const [ready, setReady] = useState(false)

  useEffect(() => {
    // 청크 단위로 처리하여 UI 블로킹 방지
    const newMap = new Map(items.map((item) => [item.key, item]))
    setMap(newMap)
    setReady(true)
  }, [items])

  return { map, ready }
}

10만개 이상이면 Web Worker 고려.

#react#performance#indexing
#508

WeakMap의 키를 “입력 배열의 참조 자체”로 쓰면 캐시 무효화 로직이 0줄이 된다 — 무효화를 참조 동등성에 위임.

언제: 같은 배열을 이름 같은 키로 반복 조회해서 O(n) 스캔이 계속 도는데, 그 배열이 언제 바뀌는지 추적하기는 싫을 때.

절차

const indexCache = new WeakMap<Item[], Map<string, string>>()

// name → id 역인덱스를 1회 빌드 (O(n))
const buildIndex = (items: Item[]) =>
  new Map(items.map((it) => [it.name, it.id]))

function lookup(items: Item[], name: string): string | null {
  let index = indexCache.get(items)
  if (!index) {
    index = buildIndex(items) // 캐시 미스일 때만 빌드
    indexCache.set(items, index)
  }
  return index.get(name) ?? null
}

확인: 같은 배열 참조로 두 번 부른다. buildIndex가 한 번만 돌면 된 것이다.

함정: 호출 측 items 참조가 stable해야 작동한다. 매번 [...data]·data.filter()로 새 배열을 넘기면 항상 miss라 무의미하다. (TanStack Query의 data/select 결과는 참조 안정성을 보장하므로 그대로 넘기면 OK)

왜 되는가

  • 같은 참조로 재호출 → cache hit, O(1)
  • 데이터가 새 참조로 교체(refetch 등) → 자동 miss → 새 index 빌드. 옛 index는 옛 items와 함께 GC 대상
  • 키가 weak reference라 items가 어디서도 안 잡히면 entry도 같이 사라짐. 일반 Map이면 참조가 영구히 붙들려 메모리 누수

참고

#weakmap#cache-invalidation#referential-equality#garbage-collection#reference-as-cache-key#memoization#typescript#react-query#performance
#546

blocking=render 는 <body> 전에만 등록된다 — 뒤에 붙으면 조용한 no-op

파서를 멈추는 것과 paint를 멈추는 것은 다르다. 동기 <script>는 파서만 세운다. 그 위에 이미 파싱된 청크가 먼저 그려질지는 브라우저 재량이라, default 상태가 한 프레임 노출되지 않는다는 보장이 없다. blocking="render"가 그 보장을 명시적으로 만든다.

언제: 새로고침하면 한 프레임 동안 다른 화면이 보일 때. 먼저 원인을 판별한다.

증상 원인 처방
스타일이 붙기 전 default 상태가 한 프레임 보인다 스타일 적용이 첫 페인트보다 늦다 blocking="render" — 아래 절차
다크 테마인데 흰 화면이 번쩍인다 서버가 사용자 상태를 몰라 기본값으로 렌더했다 첫 페인트 전 인라인 스크립트 → 594 R2

뒤쪽은 이 축으로 안 고쳐진다 — 서버가 낸 HTML 자체가 이미 다른 값이라 렌더를 막아도 그 값이 그대로 보인다.

절차

  1. blocking="render"를 붙인다.
  2. <body>가 열리기 전에 둔다. 컴포넌트 마크업 안이면 이미 늦다.

확인: 마크업에서 위치를 본다 — <body>보다 앞인가. 화면으로는 구분이 안 된다(아래).

함정: <body>가 생기는 순간 등록 자체가 닫힌다. 뒤에 붙인 blocking="render"는 실패하지 않고 조용한 no-op이 된다 — attribute를 모르는 브라우저에서 옛 동작으로 떨어지는 것과 같은 모양이라, 안 먹는다는 사실이 드러나지 않는다.

왜 <body>인가: 스펙은 “head 안에 둬라”라고 말하지 않는다. 대신 등록 창을 이렇게 닫는다.

A Document document allows adding render-blocking elements if document’s content type is “text/html” and the body element of document is null.

— HTML Standard

#performance#rendering#fouc#html
#567