Google Lighthouse: 사용자 경험 및 검색 엔진 가시성 향상을 위한 윤리적 해커 매뉴얼(2024)

Google Lighthouse는 개발자를 위한 웹 페이지 성능 향상을 게임화하고 장려하는 가장 효율적인 방법 중 하나로 돋보입니다. Lighthouse를 활용하면 버튼 하나만 누르면 전반적인 효율성, 접근성, SEO 및 Google가 선호하는 "모범 사례" 측면에서 웹 페이지를 평가할 수 있습니다.

이러한 검사는 프런트 엔드 프레임워크의 기본 성능을 평가하거나 세심한 재구성을 통해 달성된 효율성 향상을 보여주는 데 활용될 수 있습니다. 소셜 미디어에 귀하의 완벽한 Lighthouse 평가를 표시하는 것은 부인할 수 없이 만족스러운 일입니다. 이는 활기찬 축하를 받을 만한 가치 있는 성과입니다.

Lighthouse가 우리와 같은 개발자들 사이에서 성능에 관한 대화를 유도한다는 단순한 사실은 승리입니다. 그러나 문제의 중요성을 무시하지 않고 웹 성능은 훨씬 더 복잡합니다. 이 글에서는 Google Lighthouse의 성능 평가 이면에 있는 방법론을 살펴보고, 이러한 지식을 활용하여 결과를 우리에게 유리하게 조작하려고 노력할 것입니다. 모두 즐거움과 탐험의 정신으로 – 궁극적으로 Lighthouse는 성능 문제를 진단하기 위한 신뢰할 수 있으면서도 대략적인 가이드 역할을 합니다. 재미있게 놀면서 우리가 정당하게 받을 수 있는 것 이상으로 향상된 점수를 제시하기 위해 Lighthouse를 얼마나 능가할 수 있는지 관찰해 봅시다.

하지만 그 전에 먼저 데이터를 살펴보겠습니다.

현장 데이터는 필수입니다

로컬 성능 평가는 웹 사이트 성능이 긍정적인 방향으로 움직이고 있는지에 대한 귀중한 통찰력을 제공하지만 현실을 완벽하게 나타내지는 않습니다. 인터넷은 무한한 다양성의 영역이며, 종합적으로 우리는 웹 사이트에 액세스하는 개인이 사용하는 수많은 장치, 인터넷 속도, 화면 크기, 브라우저 및 브라우저 버전을 추적하지 못했을 가능성이 높습니다. 이 모든 것이 페이지 성능과 사용자 상호 작용에 영향을 미칠 수 있습니다. .

Sentry와 같은 애플리케이션 성능 모니터링 도구를 통해 자신의 기기에서 웹 사이트에 액세스하는 실제 사용자로부터 수집한 대량의 필드 데이터는 높은 수준의 샘플을 사용하여 얻은 단일 샘플에서 얻은 실험실 데이터와 비교하여 웹 사이트 성능에 대한 훨씬 더 정확한 평가를 제공합니다. 통제된 상황에서 구동되는 현상기. 2021년 Philip Walton이 공개한 HTTP 아카이브의 데이터는 "Lighthouse에서 100점을 받은 모든 페이지의 거의 절반이 권장되는 핵심 웹 바이탈 임계값을 충족하지 못했다"는 점을 강조했습니다.

웹 성능은 단일 핵심 웹 필수 지표 또는 Lighthouse 성능 등급 이상으로 확장됩니다. 우리의 담론은 우리가 작업하는 기본 데이터 유형을 초월합니다.

웹 성능은 통계 이상의 것을 포함합니다.

