Google의 Accelerated Mobile Pages에 대해 알아야 할 모든 것

2015년 5월 Facebook은 새로운 인앱 퍼블리싱 플랫폼인 Instant Articles를 공개했습니다. 한 달 후, Apple은 iOS 9에서 이전 Newsstand 경험(기본적으로 뉴스 앱으로 가득 찬 멋진 폴더)이 Apple News라는 새로운 뉴스 집계 및 검색 플랫폼으로 대체될 것이라고 선언했습니다.

스매싱에 대한 추가 읽기 :

• 인지된 성능
• 예압: 무엇이 좋은가요?
• HTTP/2 준비
• 점진적 향상
• 프로그레시브 웹 AMP

4개월 후 Google은 Accelerated Mobile Pages 또는 AMP라는 오픈 소스 웹 기반 솔루션으로 모바일 뉴스 소비에 혁명을 일으키겠다는 다소 늦었지만 야심찬 자체 계획을 발표할 차례였습니다. 불과 몇 달 만에 Facebook, Apple, 그리고 현재 Google이 게시자의 충성도와 독자의 관심을 놓고 경쟁함에 따라 모바일 디지털 출판의 상대적인 평온함이 또 다른 전면적인 플랫폼 전쟁으로 분출하는 것을 보았습니다.

Facebook과 Apple은 Google에서 상당한 우위를 점하고 있지만 AMP가 빠르게 따라잡을 것이라고 믿을 만한 충분한 이유가 있습니다(심지어 경쟁사 중 하나 또는 둘 다를 능가할 수도 있음). Google의 Accelerated Mobile Pages가 왜, 무엇을, 어떻게 사용되는지 최대한 빠르고 효율적으로 파악해야 하는 개발자 또는 게시자라면 지금 바로 찾아오셨습니다.

그러나 문제가 무엇입니까?

솔루션에 대해 논의하기 전에 잠시 시간을 내어 문제를 살펴보는 것이 좋습니다. 모바일 장치에서 독서를 많이 한다면, 휴대폰이나 태블릿에서 웹 기반 콘텐츠와 상호 작용하는 것이 거의 허용되지 않는 것에서 끔찍할 정도로 다양하다는 것을 이미 너무 잘 알고 있을 가능성이 매우 높습니다. 페이지는 종종 두 가지 주요 이유로 느리게 로드되고, 불규칙하게 렌더링되며, 예측할 수 없게 동작합니다.

• 타사 간섭 . 광고 및 관련 추적 기술은 이미 대역폭 및 CPU 제약이 있는 장치에 대량의 추가 요청을 추가할 뿐만 아니라 여러 document.write() 호출을 둘러싸고 경련을 일으킬 때 페이지가 마치 홀린 것처럼 작동하는 경우가 많습니다. New York Times는 최근 iOS 콘텐츠 차단기를 설치한 후 페이지 크기가 크게 감소하고 배터리 수명이 증가하는 테스트를 수행했습니다.
• 반응형 디자인으로 인한 부수적 손상 . 반응형으로 디자인된 대부분의 웹 사이트는 모든 크기의 화면에서 잘 보이지만 모바일에서 볼 때 데스크톱 웹 사이트의 많은 짐을 포함하는 경우가 많습니다. Paul Irish가 Reddit의 성능 감사를 수행했을 때, 그는 많은 오버헤드가 SnooIcon이라는 자산으로 추적될 수 있다는 것을 발견했습니다. SnooIcon은 SVG에서 애니메이션이 가능하도록 렌더링된 Reddit 마스코트입니다. 더 많은 오버헤드) 마우스 오버 시 — 자산이 모바일 장치에서 자주 발견되는 상황이 아닙니다.

Facebook Instant Articles, Apple News 및 Accelerated Mobile Pages를 입력하세요. Facebook(PDF, 3.4MB)에 따르면 모바일 장치에서 기사의 평균 로드 시간이 8초인 세상에서 우리의 구원자입니다. 8초를 영원이라고 부르는 것은 분명히 과장법이지만, 그 시간 동안 두 번째 Vine 비디오를 볼 수 있다는 점을 감안하면 오늘날의 기준으로 볼 때 적어도 10년이라고 말하는 것이 타당할 것입니다.

Facebook Instant Articles, Apple News 및 Accelerated Mobile Pages의 짧은 데모. Facebook Instant Articles 및 Apple News는 인앱 경험인 반면 AMP는 완전히 브라우저 기반입니다.

AMP는 어떻게 다른가요?

