웹사이트 성능 및 주요 렌더링 경로 최적화

게시 됨: 2022-03-11

웹 페이지의 렌더링 성능이 오늘날의 표준을 충족합니까? 렌더링은 사용자가 웹사이트를 방문할 때 서버의 응답을 브라우저가 "그림으로 그리는" 그림으로 변환하는 프로세스입니다. 나쁜 렌더링 성능은 상대적으로 높은 이탈률로 해석될 수 있습니다.

페이지가 렌더링되는지 여부를 결정하는 다양한 서버 응답이 있습니다. 이 기사에서는 HTML 구문 분석으로 시작하는 웹 페이지의 초기 렌더링에 초점을 맞출 것입니다(브라우저가 서버의 응답으로 HTML을 성공적으로 수신한 경우). 렌더링 시간이 길어지는 원인과 해결 방법에 대해 알아보겠습니다.

중요한 렌더링 경로

중요 렌더링 경로(CRP)는 브라우저가 코드를 화면에 표시할 수 있는 픽셀로 변환하기 위해 거치는 프로세스입니다. 여러 단계가 있으며 그 중 일부는 시간을 절약하기 위해 병렬로 수행될 수 있지만 일부는 결과적으로 수행되어야 합니다. 다음과 같이 시각화됩니다.

우선 브라우저가 응답을 받으면 구문 분석을 시작합니다. 종속성이 발생하면 다운로드를 시도합니다.

스타일시트 파일인 경우 브라우저는 페이지를 렌더링하기 전에 완전히 구문 분석해야 하므로 CSS를 렌더링 차단이라고 합니다 .

스크립트라면 브라우저는 구문 분석을 중지하고 스크립트를 다운로드한 다음 실행해야 합니다. JavaScript 프로그램은 웹 페이지(특히 HTML)의 내용을 변경할 수 있기 때문에 그 후에야 구문 분석을 계속할 수 있습니다. 이것이 JS를 파서 차단이라고 부르는 이유입니다.

모든 구문 분석이 완료되면 브라우저에 DOM(Document Object Model)과 CSSOM(Cascading Style Sheets Object Model)이 구축됩니다. 이들을 결합하면 렌더 트리가 생성됩니다. 페이지의 표시되지 않은 부분은 페이지를 그리는 데 필요한 데이터만 포함하기 때문에 렌더 트리에 포함되지 않습니다.

두 번째 단계는 렌더 트리를 레이아웃으로 변환하는 것입니다. 이 단계를 Reflow라고도 합니다. 여기에서 모든 렌더 트리 노드의 모든 위치와 크기가 계산됩니다.

마지막으로 마지막 단계는 페인트입니다. 이전 단계에서 브라우저가 계산한 데이터에 따라 문자 그대로 픽셀에 색상을 지정하는 작업이 포함됩니다.

최적화 관련 결론

짐작할 수 있듯이 웹 사이트 성능 최적화 프로세스에는 다음을 줄이는 웹 사이트 변경이 포함됩니다.

전송해야 하는 데이터의 양
브라우저가 다운로드해야 하는 리소스 수(특히 차단 리소스)
CRP의 길이

더 나아가, 우리는 그것이 어떻게 이루어졌는지에 대해 자세히 알아볼 것이지만, 먼저 준수해야 할 중요한 규칙이 있습니다.

성능 측정 방법

최적화의 중요한 규칙은 다음과 같습니다. 먼저 측정하고 필요에 따라 최적화합니다 . 대부분의 브라우저 개발자 도구에는 성능 이라는 탭이 있으며 여기에서 측정이 수행됩니다. 가장 빠른 초기(첫 번째) 렌더링을 위해 최적화할 때 살펴봐야 할 가장 중요한 것은 다음 이벤트의 시간입니다.

첫 번째 페인트
첫 번째 콘텐츠가 있는 페인트
첫 번째 의미 있는 페인트

여기서 "페인트"는 중요한 렌더링 경로의 마지막 단계인 페이지의 성공적인 렌더링을 의미합니다. 브라우저는 최대한 빨리 표시하고 나중에 업데이트하려고 하기 때문에 몇 가지 렌더링이 차례로 발생할 수 있습니다.

