웹 성능, 라이트하우스 점수 100 유지.

웹 사이트 경험 품질은 웹 사이트의 비즈니스 목표를 달성하고 방문자의 만족도를 높이는 데 매우 중요합니다.

Adobe Experience Manager(AEM)는 우수한 경험과 최적의 웹 성능을 제공하도록 최적화되었습니다. RUM(Real Use Monitoring) 작업 데이터 수집을 사용하면 필드 사용에서 정보가 지속적으로 수집되며 CRuX 데이터가 코드 및 배포 변경의 효과를 나타낼 때까지 기다릴 필요 없이 실제 사용 성능 측정을 반복할 수 있습니다. RUM에서 수집된 필드 데이터는 실제 장치에 대한 네트워크, 지리적 위치 및 처리 능력이 실험실의 시뮬레이션된 조건보다 훨씬 다양하기 때문에 실험 결과에서 벗어나는 것이 일반적입니다.

Google PageSpeed Insight Service는 훌륭한 랩 측정 도구입니다. 웹 사이트의 성능 및 경험 점수가 느리게 저하되는 것을 방지하기 위해 사용할 수 있습니다.

개발자 튜토리얼에서와 같이 Boilerplate으로 프로젝트를 시작하면 100에 모바일과 데스크톱 모두에 대한 PageSpeed Insight에서 매우 안정적인 Lighthouse 점수를 받게 됩니다. 등대 점수의 모든 구성 요소에는 프로젝트 코드가 사용하고 완벽한 100 등대 점수의 경계 내에 있을 수 있는 버퍼가 있습니다.

가져오기 요청 테스트

Lighthouse 점수가 낮으면 향상하기 어렵지만 테스트를 계속 진행하면 100에서 유지하는 것이 어렵지 않습니다.

프로젝트에서 끌어오기 요청(PR)을 열면 프로젝트 설명의 테스트 URL이 PageSpeed Insights 서비스를 실행하는 데 사용됩니다. 점수가 100 미만이면 AEM GitHub 봇이 자동으로 PR을 실패하고 결과의 일부 변동성을 설명하기 위해 약간의 버퍼가 사용됩니다.

그 결과는 모바일 등대 점수에 대한 것인데, 이는 데스크탑 보다 달성하기 어려운 경향이 있기 때문이다.

Google PageSpeed Insights를 사용해야 하는 이유

많은 팀과 개인이 Lighthouse 점수를 측정하기 위해 자체 구성을 사용합니다. 다양한 팀이 자체 테스트 하니스를 개발하고 지속적인 모니터링 및 성능 보고 사례의 일부로 설정된 구성을 통해 자체 테스트 도구를 사용합니다.

웹 사이트의 성능은 검색 결과의 순위에 영향을 주며 이는 crUX 보고서의 핵심 웹 바이탈에 반영됩니다. Google은 장치 정보의 관련 평균 조합(예: 화면 크기)과 해당 장치의 네트워크 성능에 대한 뛰어난 처리 능력을 갖추고 있습니다. 그러나 결국, SEO는 좋은 웹 성능과 나쁜 웹 성능이 무엇인지에 대한 궁극적인 중재자이다. 특정 구성이 움직이는 대상이므로 성능 사례는 전 세계의 현재 평균 디바이스 및 네트워크 특성에 맞게 조정되어야 합니다.

따라서 Lighthouse 테스트를 위해 프로젝트별 구성을 사용하는 대신, 최신 버전의 Google PageSpeed Insights API에서 참조한 모바일 및 데스크톱 전략의 일부로 볼 수 있는 지속적으로 업데이트된 구성을 사용합니다.

일부 개발자는 Lighthouse 점수를 측정하는 다른 방법으로부터 수집할 수 있다고 생각하는 추가적인 통찰력이 있을 수 있지만 프로젝트 간에 의미 있고 비슷한 성능 대화를 나눌 수 있으려면 일반적으로 성능을 측정하는 방법이 있어야 합니다. 기본 PageSpeed Insight Service는 성능 측정에 있어 가장 권위적이고 가장 널리 받아들여지는 랩 테스트입니다.