AMP가 Facebook Instant Articles 및 Apple News와 어떻게 다른지에 대한 몇 가지 맥락은 Google이 새로운 디지털 퍼블리싱 이니셔티브에 대해 내린 결정 중 일부를 더 명확하게 할 것입니다.

Facebook 인스턴트 아티클과 Apple 뉴스에는 몇 가지 공통점이 있습니다.

• 인앱 경험 . 독자는 모바일 장치에서 Facebook을 통해 Facebook Instant Articles에 액세스하고 Apple News는 iOS 9와 함께 제공되는 독립 실행형 앱입니다. 현재 두 플랫폼 모두 사용자가 해당 앱 외부에서 특정 형식의 기사를 볼 수 있도록 허용하지 않습니다. 둘 다 RSS의 응용 프로그램별 새로 고침으로 생각하십시오.
• 신디케이션 중심 . Facebook 인스턴트 아티클과 Apple News는 매우 다른 신디케이션 형식을 사용하지만(Apple News 형식은 JSON 기반이고 인스턴트 아티클 마크업은 RSS 피드로 래핑된 HTML) 유사한 원칙을 기반으로 합니다. 필요한 신디케이션 형식을 제공하고 Facebook 또는 Apple News는 이를 과감하게 분석하고 사용자 정의되고 최적화된 렌더러를 통해 아름답고 빠르게 만들 것입니다.
• 경험 지향적 . Facebook Instant Articles와 Apple News는 모두 성능에 중점을 두고 있지만 기사의 모양과 느낌을 현대적으로 만드는 데 똑같이 관심이 있습니다. 두 플랫폼 모두 우리가 일반적으로 맞춤 제작한 손으로 만든 읽기 경험과 연관되는 매끄럽고 부드러운 상호 작용을 허용하는 구성 요소를 가지고 있습니다.

이와 대조적으로 Accelerated Mobile Pages에는 다음과 같은 뚜렷한 초점이 있습니다.

• 웹 기반 경험 . AMP 문서는 브라우저나 WebView에서 렌더링되도록 설계되었습니다.
• 원자 문서 . AMP 문서는 AMP 런타임에 의해 검증, 구문 분석 및 부분적으로 렌더링되지만(아래에서 자세히 설명) AMP 문서는 어느 시점에서 기사로 변환되고 앱에서 렌더링되는 메타데이터입니다.
• 성과 지향적인 . AMP는 미학이나 상호작용 패턴보다 AMP 문서의 성능을 훨씬 더 중요하게 생각합니다. 그렇다고 AMP 문서가 본질적으로 평범하다는 것은 아니지만(올바른 스타일의 Facebook Instant Articles 또는 Apple News 기사만큼 매력적일 수 있음) 런타임은 다음과 같은 멋진 시각 효과를 제공하는 것보다 기사를 빠르게 렌더링하는 데 훨씬 더 관심이 있습니다. 미친 작은 흔들리는 것들.

AMP가 정확히 무엇인가요?

충분한 철학과 수준 높은 손놀림. 구체적으로 들어가 보겠습니다. Facebook Instant Articles와 Apple News를 이해하는 것은 매우 쉽지만(이들은 본질적으로 독점 신디케이션 형식 위에 구축된 사용자 지정 렌더러가 있는 멋진 뉴스 수집기임) AMP가 예외입니다. 두 가지 이유로 이해하기가 조금 더 어렵습니다.

• 비교할 수 있는 간단한 모델이 없습니다. RSS가 처음 등장했을 때 우리 모두는 RSS의 위력에 감탄했고 파괴적인 잠재력에 대해 수많은 기사와 블로그 게시물을 작성했으며 홈페이지가 죽었다고 선언한 후(아직도) 모든 것을 잊어버렸습니다. Facebook Instant Articles와 Apple News는 표준의 모든 불편함을 없애고 각각 하나의 응용 프로그램에서만 작동한다는 점을 제외하면 본질적으로 RSS 재부팅입니다.
• AMP는 클라이언트가 아닙니다. . Facebook Instant Articles, Apple News 및 AMP에는 독점 신디케이션 형식 및 사용자 지정 렌더러와 같은 몇 가지 공통 요소가 있지만 AMP는 전용 클라이언트(브라우저 제외)가 없는 유일한 것입니다. AMP는 그 자체로 종단 간(출판자 간) 솔루션이 아니라 솔루션으로 결합될 수 있는 사양, 규칙 및 기술의 집합입니다.

이제 우리는 AMP를 완전히 구운 케이크가 아니라 재료의 집합체로 생각한다는 것을 알았으므로 이러한 개별 구성 요소가 무엇인지 살펴보겠습니다.