속도 웹 성능, 즉 페이지가 얼마나 빨리 로드되는지에 대한 논의에서 주요 초점으로 자주 등장합니다. 이는 고려해야 할 중요한 요소이지만 속도는 비즈니스 목표와 판매 목표에 크게 영향을 받는다는 점을 인정해야 합니다. 2018년 Google가 발표한 보고서에 따르면 페이지 로딩 시간이 3초를 초과하면 32%에 의한 이탈률이 증가할 가능성이 커지고, 로딩 시간이 10초를 초과하면 123%로 급증합니다. 따라서 판매 전환율을 높이기 위해서는 페이지 로딩 속도를 높이는 것이 필요합니다. 이탈률을 줄이는 핵심 의도는 페이지를 신속하게 처리하는 것입니다. 로드 중.

그런데 "더 빠르게 로드"한다는 것은 정확히 무엇을 의미합니까? 웹페이지의 로딩 속도를 물리적으로 가속화할 수 없는 임계값이 있습니다. 인간과 그들을 연결하는 서버는 전 세계적으로 분산되어 있으며 현대 인터넷 인프라는 주어진 시간에 제한된 양의 데이터만 전송할 수 있습니다.

문제의 핵심은 페이지 로딩이 특정 순간을 나타내지 않는다는 것입니다. “속도란 무엇인가?”라는 제목의 기사에서 Google는 페이지 로딩 사고가 다음과 같다는 것을 설명합니다.

단일 지표로는 완전히 캡슐화할 수 없는 만남입니다. 로딩 과정 중 수많은 인스턴스가 사용자가 '빠르다'고 인식하는지 여부에 영향을 미칠 수 있으며, 하나만 집중하면 남은 시간 동안 발생하는 부정적인 사건을 간과할 수 있습니다.

여기서 핵심 용어는 경험. 진정한 웹 성능은 그 이상입니다. 측정항목 그리고 속도, 더 집중하다 우리가 어떻게 인식하는지 사용자로서의 페이지 로딩 및 페이지 조작성. 이를 통해 Google Lighthouse가 성능 등급을 계산하는 방법에 대한 대화로 쉽게 이어집니다. (사람들이 생각하는 것보다 순전히 속도에 관한 것이 눈에 띄게 적습니다.)

Google Lighthouse 성능 점수는 어떻게 결정되나요?

Google Lighthouse 성능 점수 계산에는 핵심 웹 필수 지표(예: FCP(첫 번째 콘텐츠 포함 페인트), LCP(최대 콘텐츠 포함 페인트), CLS(누적 레이아웃 전환)) 및 기타 속도 관련 지표에서 파생된 점수의 가중치 통합이 포함됩니다. (예: 속도 지수(SI) 및 총 차단 시간(TBT)) 페이지 로딩 타임라인 전반에 걸쳐 분명하게 나타남.

다음은 전체 점수 내에서 이러한 지표에 가중치가 부여되는 방식에 대한 분석입니다.

각 지표에 가중치를 할당하면 Google가 우수한 사용자 경험에 기여하는 다양한 요소의 우선 순위를 어떻게 지정하는지에 대한 통찰력을 얻을 수 있습니다.

1. 웹페이지는 사용자 입력에 즉시 응답해야 합니다.

기본 가중 측정항목은 다음과 같습니다. 총 차단 시간(TBT), 이후의 지속 시간을 검사하는 게이지 첫 번째 콘텐츠가 포함된 페인트(FCP) 메인 스레드가 장기간 방해를 받아 사용자 명령에 대한 신속한 응답을 방해할 수 있는 인스턴스를 식별합니다. 메인 스레드에서 JavaScript 작업이 50ms 이상 발생할 때마다 메인 스레드는 "차단"된 것으로 간주됩니다. TBT를 줄이면 웹 사이트가 유형의 사용자 작업(예: 키보드 입력, 마우스 클릭 등)에 반응하는 것이 보장됩니다.

2. 웹페이지는 예상치 못한 시각적 변동 없이 관련 콘텐츠를 표시해야 합니다.

