퍼블리셔 가이드, 2장
모바일과 데스크톱의 페이지 구조
마지막 검토: 2026년 11월
독자는 뉴스 페이지에 머물 만한지 빠르게 판단합니다. 헤드라인은 빨리 나타나야 하고, 페이지는 흔들리지 않아야 하며, 모든 탭에 반응이 있어야 합니다. Google은 페이지의 모바일 버전을 색인하므로, 검색에서도 기준이 되는 것은 휴대폰 레이아웃입니다.
목표로 삼을 수치
Google의 Core Web Vitals는 세 가지 측정값과 각각의 명확한 목표를 제시합니다.
| 지표 | 측정 대상 | 양호 |
|---|---|---|
| Largest Contentful Paint (LCP) | 로딩 | 2.5초 이하 |
| Interaction to Next Paint (INP) | 입력에 대한 반응 | 200밀리초 이하 |
| Cumulative Layout Shift (CLS) | 시각적 안정성 | 0.1 이하 |
페이지 로드의 75번째 백분위수를 측정하고, 모바일과 데스크톱은 따로 집계합니다. 세 지표가 모두 그 백분위수에서 목표를 충족해야 통과입니다.
실제 방문에서 얻은 필드 데이터를 사용하세요. Search Console의 Core Web Vitals 보고서, PageSpeed Insights, Chrome 사용자 경험 보고서가 여기에 해당합니다. Lighthouse는 실험실 환경에서 유용하지만 INP를 측정할 수 없고, 그 대신 Total Blocking Time을 보고합니다.
Google은 단일한 페이지 경험 신호는 없다고 설명합니다. 다만 Core Web Vitals는 Google의 순위 시스템에서 사용되며, 그 밖의 페이지 경험 요소는 사이트 순위에 직접 도움이 되지 않지만 사용성을 높여 줄 수는 있다고 말합니다.
두 화면을 위한 하나의 페이지
Google은 반응형 디자인을 구현과 유지 관리가 가장 쉬운 방식으로 권장합니다. 같은 HTML이 모든 기기에 제공되므로 별도 작업 없이 콘텐츠와 메타데이터가 일치합니다. 모바일 전용 페이지를 따로 운영한다면 다음 항목은 데스크톱과 똑같이 유지하세요.
- 주요 콘텐츠
- 제목 구조
- 구조화된 데이터
- robots 메타 태그(실수로 들어간
noindex가 모바일 페이지를 색인에서 빠지게 할 수 있습니다)
먼저 viewport 태그를 넣고, 페이지가 320 CSS 픽셀 너비에서 가로 스크롤 없이 재배치되는지 확인하세요.
<meta name="viewport" content="width=device-width, initial-scale=1">
모바일에서
- 헤드라인, 바이라인, 눈에 보이는 날짜를 먼저 두고, 그다음에 대표 이미지나 첫 문단을 두세요.
- 기사 본문은 HTML 안에 두세요. 탭하면 나머지를 불러오는 “계속 읽기” 버튼은 클릭, 스와이프, 입력을 하지 않는 Google에게 그 텍스트를 숨길 수 있습니다.
- 터치 대상은 WCAG 2.2 AA의 최소 기준인 24 x 24 CSS 픽셀 이상으로 만드세요. 메뉴와 닫기 버튼은 AAA 수준인 44 x 44를 목표로 하세요.
- 고정 헤더는 낮게 유지하고,
scroll-padding-top을 헤더 높이로 설정해 포커스된 링크가 헤더 뒤에 가려지지 않게 하세요.
데스크톱에서
- 본문은 한 줄에 80자 이하로, 중국어, 일본어, 한국어는 40자 이하로 유지하세요. 이는 WCAG AAA 지침이며 모든 독자에게 도움이 됩니다.
- 문단 안의 줄 간격은 1.5 이상으로 설정하세요.
- 보조 콘텐츠는 불러올 때 기사를 밀어내지 않는 사이드바에 두세요.
더 빠른 로딩
뉴스 페이지에서 가장 큰 요소는 대개 대표 이미지입니다. 이를 페이지에서 가장 중요한 요청으로 다루세요.
<img
src="/images/lead-1200.jpg"
srcset="/images/lead-800.jpg 800w, /images/lead-1200.jpg 1200w"
sizes="(min-width: 768px) 720px, 100vw"
width="1200"
height="675"
alt="Describe what the photo shows"
fetchpriority="high">
- LCP 이미지는 지연 로딩하지 마세요.
- 스크립트가 실행되기 전에 브라우저가 찾을 수 있도록 초기 HTML에 넣으세요.
fetchpriority="high"는 이미지 한두 개에만 사용하세요. 그 이상은 효과가 없습니다.loading="lazy"는 첫 화면 밖의 이미지와 iframe에만 사용하세요.- 리디렉션을 줄이고 페이지를 캐시할 수 있게 유지하세요. 고유한 URL 매개변수가 있으면 요청이 CDN 대신 원본 서버로 돌아갈 수 있습니다.
흔들리지 않는 페이지
- 모든 이미지와 동영상에
width와height를 지정하고, CSS에는height: auto를 유지하세요. srcset의 모든 이미지는 같은 가로세로 비율을 사용하세요.- 광고, 임베드, iframe은 불러오기 전에 공간을 확보하세요. 슬롯 크기는 광고 장에서 다룹니다.
- 쿠키 알림과 가입 유도 창은 겹쳐서 띄우거나 공간을 확보해 기사를 아래로 밀어내지 않게 하세요.
font-display: optional을 쓰거나, 웹 폰트의 메트릭에 맞춰 조정한 대체 폰트를 사용하세요.- 애니메이션에는
transform을 사용하세요.top이나left를 애니메이션하면 레이아웃 이동이 생깁니다.
빠른 반응
전체 상호작용 시간은 코드가 실행되기 전의 대기, 코드 실행, 그 뒤의 렌더링이라는 세 부분으로 이루어집니다. 50밀리초보다 오래 걸리는 작업은 모두 긴 작업입니다.
- 이벤트 콜백에서는 가능한 한 적게 처리하세요. 화면을 먼저 갱신하고 나머지는 미루세요.
- 긴 작업은
scheduler.yield()로 나누고, 지원하지 않는 브라우저에서는setTimeout을 대신 사용하세요. - DOM을 작게 유지하세요. 긴 기사 목록은
content-visibility로 화면 밖 항목의 렌더링을 나중으로 미룰 수 있습니다. - 각 iframe에는 자체 메인 스레드가 있으므로, 느린 상호작용이 어느 프레임에서 시작되었는지 확인하세요.
긴 페이지와 무한 스크롤
섹션 페이지가 끝없이 스크롤된다면, 각 구간에 ?page=12처럼 절대 페이지 번호가 있는 고유한 영구 URL을 부여하고 그 페이지들을 순서대로 링크하세요. 독자가 이동할 때 History API로 주소를 갱신하세요. Google은 스크롤하거나 클릭하지 않으므로, 지연 로딩되는 콘텐츠는 뷰포트에 들어올 때 아무 동작 없이 로드되어야 합니다.
체크리스트
- Search Console에서 LCP, INP, CLS를 모바일과 데스크톱으로 나누어 확인하세요.
- 가장 많이 쓰이는 기사 템플릿을 휴대폰에서 열어 헤드라인과 날짜가 첫 화면에 있는지 확인하세요.
- 서버가 보내는 HTML에 기사 전문이 들어 있는지 확인하세요.
- 모바일과 데스크톱에서 콘텐츠, 제목 구조, 구조화된 데이터, robots 태그가 일치하는지 비교하세요.
- 대표 이미지에서
loading="lazy"를 제거하고fetchpriority="high"를 추가하세요. - 모든 이미지와 동영상에
width와height를 추가하세요. - 모든 광고, 임베드, 배너의 공간을 확보하세요.
-
scroll-padding-top을 고정 헤더에 맞게 설정하세요. - 페이지를 320 CSS 픽셀 너비에서 테스트하세요.
- 무한 스크롤 페이지의 각 구간에 고유한 URL을 부여하세요.
출처
- Understanding Google Page Experience, Google Search Central
- Understanding Core Web Vitals and Google search results, Google Search Central
- Mobile-first Indexing Best Practices, Google Search Central
- Fix Lazy-Loaded Website Content, Google Search Central
- Web Vitals, web.dev
- Optimize Largest Contentful Paint, web.dev
- Optimize Cumulative Layout Shift, web.dev
- Optimize Interaction to Next Paint, web.dev
- Optimize long tasks, web.dev
- Browser-level image lazy loading for the web, web.dev
- Web Content Accessibility Guidelines (WCAG) 2.2, W3C
- Understanding Target Size (Enhanced), W3C WAI
- Understanding Visual Presentation, W3C WAI