• AMP HTML,
• AMP 런타임,
• AMP 캐시.

AMP HTML

AMP 문서는 HTML로 작성되지만 모든 HTML은 아닙니다. 일부 태그는 금지되지만 몇 가지 새로운 태그가 도입되었습니다(금지된 태그를 부분적으로 교체하고 부분적으로 대화형 기능을 캡슐화하기 위해). AMP HTML은 HTML이 모바일 성능만을 염두에 두고 디자인된 경우의 모습이라고 생각할 수 있습니다(iPhone이 출시되기 14년 전에 소개된 것과는 대조적으로).

AMP HTML은 최적의 성능을 위해 설계되었기 때문에 AMP HTML의 가치를 이해하고 높이 평가하려면 HTML이 해결하는 문제를 이해해야 합니다. 다음은 모바일 장치에서 웹 페이지의 로드 및 렌더링을 방해하는 세 가지 가장 큰 요소입니다.

• 페이로드 크기 . 반응형 웹 디자인은 우리가 모든 장치와 화면에 대해 단일 웹사이트를 구축할 수 있도록 해주기 때문에 우리에게 큰 도움이 되었습니다. 그러나 이는 때로는 데스크톱 크기의 페이로드(HTML, JavaScript, CSS 및 자산)를 대역폭과 CPU가 매우 제한된 모바일 장치에 전달하는 것을 의미하기도 합니다. (휴대폰을 작은 데스크탑 컴퓨터로 생각하는 사람들은 모바일 하드웨어에 너무 많은 신뢰를 주고 있습니다. iPhone 6s에는 2GB RAM이 있는 반면 랩톱에는 8GB 또는 16GB RAM이 있을 수 있습니다.)
• 리소스 로딩 . 리소스가 항상 최적의 순서로 로드되는 것은 아닙니다. 즉, 대역폭, CPU 및 RAM이 사용자가 전혀 볼 수 없는 자산에 전용되는 경우가 많습니다. 또한 리소스는 종종 너비와 높이를 선언하지 않습니다(특히 광고 네트워크를 통해 제공되거나 document.write() 호출을 통해 삽입되는 경우). 리소스 크기가 느리게 결정될 때 페이지 크기가 자체적으로 조정될 뿐만 아니라 불필요한 트리거가 발생합니다. 고가의 레이아웃 재계산. 그것이 웹 페이지가 레이저를 쫓는 새끼 고양이처럼 느리게 나타나게 만드는 원인입니다.
• 자바스크립트 실행 . 여기서 JavaScript 성능에 대한 주제를 다루려는 것은 아니지만 최신 웹사이트는 종종 메가바이트 단위로 쌓이고 데스크톱 컴퓨터에서는 식별할 수 있는 대기 시간 없이 실행될 수 있지만 모바일은 여전히 ​​매우 다른 환경입니다. 우리 모두 동의할 수 있습니다. JavaScript는 최소한으로 유지하는 것이 가장 좋습니다.

모바일 기기에서 유동적인 웹 경험에 대한 이러한 세 가지 장벽을 감안할 때 AMP HTML은 주로 세 가지 목적을 위해 존재합니다.

• 간결함을 권장 합니다. AMP 문서는 반응형 버전의 데스크톱 웹사이트가 아닙니다. AMP 문서는 반응형일 수 있고 일반적으로 반응형이지만 모바일 컨텍스트에서는 반응형입니다. 다시 말해, 모든 곳(데스크톱 및 모바일)에서 절대적으로 작동하는 한 페이지가 아니라 AMP 문서는 모바일 장치에서 잘 작동하도록 특별히 설계되었습니다.
• 외부 리소스 로드를 제어합니다 . AMP 런타임은 외부 리소스 로드를 제어하여 프로세스가 매우 효율적이고 결과적으로 콘텐츠가 가능한 한 빠르고 지능적으로 사용자의 화면에 표시되도록 합니다.
• 대화형 기능을 캡슐화합니다 . AMP 문서는 독자에게 직접적인 읽기 경험을 제공하는 비즈니스로 직결되는 경향이 있지만 그렇다고 해서 현대적이고 대화식일 수 없다는 의미는 아닙니다. AMP 런타임은 고도로 최적화된 JavaScript를 통해 캡슐화된 기능을 제공하므로 개발자가 직접 작성하여 성능을 저해할 위험이 없습니다.

AMP HTML 태그

다음은 AMP HTML에서 전면 금지된 태그 목록입니다.

