AMP Conf 2018. Feb 13/14. Amsterdam.
AMP Conf. Feb 13/14.

설계 원칙

이러한 설계 원칙은 AMP의 지속적인 설계 및 개발을 안내하기위한 것입니다. 그들은 우리가 내부적으로 일관된 결정을 하도록 도와야합니다.

사용자 경험 > 개발자 경험 > 구현의 용이함

불확실한 경우, 페이지 제작자나 라이브러리 개발자가 구현이 어렵다고 하더라도, 최종 사용자 경험에 가장 적합한 것을 하세요.

더 빠른 브라우저가 나올 것이라는 가정 하에 설계하지 마세요.

우리는 내일의 웹이 아닌 현재의 웹을 수정해나가기 위한 확장성 있는 웹 선언문의 정신으로 AMP를 라이브러리로 구축하기로 했습니다. AMP는 현재의 브라우저에서 빠릅니다. 현재 플랫폼에서 최적화가 불가능한 경우, AMP 개발자가 표준 개발에 참여하여 웹 플랫폼에 이런 기능을 추가해야 합니다.

웹을 망가뜨리지 마세요.

즉, Google AMP Cache, URL API 또는 라이브러리에 오류가 발생하면 웹 사이트나 대상 앱에게 단계적 축소(Graceful degradation)를 제공할 수 있어야 합니다. 예를 들어, AMP 캐시와 함께 동작하는 어떤 기능은 AMP 캐시가 없어도 동작가능해야 합니다.

올바른 레이어에서 문제를 해결하십시오.

예를 들어, 서버 사이드에서 사용자 환경을 개선하는 것이 맞음에도 더 쉽다는 이유로 클라이언트 사이드에서 모든 것을 통합해서는 안됩니다.

빠르게 실행 가능한 경우에만 처리하세요.

AMP에 60fps에서 안정적으로 동작하지 않는 기능이나 컴포넌트를 도입하거나, 현존하는 가장 일반적인 모바일 기기에서 즉각적인 로딩 경험을 방해하지 마십시오.

사용자 경험을 향상시키는 것에 우선순위를 두세요. 하지만 때로는 타협도 필요합니다.

어떤 사항들은 빠르게 만들 수 있지만, 사용자 경험 측면에서는 여전히 끔찍한 경우가 존재합니다. AMP는 환상적인 사용자 경험을 제공해야 하며 속도는 그 중 일부일 뿐입니다. 어떤 사항들에 대한 지원이 부족한 경우 유일한 타협점은 AMP를 널리 사용하거나 배포되는 것을 중단하는 것입니다.

화이트 리스트의 부재

보안 또는 성능상의 이유로 필요한 경우를 제외하고는 특정 사이트, 도메인 또는 출처에 대해 특별한 처리를 하지 않을 것입니다.

구현 시작하기