링크를 한곳에 모아 빠르게 탐색하려는 사용자에게 속도는 기능 그 자체다. 링크모음이나 주소모음 페이지가 2초를 넘겨 버벅이면 사용자는 망설이고, 4초가 지나면 뒤로 가기 버튼을 누를 확률이 높아진다. 실무에서 체감하는 수치로는, LCP가 2.5초를 넘는 순간 체류 시간이 급격히 꺾이고, 모바일에서는 데이터 요금과 배터리 부담까지 더해져 이탈이 눈에 띈다. 주소아지트 같은 링크 중심 서비스에서는 더 치명적이다. 썸네일, 파비콘, 미리보기 텍스트처럼 작아 보이는 조각들이 동시에 수십 개씩 로딩돼 병목을 만든다. 이 글은 그 병목을 해부하고, 로딩 전략과 이미지 최적화로 체감 속도를 끌어올리는 방법을 현장에서 통했던 단계와 판단 기준으로 풀어낸다.
링크모음이 특히 느려지는 이유
링크모음은 통상적으로 다음 특징을 가진다. 각 항목이 외부 도메인의 자원을 참조하고, 텍스트 한 줄에 멈추지 않고 썸네일, 파비콘, 도메인명, 링크 요약 등 다양한 요소를 함께 보여준다. 여기서 네트워크 연결 수가 급증한다. HTTP/2나 HTTP/3가 병렬 전송을 돕지만, 수십 개의 다른 호스트로 향하는 연결은 여전히 왕복 지연이 누적된다.
두 번째는 예측 불가능성이다. 어떤 링크는 Open Graph 이미지가 크고 무겁고, 어떤 링크는 301을 여러 번 타거나, 심지어 블로킹을 건다. 썸네일의 원본 비율을 모르니 초기 레이아웃이 흔들리고, CLS 점수가 악화된다. 프런트엔드에서 크기를 모르고 렌더링했다가 이미지가 늦게 도착하면서 카드 그리드가 출렁이는 장면은 흔하다.
세 번째는 서버 쪽 병목이다. 사용자가 리스트를 열 때마다 백엔드가 링크 메타데이터를 새로 긁어오면 TTFB가 길어진다. OG 스크레이핑은 네트워크 I/O가 길고, 대상 서버가 느리면 요청이 대기열을 막는다. 동일 도메인으로 중복 요청이 몰리면 외부에서 레이트 리밋을 걸어 응답이 더 지연되기도 한다.
그리고 마지막으로, 페이지 자체의 렌더 블로킹 요소가 있다. 크고 무거운 JS 번들, 폰트 로딩 블로킹, 비효율적인 CSS, 초기 페인트 전에 실행되는 서드파티 태그들. 링크 항목이 가볍더라도, 프레임워크 초기화와 서드파티 스크립트가 첫 페인트를 밀어낸다면 사용자는 빈 화면만 본다.
측정 없이는 개선이 없다
속도 개선은 계측이 80%다. 최적화는 팀의 감이 아니라 수치와 재현성으로 움직인다. 실무에서는 Lighthouse 하나로 끝나지 않는다. 크롬 DevTools로 네트워크 워터폴과 메인 스레드 차트를 확인하고, WebPageTest로 3G Slow나 4G 평균 조건에서 첫 로드와 재방문을 비교한다. 실제 사용자 데이터는 CrUX나 RUM 스니펫으로 수집한다. 랩과 필드가 다를 때는 대체로 필드를 믿는다. 랩에서 1.8초가 나와도, 필드에서 3초가 넘으면 사용자는 느리다고 느낀다.
아래는 링크모음 페이지를 점검할 때 쓰는 간단한 흐름이다.
- 테스트 기기와 네트워크를 고정한다. 중급 안드로이드 기기, 4G 300 ms RTT, 1.6 Mbps 정도로 스로틀링해 반복 측정한다. Core Web Vitals 목표를 정한다. LCP 2.5초 이하, CLS 0.1 이하, INP 200 ms 이하를 기본선으로 깐다. 네트워크 워터폴에서 커넥션 수, 초기 HTML의 TTFB, 렌더 블로킹 리소스를 체크한다. 스크롤 초기 뷰포트에 실제로 필요한 리소스만 우선 전송되도록 힌트 설정을 검증한다. Fetchpriority, preload, preconnect의 효과를 번갈아 켜고 비교한다. 필드 데이터 수집을 시작해, 국가, 기기, 네트워크 유형별 분포를 본다. 상위 20%의 느린 조건을 별도로 관찰한다.
이 정도만 습관화해도, 어디를 먼저 손봐야 할지 방향이 잡힌다. 실무 예로, 주소아지트 팀에서 한 번은 LCP가 3.8초로 높게 나왔다. 네트워크 워터폴을 보니 첫 뷰포트에 보이는 히어로 섹션 썸네일이 lazy로 밀려 있었다. Fetchpriority를 high로, preload를 명시하고, 이미지 크기를 고정했다. 동시에 크리티컬 CSS를 인라인하고, 모듈 JS를 지연했다. 그 조합으로 모바일 LCP가 1.4초대로 떨어졌다.
첫 화면을 최대한 빨리 보여주는 법
첫 페인트까지의 시간을 줄이는 기본기는 크게 세 가지다. 초기 HTML을 작게, 크리티컬 경로를 얕게, 위에 보이는 요소의 의존성을 명확히. 프레임워크를 무엇을 쓰든 원리는 같다.
초기 HTML에는 첫 뷰포트에 필요한 링크 카드 몇 개를 서버 렌더링으로 바로 넣는다. 이때 카드의 이미지 박스에는 width와 height, 혹은 aspect-ratio를 지정해 레이아웃을 고정한다. 이미지를 나중에 채워도 박스 크기는 변하지 않는다. 카드 텍스트는 폰트가 도착하더라도 리플로우를 최소화하도록 system font 스택을 우선 적용하고, 웹폰트는 font-display: swap이나 optional을 쓴다. 최근에는 size-adjust, ascent-override, descent-override를 함께 설정해 대체 폰트와의 메트릭 차이를 좁히면 CLS를 더 줄일 수 있다.
CSS는 크리티컬 경로만 인라인하고 나머지는 지연 로딩한다. 초기 그리드와 타이포그래피, 네비게이션 정도가 크리티컬이다. 범용 UI 라이브러리 전체를 첫 화면에 얹는 습관을 버리면, 30 KB 이상 아낀다. JS는 가능한 한 늦게, interaction이 일어날 때만 로드한다. 라우터, 애널리틱스, A/B 스크립트, 에디터 등은 분할해 조건부로 불러온다. 모듈 스크립트는 기본 defer처럼 동작하므로 과감하게 나눠도 된다.
리소스 힌트는 꼭 필요한 범위에서만 사용한다. Preconnect는 2개, 많아도 3개 도메인까지만 추천한다. TCP 및 TLS 핸드셰이크는 비용이 크다. 이미지 CDN, 폰트 CDN, 자체 정적 자산 도메인을 우선으로 둔다. Dns-prefetch는 비용 대비 체감 이득이 낮아 난발을 피한다. Preload는 오직 화면에 꼭 필요한 리소스에만 붙인다. 예를 들어 히어로 섹션 배경 이미지, 상단 로고 폰트, 크리티컬 CSS. Fetchpriority는 브라우저의 기본 판단을 건드리는 신호이므로 target을 좁혀 사용한다. Hero 썸네일에는 high, fold 아래 이미지에는 low를 준다.
HTTP/2와 HTTP/3의 장점은 동시성에 있다. 그렇지만 연결을 쪼개는 도메인 샤딩은 더 이상 이득이 없다. 오히려 연결이 늘어 지연이 생긴다. 연결 코얼레싱을 고려하면 정적 자산과 이미지 CDN을 동일 도메인 또는 인증서 SAN에 묶는 것이 유리하다.
이미지 최적화의 디테일
링크모음에서 이미지 최적화는 성능 예산의 절반을 좌우한다. 대부분의 카드는 파비콘 16~32 px, 썸네일 120~480 px, 경우에 따라 800 px 이상의 OG 이미지로 구성된다. 전략은 간단하지만, 구현 디테일에서 성패가 갈린다.
첫째, 형식을 바꾼다. WebP와 주소모음 AVIF는 JPEG 대비 용량을 25~60% 줄인다. 다만 AVIF는 디코딩 비용이 높고, 오래된 브라우저 호환성이 낮다. 일반적으로 picture 요소를 써 AVIF, WebP, JPEG 순서로 준비한다. 품질은 WebP는 70~85, AVIF는 45~60 사이에서 아티팩트를 육안으로 점검해 결정한다. 텍스트가 많은 썸네일은 AVIF에서 링잉이 덜 보이지만, 포터레이트는 WebP가 덜 부자연스러울 때가 있다.
둘째, 크기를 잘라낸다. Srcset과 sizes를 제대로 선언하면 브라우저가 뷰포트와 DPR에 맞는 이미지를 고른다. 서버에서는 1x, 2x 기준으로 3~5단계 사이즈를 만들어 둔다. 160, 320, 480, 640, 960 px 정도가 실무에서 쓰기 좋다. 3x 기기에서 2x까지만 제공해도 충분한 경우가 많다. 과한 해상도는 낭비다. 어차피 카드에서 120 px로 보이는 이미지를 1200 px로 내려받을 이유가 없다.
셋째, 레이아웃을 고정한다. Width와 height를 HTML 속성으로 명시하면 브라우저는 자리 크기를 먼저 계산하고 이미지를 불러온다. 비율만 필요한 경우에는 aspect-ratio로 해결할 수 있다. 이렇게 하면 CLS가 줄고 프레임 드랍도 줄어든다.
넷째, 로딩 우선순위를 정한다. 첫 뷰포트에 보이는 이미지 하나에는 fetchpriority="high"를 주고, 나머지는 loading="lazy"로 미룬다. Decoding="async"를 기본으로, 중요 이미지에는 sync를 테스트해 본다. Lazy는 만능이 아니다. 히어로 컨텐츠를 lazy로 미루면 LCP가 치솟는다. 미묘한 차이 하나가 전체 체감을 바꾼다.
다섯째, 자리 표시를 아름답게 만든다. LQIP처럼 20~40 px 블러 이미지를 먼저 보여주거나, dominant color로 배경을 깔고 아이콘 오버레이를 얹는 방식이 가볍고 효과적이다. SVG 기반의 초저해상도 프록시도 써볼 만하다. 중요한 것은 블러 자체보다 레이아웃 안정성과 시각적 피드백이다. 사용자는 빈칸보다 흐릿한 그림을 훨씬 덜 불편해한다.
여섯째, 메타데이터를 제거한다. EXIF와 썸네일을 삭제하면 5~10%가 줄어든다. 프로덕션 파이프라인에서 자동으로 제거되도록 설정한다. 이미지 CDN을 쓴다면 q, f, w, dpr, auto=format 같은 파라미터로 변환을 서버에서 맡기는 것이 관리에 유리하다.
실전 팁 하나. 많은 사이트가 파비콘을 원본 도메인에서 직접 가져오려다 느려진다. 404가 나거나 16 px BMP 같은 구형 형식이 돌아온다. 파비콘은 내부적으로 도메인 해시를 키로 한 캐시를 두고, 실패 시 기본 아이콘이나 도메인 이니셜을 렌더링하라. 주소모음 페이지에서 50개 링크를 보여줄 때 파비콘만 안정적으로 처리해도 체감은 확 달라진다.
서버에서 미리 하는 일
클라이언트에서 아무리 잘해도 서버가 느리면 한계가 있다. 링크메타를 처리하는 백엔드는 다음 원칙이 중요하다. 요청-응답 경로를 짧게, 외부 호출은 배경으로, 캐시는 다층으로.
사용자가 리스트를 열 때 OG 메타를 지금 긁어오면 늦다. 등록 시점이나 배치로 미리 긁고 캐시한다. TTL은 6시간에서 24시간 사이가 보통 적당하다. 뉴스나 가격 변동이 빠른 사이트는 짧게, 정적 문서는 길게. 만료 정책은 URL 패턴으로 분기한다. 404나 410이 되면 항목을 숨기거나 재시도 간격을 크게 늘린다. 외부 요청에는 타임아웃과 재시도 백오프를 걸어 큐 점유를 방지한다.
이미지는 원본을 직접 노출하지 말고, 프록시를 거쳐 캐시 가능한 URL로 제공한다. 이렇게 하면 CORS, 혼합 콘텐츠, 만료 헤더를 통일할 수 있고, CDN 앞단에서 효율적으로 캐싱된다. ETag와 Cache-Control: public, max-age=31536000, immutable을 써서 재방문 비용을 최소화한다. 단, 링크 썸네일이 변경될 수 있는 경우에는 URL에 해시를 포함시키거나, 짧은 max-age에 stale-while-revalidate를 조합해 사용자 경험을 해치지 않는 선에서 최신화를 한다.
서버 렌더링을 채택했다면, 첫 화면에 필요한 데이터 묶음을 하나의 요청으로 만들고, N+1을 제거한다. 대부분의 성능 이슈는 DB에서 난다. 링크모음은 읽기 중심이므로 읽기 전용 복제본과 캐시 계층을 두고, 목록 키 기준으로 그룹 캐싱을 한다. 자주 쓰는 목록은 CDN에서 JSON까지 캐싱해도 된다. 다만 개인화 요소가 있으면 Edge에서 토큰 기반 분기나 쿠키 Vary를 쓰는데, 캐시 파편화를 막아야 한다.
HTTP 압축은 Brotli로, 레벨은 5~7 사이에서 서버 자원과 트래픽을 맞춘다. Lighthouse에서 텍스트 압축 미적용 경고가 보이면 즉시 조치한다. 이미지에는 압축이 이미 적용되어 있으니 중복 압축을 피한다.
클라이언트 코드 다이어트
링크모음은 본질적으로 읽기 UI다. 상호작용이 적고, 대형 런타임이나 상태 관리가 꼭 필요하지 않다. 라이브러리의 무게를 합리화하라. 날짜 포맷을 위해 70 KB짜리 라이브러리를 들이지 말고, Intl API로 대체한다. 유틸을 직접 묶어 쓰거나, 트리셰이킹이 잘 되는 모듈만 가져온다. 애니메이션은 CSS로 처리하고, 관찰 기반 인터랙션은 IntersectionObserver를 쓴다.
번들은 페이지 단위로 쪼갠다. 링크 상세 페이지, 편집 페이지, 대시보드가 서로의 코드를 공유하지 않도록 경계를 친다. 사용량이 적은 기능은 동적 임포트로 뒤로 미룬다. 프리패치와 프리로드는 사용자의 의도를 감지할 때만 쓴다. 마우스오버 프리패치는 데스크톱에서 체감이 크지만, 모바일에서는 데이터 낭비가 생길 수 있다. Navigator.connection.saveData나 effectiveType, deviceMemory 같은 신호로 조건부 활성화한다.
서드파티 스크립트는 두 번 점검한다. 하나를 추가할 때마다 LCP와 INP가 얼마나 늘어나는지 측정하고, 대체 수단이 있으면 내부로 흡수한다. 태그 매니저는 운영 편하지만, 초기 페인트에 끼어들지 않게 설정해야 한다. 광고가 필수라면, 레이아웃 슬롯을 고정해 CLS를 제어하고, lazy로 지연하며, 사용자가 스크롤로 근접했을 때만 로딩한다.
썸네일과 미리보기, 어디까지 보여줄 것인가
링크모음은 요약이 핵심이다. 그러나 과도한 미리보기는 오히려 속도를 잡아먹는다. 어떤 팀은 외부 페이지의 첫 화면을 스크린샷으로 캡처해 보여준다. 시각적으로 강력하지만, 헤드리스 브라우저가 비싸다. 이 경우에는 서버리스 잡 큐로 미리 렌더링하고, 결과만 캐시해 노출한다. 사용자 요청 흐름에서는 절대 렌더링을 하지 않는다.
Open Graph 이미지가 없거나 용량이 비정상적으로 큰 경우를 위한 폴백을 준비한다. 기본 로고, 도메인 이니셜, 카테고리별 아이콘 같은 폴백만 잘 만들어도, 시각이 깔끔해지고 다운로드 양이 일정해진다. 폴백은 CDN 캐시 히트율을 높이는 부수 효과도 있다.
텍스트 요약은 서버에서 140~200자 정도로 잘라두고, 클라이언트에서는 접고 펴는 인터랙션만 유지한다. 접힘 상태에서 전체 텍스트를 렌더링하지 않으면, 초기 페인트가 좀 더 빨라진다.
보안과 안정성, 속도 못지않게 중요하다
외부 페이지에서 메타데이터를 긁어오는 작업은 SSRF 위험을 동반한다. 내부 IP 대역, 메타데이터 서비스, 클라우드 메타데이터 엔드포인트로의 접근을 차단한다. 허용 목록 중심으로 라우팅하고, DNS 리바인딩을 막기 위해 IP를 고정해 검사한 뒤 요청한다. 타임아웃은 짧게, 전체 요청 시간의 상한을 둔다. 헤더와 HTML을 파싱할 때는 길이 제한을 둬 메모리 폭주를 막는다.
혼합 콘텐츠는 모바일에서 자주 터진다. Http 이미지가 https 페이지에 삽입되면 차단된다. 프록시를 통해 https로 변환하거나, 아예 폴백으로 전환한다. CORS가 막히는 경우도 많다. 직접 링크 삽입 대신, 서버 프록시나 이미지 CDN 경유로 통일하면 문제의 90%가 사라진다.
스크롤 성능과 그리드 렌더링
링크가 수백 개로 늘어나면 스크롤이 뚝뚝 끊긴다. 가상 스크롤을 적용해 화면에 보이는 카드만 렌더링하면 메모리와 레이아웃 계산 비용이 줄어든다. 카드의 높이가 일정하면 브라우저가 스크롤바를 계산하기 쉬워지고, 복잡한 측정을 하지 않아도 된다. Masonry 스타일은 보기 좋지만 레이아웃 비용이 높아질 수 있다. 흔들림 없는 두세 가지 카드 높이만 허용하는 설계가 유지보수에 유리하다.
이미지 로딩 트리거는 IntersectionObserver로 통일한다. 스로틀과 디바운스를 적절히 섞되, 메인 스레드를 점유하는 빈도를 낮춘다. CSS will-change를 남발하지 않고, transform과 opacity 위주로 효과를 구성하면 리플로우를 줄일 수 있다.
접근성과 데이터 절약
이미지는 alt를 채운다. 도메인명과 간단한 설명만으로도 스크린 리더 사용자에게 도움이 된다. 색 대비와 폰트 크기는 시스템 설정을 존중한다. Prefers-reduced-motion을 감지해 애니메이션을 줄이고, prefers-reduced-data나 네트워크 상태를 감지해 고해상도 이미지 프리패치를 끈다. 데이터 세이브가 켜진 사용자는 썸네일을 기본적으로 비활성화하고 탭으로 로드하도록 선택권을 주는 것도 고려할 만하다.
CDN과 엣지에서 끝내는 최적화
CDN은 링크모음의 친구다. 정적 자산, 이미지 프록시, 캐싱 가능한 JSON까지 가능한 것을 모두 올린다. 엣지 함수에서 간단한 헤더 주입, 쿠키 파싱, 리다이렉트 처리, A/B 분기를 가볍게 끝내면 오리진 부하가 크게 줄어든다. 한국 사용자 비중이 높다면 국내 PoP가 촘촘한 사업자를 고르는 것이 유리하다. 국제 서비스라면 라우팅 품질과 TLS 핸드셰이크 성능을 체크해 본다. WebPageTest의 트레이스를 보면, 동일 CDN이라도 지역별 체감이 꽤 다르다.
실전에서 먹히는 빠른 승부수
빠르게 체감을 바꿀 수 있는 항목은 정해져 있다. 아래 항목만 반영해도 링크모음의 첫 인상은 달라진다.
- 첫 뷰포트 카드 4~6개를 서버 렌더링하고, 해당 썸네일만 preload와 fetchpriority="high"를 건다. 모든 이미지에 width, height를 명시하고, lazy의 임계값을 200~400 px 앞당겨 조정한다. CSS 크리티컬 경로를 8~12 KB로 묶어 인라인하고, 나머지는 지연 로딩한다. 파비콘은 외부 도메인 직링크 대신 프록시 캐시를 거쳐 통일된 형식으로 제공한다. Open Graph 메타데이터와 썸네일은 등록 시점에 미리 수집하고, TTL과 재시도 정책을 분리한다.
이 다섯 가지만 지켜도 LCP가 30~50% 개선되는 사례를 여러 번 보았다. 실제로 주소아지트에서 비슷한 조합으로 작업했을 때, 모바일 P75 LCP가 2.9초에서 1.7초로 내려갔고, 스크롤 초기 구간의 dropped frame 비율이 절반 가까이 줄었다.
예산과 모니터링을 운영에 녹이기
성능은 한 번 올려 놓는다고 유지되지 않는다. 새로운 기능, 새로운 라이브러리, 때로는 무심코 추가한 한 줄이 예산을 깨뜨린다. 팀 차원의 퍼포먼스 예산을 CI에 붙인다. Lighthouse CI로 LCP, CLS, JS 총량, 이미지 총량에 하드 가드를 두고, PR마다 리포트를 확인한다. JS는 gzip 기준 120 KB, CSS 60 KB, 초기 이미지 합계 60 KB를 넘지 않도록 하고, 각 페이지마다 허용치를 정해둔다. 이미지 가이드는 명문화한다. 썸네일 폭은 320 px, 2x까지, 형식은 WebP 우선, 폴백은 JPEG. 변경이 필요하면 PR 템플릿에서 성능 영향 섹션을 채워 리뷰한다.
필드 데이터는 월간이 아니라 일간으로 본다. 주말과 평일, 한국과 해외, Wi‑Fi와 셀룰러의 차이를 분리해 본다. 성능 경보는 제품 지표와 연결한다. LCP가 임계값을 넘는 구간에서 이탈률이 함께 튀는지 상관계를 확인한다. 상관관계가 약해도, 느린 페이지는 결국 고객 신뢰를 깎는다.
자주 부딪히는 함정과 선택지
실서비스를 운영하다 보면 이상한 상황을 맞는다. 이미지가 모바일 사파리에서만 깨진다거나, 특정 캐리어에서만 썸네일이 늦다거나. 이런 때는 형식과 헤더를 의심한다. AVIF가 특정 iOS 버전에서 불안정하면 WebP로 빠른 우회로를 둔다. Cache-Control의 no-store가 섞여 있으면 중간 캐시가 히트를 못 친다. CORS 헤더가 빠지면 프리로드가 무시된다. 서버와 CDN, 브라우저 캐시가 얽히면 디버깅에 시간이 걸린다. 헤더를 최소한으로, 일관되게 유지하라.
또 하나, 무조건 최신 기술이 답은 아니다. 클라이언트 힌트 기반의 DPR 최적화는 좋지만, 프라이버시 정책 상 일부 브라우저에서 비활성화될 수 있다. 서비스 워커로 이미지 캐싱을 커스터마이즈하는 것은 파워풀하지만, 업데이트 복잡도와 버그 리스크가 올라간다. 먼저 CDN에서 해결할 수 있는지 보라.
마지막으로, 디자인과 협업이 중요하다. 카드 레이아웃과 타이포그래피에서 성능을 고려한 선택을 해주면, 개발은 두 배로 쉬워진다. 예를 들어 고정된 비율의 썸네일, 제한된 폰트 웨이트, 단순한 그리드. 설계 단계에서 합의하면, 배포 이후에 성능 핑퐁을 하지 않아도 된다.
주소아지트 사례에서 얻은 교훈
주소아지트는 한국 사용자 비중이 높고, 모바일 트래픽이 70%를 넘는다. 이미지 CDN을 자체 도메인에 묶어 연결 코얼레싱을 확보했고, 파비콘과 썸네일 모두를 프록시를 통해 통일했다. 링크 등록 시점에 헤드리스 렌더링으로 OG 이미지를 안정화하고, 실패 시 폴백을 강하게 적용했다. 프런트는 서버 렌더링으로 첫 카드 6개를 즉시 표시하고, critical CSS 9.6 KB를 인라인했다. WebP 우선, AVIF는 단계적으로 도입했다. 프리패치는 데스크톱에서만, 마우스오버 이벤트로 제한했다.
모니터링에서는 RUM을 붙여 국가별 분포를 보았고, 한국 LTE 환경에서 P75 LCP를 1.6~1.9초로 유지했다. JS 예산을 110 KB로 제한하고, 날짜 라이브러리를 걷어냈다. 파비콘 프록시는 캐시 적중률이 92%까지 올라갔다. 예상 밖으로 효과가 컸던 것은 폰트 메트릭 튜닝이었다. Size-adjust를 적용하자 CLS가 0.06에서 0.01대로 줄었다. 이미지를 더 압축하려다 화질 이슈로 되돌린 경험도 있다. 팀 내부 가이드를 두고, 마케팅 캠페인용 랜딩에는 예외를 허용하되, 기간을 제한하는 룰을 추가했다.
앞으로의 여지
이미지 최적화는 계속 발전한다. JPEG XL의 부활 가능성, AVIF의 하드웨어 디코딩 보급, 브라우저의 priority 자동화가 변수다. 하지만 원칙은 변하지 않는다. 첫 화면을 가볍게, 외부 의존을 배경으로, 자원은 필요한 순간에만. 링크모음과 주소모음은 콘텐츠가 외부에서 오기 때문에 통제할 수 없는 영역이 넓다. 그래서 통제 가능한 경로를 설계하는 것이 곧 속도 전략이다.
링크를 모아 보여주는 제품은 간결함에서 힘이 나온다. 빠르게 뜨고, 조용히 스크롤되며, 필요한 정보가 딱 보이는 경험. 거기에 이르려면 화려한 기술보다 기본 동작을 신중하게 쌓아가야 한다. 이미지 한 장, 힌트 한 줄, 캐시 한 층. 그런 작은 선택이 체감 속도를 만든다.