Thor 렌더 엔진 만나보기: 번개처럼 빠른 페이지 만들기

제 이름은 Instapage의 엔지니어링 선임 이사인 Piotr Dolistowski입니다. 저는 프로젝트 조정 및 인력 관리를 포함하여 폴란드 바르샤바에 있는 회사의 기술 지사를 이끌고 있습니다. 오늘 기사의 모든 내용은 Instapage 고객을 위해 더 빠른 페이지 렌더링 시스템을 만들기 위한 우리 팀의 노력의 직접적인 결과입니다.

페이지 로드 속도가 사용자 참여 및 이탈률에 직접적인 영향을 미친다는 것은 디지털 마케터에게 비밀이 아닙니다. Google 및 기타 업체는 최소 몇 년 동안 디지털 마케팅 분야에서 일하는 모든 사람에게 페이지 속도를 강조해왔으므로 2019년에는 새로운 것이 아닙니다.

이전에 여러 번 소개했지만 Google의 연구에 따르면 로딩 속도가 느린 페이지의 경우 사용자 참여가 급감하고 이탈률이 증가합니다.

이것이 우리 팀이 Thor Render Engine™을 제공하기 위해 끊임없이 노력한 이유입니다. 렌더링 엔진은 당사의 새로운 페이지 생성기이자 완전히 반응하는 페이지 경험의 일부로, 사용자의 노력 없이도 클릭 후 랜딩 페이지가 매우 빠르게 로드되도록 합니다.

Instapage의 새로운 렌더링 시스템에 대해 자세히 알아보기 전에 클릭 후 랜딩 페이지를 느리게 로드하는 것이 전환에 해로운 이유를 검토해 보겠습니다.

느린 로딩 페이지가 전환에 미치는 영향

느린 로딩 페이지는 얼마나 느립니까? 모바일 페이지 로드 시간이 1초 지연될 때마다 전환율이 떨어집니다.

번역: 온라인 사용자는 페이지가 로드될 때까지 오래 기다릴 인내심이 없습니다. 따라서 거의 즉시 로드되지 않으면 페이지를 떠날 것입니다. 이로 인해 이탈률이 증가하고 사용자 참여가 감소하며 전반적인 사용자 경험에 좋지 않으며 궁극적으로 전환이 제한됩니다.

Akamai는 최고의 온라인 소매업체로부터 100억 명의 사용자 방문에 대한 데이터를 수집한 후 다음과 같은 인사이트를 얻었습니다.

• 소비자의 절반은 스마트폰으로 제품과 서비스를 탐색하지만 실제로 모바일로 구매하는 사람은 5명 중 1명에 불과합니다.
• 웹사이트 로드 시간이 100밀리초 지연되면 전환율이 7% 감소할 수 있습니다.
• 웹 페이지 로드 시간이 2초 지연되면 이탈률이 103% 증가합니다.
• 모바일 사이트 방문자의 53%는 로드하는 데 3초 이상 걸리는 페이지를 떠납니다.
• 휴대폰 쇼핑객의 이탈률이 가장 높았고 태블릿 쇼핑객의 이탈률이 가장 낮았습니다.

그렇다면 클릭 후 랜딩 페이지가 빠르게 로드되도록 하려면 어떻게 해야 할까요? Google의 PageSpeed ​​Insights가 도움이 될 수 있지만 얼마나 도움이 될까요?

Google의 PageSpeed ​​Insights는 모바일 및 데스크톱 장치 모두에서 페이지가 빠른지, 평균적인지 또는 느린지를 보여주는 페이지 성능에 대해 보고합니다. 또한 해당 페이지를 개선할 수 있는 방법에 대한 제안도 제공합니다.

그러나 기술적인 배경 지식이 없는 경우 페이지 속도 정보가 혼란스러울 수 있습니다. FCP(First Contentful Paint) 및 FID(First Input Delay) 메트릭이 무엇인지 이해하면 바로 이해할 수 있습니다.

Instapage의 Thor Render Engine™에 들어가십시오.

Thor Render Engine™의 세부 사항

우리는 모든 Instapage 클릭 후 랜딩 페이지가 빠르게 로드되도록 Thor Render Engine™을 개발했습니다.

즉, 페이지 백엔드의 모든 항목이 즉시 로드되도록 HTML 구조, JavaScript 및 CSS 리팩토링, CSS 응답성을 변경하는 등 모든 측면에서 클릭 후 랜딩 페이지를 완전히 다시 작성해야 했습니다.

이러한 모든 변경 사항의 가장 좋은 점은 Thor Render Engine™이 페이지 뒤에서 조용히 작동하여 페이지를 번개처럼 빠르게 만들기 때문에 아무 것도 할 필요가 없다는 것 입니다.