그러나 PageSpeed Insights에서 받은 권장 사항이 반드시 더 나은 결과를 초래하는 것은 아니며, 특히 등대 점수가 100에 가까울수록 더 좋다는 것을 기억해야 합니다.

기본 제공 RUM 데이터 수집으로 수집된 CWV(Core Web Vitals)는 결과를 확인하는 데 중요한 역할을 합니다. 그러나 사소한 변경의 경우 결과의 분산과 단기간에 충분한 데이터 포인트(트래픽)가 없으면 대부분의 경우 통계적으로 관련된 결과를 얻는 것이 어렵습니다.

3상 로딩(E-L-D)

웹 페이지에 있는 페이로드를 세 단계로 분류하면 등대 점수가 깔끔하게 나오는 것이 비교적 간단하므로 훌륭한 고객 경험을 위한 기준을 마련할 수 있습니다.

3단계 로드 접근 방식은 페이로드와 페이지 실행을 3단계로 나눕니다

E단계: 진행 중

작업이 발생하기 전에 이미지 다운로드를 시작하지 않도록 하고 초기 CLS을(를) 방지하려면 본문을 숨겨야 합니다(display:none 포함).

열망 단계에서 첫 번째 작업은 DOM을(를) "장식"하는 것입니다. 로딩 순서는 주로 아이콘, 단추, 블록 및 섹션에 CSS 클래스를 추가하고 자동 블록을 만듭니다. 결과 마크업에 대한 자세한 내용은 마크업, 섹션, 블록 및 자동 차단 페이지를 참조하십시오.

그런 다음 섹션이 아직 로드되지 않았으며 숨겨진 상태로 남아 있음을 고려하여 본문을 이미 표시할 수 있습니다.

그런 다음 전체 첫 번째 섹션 ​에 이 섹션의 첫 번째 이미지인 "LCP 후보"에 우선 순위가 지정됩니다. 이론상 첫 번째 섹션에 있는 블록이 적을수록 LCP을(를) 더 빨리 로드할 수 있습니다.

LCP 후보 및 섹션의 모든 블록이 로드되면 첫 번째 섹션이 표시되고 글꼴이 비동기식으로 로드될 수 있습니다.

열거 단계를 종료합니다.

LCP

일반적으로 LCP은(는) 페이지 맨 위에 표시되는 "영웅" 이미지입니다. 이 이미지가 로드 시퀀스에서 가능한 한 빨리 로드되어 표시되도록 하는 것이 중요합니다(Eague 단계 참조).

실제 LCP을(를) 표시하기 위해 로드해야 하는 모든 항목을 로드해야 합니다. 프로젝트에서 이 태그는 일반적으로 마크업, CSS 스타일 및 JavaScript 파일로 구성됩니다.

대부분의 경우 LCP 요소가 블록에 포함되어 있습니다. 여기서 블록 .js 및 .css도 로드되어야 합니다.

LCP이(가) 100kb 아래에 표시되기 전에 집계 페이로드를 유지하는 것이 좋습니다. 이 경우 일반적으로 1560ms(PSI 100에서 LCP 점수 매기기)보다 빠른 LCP 이벤트가 발생합니다. 특히 모바일에서 네트워크는 대역폭 제한이 있는 경향이 있으므로 LCP 전에 로딩 순서를 변경하면 영향을 최소화할 수 있습니다.

LCP이(가) 발생하기 전에 두 번째 원본에서 로드하거나 두 번째 원본에 연결하는 것은 두 번째 연결(TLS, DNS 등)을 설정하면 LCP에 상당한 지연이 추가되므로 권장되지 않습니다.

실제 LCP 요소가 클라이언트에 전송되는 마크업에 포함되지 않는 경우가 있습니다. 이 문제는 LCP 요소에 대해 간접 또는 조회(예: 호출된 서비스, 로드된 조각 또는 .json에서 일어나야 하는 조회)가 있는 경우 발생합니다.
이러한 경우, 첫 번째 블록이 DOM에 필요한 변경 작업을 수행할 때까지 LCP 후보(현재 페이지의 첫 번째 이미지)를 예상하면서 페이지 로드가 대기하는 것이 중요합니다.