• script 이것은 분명히 큰 것입니다. 아래에서 JavaScript에서 AMP의 위치에 대해 자세히 설명하겠습니다. 지금은 AMP 문서에 포함할 유일한 script 태그가 AMP 런타임을 로드하는 태그와 선택적으로 JSON 기반 연결된 데이터에 대한 태그라고 가정합니다.
• base 태그는 많은 주의를 기울여 금지된 것으로 보이며 커뮤니티에서 불만을 제기하면 화이트리스트에 추가될 수 base . (내 생각에 아무도 정말로 어떤 식 으로든 신경 쓰지 않는다는 것입니다.)
• frame 과 frameset 어쨌든 모바일 부동산을 잘 활용하는 것은 아닙니다.
• object , param , applet 및 embed 슬프게도 AMP 문서에는 Flash 또는 Java 애플릿이 포함되지 않습니다. (그것은 완전히 명백하지 않은 경우를 대비하여 풍자였습니다.)
• form 및 input 요소( button 태그 제외) 양식 지원은 스크립팅 없이는 제한적으로 사용되기 때문에 결국 캡슐화된 구성 요소로 구현될 것입니다.

이제 리소스 로딩을 최적화하고 최상의 보안 사례를 시행하기 위해 HTML 태그를 대체하는 태그 목록이 있습니다.

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) img 태그를 대체하고 표시 영역 위치, 시스템 리소스 및 연결과 같은 요소를 고려하여 리소스 로드를 최적화합니다.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) 동영상 콘텐츠를 느리게 로드할 수 있도록 HTML5 video 태그를 대체합니다(표시 영역 고려).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) 오디오 콘텐츠를 느리게 로드할 수 있도록 HTML5 audio 태그를 교체합니다(표시 영역 고려).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) amp-iframe 태그는 기본적으로 콘텐츠를 샌드박싱하고 여기서 iframe은 AMP 문서를 지배하지 않도록 표시될 수 있습니다.

마지막으로 다음은 JavaScript를 작성할 필요 없이 문서에 기능이나 상호작용을 추가하기 위해 AMP HTML이 도입한 모든 태그입니다.

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) amp-ad 태그를 사용하면 AMP 런타임에서 외부에서 로드되는 다른 모든 리소스(현재 , 광고가 마지막에 로드됨), 광고 네트워크의 JavaScript가 상위 AMP 문서 내에서 실행되거나 불필요한 레이아웃 계산을 트리거할 수 없도록 합니다. (안녕, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) 이 미니어처 프레임워크는 분석 데이터를 패키징하여 타사 제공업체에 보냅니다. 오늘부터 AMP 지원은 Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen 및 Parse.ly에서 제공됩니다.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) 웹 비콘을 삽입하는 데 사용되며 여러 클라이언트 변수를 서버로 보내기 위한 토큰을 지원합니다.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) 이 최적화된 구성요소는 대화형 수평 방향으로 하위 이미지를 표시합니다.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) 이를 통해 독자는 전체 화면 '라이트박스' 보기에서 이미지를 열 수 있습니다. 썸네일 및 전체 크기 이미지의 사양을 모두 지원합니다.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) 애니메이션 GIF를 로드하고 꼭 필요한 자리 표시자 기능을 제공합니다.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) 맞춤 글꼴에 로드 시간 제한을 설정하고 맞춤 글꼴이 할당된 시간 내에 로드되지 않는 경우 대체 글꼴을 지정합니다. .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) amp-fit-text 태그 내의 텍스트에는 다음에 최적화된 글꼴 크기가 자동으로 할당됩니다. 사용 가능한 공간. 미리 포장된 약간의 응답성이라고 생각하십시오.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) amp-list 태그를 사용하면 동적 반복 JSON 데이터를 로드한 다음 HTML을 사용하여 렌더링할 수 있습니다. 주형. (아래의 amp-mustache 태그를 참조하세요.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) 이것은 Mustache HTML 템플릿의 렌더링을 지원합니다.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) AMP 캐시를 사용하지 않기로 선택하면(캐싱에 대한 자세한 내용은 아래 참조) amp-install-serviceworker 태그는 현재 페이지에 대한 서비스 워커를 로드하고 설치합니다. 서비스 워커는 유능하지만, 제 생각에는 서비스 워커에 의존하기에는 조금 이르다고 생각합니다.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) 예상대로 이렇게 하면 지정된 동영상 ID로 YouTube 동영상이 삽입됩니다.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) 트윗을 삽입합니다(Twitter 카드 선택사항).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Instagram 이미지를 삽입합니다.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) 이 구성요소는 Brightcove에서 동영상(및 동영상 플레이어)을 로드하고 표시합니다.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) AMP 문서에 Pinterest 위젯 또는 '고정' 버튼을 삽입합니다.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) 지정된 Vine 동영상을 AMP 문서에 삽입합니다.

