한국의 개발자들을 위한 Google for Developers 국문 블로그입니다.
AMP를 훨씬 빠르게 만드는 방법
2018년 11월 20일 화요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 번역 리뷰에는
Jimmy Moon(Webtech GDE)
님이 참여해 주셨습니다.>
게시자: Sebastian Benz, Google 파트너 디벨로퍼 Advocate
ampproject.org에 “
Optimizing your hosted AMP pages
”(호스트된 AMP 페이지의 최적화)에 관한 새로운 가이드를 게시했었습니다. AMP 문서를 최적화하여 훨씬 더 빠르게 로드되도록 할 수 있는 방법을 설명한 가이드입니다.
'잠깐, AMP는 원래 빠르게 로드되도록 만든 페이지 아냐?'라고 생각하실지 모르겠습니다. 물론 그 생각이 맞습니다. AMP 런타임은 속도에 최적화되어 있어 유효한 AMP 페이지는 모두 빠르게 로드됩니다. 하지만 브라우저가 AMP 페이지를 훨씬 더 빠르게 로드하는 데 도움이 되도록 구현할 수 있는 추가적인 성능 최적화가 있습니다. 이러한 변화는 사소한 것이지만, AMP의 유효성을 깨뜨리지 않고 로딩 성능을 상당히 개선할 수 있습니다.
예를 들어 XWP에서 개발 중인
AMP WordPress 플러그인
은 가이드에 설명되어 있는 기술 중 몇 가지는 이미 제공되고 있습니다. 이에 따라
xwp.co
의 로딩 시간이
12.6%
빨라졌습니다.
또 다른 예는
Evening Standard
인데, 이 회사는 한 걸음 더 나아가 SSR(server-side-rendering)로 최적화된 AMP를 게시합니다. 그 결과, 유효한 AMP 버전보다 FCP가
69%
향상되었습니다.
관심을 가져야 할 이유는?
한발 물러나 생각해 봅시다. 이게 과연 필요한 걸까요? AMP 문서는
이 모든 최적화
를 자동으로 수행하는 AMP 캐시에 의해 항상 제공되는 게 아닌가요? AMP 문서가 Google 또는 Bing 검색결과에 노출될 때와 같은 몇 가지 경우에는 그 말이 맞습니다. 하지만 다음과 같이 AMP 문서가 출처에서 제공되는 경우도 있습니다.
https://tasty.co
와 같이 정규 웹페이지나 모바일 웹페이지를 AMP로 빌드할 때.
출처에 있는 AMP 문서에 대한 다른 플랫폼 링크. 예를 들어 Twitter는 표준 모바일 버전을 제공하는 대신
AMP 페이지에 대한 링크 연결을 시작
했습니다. 즉, 사용자가 Twitter의 모바일 앱 중 하나에 있는 링크를 클릭하면 링크가 개발자의 자체 서버에 있는 페이지의 AMP 버전으로 이동한다는 의미입니다.
이와 같이 자체 서버에서 AMP 페이지를 제공하는 경우, AMP 페이지가 최적의 로딩 성능을 제공하도록 하는 것이 중요합니다.
브라우저가 AMP 페이지를 더 빠르게 로드할 수 있게 하는 방법은?
AMP의 로딩 성능 최적화가 작동하는 방식을 빠르게 살펴봅시다. amp-img 또는 amp-video와 같은 AMP 특정 요소가 작동하도록 AMP 런타임을 로드할 필요가 있습니다. 즉, amp-img는 AMP 런타임이 로드된 후 이미지를 다운로드하기 시작할 뿐이라는 의미입니다.
따라서 다음과 같이 AMP 페이지가 더 빠르게
로드되도록
만들 수 있는 두 가지 기회가 주어집니다.
브라우저가 AMP 런타임을 최대한 빠르게 다운로드하는지 확인하세요.
AMP 런타임을 사용할 수 있기 이전에
이미지와 같이 중요한 자산의 다운로드를 시작하도록 브라우저를 설정하세요.
이런 결과를 얻기 위한 관건은
rel=preload
와 같은 리소스 힌트를 사용하여 중요한 리소스의 다운로드 우선순위를 정하는 것입니다.
AMP 최적화 가이드
에서는 리소스 힌트를 사용하여 AMP 페이지를 최적화할 수 있는 다양한 방법을 설명합니다. 최적화된 AMP 템플릿을 빠르게 생성할 수 있게 해주는
AMP Boilerplate Generator
를 살펴보는 것도 좋은 생각입니다.
first-contentful-paint를 향상할 방법은?
성능 최적화를 한 단계 더 진행할 수도 있습니다. AMP 런타임은
정적 페이지 레이아웃 시스템
을 구현하여 렌더링과 스크롤링 정크를 줄입니다. AMP 런타임이 로드될 때까지
AMP 상용구 코드
가 처음에는 문서를 숨기는 방식으로 작동합니다. AMP 런타임은 로드된 후 레이아웃을 계산하고 그 내용을 보여줍니다. 이 접근 방식은 AMP 런타임이 로드될 때까지는 사용자에게 빈 페이지가 표시된다는 단점이 있고 프로그레시브 렌더링을 지원하지 않습니다.
이런 부정적 측면을 상쇄하기 위해 AMP
SSR(server-side-rendering)
을 사용하여
FCP(first-contentful-paint)
시간을 개선할 수 있습니다. 이런 식으로, AMP 런타임 자바스크립트를 실행하지 않고 AMP 문서를 페인팅할 수 있도록 AMP 상용구를 제거할 수 있습니다. 예를 들어
AMP Boilerplate Generator
의 SSR 버전은 일반 AMP 버전보다
2배 빠르게 렌더링
합니다.
서버에 있는 AMP 문서의 최적화 방법을 알아보려면
AMP Optimizer
를 확인해보세요.
성능 향상이란?
최적화가 로딩 성능에 어떤 영향을 주는지 알아보기 위해 필자는 다음과 같이
AMP Start Bike Shop 템플릿
의 방문 페이지를 세 가지 다른 버전으로 만들어 보았습니다.
이미지 없음
: 로드되는 AMP 런타임에 종속되는 시각적 콘텐츠가 없는 최상의 사례를 보여주는 시나리오를 시뮬레이션하기 위한 버전
이미지
: 콘텐츠가 로드되는 AMP 런타임에 종속될 때의 로딩 시간을 보여주기 위한 버전
자체 호스트 글꼴:
커스텀 폰트에 따른 영향을 보여주기 위한 버전
각 페이지에 대해 다음 4가지 변형을 테스트했습니다.
1.
원본:
원래의 유효한 AMP 버전.
2.
최적화:
다음과 같은 최적화를 구현하는 유효하고 최적화된 AMP 버전
3.
런타임 로딩 최적화
히어로 이미지 미리 로드
(해당될 경우)
사용자설정 글꼴 최적화
(해당될 경우)
4. 최적화 + SSR:
이전 버전과 같은 최적화를 구현하지만
AMP Optimizer
를 통해
SSR(server-side-rendering)
을 추가로 사용합니다. 참고: 이 버전은 유효한 AMP가 아닙니다.
5. 캐시:
참조로 사용되며 Google AMP Cache에 의해 제공되는 버전
300ms의 지연 시간으로 1.6Mbps 3G 연결 시, Motorola G(4세대)를 통해 Chrome에서 수행되는 모든 테스트는
Webpagetest
에 의해 3회 실행됩니다. 이
문서
에서 Webpagetest에 대한 링크를 포함한 전체 결과를 찾을 수 있습니다. 실제 기기에서 테스트를 실행하므로 실행 시간에 차이가 날 수 있습니다.
이제 그 결과를 살펴봅시다.
이미지 없음
로드 시간(초)
렌더링 시작(초)
최초의 상호 작용(초)
원본
4.569
4.569
4.424
최적화
4.564
-0.11%
4.564
-0.11%
4.423
-0.02%
최적화 + SSR
2.233
-51.13%
2.233
-51.13%
4.48
1.27%
AMP 캐시
2.039
-55.37%
2.039
-55.37%
3.508
-20.71%
서버 측 렌더링 버전에 대해 50% 이상 빠른 로드 시간은 서버 측 렌더링 AMP의 이점을 분명히 보여줍니다. 하지만 상호 작용 시간은 여전히 로드되는 AMP 런타임에 따라 다르므로 변경되지 않습니다.
이미지
로드 시간(초)
렌더링 시작(초)
최초의 상호 작용(초)
원본
5.435
4.591
5.367
최적화
4.591
-15.53%
4.566
-0.54%
5.094
-5.09%
최적화 + SSR
4.095
-24.66%
1.892
-58.79%
4.818
-10.23%
AMP 캐시
3.827
-29.59%
1.834
-60.05%
4.13
-23.05%
여기서 이미지를 미리 로드하면 로드 시간이 상당히 개선된다는 점을 알 수 있습니다. 유효한 최적화 AMP 버전은 로딩 속도가 15% 더 빨라지는 반면, 최적화 + SSR 버전은 '불과' 24%만 더 빨라질 뿐입니다. 이는 이미지 렌더링이 로드되는 AMP 런타임에 따라 결정되기 때문입니다.
자체 호스트 글꼴
로드 시간(초)
렌더링 시작(초)
최초의 상호 작용(초)
원본
5.509
4.609
5.424
최적화
4.55
-17.41%
4.53
-1.71%
5.112
-5.75%
최적화 + SSR
4.478
-18.71%
1.989
-56.85%
5.203
-4.07%
AMP 캐시
3.978
-27.79%
1.847
-59.93%
4.317
-20.41%
이 경우에는 서버 측 렌더링 버전이 추가 글꼴 다운로드로 인해 지연되므로 최적화와 최적화 + SSR 사이의 전체 로드 시간 차이가 매우 작아집니다. 그래도 서버 측 렌더링을 사용하면 렌더링은 훨씬 빨리 시작합니다.
참고: AMP Cache는 모든 경우에 더 빠릅니다. 그 주된 이유는 다음 두 가지입니다.
이미지 최적화를 추가로 수행합니다.
같은 도메인에서 런타임이 제공되므로 AMP 런타임을 다운로드하기 위해 다시 https 연결을 설정할 필요가 없습니다.
결론
자체 서버에서 AMP 페이지가 훨씬 빠르게 로드되도록 만들 수 있다는 점을 살펴보았습니다. AMP 페이지를 게시하는 모든 이에게 핵심적인 사항은 다음과 같이 정리할 수 있습니다.
페어링된 AMP를 호스트하는 웹사이트는
캐시되지 않은 AMP 문서에 연결된 Twitter 및 기타 플랫폼에서 최상의 로딩 성능을 보장해야 합니다.
몇 가지 사소한 변경으로 AMP 페이지를 1초라도 더 빠르게 로드할 수 있다는 점을 기억하세요.
AMP로 빌드한 웹사이트는 프로그레시브 렌더링을 사용하고 FCP 시간을 대폭 개선해주는
AMP Optimizer
의 사용을 고려해봐야 합니다.
우리는 새로운 최적화 방법을 발견하고 AMP 로딩 성능을 개선하기 위해 적극적으로 노력하고 있습니다.
Contents
ML/Tensorflow
Android
Flutter
Web/Chrome
Cloud
Google Play
Community
Game
Firebase
검색
Tag
인디게임페스티벌
정책 세미나
창구프로그램
AdMob
AI
Android
Android 12
Android 12L
Android 13
Android 14
Android Assistant
Android Auto
Android Games
Android Jetpack
Android Machine Learning
Android Privacy
Android Studio
Android TV
Android Wear
App Bundle
bootcamp
Business
Chrome
Cloud
Community
compose
Firebase
Flutter
Foldables
Game
gdg
GDSC
google
Google Developer Student Clubs
Google Play
Google Play Games
Interview
Jetpack
Jetpack Compose
kotlin
Large Screens
Library
ma
Material Design
Material You
ML/Tensorflow
mobile games
Now in Android
PC
Play Console
Policy
priva
wa
wear
Wearables
Web
Web/Chrome
Weeklyupdates
WorkManager
Archive
2024
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2023
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2022
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2021
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2020
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2019
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2018
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2017
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2016
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2015
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2014
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2013
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2012
12월
11월
10월
9월
8월
7월
6월
5월
3월
2월
1월
2011
12월
11월
Feed