후속 가중치가 높은 Lighthouse 측정항목은 다음을 포함합니다. 콘텐츠가 포함된 최대 페인트(LCP) 그리고 CLS(누적 레이아웃 변경). LCP는 페이지의 기본 콘텐츠가 로드되는 시점을 나타냅니다. 아마도 로드되었으므로 귀중한.

기본 콘텐츠 로딩이 완료되는 것으로 예상되는 경우 원활한 사용자 참여를 보장하고 예상치 못한 시각적 중단을 방지하려면 시각적 일관성을 유지하는 것이 중요합니다. 갑작스러운 시각적 움직임(CLS)의 영향을 받지 않습니다. 이상적인 LCP 측정은 2.5초 미만의 지속 시간입니다. 최대한 신속하게).

3. 웹페이지에 콘텐츠 로딩

그만큼 첫 번째 콘텐츠가 포함된 페인트(FCP) 측정항목은 사용자가 화면의 콘텐츠를 식별할 수 있는 페이지 로딩 과정의 초기 순간을 의미합니다. 속도지수(SI) 페이지가 "완료" 상태에 도달할 때까지 로딩 프로세스 중에 콘텐츠가 시각적으로 얼마나 빠르게 표시되는지 측정합니다.

귀하의 페이지 평가는 HTTP Archive의 성능 통계를 활용하여 실제 웹사이트의 속도 측정을 기반으로 합니다. 칭찬할 수 있는 FCP 지표는 1.8초 미만이고, 칭찬할 수 있는 SI 지표는 3.4초 미만입니다. 이러한 벤치마크는 속도를 고려할 때 예상할 수 있는 것보다 높습니다.

순수한 속도보다 유용성을 선호합니다.

Google Lighthouse의 성능 평가는 의심할 여지 없이 속도보다는 유용성을 강조합니다. SI 및 FCP는 탁월한 속도를 보일 수 있지만 LCP에서 렌더링 지연이 발생하여 정교한 이미지나 외부 콘텐츠로 인해 시각적 변화가 발생하여 CLS가 발생하는 경우 페이지가 약간 지연되는 시나리오에 비해 전반적인 성능 평가가 열등해집니다. FCP를 표시하지만 CLS 발생을 방지합니다. 본질적으로 JavaScript가 50ms 이상 메인 스레드를 방해하여 페이지의 응답성을 방해하는 경우 페이지에서 FCP 표시를 약간 지연시키는 경우보다 성능 평가에 더 부정적인 영향을 미치게 됩니다.

각 지표의 가중치가 최종 성능 평가에 어떻게 영향을 미치는지 더 잘 이해하려면 Lighthouse 점수 계산기의 슬라이딩 컨트롤을 사용해 볼 수 있습니다. 다음은 전체 성능 평가에서 개별 지표 가중치에 대한 편향된 강조가 미치는 영향을 설명하는 간단한 표입니다. 이는 순전히 속도보다 페이지 유용성과 응답성에 우선 순위가 있음을 입증합니다.

전체 Google Lighthouse 성능 점수는 HTTP 아카이브의 실제 웹 사이트 성능 데이터의 성능 측정 항목에서 비롯된 Lighthouse 점수 분포 내 배치를 기반으로 각 원시 측정 항목 값을 0~100 범위의 점수로 변환하여 계산됩니다. 수학적으로 집약적인 이 데이터에서 두 가지 중요한 사실이 드러납니다.

1. 귀하의 Lighthouse 성능 점수는 개별적으로 분리되지 않고 실제 웹사이트 성능 데이터에 따라 상황에 맞게 조정됩니다.
2. 점수 매기기에서 로그 정규 분포를 활용하면 개별 지표 값과 총 점수 간의 상관 관계가 비선형입니다. 즉, 성과가 낮은 점수를 크게 향상시킬 수 있지만 이미 높은 점수를 향상시키는 것은 더욱 어려워집니다.

개발자.chrome.com에서 로그 정규 분포 곡선의 그래픽 표현을 통해 측정항목 점수를 확인하는 방법에 대해 자세히 알아보세요.