amp- 접두사가 붙은 태그는 정확히 표준 HTML은 아니지만 독점 태그도 아닙니다. 오히려 이들은 모범 보안 사례를 시행하고 원격 리소스 로드의 우선 순위를 지정하는 등의 작업을 수행하는 JavaScript 구현이 포함된 합법적인 맞춤 요소입니다(아래 "AMP 런타임" 섹션에서 자세히 설명). 다시 말해서 AMP HTML은 의심스럽게도 수용, 확장 및 소멸 전략처럼 보일 수 있지만 실제로는 웹 표준을 영리하게 적용한 것일 뿐 사용자 지정 data- 속성과 크게 다르지 않습니다.

AMP HTML 스타일 지정

AMP 문서의 스타일 지정은 표준 CSS로 수행되며 이미 콘텐츠 스타일을 지정하는 방법과 크게 다르지 않습니다. 그러나 몇 가지 사항을 염두에 두십시오.

• 모든 스타일링은 인라인 스타일 시트로 이루어져야 합니다. 외부 링크 스타일 시트와 요소 수준 인라인 스타일이 없습니다. (외부적으로 연결된 스타일 시트는 레이아웃을 계산하기 전에 추가 문서를 다운로드해야 하며 인라인 요소 수준 스타일은 문서를 부풀릴 수 있습니다.)
• 스타일은 50KB로 제한됩니다. Google의 철학은 50KB가 좋은 문서나 기사에는 충분하지만 멋진 웹사이트에는 충분하지 않다는 것입니다.
• 인라인 스타일 시트에는 amp-custom 속성(예: <style amp-custom> )이 있어야 합니다.
• @ 규칙 — @font-face (아래 글꼴에 대한 자세한 내용), @keyframes 및 @media —가 허용됩니다.
• 일부 선택기에는 범용( * ) 선택기 및 :not() 선택기와 같이 성능에 문제가 있는 것으로 알려진 제한 사항이 있습니다.
• !important 한정자는 AMP 런타임에 요소 크기 조정에 대한 마지막 단어가 포함되도록 금지됩니다.
• amp-carousel 과 같은 맞춤 AMP 구성요소의 스타일 지정은 .amp-carousel-button-prev 와 같은 기본 클래스를 재정의하거나 --arrow-color 와 같은 미리 정의된 CSS 맞춤 속성 집합을 사용하여 수행됩니다.
• 비용이 많이 드는 DOM 레이아웃 재계산을 최소화하기 위해 외부에서 로드된 모든 리소스에는 너비, 높이 및 레이아웃 속성이 지정되어 있어야 합니다(아래 레이아웃에 대해 자세히 설명).
• GPU 가속이 가능한(재계산을 트리거하지 않는) 전환 및 애니메이션이 허용됩니다. 현재 opacity 및 transform 이 허용 목록에 있습니다.

문서 스타일 지정에 대한 자세한 내용은 AMP HTML 사양을 참조하세요.

글꼴

AMP는 다음과 같은 몇 가지 조건으로 사용자 정의 글꼴을 기꺼이 지원합니다.

• 글꼴은 링크 태그 또는 CSS @font-face 규칙과 함께 로드되어야 합니다. 즉, JavaScript를 사용하여 글꼴을 로드할 수 없습니다.
• 모든 글꼴은 HTTPS를 통해 제공되어야 합니다.
• 글꼴 공급자는 허용 목록에 있어야 합니다. 현재 허용된 유일한 제공업체는 fonts.googleapis.com 및 fast.fonts.net 입니다. 그러나 게시자, 광고주 및 분석 제공업체가 AMP에 대한 지원을 얼마나 빨리 추가하는지를 감안할 때 더 많은 지원이 곧 추가될 것이라고 생각합니다.

형세

레이아웃에 대한 AMP의 접근 방식은 두 가지 주요 목표를 중심으로 고안되었습니다.