더 빠른 로딩 페이지를 위해 우리가 무엇을 했는지 알아보기 위해 변경 사항을 분석해 보겠습니다.

HTML 구조

리소스 우선 순위 지정부터 시작하여 HTML 관점에서 페이지 렌더링 시스템을 더 빠르게 만드는 데 많은 노력을 기울였습니다.

자원 우선순위

사용되지 않거나 모호하거나 최적화되지 않은 많은 코드의 클릭 후 방문 페이지를 제거하여 명확하고 빠르게 렌더링되는 마크업을 만들었습니다.

새로운 HTML 구조는 모든 리소스가 올바른 순서로 로드되도록 보장합니다. 페이지 스타일(글꼴 스타일 제외)이 헤드 섹션에 추가되었습니다. 이후에는 페이지가 CSS 스타일시트를 사용하는 것보다 더 빨리 로드되기 때문입니다.

추가 코드 없이도 페이지가 빠르게 로드되고 멋지게 표시되기 때문에 응답성은 더 이상 CSS 또는 JavaScript에서 추가 중단점이 필요하지 않습니다. 또한 모든 스크립트는 페이지 본문 하단에 배치되어 페이지 렌더링을 차단하지 않습니다. 중요한 스크립트 및 리소스(예: 글꼴)는 브라우저 사전 로드 기능을 사용하므로 페이지가 렌더링되는 동안 차단되지 않습니다. 또한 페이지의 헤드 태그에는 동기 JavaScript가 배치되지 않습니다.

이미지 및 동영상 지연 로드

이미지와 비디오가 렌더링 차단되지는 않지만 페이지에 여러 개가 있는 경우 특히 큰 이미지의 경우 너무 많은 요청으로 인해 대역폭이 막힐 수 있습니다. 이는 방문자에게 보이지 않는 접힌 부분 아래의 이미지와 함께 위쪽 접힌 부분의 이미지가 동시에 로드되기 때문에 사용자 경험이 좋지 않을 수 있습니다.

이 문제를 해결하기 위해 다음과 같은 최적화를 도입했습니다.

• 우선순위가 더 높은 접힌 부분 위의 이미지 로드 — 다운로드가 즉시 시작되므로 페이지가 상호작용하기 전에도 볼 수 있습니다.
• 접은 부분 아래의 이미지와 동영상은 느리게 로드 됩니다. 사용자가 스크롤하면 다운로드가 트리거됩니다. 회색 상자는 아직 로드되지 않은 이미지의 자리 표시자로 사용됩니다.
• 사용자에게 이러한 회색 상자가 표시되지 않도록 하기 위해 이미지는 뷰포트로 스크롤될 때 실제로 로드됩니다. 그러나 뷰포트 하단까지 400px 거리에서 스크롤할 때. 뷰포트에 들어가면 이미 로드되어 있습니다.
• iframe에 로드 되는 동영상에도 동일한 규칙이 적용됩니다 .

이를 실현하기 위해 우리는 IntersectionObserver의 최첨단 API를 활용하여 작은 코드 크기 공간으로 지연 로딩을 매우 효율적으로 만듭니다.

자바스크립트 리팩터링

JavaScript 리팩터에는 다음과 같은 최적화가 포함되었습니다.

1. 모듈식 아키텍처: 클릭 후 랜딩 페이지의 모든 JavaScript 코드는 특정 위젯의 기능과 관련됩니다. 우리는 코드를 여러 번들로 분할하고 각 번들에는 특정 기능에 대한 코드가 포함되어 있습니다. 따라서 사용자가 이미지와 링크만으로 페이지를 디자인할 때 Form 또는 Popup 위젯에 대한 코드가 로드되지 않아 페이지 로드가 빨라집니다.
2. 초경량: 오래된 라이브러리를 제거하고 전체 코드 아키텍처를 재설계하여 페이지의 총 JavaScript 크기를 1MB 이상에서 약 200kB(5배 적음!)로 줄일 수 있었지만 일반적인 페이지는 100kB 미만으로 로드됩니다. 위에서 설명한 모듈화 덕분입니다.
3. All Async: JavaScript는 렌더링을 차단하므로 모든 스크립트 가져오기를 BODY 태그의 맨 아래로 이동했습니다. 이렇게 하면 스크립트가 실행되기 전에 브라우저가 전체 페이지를 렌더링하여 방문자가 의미 있는 콘텐츠를 더 일찍 볼 수 있습니다. 상호 작용을 제공하는 스크립트는 페이지의 해당 섹션과 상호 작용을 시작한 후에만 로드되고 실행됩니다. 이것은 특히 성능이 낮고 종종 인터넷 연결이 좋지 않은 모바일 장치에서 매우 좋은 경험을 제공합니다.

