2020년 페이지 속도 측정을 위한 고급 개념

게시 됨: 2020-04-09

2020년의 페이지 속도에 영향을 미치는 요소를 이해하려면 먼저 브라우저가 웹 페이지를 렌더링하는 방법을 이해해야 합니다. 페이지 속도 및 DOM, CSSOM, 렌더링 트리, 리플로우 비용 및 DOM 유형과 같은 웹 기술 개념에 익숙하지 않은 경우 위에 링크된 기사를 읽고 시작하는 것이 좋습니다.

웹사이트와 웹 브라우저가 더 복잡해짐에 따라 페이지 속도는 페이지의 크기나 서버의 응답 속도 그 이상입니다. 이 기사에서는 2020년 이후에 페이지 속도에 대한 새롭고 새로운 메트릭(리소스 요청의 수와 크기, 중요한 렌더링 경로, LCP, CLS, 총 차단 시간)을 살펴보겠습니다.

이 기사는 페이지 속도에 관한 4개의 기사 시리즈 중 두 번째 기사입니다. 첫 번째 기사는 여기에서 찾을 수 있습니다. 브라우저는 웹 페이지를 어떻게 생성합니까?

리소스 요청의 순서, 크기 및 수 관리

렌더링 프로세스의 각 단계에는 시간이 걸립니다. 웹 사이트가 느린 위치와 속도를 높이는 방법에는 페이지를 렌더링하는 과정에서 브라우저가 리소스를 처리하는 방법을 살펴보는 것이 포함됩니다.

이는 요청의 순서, 수 및 크기가 오늘날 페이지 속도를 측정하는 데 중요한 역할을 한다는 것을 의미합니다.

리소스 순서 및 리소스 로드 힌트 최적화의 가장 중요한 기여는 가장 큰 콘텐츠가 포함된 페인트를 통해 TTI(Time to Interactive)를 줄이는 것입니다. 리소스 순서 최적화를 사용하면 더 짧은 시간에 동일한 수와 크기의 파일을 업로드하여 사용자와 검색 엔진에 전달할 수 있습니다.

중요 렌더링 경로란 무엇입니까?

중요한 렌더링 경로에는 웹 페이지의 스크롤 없이 볼 수 있는 부분을 만드는 모든 리소스가 포함됩니다.

귀하의 웹 페이지는 페이지의 총 로드 크기로 인해 경쟁업체의 웹 페이지보다 느릴 수 있습니다. 그러나 여기에 트릭이 있습니다. 다른 비즈니스 부서에서 페이지의 로드 크기를 수정하도록 허용하지 않더라도 중요한 렌더링 경로를 최적화하여 경쟁사보다 더 빠르게 콘텐츠를 제공할 수 있습니다.

중요한 렌더링 경로를 최적화하는 방법

이것은 Sergey Chernyshev가 만든 페이지 속도 및 전환율 상관 시뮬레이터입니다. 내 웹 페이지가 사용자를 위해 0.5초 더 빠르게 로드되고 개발자 팀에 이를 표시하여 밀리초마다 전환을 개선할 수 있다고 지정하면 어떻게 되는지에 대한 질문에 대한 답을 찾을 수 있습니다.

중요한 렌더링 경로를 최적화하려면 접힌 부분 위에 생성하는 데 필요한 리소스를 결정해야 합니다. 그 후에 몇 가지 사소한 질문이 있습니다.

브라우저에서 중요한 소스를 다운로드하지 못하도록 하는 리소스는 무엇입니까?
중요 소스의 크기와 수를 줄일 수 있습니까?
중요한 소스를 인라인할 수 있습니까?
중요한 렌더링 경로 소스를 통합하여 DNS 조회 프로세스를 제한할 수 있습니까?

예제를 살펴보겠습니다. CSS, JS 및 HTML을 가속화하기 위한 몇 가지 권장 사항도 제공합니다.

다음은 Amazon 웹 페이지의 중요한 부분 예입니다. DevTools를 사용하면 필요한 CSS 코드와 함께 페이지의 중요한 부분에서 가장 중요한 <div> 요소를 볼 수 있습니다. 이러한 방식으로 렌더링 차단 리소스가 브라우저를 방해하기 전에 인라인 CSS 코드 블록을 만들 수 있습니다. 하단에 사용되지 않은 코드 스택이 표시될 수도 있습니다. Amazon은 최적화되지 않은 경우에도 다양한 카테고리에 대해 항상 동일한 CSS/JS 리소스 패턴을 사용합니다.