• 런타임은 최종 레이아웃이 가능한 한 빨리 계산될 수 있도록 실제로 로드되기 전에 외부에서 로드된 모든 리소스의 크기를 유추할 수 있어야 합니다. 레이아웃이 계산되면 광고, 이미지, 오디오 및 비디오가 아직 로드되지 않은 경우에도 기사가 렌더링되고 독자가 기사와 상호 작용할 수 있습니다. (또한 이러한 리소스가 로드되면 문서 레이아웃을 업데이트하여 읽기 환경을 방해하지 않고 원활하게 렌더링됩니다.)
• AMP 기사는 반응형이어야 합니다. "Accelerated Mobile Pages"라는 이름에서 알 수 있듯이 AMP 문서는 특히 모바일 장치용입니다. 따라서 이 컨텍스트에서 "반응형"에는 데스크톱 해상도가 포함되지 않습니다. 오히려 AMP 문서는 사람들이 여전히 사용하고 있는 작고 오래된 iPhone 4 유물부터 상대적으로 거대한 iPad Pro에 이르기까지 모든 모바일 기기에서 잘 보일 것입니다.

전자의 목표는 주로 외부에서 로드된 모든 리소스에 width 및 height 속성이 있어야 한다는 요구 사항에 의해 달성됩니다(또한 새 리소스를 삽질할 수 없도록 하는 제한 스크립트를 통해 더욱 강화됨). 후자는 표준 미디어 쿼리, media 속성, sizes 속성 및 AMP별 layout 속성에 의해 달성됩니다.

다음은 AMP가 현재 지원하는 레이아웃의 개요입니다.

• nodisplay 요소는 처음에 표시되지 않지만 표시는 사용자 작업에 의해 트리거될 수 있습니다. ( 이것은 amp-lightbox 와 같은 구성요소와 함께 사용됩니다.)
• fixed 요소의 너비와 높이가 고정되어 런타임에서 반응형 동작을 적용할 수 없습니다.
• responsive 제 생각에는 이것이 AMP 레이아웃 옵션 중 가장 유용하고 마법 같은 것입니다. 요소는 종횡비를 유지하면서 할당된 공간을 사용합니다. (기본적으로 "어떤 해상도에서도 잘 보이도록 해주세요. 감사합니다.")
• fixed-height 요소는 할당된 공간을 사용하지만 고정 높이를 유지합니다(수평으로 크기 조정).
• fill 요소는 종횡비에 관계없이 요소가 있는 컨테이너를 채웁니다. ( width: 100% 및 height: 100% % 라고 생각하십시오.)
• container 요소는 컨테이너이므로 표준 div 요소와 똑같이 자식(부모가 아닌)이 크기를 정의할 수 있습니다.

AMP의 레이아웃 시스템을 사용하여 기능적이고 간단한 문서 레이아웃을 달성하는 것은 상대적으로 쉽지만, AMP가 지원하는 모든 것과 값이 다양한 유형의 요소에 적용되는 방식을 고려할 때 상당한 뉘앙스가 있습니다. 훨씬 더 자세한 분석은 AMP 레이아웃 사양을 참조하세요.

SVG는 어떻습니까?

지원! 기본 SVG는 데스크톱 및 모바일 브라우저 모두에서 포괄적인 지원을 제공하며 그래픽은 벡터보다 훨씬 더 반응이 좋지 않으므로 AMP와 SVG는 매우 좋은 팀입니다. 가장 큰 제한은 스크립팅 제한으로 인해 JavaScript로 벡터에 애니메이션을 적용할 수 없다는 것입니다. 솔직히 말해서 모바일에서는 해서는 안 됩니다. 그러나 SVG에 생명을 불어넣어야 한다면 위의 스타일링 섹션에서 설명한 것과 동일한 제약 조건에 따라 CSS 애니메이션을 사용하여 여전히 그렇게 할 수 있습니다. SVG는 DOM의 일부이므로 다른 요소처럼 쉽게 스타일을 지정하고 애니메이션을 적용할 수 있습니다.

JavaScript에 대한 AMP의 철학

좋은 소식과 나쁜 소식이 있습니다. 나쁜 소식은 곧 AMP 문서용 JavaScript를 작성하지 않을 것이라는 점입니다. 하지만 어떤 면에서는 좋은 소식이기도 합니다. AMP는 모바일 애플리케이션 프레임워크가 아닙니다. 오히려 모바일 기사 프레임워크이며 기사는 매끄럽고 유동적인 읽기 경험에 최적화되어야 하기 때문에 무거운 클라이언트 측 스크립팅에 대한 좋은 사용 사례는 실제로 많지 않습니다.