Google Lighthouse를 능가하는 것이 가능합니까?

나는 웹 성능에 대한 담론에서 순전한 속도보다는 유용성을 강조하는 Google의 점에 감탄합니다. 이는 개발자가 임의의 지표를 추구하는 것보다 진정한 경험을 창출하는 데 우선순위를 두도록 권장합니다. 그럼에도 불구하고, 나는 2024년이라는 오늘날의 시대에 Google Lighthouse가 잘못 설계되고 도움이 되지 않는 페이지를 뛰어난 것으로 인식하도록 속이는 것이 가능한지 생각해 보았습니다.

나는 조사를 시작하기 위해 실험복과 과학용 고글을 착용했습니다. 모든 테스트는 다음과 같이 수행되었습니다.

• Chromium Lighthouse 플러그인을 사용하면,
• Arc 브라우저를 사용하는 시크릿 창에서
• "내비게이션" 및 "모바일" 구성 선택(달리 지정된 경우 제외)
• 제가 작성한 연구실 환경(즉, 실제 데이터 없음) 내입니다.

이 게시물 시작 부분의 조언과 모순되는 통제된 실험 환경에도 불구하고 실험은 흥미로운 노력임이 입증되었습니다. 나는 여러분이 Lighthouse 점수가 복잡한 웹 성능 퍼즐의 한 요소일 뿐이라는 사실을 깨닫기를 바랍니다. 비록 사소하기는 하지만요. 더욱이, 실제 데이터가 부족하여 이러한 발견의 타당성에 의문이 제기될 수 있습니다.

FCP 및 LCP 점수 조작 전략

핵심요약: Lighthouse 평가가 완료될 때까지 FCP 및 LCP 점수를 높이기 위해 로드 시 최소한의 LCP 적격 콘텐츠를 표시합니다.

FCP는 사용자가 화면의 모든 콘텐츠를 인식할 수 있는 페이지 로딩 프로세스의 초기 단계를 지정하는 반면, LCP는 기본 페이지 콘텐츠(예: 가장 큰 텍스트 또는 이미지 요소)가 로드되었을 가능성이 있는 로딩 타임라인의 지점을 나타냅니다. 신속한 LCP는 페이지 내용에 대한 사용자의 신뢰도를 강화하는 데 기여합니다. 이익. 여기서 염두에 두어야 할 핵심 용어는 "가능성이 있는"과 "유익한"입니다.

LCP 요소 식별

Lighthouse에서 LCP를 위해 고려하는 웹페이지의 요소 범주는 다음과 같습니다.

• <img> 태그
• <image> 내의 태그 <svg> 꼬리표
• 태그
• 배경 이미지가 로드된 요소 URL() 기능(CSS 그래디언트 제외)
• 텍스트 노드 또는 인라인 수준 텍스트 요소를 포함하는 블록 수준 요소

그에 따른 요소는 다음과 같습니다. 생략 유용한 콘텐츠가 부족하다는 추정으로 인해 LCP 고려 사항에서:

• 투명도가 0인 요소(사용자에게 보이지 않음),
• 전체 뷰포트를 가리는 요소(배경 요소일 가능성이 있음) 및
• 자리 표시자 이미지 또는 한계 엔트로피가 있는 정보가 적은 콘텐츠 이미지(예: 단색 이미지).

그러나 이미지나 텍스트 요소를 유익한 것으로 판단하는 개념은 이 시나리오에서 매우 주관적이며 일반적으로 기계 알고리즘이 안정적으로 결정할 수 있는 범위를 벗어납니다. 예를 들어, 내가 만든 페이지에는 다음과 같은 내용만 포함되어 있습니다. <h1> 이 태그는 10초가 지나면 JavaScript에 의해 DOM에 추가 설명 콘텐츠가 삽입된 다음 숨깁니다. <h1> 꼬리표.