속도 외에도 여기에는 또 다른 문제가 있습니다. 휴대폰 화면의 크기가 다르기 때문에 웹 페이지의 중요한 부분은 모델마다 다릅니다. 일부 화면에는 가격이 표시되지 않고 일부 화면에는 주식 정보가 표시되지 않습니다. 이것은 중요한 설계 오류이지만 중요한 렌더링 경로 최적화를 어렵게 만들기도 합니다. 또한 이 영역에 링크가 있는 경우 PageRank 값을 나누어 전환 확률을 낮춥니다.

Puppeteer(Googlebot의 크롤링 엔진)를 사용하여 이러한 유형의 문제를 검사하고 모든 스마트폰/태블릿 모델에 대해 자동 스크린샷을 찍고 웹 페이지의 중요한 부분 디자인을 확인할 수 있습니다. Jean-Francois Lagarde에는 이 작업에 대한 멋진 Puppeteer 라이브러리가 있습니다.

다음은 모든 장치 뷰포트 도구에 대한 Puppeteer 자동 스크린샷의 장치 구성에 대한 빠른 스크린샷입니다.

가장 큰 내용이 포함된 페인트는 무엇입니까?

LCP(Large Contentful Paint)는 바이트 및 크기 면에서 웹 페이지에서 가장 큰 영역입니다. 모든 웹 페이지에는 많은 "div" 요소가 있으며 모두 다른 페이지 구성 요소를 포함합니다. 그리고 이러한 구성 요소는 페이지 로드 값이 다릅니다.

Google에 따르면 가장 큰 콘텐츠가 포함된 페인트는 대부분 페이지의 가장 중요한 요소의 영향을 받습니다. LCP의 중요성에 대한 아이디어를 제공하기 위해 Google은 향후 Lighthouse 보고서에 이 새로운 측정항목을 추가하기로 결정했습니다.

이것은 또한 실제 사용자 메트릭(RUM)과 함께 사용되며 특히 중요한 렌더링 경로와 관련된 핵심 메트릭이 될 것이기 때문에 LCP에 대해 점점 더 많이 듣게 될 것임을 의미합니다.

다음은 Lendio의 가장 큰 콘텐츠가 포함된 페인트 예입니다. 보시다시피 DevTools는 유형, 크기 및 로드 시간에 대한 데이터와 함께 페이지에 LCP를 표시합니다. 가장 큰 콘텐츠가 포함된 페인트의 콘텐츠에는 항상 가장 중요한 기능 또는 CTA와 함께 페이지의 목적과 가치가 포함되어야 하며, 가장 중요한 것은 가장 먼저 로드되어야 한다는 것입니다!

이 예에서는 텍스트일 뿐입니다. 기능적 도구와 결합하면 단순한 텍스트/이미지 LCP보다 낫습니다.

LCP는 특정 유형의 리소스만 고려합니다. 그 주된 이유는 처음에 LCP 측정을 간단하게 유지하기 위함입니다. 아래는 LCP 항목 목록을 생성하기 위해 스탬프가 찍힌 "스크립트 인스턴스"입니다. 이러한 코드를 연구하면 Google 개발자가 페이지를 로드할 때 무엇에 어떻게 주의를 기울이는지 알 수 있습니다.

[노출=창]
인터페이스 LargestContentfulPaint : PerformanceEntry {
읽기 전용 속성 DOMHighResTimeStamp renderTime;
읽기 전용 속성 DOMHighResTimeStamp loadTime;
읽기 전용 속성 unsigned long 크기;
읽기 전용 속성 DOMString id;
읽기 전용 속성 DOMString url;
읽기 전용 속성 요소? 요소;
[기본값] 개체 toJSON();
};

이 목록에 표시되는 것은 LCP 항목 목록에 들어가는 후보 항목을 비교하는 데 필요한 척도입니다. 아래에서 LCP 후보를 선택하는 방법론(“큰 본문 텍스트” 및 “큰 이미지”)을 보여 드리겠습니다.

LCP를 정의하기 위한 원칙 및 프로세스 이해

LCP를 결정하는 원칙은 매우 중요합니다.

페이지가 로드되는 동안 LCP는 몇 초 만에 변경될 수 있습니다. 때로는 페이지 구성 요소가 화면에 LCP만큼 충분히 오래 남아 있어도 뒤에 로드된 더 큰 페이지 요소가 이전 상태를 변경하지 않는 경우가 있습니다.
때로는 스크롤 없이 볼 수 있는 요소(웹 페이지의 중요한 부분)가 스크롤 없이 볼 수 있는 부분(웹 페이지의 중요하지 않은 부분) 아래에 있는 더 큰 항목 대신 LCP로 선택됩니다.
구성 요소가 화면에서 분할된 경우 더 큰<div> 요소를 LCP로 선택할 수 없습니다. 대신 블록 <div> 요소가 LCP로 선택됩니다. 아래에서 이를 설명하는 예를 볼 수 있습니다.