콘텐츠에 데스크톱용 이미지, 모바일용 이미지 등 2개의 영웅 이미지가 포함된 다른 상황도 있습니다. 위와 마찬가지로, 올바른 이미지를 LCP 후보로 간주하고 "hero" 블록을 조정해야 DOM에서 불필요한 이미지를 제거(모바일 장치에서 데스크톱 이미지를 제거 또는 그 반대로 제거)하여 대역폭 사용 이미지를 로드하지 않고, 불필요한 이미지를 LCP 후보로 먼저 로드하도록 하는 것이 중요합니다.

마지막으로 LCP은(는) 이미지, 비디오, 긴 텍스트 이외의 항목이 될 수 있습니다. 이러한 모든 경우 올바른 최적화를 위해 로딩 시퀀스와 LCP 후보의 계산 방법을 깊이 이해해야 합니다.

단계 L: 지연

지연 단계에서 총 차단 시간(TBT) 및 궁극적으로 첫 번째 입력 지연(FID)에 영향을 주지 않는 페이로드의 부분이 로드됩니다.

여기에는 다음 섹션 및 해당 블록(JavaScript 및 CSS) 로드와 loading="lazy" 특성 및 차단되지 않는 기타 JavaScript 라이브러리에 따라 나머지 모든 이미지 로드와 같은 작업이 포함됩니다. 지연 단계는 일반적으로 프로젝트 요구 사항을 처리하기 위해 만들려는 여러 blocks에서 발생하는 모든 것입니다.

이 단계에서는 페이로드의 대량이 동일한 원본에서 오고 퍼스트 파티가 제어하여 TBT, TTI 및 FID에 부정적인 영향을 주지 않도록 필요한 경우 변경할 수 있도록 하는 것이 좋습니다.

단계 D: 지연됨

delayed 단계에서 경험에 즉각적인 영향을 주지 않거나 프로젝트에 의해 제어되지 않고 타사에서 가져온 페이로드의 부분이 로드됩니다. 마케팅 도구, 동의 관리, 확장된 분석, 채팅/상호 작용 모듈 등을 생각해 보십시오. 태그 관리 솔루션을 통해 배포되는 경우가 많습니다.

전반적인 고객 경험에 미치는 영향을 최소화하려면 이 단계의 시작을 상당히 지연해야 한다는 사실을 이해하는 것이 중요합니다. 지연된 단계는 LCP 이벤트 후 최소 3초여야 나머지 경험이 해결될 수 있는 충분한 시간을 남길 수 있습니다.

지연된 단계는 일반적으로 TBT을(를) 유발하는 스크립트의 초기 다목적 캐치(catch-all) 역할을 하는 delayed.js에서 처리됩니다. TBT 문제는 주 스레드 외부(웹 작업자)에서 로드하거나 코드에서 실제 차단 시간을 제거하여 문제가 있는 스크립트에서 제거하는 것이 가장 좋습니다. 문제가 해결되면 해당 라이브러리를 지연 단계에 쉽게 추가하고 더 일찍 로드할 수 있습니다.

스크립트에는 차단 시간이 없는 것이 이상적입니다. 이는 종종 태그 관리자나 빌드 도구와 같이 일반적으로 사용되는 기술로는 달성하기 어려운 기술로서, 브라우저가 파일을 구문 분석할 때 차단되는 큰 JavaScript 파일을 만듭니다. 성능 측면에서는 이러한 기술을 제거하고 개별 스크립트가 차단되지 않는지 확인한 다음 개별 작은 파일로 개별적으로 로드하는 것이 좋습니다.

머리글 및 바닥글

페이지의 머리글과 바닥글이 LCP에 대한 중요 경로에 없으므로 각 블록에 비동기적으로 로드됩니다. 일반적으로 동일한 라이프 사이클을 공유하지 않는 리소스(즉, 서로 다른 시간에 작성 변경 내용으로 업데이트됨)는 원본과 브라우저 간의 캐싱 체인을 보다 간단하고 효율적으로 만들려면 별도의 문서에 보관해야 합니다. 이러한 리소스를 분리하면 캐시 적중률이 증가하고 캐시 무효화와 캐시 관리의 복잡성이 줄어듭니다.

글꼴