실험에 따르면 Lighthouse는 제목 태그를 가장 큰 콘텐츠 포함 페인트(LCP) 구성 요소로 간주합니다. 이 단계에 도달하면 페이지의 로드 타임라인이 완료되지만 기본 콘텐츠는 완전히 로드되지 않습니다. 그럼에도 불구하고 Lighthouse는 높은 확률로 10초 내에 콘텐츠가 로드되었다고 가정합니다. 놀랍게도 Lighthouse는 제목을 마침표와 같은 간단한 구두점으로 대체하더라도 여전히 만점 100점을 제공하는데, 이는 훨씬 덜 가치가 있습니다.

이 시도는 클라이언트 측 JavaScript를 통해 페이지 콘텐츠를 로드할 때 스켈레톤 로더 화면을 표시하지 않는 것이 더 나을 수 있음을 나타냅니다. 이러한 화면을 표시하려면 페이지에 추가 요소를 로드해야 하기 때문입니다. 이 프로세스에는 시간이 좀 걸린다는 점을 인식하고 전체 차단 시간에 영향을 주지 않도록 네트워크 요청을 메인 스레드에서 웹 작업자로 전송함으로써 더 나은 우선 순위를 위해 최소 실행 가능한 LCP 구성 요소가 포함된 일반 "스플래시 화면"을 사용할 수 있습니다. 콘텐츠가 포함된 페인트(FCP) 점수. 이 접근 방식은 페이지가 실제보다 훨씬 빠르게 사용자 친화적이라는 인상을 Lighthouse에 제공합니다.

필요한 것은 FCP를 나타내는 합법적인 LCP 구성 요소를 포함하는 것뿐입니다. 2024년에는 클라이언트 측 JavaScript를 통해 기본 페이지 콘텐츠를 로드하는 것을 권장하지 않지만(콘텐츠 전달 네트워크에서 정적 HTML을 제공하거나 서버에 최대한 많은 콘텐츠를 구축하는 것을 선호), 이 "해킹"을 사용하는 것도 권장되지 않습니다. Lighthouse 성능 점수에 관계없이 긍정적인 사용자 경험. 또한 이 방법은 검색 엔진 인덱싱에 유용하지 않을 수 있습니다. 왜냐하면 검색 봇이 DOM에 없는 경우 주요 콘텐츠를 찾을 수 없기 때문입니다.

나는 페이지의 유용성을 더욱 감소시키기 위해 LCP로 위장한 다양한 무작위 이미지를 사용하여 유사한 시험을 수행했습니다. 그러나 더 작은 파일 크기를 사용하는 경우(페이지 로딩 속도를 높이기 위해 타사 이미지 API를 통해 추가로 축소 및 "차세대" 이미지 형식으로 변환됨) Lighthouse는 이러한 이미지를 "자리 표시자 이미지" 또는 "낮은 이미지 형식"으로 인식했습니다. 엔트로피”. 결과적으로 이러한 이미지는 LCP 구성 요소로 인식되지 않았으며 이는 LCP가 조작에 덜 민감하도록 만드는 바람직한 결과입니다.

결과를 직접 확인하려면 시크릿 모드에서 Chromium DevTools를 사용하는 데모 페이지를 확인하세요.

그러나 이 전략은 다른 많은 시나리오에서는 효과적이지 않을 수 있습니다. 예를 들어, Discord는 브라우저에서 애플리케이션을 강제로 새로 고칠 때 "스플래시 화면" 방법을 사용하여 29라는 실망스러운 성능 점수를 얻었습니다.

DOM을 삽입한 데모와는 반대로 LCP 구성 요소는 스플래시 화면 자체 내의 요소가 아니라 스플래시 화면 뒤에 숨겨진 일부 콘텐츠로 식별되었습니다. 이는 아마도 제가 테스트한 집중된 텍스트 채널에 하나 이상의 큰 이미지가 있기 때문일 것입니다. . Lighthouse 점수는 검색 엔진에서 색인을 생성할 필요가 없기 때문에 인증 후에만 액세스할 수 있는 애플리케이션의 경우 중요성이 덜하다고 주장할 수 있습니다.