이 예에서 가장 큰 구성 요소는 4개의 다른 이미지를 포함하는 <div>입니다. 그러나 이러한 개별 이미지 중 어느 것도 Oncrawl 로고와 동일한 <div> 요소에 포함된 텍스트보다 크지 않습니다. 둘 다 웹 페이지의 중요한 부분에 있으므로 두 번째 요소는 LCP가 됩니다.

LCP 타이밍을 계산하고 Google 개발자의 관점을 결정하는 동안 "복합" 디자인에도 중점을 두어야 합니다. <div> 요소가 복합적이고 통일된 디자인 느낌/관점을 갖지 않는다면 아마도 LCP로 선택되지 않을 것입니다.

선택하더라도 Google Chrome은 향후 LCP API에 추가할 새 코드가 포함된 정상적인 LCP가 아니라고 생각할 수 있습니다. UX와 관련된 이유와 페이지 속도에 대한 더 나은 이해를 위해 Google은 이러한 방법을 사용하여 자체 인식을 계속 개선할 것입니다.

레이아웃 이동 및 누적 레이아웃 이동이란 무엇입니까?

레이아웃 이동은 브라우저에서 페이지를 다운로드하는 동안 페이지 요소가 사용자를 방해할 수 있는 방식으로 위치를 변경한다는 아이디어입니다.

페이지가 다운로드되는 동안 모든 페이지 부분이 지정된 순서대로 하나씩 표시됩니다. 이것은 정상입니다. 그러나 이러한 부품이 후속 부품으로 인해 시작 위치를 변경하는 경우 이는 레이아웃 이동입니다.

CLS(누적 레이아웃 이동)는 모든 레이아웃 이동 이벤트의 합계입니다.

Chrome 사용자 환경에는 CLS 점수에 대한 섹션도 있습니다. 하지만 UX만 있는 것은 아닙니다. 레이아웃 이동은 감광성 간질 환자에게 해로울 수 있습니다. Google은 "건강 회사"로서 사용자의 건강에도 가치를 부여해야 합니다. 그들은 가능한 한 "웹 스트레스"를 줄이려고 노력합니다.

“저는 Google이 이미 건강 회사라고 생각합니다. 처음부터 회사의 DNA에 있었습니다.”
David Feinberg – Google Health 책임자

다음은 이 시리즈의 앞부분에서 본 동일한 사이트 중 하나에서 가져온 간단하고 결정적인 레이아웃 전환 예입니다. 그것은 터키의 주요 뉴스 웹사이트이며 이것은 그들의 주요 페이지입니다…

Moz 개발자로부터 건강에 위험한 레이아웃 이동, 깜박임, 깜박임 및 색상 변형에 대해 자세히 알아볼 수 있습니다.

웹사이트에서 누적 레이아웃 이동을 찾는 방법

웹 페이지의 변화하는 레이아웃 부분을 보려면 Google Chrome DevTools를 사용하거나 Layout Instability API를 사용하여 모든 웹 페이지의 프로세스를 확장할 수 있습니다.

누적 레이아웃 이동 또는 모든 레이아웃 이동 이벤트의 합계는 2020년 이후 페이지 속도와 UX 모두의 중요한 기준입니다. 로드하는 동안 웹 페이지의 스크롤 없이 볼 수 있는 부분이 이동하는 경우 속도를 최적화할 때도 이를 최적화해야 합니다.

아래에서 Layout Shifting Formula와 CLS 기여도에 대한 관점을 제공하는 Layout Instability API 코드 예제 및 레이아웃 이동 점수를 계산하는 방법을 찾을 수 있습니다.

레이아웃 이동 공식은 다음과 같습니다.
레이아웃 이동 점수 = 충격 비율 * 거리 비율

Layout Shifting 점수는 두 가지 유용한 새 용어인 Impact Fraction 및 Distance Fraction으로 계산됩니다.

Impact fraction 은 시프트의 영향을 받는 화면의 비율입니다. 모바일 장치에서 표시 영역의 50%를 차지하는 페이지 요소가 레이아웃 이동을 생성하는 경우 CLS가 높다는 것을 알고 있습니다. 이동하면 화면의 최소 50% 이상에 영향을 미치기 때문입니다.
거리 비율 은 이동하는 요소가 이동하는 동안 이동하는 방향으로 원래 지점에서 멀어지는 거리로 측정됩니다. 첫 번째 위치와 마지막 위치 사이의 거리가 과도하면 거리 비율도 과도하게 됩니다.