즉, 모든 JavaScript를 영원히 금지하는 것은 비현실적이며 약간 가혹합니다. 현실은 웹이 광고, 분석 및 인터랙티브 기능과 같은 일을 위해 지금까지 한동안 JavaScript에 의존해 왔습니다. 또한 웹의 가장 좋은 점 중 하나는 개방성과 실험, 표현력 및 창의성에 대한 무한해 보이는 능력입니다. 이 중 상당 부분은 JavaScript로 구동됩니다.

임의의 사용자 작성 JavaScript가 성능 보장에 가하는 부담과 최신 웹 환경에서 JavaScript의 편재성과 불가피성을 모두 인식하여 AMP 팀은 다음 스크립팅 원칙을 제시했습니다.

• 현재 사용자 작성 JavaScript가 지원되거나 허용되지 않습니다. AMP 문서에는 두 가지 유형의 스크립트 태그만 있을 수 있습니다. 연결된 데이터 태그(유형이 application/ld+json 인 경우)와 AMP 런타임 및 확장 AMP 구성요소를 모두 포함하기 위한 태그입니다.
• AMP 프로젝트의 작성자는 모바일 기사 소비의 맥락에서 JavaScript에 대한 대부분의 요구를 예상했으므로 AMP는 대안( amp-pixel , 링크 태그가 있는 사용자 정의 글꼴 포함 또는 @font-face 규칙 등)을 지원하거나 AMP 런타임과 호환되므로 보안과 성능을 모두 보장하는 구현을 제공합니다( amp-ad , amp-analytics , amp-carousel 등).
• 대화형 기능과 같은 기능에 자바스크립트를 사용해야 하는 경우 기능을 독립적으로 빌드한 다음 [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) 태그. amp-iframe 에 포함된 콘텐츠는 크기 조정 요청과 같은 경우 상위 문서와의 제한된 통신도 허용됩니다.
• AMP 구성 요소는 오픈 소스(Apache 2)이며 기여에 열려 있으므로 시간이 지나면 새로운 구성 요소가 나타날 것입니다(사실 이 기사를 작성하고 편집하는 과정에서 여러 개의 새로운 구성 요소가 나타났으므로 이미 몇 번 업데이트했습니다). AMP 팀은 서비스별 기능(예: 소셜 스타트업을 위한 위젯)보다 일반화된 구성 요소를 우선시하지만 가능한 가장 광범위한 콘텐츠를 수용할 수 있도록 충분한 다양성을 제공하기 위해 노력합니다.
• 마지막으로 이러한 모든 정책은 변경될 수 있습니다. 웹 작업자, 사용자 지정 요소 및 섀도우 DOM과 같은 브라우저 기능이 더 널리 지원됨에 따라 보안 및 성능을 계속 보장하면서 사용자 작성 JavaScript 및 사용자 지정 구성 요소를 지원하는 옵션이 크게 확장될 것입니다.

AMP 구성 요소의 미래에 대한 자세한 내용은 "AMP HTML 구성 요소" 사양의 "확장 구성 요소" 섹션을 참조하세요.

AMP 문서의 구조

이제 AMP HTML에 대해 확실히 이해했으므로 상용구를 분석해 보겠습니다.

물론 doctype 선언으로 AMP 문서를 시작합니다.

 <!doctype html>

다음으로 HTML 문서를 AMP HTML로 지정합니다. 믿거나 말거나 고전압 이모티콘을 html 태그의 속성으로 사용합니다.

 <html >

또는 구식 curmudgeon이고 사랑스러운 이모티콘으로 코드를 꾸미는 아이디어에 뻣뻣하다면 훨씬 보수적인 amp 속성을 대신 사용할 수 있습니다.

 <html amp> <!-- A good sign that you're boring! -->

head 태그에서 utf-8 문자 인코딩 지침을 잊지 마십시오.

 <meta charset="utf-8">

그리고 문서의 비 AMP 버전에 대한 링크(중복 콘텐츠로 표시되지 않도록 canonical 으로 표시됨):

 <link rel="canonical" href="my-non-amp-index.html">

반대로 AMP가 아닌 버전에는 AMPlified 문서에 대한 참조가 포함되어야 합니다.

 <link rel="amphtml" href="my-amp-index.html">

AMP 페이지는 모바일 기기용(GPU 래스터화도 원함)이므로 메타 viewport 태그를 포함해야 합니다.

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

다음 코드 줄은 약간 이상하게 보일 것입니다. 글꼴이 로드 및 적용되기 전에 웹 페이지가 텍스트를 간략하게 렌더링한 다음 깜박이고 디자이너가 의도한 대로 다시 렌더링되는 경우가 있다는 것을 알고 계십니까? 아래 태그는 적절한 스타일이 지정될 때까지 페이지의 불투명도를 0 (보이지 않음)으로 유지합니다.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

