AMP 캐시를 사용하면 장단점이 있지만 일관되게 빠른 속도를 제공하고 사용자에게 친숙한 환경을 보장해 주므로 사용자에게는 유리합니다. AMP 캐시는 다음과 같은 목적으로 설계되었습니다.
- 모든 AMP 페이지가 실제로 유효한 AMP인지 확인합니다.
- AMP 페이지가 효율적이고 안전하게 미리 로드되도록 허용합니다.
- 콘텐츠에 대해 사용자에게 유리한 추가 성능 최적화를 무수히 많이 수행합니다.
하지만 우선 다음 사항부터 살펴봐야 합니다.
기본 사항: 분석 귀인 및 링크 공유
AMP 캐시 모델이 원본 모델(게시자 자체 도메인에서 페이지 제공)을 따르지 않더라도 모든 트래픽을 게시자 때문인 것으로 돌립니다. <amp-analytics> 태그를 통해 AMP는 점점 증가하는 분석 제공업체(현재까지 26개에 달하며 계속 증가하는 추세임
)를 지원하여 게시자의 성공 정도를 평가하고 트래픽의 귀속성이 올바로 확인되도록 합니다.
사용자와 개발자들에게 캐시된 AMP 결과에서 정규 페이지로 "클릭"하여 이동하고 싶은 이유를 물어보면 종종 링크 공유를 답변으로 내놓는 경우를 접하게 됩니다. 물론 당연한 얘기입니다. 정규 URL 대신 google.com URL을 복사하는 건 성가신 일이죠. 하지만, 이는 생각하시는 것처럼 그리 큰 문제는 아닙니다. Google에서는 Schema.org 및 OpenGraph 메타데이터를 사용하여 캐시된 AMP 검색 결과를 수정하므로, 이를 따르는 모든 플랫폼에 링크를 게시하면 기본 URL이 공유되게 됩니다. 말이 나온 김에, 공유 흐름을 향상시킬 수 있는 기회가 더 있습니다. 네이티브 웹 뷰에서 앱이 지원한다면 직접 정규 URL을 공유할 수 있습니다. 또한, 사용자 피드백에 따라 Google 팀은 모든 프레임에서 정규 URL에 손쉽게 액세스할 수 있도록 하기 위한 작업을 현재 진행 중입니다.
이러한 사항을 살펴봤으므로 이제 좀 더 깊이 들어가 봅시다.
레이블이 AMP를 나타내는 경우 AMP 구현 가능
AMP 프로젝트는 매우 높은 성능 및 품질 기준을 충족하도록 엄격한 유효성 검사를 사용하는 에코시스템으로 구성되어 있습니다. 개발 과정에서 특정 버전의 유효성 검사기를 사용할 수 있지만, AMP 캐시는 콘텐츠를 사용자에게 표시할 때 마지막 단계에서 유효성을 확인합니다.
어떤 AMP 페이지가 AMP 캐시에서 처음으로 요청될 때는 캐시가 먼저 문서의 유효성을 검사하고 문제가 발견되면 사용자에게 해당 문서를 제공하지 않습니다. AMP를 통합한 플랫폼(예: Bing, Pinterest, Google)은 트래픽을 원본 서버에서 AMP 페이지로 직접 전송하거나 AMP 캐시로 전송하도록 선택할 수 있습니다. 단, 캐시에서 제공될 때만 유효성이 보장됩니다. 따라서 사용자에게 AMP 레이블이 보인다면 거의 항상 빠르고 사용자에게 친숙한 환경을 이용할 수 있게 됩니다. 느리지만 유효한 AMP 페이지를 작성하는 것은 어렵지만 불가능한 일은 아닌데, 어쨌든 이런 페이지를 작성할 방법을 찾지 못하신다면 제가 알려드리죠. 큰 웹 글꼴을 사용하면 됩니다.
생각보다 훨씬 더 유용한 사전 렌더링 기능
이 게시글에서 명심해야 할 점이 있다면 그것은 바로 사전 렌더링일 것입니다. 특히, AMP의 변형을 사전 렌더링하는 경우 원본 서버에서 직접 호스팅함으로써 이론상 얻을 수 있는 속도 이득보다 훨씬 더 큰 이득을 얻을 수 있습니다. 원본 서버가 몇 밀리초를 단축할 수 있을 정도로 사용자에게 가깝게 있더라도(드물기는 하나 가능한 일임) 사전 렌더링이 거의 확실히 가장 큰 영향을 미치는 요소입니다.
훨씬 더 빠르게 인지
사실, 사전 렌더링을 사용하면 몇 밀리초가 아니라 수초의 시간을 단축할 수 있는 경우가 많습니다. AMP JS 라이브러리의 다양한 다른 성능 최적화 기능과 상반되게 사전 렌더링이 미치는 영향은 꽤 극적일 수 있으며, "즉각적인 느낌"의 환경에 크게 기여합니다.
전체 사전 렌더링에 비해 매우 뛰어난 효율성 제공
이것이 전부라면 원본 서버에서 AMP 페이지를 사전 렌더링하는 것처럼 쉽게 처리할 수 있을 것입니다. 하지만 그럴 경우 페이지가 원본 서버에서 유효한 AMP인지 보장할 수 없으며, 따라서 유효한 AMP가 AMP JS 라이브러리에서 제공하는 맞춤형 사전 렌더링에 매우 중요합니다. 링크 프리페치와 같은 기능을 통해 전체 페이지를 사전 렌더링하는 것과 다르게 AMP에서 사전 렌더링을 구현하면 사용자의 대역폭, CPU 및 배터리를 적게 사용하게 됩니다!
유효한 AMP 문서는 사전 렌더링 단계에서 다음과 같이 "협조적인 방식으로" 동작합니다. 첫 번째 표시 영역의 자산만 사전 로드되며, 타사 스크립트는 실행되지 않습니다. 따라서 사전 로드 작업 시 비용이 적게 들고, 대역폭 및 CPU 사용이 적으므로 플랫폼이 첫 번째 표시 영역뿐만 아니라 사용자가 클릭할 가능성이 있는 몇몇 AMP 페이지도 사전 렌더링할 수 있습니다.
안전하게 삽입 가능
AMP 캐시는 브라우저 사전 렌더링에 의존할 수 없으므로(위 섹션 참조) 페이지 간의 일반적인 탐색 기능이 작동하지 않습니다. 따라서, AMP 캐싱 모델에서는 페이지가 플랫폼 페이지에서 인라인으로 열려야 합니다. AMP 캐시는 요청된 AMP 페이지가 이러한 작업을 안전하게 수행할 수 있도록 보장합니다.
- 유효성 검사기는 기본 문서에서 교차 사이트 스크립팅(XSS)이 없는지 확인합니다.
- AMP 캐시는 유효성 검사기를 기반으로 명확한 방식으로 문서를 파싱한 후 다시 직렬화합니다(즉, HTML5 오류 수정에 의존하지 않음). 따라서 브라우저 파싱 버그 및 차이로 인해 XSS가 발생하지 않도록 합니다.
- 캐시는 콘텐츠 보안 정책(CSP)을 적용합니다. 이를 통해 XSS 공격에 대한 심층 방어를 추가로 제공합니다.
추가적인 개인정보 보호
그 밖에도, AMP 캐시는 사전 렌더링에서 발생할 수 있는 중요한 개인정보 보호 문제를 없애줍니다. 결과 페이지에서 AMP 페이지를 사전 로드하는 콘텐츠 플랫폼에서 검색을 수행하는 경우 사전 로드된 AMP 페이지 중 어떤 페이지도 자신이 사전 로드되었다는 사실을 인식하지 못합니다.
이를 다음과 같은 식으로 생각해 보세요. 예컨대 제가 "breakfast burrito"를 검색한다고 해봅시다. 저를 잘 알고 계시다면 제가 분명히 Parry Gripp의 노래 제목을 검색했다고 생각하실 겁니다. 하지만 검색 결과 페이지에는 실제로 부리토 아침 메뉴를 판매하는 패스트푸드 체인점에서 찾은 AMP 검색 결과 두어 개도 표시됩니다. 이런 검색을 한 후 한 달 동안은 위의 링크를 클릭하지 않았다면 어디서도 실제 부리토 아침 메뉴와 관련된 링크를 보고 싶지 않을 것입니다. 설령 이런 링크를 클릭했다 하더라도 말입니다. 광고주 역시 저처럼 당장은 부리토에 아무런 관심도 없는 사람에게 무의미하게 부리또에 대한 리마케팅 광고를 하느라 돈을 낭비하고 싶지 않을 것입니다. AMP는 AMP 페이지 게시자와 그와 관련된 제삼자가 제공하는 사전 로드를 숨겨주므로 사용자와 광고주 모두 윈윈하게 됩니다.
극적인 속도 향상 결과를 가져다 주는 경우가 많은 자동 최적화
AMP 캐시는 처음에는 위에서 설명한 모든 기능과 함께 제공되었지만 그 이후 기능에 많은 혁신적인 변화가 있었습니다. 이러한 최적화 중 몇 가지를 예로 들면 다음과 같습니다.
- 모든 콘텐츠(대규모 게시자로 국한되지 않음)에 대해 일관되고 빠르고 자유로운 콘텐츠 전송 네트워크
- 스크립트를 이상적인 순서로 가져오고, 중복된 스크립트 태그를 제거하고 불필요한 따옴표 및 공백을 제거하는 등의 방법을 통해 HTML 최적화
- 캐시 시간의 제한이 없도록 JavaScript URL 재작성
- 이미지 최적화(평균적으로 40%의 대역폭 향상 실현!)
이미지 압축 측면에서만 보면 Google은 캐시를 통해 무손실(EXIF 데이터 제거와 같은 어떠한 시각
적 변화도 없음) 및 손실(뚜렷한 시
각적 변화는 없음) 압축을 수행하고 있습니다. 또한, WebP를 지원하는 브라우저에 대해 이미지를 WebP로 변환하고 각 기기에 올바른 크기의 이미지를 생성하고 표시하는 데 srcset 속성을 아직 사용할 수 없는 경우 srcset 속성을 자동으로 생성합니다(소위 반응형 이미지라고 함).
이러한 작업을 수행하는 더 나은 방법은 없을까요?
저는 여러분의 말에 귀를 기울입니다. AMP 캐시 제공업체는 여러분의 콘텐츠를 미러링합니다. 이는 중요한 역할이며 큰 책임을 수반합니다. 캐시 제공업체가 모든 AMP 페이지에 기분 나쁜 광고를 삽입하는 것과 같이 정말로 어리석은 일을 할 경우 AMP는 게시자에게 더 이상 실행 가능한 솔루션으로서의 이점을 제공하지 않게 되며, 따라서 그 효과 역시 사라져버립니다.
AMP는 게시자, 사용자 및 플랫폼에 더 나은 모바일 웹을 만들기 위한 수단으로 게시자와 함께 협력하여 생성되었다는 점을 잊지 마시기 바랍니다. 이것이 바로 AMP 팀이 AMP 캐시에 대한 엄격한 가이드라인을 발표한 이유입니다. 그 중에서 여러분에게 두 가지 흥미로운 사항을 발췌해서 알려드리자면 콘텐츠는 "원본 문서에 충실한 시각적 및 UX 재현"을 제공해야 하고 캐시 제공업체는 캐시에 대한 서비스가 해제되더라도 URL이 무기한 작동하도록 유지하겠다는 약속을 해야 합니다. 그 밖에도 많은 규칙이 더 있으므로 캐시로 인해 콘텐츠가 좋지 않은 영향을 받는 일이 없도록 보장됩니다.
가장 중요한 점은 여러 AMP 캐시를 사용할 수 있는 충분한 옵션이 있다는 점입니다. 실제로 Cloudflare는 자체 캐시를 바로 얼마 전에 발표했습니다. 이러한 AMP 캐시 가이드라인이 발표됨에 따라 다른 인프라 업체도 규칙을 따르기만 한다면 새로운 AMP 캐시를 만들 수 있습니다. 원하는 캐시를 고르는 것은 AMP를 통합하는 플랫폼에 달려 있습니다.
캐시에서 웹 표준으로 나아갈 길
즉각적인 느낌을 주며 사용자에게 친숙한 모바일 웹 환경을 제공하기 위해 AMP 캐시에서 제공하는 이점과 그에 따른 절충점에 대해 살펴봤습니다. 이런 절충 과정 없이 캐시를 전혀 사용하지 않고도 이처럼 멋진 최적화 기능을 많이 이용할 수 있다면 어떻겠습니까?
개인적으로 저는 자산이 로드되기 전에 페이지의 표시 방식을 파악할 수 있는 정적 레이아웃 시스템과 같이 캐시 모델을 뛰어넘을 수 있는 웹 표준이 미래에도 계속해서 발명될 것을 기대합니다.
2016년에 저희는 CPP로 첫 번째 걸음마를 내디뎠으며, 이는 주요 정책으로 바뀌었습니다. 이는 "내 사이트와 타사 사이트에서 로드되는 모든 iframe에서 document.write를 허용하지 않음"과 같은 규정을 나타내는 방법입니다. 정적 레이아웃 및 안전한 사전 렌더링과 같이 더욱 진보된 개념을 구현하기 위해서는 웹 플랫폼에 터무니 없을 정도의 변경 작업이 필요합니다. 미래로 떠나는 시간 여행과 같이 아주 많이 어렵기는 하겠지만 불가능하지는 않을 것입니다.
Twitter 또는 Slack에서 저와 친구를 맺어 이에 대해 함께 알아보면 좋겠습니다. 저는 항상 여러분이 가지고 있는 질문 사항, 아이디어, 문제점을 귀 기울여 들을 것입니다. 계속 앞으로 나아갑시다!
게시자: Paul Bakaus, Google의 AMP 디벨로퍼 어드보케
