Do you build things with AMP? Fill out the new AMP Developer Survey!
AMP

AMP 작동 원리

AMP 페이지가 순간적으로 로딩되는 것처럼 보일 만큼 빠른 이유는 다음의 최적화 조합 덕분입니다. 총 7가지 이유를 확인해 보세요. 글이 너무 길다고 생각하신다면 아래 설명 동영상을 시청하셔도 좋습니다.

AMP JavaScript 비동기 처리

JavaScript는 페이지의 거의 모든 측면을 수정할 수 있을 만큼 강력하지만 한편으로는 DOM 생성을 차단하고 페이지 렌더링을 지연시킬 가능성이 있습니다(참고 항목 JavaScript로 상호작용 추가). AMP는 JavaScript에서 페이지 렌더링이 지연되지 않도록 비동기 JavaScript만을 허용합니다.

AMP 컴포넌트는 기본적으로 JavaScript를 포함할 수 있지만, 이들 요소가 성능 저하를 유발하지 않도록 세심하게 설계되었습니다.

사용자 지정 JS는 amp-script에서 허용되고 타사 JS는 iframes에서 허용되지만 렌더링을 차단할 수는 없습니다. 가령, 타사 JS에서 실적-달성을-심각히-저해하는 document.write API가 사용되더라도 기본 페이지 렌더링을 차단하지는 않습니다.

모든 리소스 크기를 정적으로 지정

이미지, 광고 또는 iframe과 같은 외부 리소스는 그 크기를 HTML에 지정해야 합니다. 이를 통해 리소스 다운로드 전 AMP가 각 요소의 크기와 위치를 결정할 수 있습니다. AMP는 리소스 다운로드를 기다리지 않고 페이지 레이아웃을 로드합니다.

AMP는 문서 레이아웃을 리소스 레이아웃에서 분리합니다. 전체 문서(+ 폰트)를 배치하는 데에는 단 하나의 HTTP 요청만이 필요합니다. AMP는 브라우저에서 불필요한 스타일 재계산 및 레이아웃을 피하도록 최적화되었기 때문에 리소스 로드 시 어떤 재배치도 수행되지 않습니다.

확장 메커니즘이 렌더링을 차단하지 않음

AMP는 확장 메커니즘이 페이지 렌더링을 차단하지 않습니다. AMP는 라이트 박스, Instagram 삽입, 트윗 등의 확장 기능을 지원합니다. 이들은 추가적인 HTTP 요청을 필요로 하지만, 해당 요청이 페이지 레이아웃 및 렌더링을 차단하지는 않습니다.

사용자 지정 스크립트를 사용하는 모든 페이지는 해당 페이지에 사용자 지정 태그가 포함될 것임을 AMP 시스템에 알려야 합니다. 예를 들어, amp-iframe 스크립트는 amp-iframe 태그가 있을 것임을 시스템에 알립니다. AMP는 무엇이 포함될지 알기 전에도 iframe 박스를 생성합니다.

<script async custom-element="amp-iframe" src="https://cdn.ampproject.org/v0/amp-iframe-0.1.js"></script>

모든 타사 JavaScript를 주요 경로에서 제외

타사 JS는 동기적 JS 로딩을 사용할 확률이 높습니다. 또한 더 많은 동기 스크립트의 document.write 사용을 선호합니다. 예를 들어, 페이지 내 5개의 광고가 있고 각각 1초의 지연 시간 연결에 동기 로드 3회를 수행한다면 JS 로딩에만 15초의 로드 시간이 소요됩니다.

AMP 페이지는 샌드박싱된 iframe에서만 타사 JavaScript를 허용합니다. 페이지를 iframe으로 제한함으로써, 기본 페이지의 실행을 차단할 수 없습니다. 페이지가 여러 번의 스타일 재계산을 트리거하더라도, 작은 iframe에는 DOM이 거의 없습니다.

스타일 재계산 및 레이아웃에 소요되는 시간은 DOM 크기에 따라 달라지므로, iframe 재계산은 페이지의 스타일 재계산 및 레이아웃에 비해 매우 빠릅니다.

모든 CSS의 인라인 및 크기 제한

CSS는 모든 렌더링과 페이지 로드를 차단하며 비대해지는 경향이 있습니다. AMP HTML 페이지에서는 인라인 스타일만 허용됩니다. 이런 경우 대부분의 웹 페이지와 비교하여 주요 렌더링 경로에서 하나 이상의 HTTP 요청을 제거합니다.