앱이 사용자 생성 콘텐츠를 제공하는 다른 많은 상황에서는 특히 이미지와 관련하여 LCP 구성 요소를 완전히 제어하는 것이 어려울 수 있습니다.

예를 들어, 웹 페이지에 있는 모든 이미지의 크기를 제어할 수 있는 경우 흥미로운 해킹이나 "최적화"(인용 부호)를 활용하여 잠재적으로 시스템을 조작할 수 있습니다. 이는 2021년 RentPath에서 입증되었으며, 개발자는 웹 페이지에서 이미지 썸네일을 확대하여 Lighthouse 성능 점수를 17포인트 높일 수 있었습니다. 그들은 Lighthouse가 JavaScript를 통해 로드하는 데 훨씬 더 오랜 시간이 걸리는 페이지의 Google 지도 타일 대신 LCP 구성 요소를 더 큰 축소판 중 하나로 간주하도록 영향을 미쳤습니다.

중요한 점은 RentPath와 유사한 해킹이나 자체 고안 중 하나를 통해 또는 진정한 개선을 통해 LCP 요소를 염두에 두고 이를 제어할 수 있는 경우 더 높은 Lighthouse 성능 점수를 달성하는 것이 가능하다는 것입니다. 이 기사에서는 스플래시 화면 접근 방식을 해킹으로 규정했지만 이러한 유형의 경험이 의미 있고 즐거운 사용자 경험을 제공할 수 없다는 의미는 아닙니다. 성능과 사용자 경험 모두 로딩 프로세스와 의도를 이해하는 데 달려 있습니다.

CLS 점수 조작 전략

빠른 요약: 데이터가 충분하다는 가정 하에 Lighthouse 테스트가 완료될 가능성이 높을 때까지 레이아웃 변경을 유발하는 콘텐츠 로드를 연기합니다. 변환을 사용하는 CSS 애니메이션은 DOM에 새 요소를 추가하는 것과 결합되는 경우를 제외하고 일반적으로 CLS를 유도하지 않습니다.

CLS는 소수점 단위로 측정되며, 0.1 미만의 점수는 양호, 0.25 이상의 점수는 불량으로 간주됩니다. Lighthouse는 뷰포트 크기와 렌더링된 두 프레임 사이의 불안정한 요소 이동을 고려하여 사용자 세션 중에 발생하는 가장 중요한 일련의 예상치 못한 레이아웃 변경을 기반으로 CLS를 계산합니다. 레이아웃 변경의 개별 인스턴스는 중요하지 않을 수 있지만 일련의 변경이 차례로 발생하면 점수에 해로운 영향을 미칩니다.

페이지가 로드 시 성가신 레이아웃 변경을 유발한다는 것을 알고 있는 경우 페이지 로드가 완료될 때까지 이를 연기하여 Lighthouse가 CLS 문제가 없다고 가정하도록 속일 수 있습니다. 개인적인 예에서 데모 페이지는 새로 추가된 텍스트 요소가 JavaScript를 통해 원본 콘텐츠를 즉시 상향 이동시키는 경우에도 CLS 점수 0.143을 반환합니다. DOM에 새 노드를 추가하는 스크립트를 임의의 5초 동안 일시 중지합니다. 세트타임아웃() 기능을 사용하면 Lighthouse가 CLS 발생을 감지하지 못합니다.

또 다른 데모 페이지는 추가 요소가 사용자 상호 작용 없이 임의로 나타나기 때문에 이전 페이지보다 실용성과 사용자 친화적이지 못함에도 불구하고 완벽한 성능 점수 100점을 달성합니다.