렌더링 시간 외에도 고려해야 할 다른 사항이 있습니다. 가장 중요한 것은 차단 리소스가 얼마나 사용되고 다운로드하는 데 걸리는 시간입니다. 이 정보는 측정 후 성능 탭에서 찾을 수 있습니다.

성능 최적화 전략

위에서 배운 내용을 감안할 때 웹사이트 성능 최적화를 위한 세 가지 주요 전략이 있습니다.

유선으로 전송할 데이터의 양을 최소화하고,
유선을 통해 전송되는 총 리소스 수 감소 및
중요한 렌더링 경로 단축

1. 전송할 데이터의 양 최소화

우선 JavaScript에서 연결할 수 없는 기능, 어떤 요소와도 일치하지 않는 선택기가 있는 스타일, CSS로 영원히 숨겨져 있는 HTML 태그와 같이 사용하지 않는 부분을 모두 제거하십시오. 둘째, 모든 중복을 제거하십시오.

그런 다음 자동 축소 프로세스를 배치하는 것이 좋습니다. 예를 들어, 백엔드에서 제공하는 모든 주석(소스 코드 제외)과 추가 정보가 없는 모든 문자(예: JS의 공백 문자)를 제거해야 합니다.

이 작업이 끝나면 텍스트로 남을 수 있습니다. 이는 GZIP(대부분의 브라우저가 이해하는)와 같은 압축 알고리즘을 안전하게 적용할 수 있음을 의미합니다.

마지막으로 캐싱이 있습니다. 브라우저가 페이지를 처음 렌더링할 때는 도움이 되지 않지만 이후 방문 시에는 많은 비용을 절약할 수 있습니다. 하지만 다음 두 가지를 염두에 두는 것이 중요합니다.

CDN을 사용하는 경우 캐싱이 지원되고 적절하게 설정되어 있는지 확인하십시오.
리소스의 만료 날짜가 올 때까지 기다리는 대신 사용자 측에서 더 일찍 업데이트할 수 있는 방법이 필요할 수 있습니다. 로컬 캐시를 무효화할 수 있도록 파일의 "지문"을 URL에 포함합니다.

물론 캐싱 정책은 리소스별로 정의되어야 합니다. 일부는 거의 변경되지 않거나 전혀 변경되지 않을 수 있습니다. 다른 사람들은 더 빨리 변하고 있습니다. 일부는 민감한 정보를 포함하고 다른 일부는 공개로 간주될 수 있습니다. "private" 지시문을 사용하여 CDN이 개인 데이터를 캐싱하지 못하도록 합니다.

이미지 요청이 구문 분석이나 렌더링을 차단하지 않더라도 웹 이미지 최적화도 수행할 수 있습니다.

2. 중요 리소스의 총 수 줄이기

"중요"는 웹 페이지가 제대로 렌더링되는 데 필요한 리소스만 나타냅니다. 따라서 프로세스에 직접 관련되지 않은 모든 스타일을 건너뛸 수 있습니다. 그리고 모든 스크립트도 마찬가지입니다.

스타일시트

특정 CSS 파일이 필요하지 않다고 브라우저에 알리려면 스타일시트를 참조하는 모든 링크에 media 속성을 설정해야 합니다. 이 접근 방식을 사용하면 브라우저는 현재 media (장치 유형, 화면 크기)와 일치하는 리소스만 필요에 따라 처리하고 다른 모든 스타일시트의 우선 순위를 낮춥니다(어쨌든 처리되지만 중요한 렌더링의 일부로 처리되지는 않습니다. 길). 예를 들어 페이지를 인쇄하기 위한 스타일을 참조하는 style 태그에 media="print" 속성을 추가하면 미디어가 print 되지 않을 때(즉, 브라우저의 페이지).

프로세스를 더욱 개선하기 위해 일부 스타일을 인라인으로 만들 수도 있습니다. 이렇게 하면 스타일시트를 가져오는 데 필요한 서버로의 왕복을 최소한 한 번 절약할 수 있습니다.

스크립트