이렇게 하면 CLS 점수를 더 쉽게 추정하고 IT 및 UX 팀에 조언할 수 있습니다.

위에서 CLS API 코드 조각을 볼 수 있고 아래에서 누적 레이아웃 이동을 계산하는 방법을 보여주는 GIF를 볼 수 있습니다.

우리가 보고 있는 동일한 터키 뉴스 사이트에서 CLS는 0,47입니다. 0과 1 사이에서 계산되는 것을 고려하면 이것은 꽤 나쁜 점수입니다.
Webpagetest.org의 Advanced Custom Metric System을 사용하여 CLS를 계산할 수 있습니다. "Sends the Info Part"까지 CLS API의 코드를 사용해야 합니다. 그런 다음 URL을 root/results/에서 root/custom_metrics.php?test={Same Result Number}로 변경해야 합니다.

총 차단 시간이란 무엇입니까?

레이아웃 변경 없이 웹 페이지의 접힌 부분 위를 빠르게 다운로드할 수 있지만 사용자 입력에 응답하지 않는 경우 Google 알고리즘은 다른 UX 및 페이지 속도 문제가 있다고 주장합니다. Total Blocking Time은 이 단계에서 손실된 시간입니다.

누적 레이아웃 이동 및 최대 콘텐츠 포함 페인트와 마찬가지로 총 차단 시간은 2020년 이후의 새로운 페이지 속도 및 UX 메트릭입니다.

총 차단 시간(TBT)에 계산되는 것은 브라우저(또는 장치)의 기본 스레드를 50밀리초 이상 차단하고 사용자가 모든 프로세스를 수행합니다.

TBT를 계산하고 최적화하는 방법

Long Tasks API를 사용하여 총 차단 시간(TBT)을 계산할 수 있습니다.

TBT 점수를 최적화하려면 요청 수 및 크기와 함께 리소스를 로드하기 위한 순서 및 기본 설정에도 중점을 두어야 합니다.

이것은 이전의 동일한 사이트에서 가져온 것입니다. 보시다시피 메인 스레드는 5초 이상 쉬지 않고 완전히 사용 중입니다. 그들의 LCP는 거의 2.5초가 지난 후에도 여전히 로드되고 있습니다... 여기서 주목해야 할 중요한 점은 그들의 가장 긴 작업 요청이 350MS보다 길다는 것입니다. 즉, 300MS 이상에 대해서는 메인 스레드를 차단하는 것으로 간주됩니다.

또한 모든 차단 시간은 총 차단 시간의 일부로 계산됩니다. 여기에는 스크롤 없이 볼 수 있는 부분의 요소가 포함될 뿐만 아니라 모든 웹 페이지 구성 요소에 적용됩니다. 웹 사이트에 유해한 브라우저 기록을 생성합니다.

TBT가 300밀리초 이상인 경우 사용자 유지 및 전환율에 상당한 피해를 줄 수 있습니다.

위의 메인 스레드에 대한 TBT에 대한 계산 예를 볼 수 있습니다. 이 예에는 4개의 요청이 있습니다. Google 크롬은 동일한 서버에서 한 번에 6개의 요청을 생성할 수 있습니다. 그 중 처음 50개 MS만 원활하게 진행됩니다. 그 후에는 CPU/네트워크 전원이 허용하는 한 동시에 여러 작업을 수행하기 시작합니다. 인간은 16MS마다 한 프레임을 볼 수 있음을 기억하십시오. Google은 사용자를 위해 1000분의 1초를 중요하게 생각합니다.

이 예에서 Total Blocking Time은 1초 및 100MS입니다.

페이지 속도 최적화의 다음 단계

지금까지 이 시리즈에서는 브라우저가 웹 페이지를 생성하는 방법을 조사했으며, 이를 통해 이 기사에서 브라우저에서 페이지가 로드되는 방식과 관련된 새로운 측정항목이 페이지 속도에 어떤 영향을 미칠 수 있는지 확인할 수 있었습니다. 우리는 몇 가지 새로운 주요 측정항목과 측정 및 최적화 방법을 살펴보았습니다.

오늘날 웹사이트의 페이지 속도에 대한 이 시리즈의 다음 기사에서는 SEO 및 웹 개발의 주요 주제가 된 주제인 페이지 속도 및 페이지 렌더링을 개선하기 위한 JavaScript 자산 최적화에 대해 다룰 것입니다.

무료 평가판 시작