페이지 로드 테스트를 위해 레이아웃 전환을 연기하는 것이 가능하지만 이 해결 방법은 이전에 설명한 것처럼 더 중요한 요소인 필드 데이터 또는 장기적인 사용자 경험에는 효과적이지 않습니다. 지연된 레이아웃 변경이 있는 페이지에서 Lighthouse를 사용하여 "시간 범위" 테스트를 수행할 때 약 0.186이라는 불만족스러운 CLS 점수를 정확하게 보고합니다.

의도적으로 데모와 유사한 혼란스러운 사용자 경험을 만드는 것을 목표로 한다면 CSS 애니메이션과 변환을 활용하여 전략적으로 콘텐츠를 페이지에 표시할 수 있습니다. Google의 CLS 가이드에서는 “한 위치에서 다른 위치로 원활하게 전환되는 콘텐츠는 사용자의 이해력을 높이고 상태 변화를 안내할 수 있다”고 언급하며 상황별 사용자 경험의 중요성을 다시 한 번 강조합니다.

다음 데모 페이지에서는 CSS 변환을 활용합니다. 규모() 텍스트 요소에 애니메이션을 적용하려면 0 에게 1 페이지에서 위치를 변경하세요. 문서가 준비되면 텍스트 노드가 이미 DOM에 있으므로 이러한 변환은 CLS를 트리거하지 않습니다. 실험 중에 JavaScript를 사용하여 페이지를 로드한 후 애니메이션을 적용한 후 텍스트 요소가 DOM에 동적으로 삽입되면 Lighthouse가 CLS를 감지하고 그에 따라 평가한다는 사실을 발견했습니다.

속도 지수 점수는 조작할 수 없습니다.

속도 지수 점수는 렌더링되는 페이지의 시각적 진행을 기반으로 계산됩니다. 페이지 로딩 순서 초기에 콘텐츠가 더 빨리 로드될수록 결과가 더 좋아집니다.

속도 지수를 속여 더 느린 로딩 순서를 인식하도록 특정 전략을 사용하려고 시도할 수 있습니다. 반대로, 콘텐츠 로딩을 인위적으로 빠르게 하는 실행 가능한 방법은 없습니다. 속도 지수 점수를 높이는 유일한 방법은 가능한 한 많은 콘텐츠를 즉시 로드하도록 웹페이지를 수정하는 것입니다. 이 접근 방식은 현재 웹 장면에서 완전히 실용적이지 않을 수 있지만(주로 디자이너의 역할을 위태롭게 하기 때문에) 다음을 통해 속도 지수를 줄이는 데 전념할 수 있습니다.

• CDN에서 직접 정적 HTML 웹 페이지를 제공합니다.
• 페이지에서 이미지를 생략하고,
• CSS를 줄이거나 제거하고,
• JavaScript 또는 외부 종속성 로드를 중지합니다.

또한 TBT 점수를 실제로 조작할 수도 없습니다.

TBT는 사용자 상호 작용에 대한 응답을 방해할 만큼 JavaScript 활동으로 인해 메인 스레드가 방해를 받은 FCP 이후의 총 지속 시간을 측정합니다. 이상적인 TBT 점수는 200ms 미만입니다.

페이지 로딩 중(렌더링된 HTML을 전송하기 전 서버에서가 아니라) 클라이언트 측에서 복잡한 상태 계산 및 DOM 조정을 실행하는 JavaScript(예: 단일 페이지 애플리케이션)를 많이 사용하는 웹 애플리케이션은 낮은 TBT 점수를 얻는 경향이 있습니다. 이러한 시나리오에서는 Lighthouse 평가가 끝날 때까지 모든 JavaScript를 연기하여 TBT 점수를 변경할 수 있습니다. 그럼에도 불구하고 FCP 및 LCP 요구 사항을 충족하고 사용자에게 임박한 활동을 알리기 위해 자리 표시자 콘텐츠나 로딩 화면을 제공해야 합니다. 또한 사용 중인 프런트 엔드 프레임워크를 탐색하려면 노력이 필요합니다. (페이지 로딩 시퀀스 내에서 불확실한 순간에 결국 별도의 React 애플리케이션을 로드하는 자리 표시자 페이지를 로딩하지 마세요!)