CSS 리팩터링

또한 전체 CSS 스타일시트를 다시 작성하여 불필요한 타사 코드를 제거하여 스타일시트를 재사용할 수 있고 읽기 쉽고 가볍게 만들었습니다. 또한 일반적인 CSS 클래스를 사용하여 CSS 코드를 최대한 재사용합니다.

또한 GPU 가속으로 CSS 전용 애니메이션을 구현했습니다. CSS 스택에서 가장 중요한 변화는 픽셀 대신 상대 단위 "rem"을 도입한 것입니다. 덕분에 클릭 후 랜딩 페이지는 이제 스마트폰에서 4k 데스크톱 디스플레이에 이르기까지 모든 장치 크기에서 원활하게 확장됩니다.

CSS 응답성

클릭 후 방문 페이지가 반응하도록 만들기 위해 "rem"을 "vw" 단위와 함께 사용하고 있습니다. 즉, 클릭 후 랜딩 페이지의 너비가 768픽셀에서 1200픽셀 사이, 너비가 400픽셀 미만으로 축소될 때 기기 해상도에 두 가지 차이가 ​​있습니다. 다른 모든 해상도에서는 기본 콘텐츠가 빌더에서와 마찬가지로 고정 너비로 ​​유지됩니다. 고정 너비 값은 모바일의 경우 400px이고 데스크톱의 경우 1200px입니다.

"Rem" 단위를 사용하면 위젯 위치와 크기를 원활하게 다시 계산할 수 있습니다. 또한 이를 위해 JavaScript를 사용할 필요가 없다는 의미이기도 합니다.

요약하자면:

• 400px 미만 콘텐츠는 화면 너비에 맞게 자동으로 조정됩니다.
• 400px에서 767px 사이 에서 콘텐츠 너비가 고정됩니다.
• 768px 모바일 보기에서 데스크톱 보기로 전환
• 768px에서 1200px까지 콘텐츠가 화면 너비에 맞게 자동으로 조정됩니다.
• 1200px 이상 에서는 내용이 고정됩니다.

Thor Render Engine™ 속도 테스트 예시

사람들이 클릭 후 방문 페이지(데스크톱, 모바일 또는 태블릿)를 어떻게 보는지 알 수 없으므로 페이지 경험이 완전히 반응하는 것이 중요합니다. Thor Render Engine™ 솔루션은 모든 해상도에서 완벽하게 반응합니다.

이제 새 렌더링 엔진을 이전 페이지 생성기와 비교해 보겠습니다. 아래 이미지는 URL은 다르지만 동일한 페이지의 페이지 속도 결과를 보여줍니다. (참고: 이 URL은 테스트 목적으로만 사용되므로 페이지는 더 이상 활성화되지 않습니다.)

이전 Instapage 페이지 렌더링 결과:

Thor Render Engine™ 결과:

첫 번째 테스트에서 56점을 받고 두 번째 테스트에서 95점으로 증가하면 페이지 로드 속도가 58.9% 증가합니다!

페이지 로드 속도 비교

Thor Render Engine™의 모든 변경 사항을 요약한 후 Instapage의 페이지 로드 속도를 경쟁 제품과 비교해 보겠습니다.

3G 연결에서 이 페이지의 속도를 테스트했습니다(스크린샷은 스크롤 없이 볼 수 있는 부분에만 표시됨).

페이지를 로드하는 데 걸리는 시간은 다음과 같습니다.

• 기존 Instapage 페이지 렌더링 시스템(상단 행): 로딩 시작까지 10.5초
• Thor Render Engine™(가운데 줄): 5초 이내에 페이지가 98% 로드됩니다.
• 경쟁사 사용(하단 행): 로드 시작까지 8초

4G 연결에서 결과는 다음과 같습니다.

• 이전 Instapage 페이지 렌더링 시스템 사용 시: 로딩 시작까지 4.5초
• Thor Render Engine™: 3.5초 이내에 완전히 로드됨
• 경쟁사 사용: 로딩 시작 까지 4.5초

Thor Render Engine™으로 더 빠른 로딩 페이지를 즐기세요

페이지 속도는 사용자 경험과 궁극적으로 전환에 중요한 역할을 합니다. 페이지 로드 시간이 지연되면 반송률이 높아질 위험이 있을 뿐만 아니라 그 과정에서 사용자를 좌절하게 만듭니다.

Thor Render Engine™을 사용하면 클릭 후 랜딩 페이지가 사용자의 노력 없이 즉시 로드되도록 보장할 수 있습니다. 오늘 Instapage Enterprise 데모에 등록하고 그 차이를 직접 경험해 보십시오.