이 접근 방식의 문제는 AMP 런타임 로드에 실패할 경우 페이지의 불투명도가 0 에서 1 로 절대 떨어지지 않을 수 있다는 점입니다. 이러한 우발 상황을 보완하기 위해 위의 코드는 다음과 같이 변경될 수 있습니다.

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

다음으로 할 일은 AMP JavaScript 런타임을 포함하는 것입니다.

 <script async src="https://cdn.ampproject.org/v0.js"></script>

그리고 필요한 확장 구성 요소에 대한 JavaScript 구현을 포함합니다.

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

( async 속성의 사용에 유의하십시오. 이는 선택 사항이 아닙니다. 차단이 적을수록 좋습니다.)

선택적으로 다음과 같이 약간의 연결된 데이터를 뿌릴 수 있습니다.

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

이제 CSS에서 link 태그 또는 @font-face 규칙을 사용하여 몇 가지 글꼴을 추가해 보겠습니다.

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

그런 다음 필수 amp-custom 속성을 사용하여 몇 가지 스타일(50KB 이하)을 지정합니다.

 <style amp-custom>

이제 AMP HTML에 대해 배운 모든 내용을 사용하여 어느 정도 표준 HTML 문서를 작성할 준비가 되었습니다.

AMP 런타임

모든 런타임과 마찬가지로 AMP 런타임은 일종의 블랙박스이기 때문에 AMP 런타임에 많은 시간을 할애하지 않겠습니다. 그렇다고 AMP 런타임에 액세스할 수 없다는 것은 아닙니다(나머지 프로젝트와 마찬가지로 오픈 소스임). 오히려 모든 좋은 런타임과 마찬가지로 개발자는 일반적으로 기능을 이해하는 한 이를 활용하기 위해 어떻게 작동하는지 정확히 알 필요가 없습니다.

AMP 런타임은 전적으로 JavaScript로 구현되며 외부 JavaScript 파일과 마찬가지로 AMP 문서에 포함하여 시작됩니다.

 <script async src="https://cdn.ampproject.org/v0.js"></script>

여기에서 AMP 런타임은 주로 다음 세 가지 작업을 수행합니다.

• 리소스 로딩 및 우선순위 관리,
• AMP 구성요소를 구현하고
• 선택적으로 AMP HTML용 런타임 유효성 검사기를 포함합니다.

유효성 검사기는 AMP 호환 문서를 작성하는 데 중요합니다. 문서의 URL에 #development=1 을 추가하기만 하면 켤 수 있습니다. 그런 다음 콘솔을 열어 성적표를 보기만 하면 됩니다.

오류는 다음과 같습니다.

훌륭하고 깨끗하며 규정을 준수하는 AMP 문서는 다음과 같습니다.

(선택 사항) AMP 캐시

AMP 문서는 다른 HTML 문서와 마찬가지로 웹 서버에서 제공할 수 있지만 특수 AMP 캐시에서도 제공할 수 있습니다. 선택적 캐시는 여러 기술을 사용하여 AMP 문서를 훨씬 더 최적화합니다.

• 이미지 참조는 뷰어의 뷰포트에 맞게 특별히 크기가 조정된 이미지로 대체할 수 있습니다.
• 스크롤 없이 볼 수 있는 이미지는 추가 HTTP 요청을 저장하기 위해 인라인될 수 있습니다.
• CSS 변수를 인라인하여 클라이언트 측 오버헤드를 줄일 수 있습니다.
• 확장 AMP 구성요소 구현을 미리 로드할 수 있습니다.
• HTML 및 CSS를 축소하여 유선(또는 이 경우 전파)을 통해 전송되는 바이트 수를 줄일 수 있습니다.

누구나 자신의 CDN에서 자신의 AMP 캐시를 실행할 수 있으며 게시자는 Google의 캐시를 무료로 사용할 수 있습니다. Google이 확장성에 대해 한두 가지를 알고 있는 것 같다는 점을 감안할 때 대부분의 AMP 채택자들이 기꺼이 그 제안을 받아들일 것이라고 생각합니다. (Google의 캐시를 선택하는 방법에 대한 문서가 곧 나올 예정이지만 Google이 이미 인터넷을 색인화하고 캐시한다는 점을 감안할 때 link 태그와 추가 meta 태그를 중심으로 회전할 것이라는 점은 확실합니다.)

독자는 AMP 콘텐츠를 어떻게 찾나요?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

물어봐주셔서 기쁩니다. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

추가 리소스

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11