또한 인라인 스타일 시트의 최대 크기는 50 킬로바이트입니다. 이 크기는 복잡한 페이지에서도 충분한 크기이지만 페이지 작성자가 CSS의 감염을 막도록 노력할 필요가 있습니다.

효율적인 글꼴 트리거

웹 글꼴은 용량이 매우 크기 때문에 성능에 있어 웹 글꼴 최적화는 중요합니다. 몇 개의 동기화 스크립트와 몇 가지 외부 스타일 시트가 포함된 일반적인 페이지에서, 이 모든 것이 수행될 때까지 브라우저는 한참 기다린 후에나 방대한 글꼴의 다운로드를 시작합니다.

AMP 시스템은 글꼴의 다운로드가 시작될 때까지 HTTP 요청을 선언하지 않습니다. 이것이 가능한 이유는 AMP에 있는 모든 JS가 async 속성을 지니며 인라인 스타일 시트만 허용되기 때문입니다. 브라우저가 글꼴을 다운로드하는 것을 차단하는 HTTP 요청은 없습니다.

스타일 재계산 최소화

요소를 측정할 때마다 스타일 재계산이 실행됩니다. 이 과정에서 브라우저가 전체 페이지 레이아웃을 조정하기 때문에 비용이 많이 듭니다. AMP 페이지에서는 모든 쓰기 동작보다 모든 DOM 읽기 동작이 먼저 발생합니다. 그렇기에 프레임당 최대 한 번만 스타일을 재계산할 수 있습니다.

스타일 및 레이아웃 재계산이 미치는 영향을 렌더링 성능에서 자세히 알아보세요.

GPU 가속 애니메이션만 실행

빠른 최적화를 위한 유일한 방법은 GPU에서 실행하는 것입니다. GPU는 레이어를 이해하며 이 레이어에서의 수행 방법을 알고 있습니다. 또한, 레이어를 이동하고 사라지게 할 수 있지만 페이지 레이아웃을 업데이트할 수는 없습니다. 이 작업을 브라우저에 넘겨주는 것도 가능하지만 권장되는 방법은 아닙니다.

애니메이션 관련 CSS의 규칙은 애니메이션의 GPU 가속을 보장해 줍니다. 구체적으로 AMP는 변환 및 불투명도에 대해서만 애니메이션과 전환을 허용하므로, 페이지 레이아웃이 필요하지 않습니다. 애니메이션 변경을 위한 변환 및 불투명도 사용 방법을 자세히 알아보세요.

리소스 로딩의 우선순위 지정

AMP는 모든 리소스 다운로드를 제어하고, 리소스 로딩의 우선순위를 지정하며 필요한 리소스만 로드하고 늦게 로드되는 리소스를 프리페치합니다.

AMP는 리소스 다운로드 시 다운로드를 최적화하므로, 현재 가장 중요한 리소스가 먼저 다운로드됩니다. 이미지와 광고의 경우 사용자가 조회하거나 빠르게 스크롤할 가능성이 있는 경우에만 다운로드됩니다.

또한, AMP는 늦게 로드되는 리소스를 프리페치합니다. 리소스는 최대한 늦게 로드되지만 최대한 빠르게 프리페치됩니다. 이런 방식으로 로드는 매우 신속히 이루어지지만, CPU는 리소스가 실제로 사용자에게 표시될 때만 사용됩니다.

즉시 페이지 로드

새로운 preconnect API는 HTTP 요청이 되었을 때 최대한 빠른 수행을 보장하기 위해 자주 사용됩니다. 이 API를 사용하면, 사용자가 탐색하고자 하는 내용을 명시적으로 지정하기 전에 페이지를 렌더링할 수 있습니다. 사용자가 실제로 페이지를 선택할 시점에 해당 페이지는 이미 사용 가능한 상태로 즉시 로드됩니다.

사전 렌더링은 모든 웹 콘텐츠에 적용될 수 있지만, 많은 대역폭과 CPU를 소모할 수도 있습니다. AMP는 이러한 요인을 모두 줄이도록 최적화되어 있습니다. 사전 렌더링은 중요한 리소스만을 다운로드하며 CPU를 많이 소모할 수 있는 리소스는 렌더링하지 않습니다.

즉시 로드하기 위해 AMP 문서를 사전 렌더링할 경우, 상단에 표시되는 리소스만 실제로 다운로드됩니다. 즉시 로드하기 위해 AMP 문서를 사전 렌더링할 경우, CPU를 많이 소모할 수도 있는 리소스(예: 타사 iframe)는 다운로드되지 않습니다.

AMP HTML이 프리로드 스캐너를 최대한 활용하지 않는 이유를 자세히 알아보세요.