흥미로운 측면은 고급 JavaScript 기능이 클라이언트 측 활동에 여전히 널리 퍼져 있는 반면, 현재 웹 환경의 혁신으로 인해 수준 이하의 TBT 점수 발생을 완화하기 위한 집단적 노력이 촉진되고 있다는 것입니다. 최신 호스팅 서비스와 결합된 수많은 프런트엔드 프레임워크는 클라이언트측 JavaScript 없이 페이지를 렌더링하고 요청에 따라 복잡한 로직을 실행할 수 있는 기능을 보유하고 있습니다. 클라이언트 측에서 JavaScript를 제거하는 것이 목표는 아니지만 배포를 줄여 페이지 로딩 중 기본 스레드에서 과도한 계산 작업이 발생할 위험을 줄일 수 있는 가능성은 무수히 많습니다.

요약하자면: 등대는 단지 대략적인 안내에 불과합니다.

Google Lighthouse는 특정 웹사이트의 모든 결함을 찾아낼 수 없습니다. Lighthouse의 성능 지표는 사용자 작업에 대한 응답성 측면에서 페이지 사용성을 우선시하지만 2024년의 모든 사용성 또는 접근성 문제를 포괄적으로 식별하지는 않습니다.

2019년에 Manuel Matuzović는 Lighthouse가 긍정적으로 인식한 잘못 디자인된 웹페이지를 의도적으로 조작하여 실험을 수행했습니다. 나는 Lighthouse의 성능이 5년 후에 향상될 것이라고 추측했습니다. 그러나 이것은 사실이 아니다.

이 마지막 데모 페이지에서는 CSS와 JavaScript가 입력 이벤트를 비활성화하여 페이지가 사용자 작업에 응답하지 않게 만듭니다. 5초 후에 JavaScript는 동작을 변경하여 버튼과의 상호 작용을 허용합니다. 놀랍게도 이 페이지는 성능과 접근성 모두에서 만점을 유지하고 있습니다.

유용성 평가 및 논리적 추론을 대체하기 위해 Lighthouse에만 의존하는 것은 바람직하지 않습니다.

추가적인 기발한 공격

삶의 모든 측면에는 시스템을 조작하는 전략이 존재합니다. 아래에는 Lighthouse 성능 점수를 인위적으로 높여 다른 모든 것보다 뛰어넘을 수 있는 입증되고 보장된 몇 가지 전략이 나와 있습니다.

• 고속 및 최상위 하드웨어에 대해서만 Lighthouse 평가를 수행합니다.
• 인터넷 연결이 최적인지 확인하세요. 필요한 경우 재배치하십시오.
• 앞서 언급한 고속 하드웨어와 탁월한 인터넷 연결을 통해 수집된 실제 사용 데이터를 통합하지 않고 실험실 데이터만 독점적으로 활용합니다.
• 지인, 동료 및 인터넷 낯선 사람에게 깊은 인상을 줄 수 있는 원하는 결과를 얻을 때까지 이 기사에 설명된 모든 독창적인 해킹을 활용하여 다양한 실험실 조건에서 평가를 반복하십시오.

중요한: 웹 성능에 대한 통찰력을 얻고 웹사이트 최적화 기술을 향상시키려면 Sentry와 같은 애플리케이션 모니터링 도구를 채택하는 것을 고려해 보십시오. Lighthouse를 예비 지표로 간주하고 Sentry를 궁극적인 생산 데이터 캡처, 효율적인 웹 바이탈 장치로 간주하십시오.

결론적으로, 여기에 교육 목적의 전체 데모 웹사이트 링크가 있습니다.