웹 글꼴은 종종 대역폭에 영향을 주고 https://fonts.adobe.com 또는 https://fonts.google.com과(와) 같은 글꼴 서비스를 통해 다른 원본에서 로드되기 때문에 LCP 전에 글꼴을 로드하는 것은 거의 불가능하므로 이후에 바로 로드됩니다.

기본적으로 AEM Boilerplate은 글꼴이 로드될 때 CLS을(를) 방지하기 위해 글꼴 대체 기술을 구현합니다. 초기 힌트, h2-푸시 또는 마크업을 통해 글꼴을 미리 로드하여 성능에 큰 영향을 주는 것은 역효과를 낼 수 있습니다.

보너스: 속도가 녹색임

빠르고, 작고, 렌더링이 빠른 웹 사이트를 구축하는 것은 더 잘 전환되는 탁월한 경험을 제공하는 좋은 아이디어일 뿐만 아니라, 탄소 배출을 줄이는 좋은 방법입니다.

성능 문제의 일반적인 원인

시간이 지남에 따라 성능에 부정적인 영향을 주는 방지 패턴의 컬렉션을 수집했으며, 이 문서의 모범 사례를 준수하지 않도록 해야 합니다.

초기 힌트 / h2-푸시 / 사전 연결 은 네트워크 예산의 일부입니다.

본능적으로, 마크업 처리가 시작되기도 전에 브라우저에서 가능한 한 많이, 가능한 한 빨리 다운로드하도록 하는 것이 적절할 것입니다. 그러나 궁극적인 목표는 가능한 한 빨리 방문자에게 표시할 안정적인 페이지를 확보하는 것입니다. LCP 타이밍은 좋은 프록시입니다.

일반적으로 PageSpeed Insight를 사용하여 모바일에서 100에 LCP을(를) 가져오려면 설정이 대역폭 제한이 있으므로 네트워크 페이로드가 100kb를 초과하지 않는 단일 호스트만 있을 수 있는 방식으로 네트워크 제한이 설정됩니다. 초기 힌트, h2-푸시 및 사전 연결은 LCP에 필요하지 않은 리소스를 다운로드하여 해당 대역폭을 소비하므로 성능에 부정적인 영향을 미치므로 제거해야 합니다.

경로 확인을 위한 리디렉션

방문자가 www.domain.com을(를) 요청하고 www.domain.com/en(으)로 리디렉션된 다음 www.domain.com/en/home,(으)로 리디렉션되면 각 리디렉션에 대한 패널티를 받게 됩니다. 즉, 성능에 부정적인 영향을 줍니다. 이는 랩 결과에서 기본적으로 PageSpeed Insights가 랩 테스트에서 리디렉션 오버헤드를 제외하므로 RUM 또는 CrUX를 통해 측정된 핵심 웹 바이탈에서 대부분 표시됩니다.

CDN 클라이언트 스크립트 삽입

마크업뿐만 아니라 .aem.page 및 .aem.live 원본도 성능에 최적화되어 있으므로 리소스의 로드 순서 뿐만 아니라 페이로드의 어떤 부분에도 매우 주의합니다.

일부 CDN 공급업체 및 구성은 대역폭을 소비하고 차단 시간을 생성하는 스크립트를 LCP 전에 삽입하여 성능에 부정적인 영향을 줍니다. 이러한 스크립트를 사용하지 않도록 설정하거나 LCP 후 로드 시퀀스에서 적절히 로드해야 합니다.

PageSpeed Insight 보고서의 .aem.live 원본과 고객 CDN(예: 프로덕션 사이트)의 앞에 있는 해당 사이트의 비교를 수행하면 AEM의 제어 외부에서 CDN이 생성하는 부정적인 영향이 표시됩니다.

CDN TTFB 및 프로토콜 구현 영향

CDN 공급업체에 따라 HTTP 페이로드의 순수 전달에 대한 프로토콜 구현과 성능 특성에 차이가 있습니다. WAF 및 AEM의 기타 네트워크 인프라 업스트림과 같은 추가 도구 역시 성능에 부정적인 영향을 줄 수 있습니다.
PageSpeed Insight 보고서의 .aem.live 원본과 고객 CDN(예: 프로덕션 사이트)의 앞에 있는 해당 사이트의 비교를 수행하면 AEM의 제어 외부에서 CDN이 생성하는 부정적인 영향이 표시됩니다.