블로그를 리뉴얼 하다.에서 언급했던 AMP(Accelerated Mobile Pages)를 이 블로그에 적용했다.
AMP를 적용한 이유는 다분히 SEO를 테스트하기 위함이다. AMP를 적용한다고 구글에서 무조건 상위에 노출시켜주는 것은 아니다. 하지만 빠른 페이지 로딩은 SEO에 도움을 주기 때문에 간접적으로 SEO에 도움이 된다.
실제로 AMP를 적용한 것은 좀 됐는데 구글에서 해당 페이지를 재색인해서 반영되는 시간을 기다리느라고 이제서야 글을 쓴다.
사실 AMP를 적용하는 것은 그리 간단하지는 않았다. AMP의 요구사항을 충족시키는 것을 간단하게 생각했으나 실제로 작업하다보니 여러가지 문제에 부딪혔다. 그중에서 몇가지와 추가적으로 알게된 사항을 나열하자면 아래와 같다.
- AMP 적용을 고려해서 페이지의 구조 설계해야 한다.
- 모든 이미지는 사이즈를 알고 있어야 한다.
- Google AMP Cache는 페이지를 변형한다(일종의 최적화를 하고 상단에 사이트명을 출력하는 Header를 추가한다).
- 블로그를 리뉴얼 하다. - 원본
- 블로그를 리뉴얼 하다. - Google AMP Cache에서 보여주는 화면
- 이로인해 페이지가 의도하지 않은 상황을 만들 수 있다. 이 블로그도 아직 몇가지를 수정해야 한다(모바일에서 우상단에 메뉴 링크가 비정상적으로 동작하는 경우가 있다).
- 외부 자바스크립트를 사용하지 못하므로 스크립트에 의존하는 페이지를 구성하면 안된다
- 완전히 불가능한 것은 아니지만 쉽지 않다. Google AMP best way to write JS script tag
- iframe에서 불려지는 페이지의 도메인은 서비스되는 도메인과 같을 수 없다.
- 일반적으로는 보안상 동일한 도메인을 요구하지만 여기서는 반대다. 인터넷에서 누군가가 보안상의 이유라고 하는데 정확한 이유는 확인해보지 않았다.
- 이 사항은 블로그에서 사용하는 Disqus를 AMP 페이지에도 적용하면서 알게 되었다. Disqus in Amp라는 페이지에 잘 설명되어 있는데 Disqus를 출력할 iframe 도메인 문제를 page on an s3 bucket로 해결한다.
- AMP Components 들의 동작이 다소 불안하다(반응형 레이아웃을 사용할 경우 : 반응형 이미지, 반응형 iframe 등).
- AMP Components 들은 AMP 페이지가 아니더라도 사용할 수 있다(실제로 글 하단의 SNS 공유 기능이 AMP Components에서 제공하는 기능이다).
그 외에도 Schema.org의 적용이 필요한데 여기서도 약간의 어려움이 있다(이미지와 로고가 포함되어야 하고 사이즈도 정해준 기준에 맞춰야 하는 등).
주저리주저리 여러가지 이야기를 했지만 결론은 하나다.
AMP를 직접 적용해보는 것이 가장 빨리 이해할 수 있는 방법이다.
사실 누군가는 "굳이 AMP 적용을 할 필요가 있는가?"라고 이야기 한다. 나의 생각도 크게 다르지 않다. 하지만 AMP의 가이드를 따라 페이지를 제작하다보면 보다 빠른 웹페이지를 설계하고 구축할 수 있는 아이디어를 얻을 수 있을 것이다. 나 또한 앞서 이야기 한 것과 같이 다분히 실험적인 이유로 AMP를 적용해 봤다.
참고로 이 블로그는 지난 글에서 이야기한 것과 같이 PHP로 직접 만든 정적 페이지 생성기에 의해 제작된다. 그래서 markdown이 파싱된 결과를 AMP에 호환되도록 변형하는데 lullabot/amp를 사용했다. 블로그다 보니 특별히 복잡한 구조가 없어서 그런지 현재까지 큰 문제없이 사용중이다.