위에서 언급했듯이 스크립트는 DOM 및 CSSOM을 변경할 수 있기 때문에 파서 차단입니다. 따라서 스크립트를 변경하지 않는 스크립트는 구문 분석을 차단해서는 안 되므로 시간을 절약할 수 있습니다.

이를 구현하려면 모든 스크립트 태그에 async 또는 defer 속성을 표시해야 합니다.

async 로 표시된 스크립트는 CSSOM이 빌드되기 전에 실행할 수 있으므로 DOM 구성 또는 CSSOM을 차단하지 않습니다. 그러나 인라인 스크립트는 CSS 위에 놓지 않는 한 CSSOM을 차단합니다.

대조적으로 defer 로 표시된 스크립트는 페이지 로드가 끝날 때 평가됩니다. 따라서 문서에 영향을 주지 않아야 합니다(그렇지 않으면 다시 렌더링됩니다).

즉, defer 를 사용하면 페이지 로드 이벤트가 발생한 후까지 스크립트가 실행되지 않는 반면, async 는 문서가 구문 분석되는 동안 백그라운드에서 스크립트가 실행되도록 합니다.

3. 중요한 렌더링 경로 길이 줄이기

마지막으로 CRP 길이는 가능한 최소로 줄여야 합니다. 부분적으로는 위에서 설명한 접근 방식이 그렇게 할 것입니다.

스타일 태그의 속성인 미디어 쿼리는 다운로드해야 하는 총 리소스 수를 줄입니다. 스크립트 태그 속성 defer 및 async 는 해당 스크립트가 구문 분석을 차단하는 것을 방지합니다.

GZIP을 사용하여 리소스를 축소, 압축 및 보관하면 전송되는 데이터의 크기가 줄어듭니다(따라서 데이터 전송 시간도 단축됨).

일부 스타일과 스크립트를 인라인하면 브라우저와 서버 간의 왕복 횟수를 줄일 수 있습니다.

아직 논의하지 않은 것은 파일 사이에서 코드를 재배열하는 옵션입니다. 최고의 성능에 대한 최신 아이디어에 따르면 웹 사이트가 가장 빠르게 수행해야 할 첫 번째 일은 ATF 콘텐츠를 표시하는 것입니다. ATF는 스크롤 없이 볼 수 있는 부분을 나타냅니다. 스크롤 없이 바로 보이는 영역입니다. 따라서 필요한 스타일과 스크립트가 먼저 로드되는 방식으로 렌더링과 관련된 모든 것을 재정렬하는 것이 가장 좋으며, 구문 분석이나 렌더링이 아닌 다른 모든 것은 중지됩니다. 그리고 변경하기 전과 후에 측정하는 것을 항상 기억하십시오.

결론: 전체 스택을 아우르는 최적화

요약하면 웹사이트 성능 최적화는 캐싱, CDN 설정, 리팩토링, 리소스 최적화 등과 같은 사이트 응답의 모든 측면을 통합하지만 이 모든 것은 점진적으로 수행할 수 있습니다. 웹 개발자는 이 문서를 참조로 사용해야 하며 실험 전후에 성능을 측정하는 것을 항상 기억해야 합니다.

브라우저 개발자는 방문하는 모든 페이지에 대해 웹사이트 성능을 최적화하기 위해 최선을 다합니다. 이것이 브라우저가 일반적으로 소위 "프리로더"를 구현하는 이유입니다. 프로그램의 이 부분은 한 번에 여러 요청을 만들고 병렬로 실행하기 위해 HTML에서 요청한 리소스보다 먼저 검색합니다. 이것이 스크립트 태그뿐만 아니라 HTML(라인 단위)에서 스타일 태그를 서로 가깝게 유지하는 것이 더 나은 이유입니다.

또한 DOM 또는 CSSOM의 변경뿐만 아니라 장치 방향 변경 및 창 크기 조정에 의해 트리거되는 여러 레이아웃 이벤트를 피하기 위해 HTML 업데이트를 일괄 처리하십시오.

유용한 리소스 및 추가 참고 자료:

PageSpeed 인사이트
캐싱 체크리스트
웹사이트에 GZIP이 활성화되어 있는지 테스트하는 방법
고성능 브라우저 네트워킹: Ilya Grigorik의 책