Lighthouse: 웹사이트 속도 최적화

Sofia Emelianova
Sofia Emelianova

개요

Lighthouse 패널을 사용하여 웹사이트를 포괄적으로 감사할 수 있습니다. Lighthouse 패널에서는 웹사이트에 대한 다음 정보를 제공하는 보고서를 생성합니다.

  • 성능
  • 접근성
  • 권장사항
  • 검색엔진 최적화

... 그 외 많은 측정항목

다음 튜토리얼에서는 Chrome DevTools에서 Lighthouse를 시작하는 방법을 설명합니다.

Lighthouse에서 웹사이트 품질을 개선하는 다른 방법을 자세히 알아보려면 Lighthouse 문서를 참고하세요.

튜토리얼의 목표

이 튜토리얼에서는 Chrome DevTools를 사용하여 웹사이트를 더 빠르게 로드하는 방법을 찾는 방법을 알려줍니다.

이 튜토리얼의 동영상 버전을 읽거나 시청하세요.

기본 요건

웹 개발 소개 수업에서 다루는 것과 유사한 기본적인 웹 개발 경험이 있어야 합니다.

로드 성능에 대해 전혀 몰라도 됩니다.

소개

저는 토니입니다. 토니는 고양이 협회에서 매우 유명합니다. 팬들이 자신의 좋아하는 음식을 알 수 있도록 웹사이트를 만들었습니다. 팬들은 사이트를 좋아하지만 토니는 사이트 로드 속도가 느립니다. 토니는 사이트 속도를 높일 수 있도록 도와달라고 요청했습니다.

토니 고양이.

1단계: 사이트 감사하기

사이트의 로드 성능을 향상하려고 할 때마다 항상 있습니다. 감사에는 두 가지 중요한 기능이 있습니다.

  • 후속 변경사항을 측정할 수 있는 기준을 만듭니다.
  • 어떤 변화가 가장 큰 영향을 미칠지에 대한 실천 가능한 팁을 제공합니다.

설정

먼저 나중에 변경할 수 있도록 토니의 웹사이트에 관한 새 작업 환경을 설정해야 합니다.

  1. Glitch에서 웹사이트 프로젝트를 리믹스합니다. 새 프로젝트가 탭에서 열립니다. 이 탭을 편집기 탭이라고 합니다.

    리믹스를 클릭한 후의 원본 소스 및 편집기 탭

    프로젝트 이름이 tony에서 무작위로 생성된 이름으로 변경됩니다. 이제 수정 가능한 코드 사본이 생성되었습니다. 나중에 이 코드를 변경합니다.

  2. 편집기 탭 하단에서 미리보기를 클릭합니다. 새 창에서 미리 봅니다. 새 탭에서 데모가 열립니다. 이 탭은 데모 탭이라고 합니다. 사이트가 로드되는 데 다소 시간이 걸릴 수 있습니다.

    데모 탭

  3. 데모와 함께 DevTools를 엽니다.

    데모를 살펴보실 수 있습니다

기준 설정

기준선이란 실적이 개선되기 전의 사이트 실적에 대한 기록을 말합니다.

  1. Lighthouse 패널을 엽니다. 패널 더보기 뒤에 숨겨져 있을 수 있습니다.

    Lighthouse 패널입니다.

  2. Lighthouse 보고서 구성 설정을 스크린샷의 설정과 일치시킵니다. 다음은 다양한 옵션이 있습니다.

    • 저장용량 비우기를 탭합니다. 이 체크박스를 선택하면 모든 감사 전에 페이지와 연결된 모든 스토리지가 삭제됩니다. 신규 방문자의 사이트 경험을 감사하려면 이 설정을 켜진 상태로 둡니다. 재방문 환경을 사용하려면 이 설정을 사용 중지하세요.
    • JS 샘플링 사용 설정. 이 옵션은 기본적으로 사용 중지되어 있습니다. 이 옵션을 사용 설정하면 자세한 자바스크립트 호출 스택이 성능 추적에 추가되지만 보고서 생성 속도가 느려질 수 있습니다. 트레이스는 Lighthouse 보고서가 생성된 후 도구 메뉴 > 제한되지 않은 트레이스 보기에서 확인할 수 있습니다. JS 샘플링이 없는 경우 (왼쪽)와 사용한 경우 (오른쪽)의 성능 트레이스
    • 시뮬레이션된 제한 (기본값) 입니다. 이 옵션은 휴대기기에서 검색할 때의 일반적인 조건을 시뮬레이션합니다. Lighthouse는 감사 프로세스 중에 실제로 제한하지 않으므로 '시뮬레이션된'이라고 합니다. 대신 모바일 상황에서 페이지가 로드되는 데 걸리는 시간을 추정합니다. 반면 DevTools 제한 (고급) 설정은 실제로 CPU와 네트워크를 제한하므로 감사 프로세스가 길어진다는 단점이 있습니다.
    • 모드 > 탐색(기본값)을 선택합니다. 이 모드는 단일 페이지 로드를 분석하므로 이 튜토리얼에서는 이것이 필요합니다. 자세한 내용은 세 가지 모드를 참조하세요.
    • 기기 > 모바일. 모바일 옵션은 사용자 에이전트 문자열을 변경하고 모바일 표시 영역입니다. 데스크톱 옵션을 선택하면 모바일 변경사항이 거의 사용되지 않습니다.
    • 카테고리 > 성능. 사용 설정된 카테고리가 하나만 있으면 Lighthouse는 해당하는 감사 세트로만 보고서를 생성합니다. 제공되는 추천 유형을 보려면 다른 카테고리를 사용 설정한 상태로 두면 됩니다. 관련 없는 카테고리를 사용 중지하면 감사 프로세스가 약간 더 빨라집니다.
  3. 페이지 로드 분석을 클릭합니다. 10~30초 후에 Lighthouse 패널에 사이트의 성능 보고서가 표시됩니다.

    사이트 성능에 관한 Lighthouse 보고서입니다.

보고서 오류 처리

Lighthouse 보고서에 오류가 발생하면 다른 탭을 열지 않은 시크릿 창에서 데모 탭을 실행해 보세요. 이렇게 하면 제거하면 됩니다. 특히 크롬 확장 프로그램은 방해가 되지 않도록 하는 것이 중요합니다.

오류가 있는 보고서입니다.

보고서 이해하기

보고서 상단에 있는 숫자는 사이트의 전체 실적 점수입니다. 나중에 코드를 변경하면 이 숫자가 증가하는 것을 볼 수 있습니다. 점수가 높을수록 실적이 우수합니다.

전체 성능 점수입니다.

측정항목

측정항목 섹션까지 아래로 스크롤한 다음 보기 펼치기를 클릭합니다. 측정항목에 관한 문서를 읽으려면 자세히 알아보기를 클릭합니다.

측정항목 섹션

이 섹션에서는 사이트 성능을 정량적으로 측정한 결과를 제공합니다. 각 측정항목은 실적의 다양한 측면에 대한 통계를 제공합니다. 예를 들어 콘텐츠가 포함된 첫 페인트는 는 콘텐츠가 화면에 처음 그려지는 시점을 알려주며, 이는 사용자가 콘텐츠를 감상하는 데 있어 중요한 시점입니다. 상호작용까지의 시간은 페이지가 사용자 상호작용을 처리할 준비가 되어 있어야 합니다

스크린샷

다음은 페이지가 로드될 때의 모습을 보여주는 스크린샷 모음입니다.

로드하는 동안 페이지의 모습을 보여주는 스크린샷

기회

다음은 이 특정 페이지의 로드 성능을 개선하는 방법에 관한 구체적인 팁을 제공하는 기회 섹션입니다.

추천 섹션

추천을 클릭하면 세부정보를 확인할 수 있습니다.

텍스트 압축 기회에 대해 자세히 알아보기

추천이 중요한 이유에 대한 구체적인 문서를 보려면 자세히 알아보기...를 클릭합니다. 추천 해결 방법을 찾을 수 있습니다.

진단

진단 섹션에서는 페이지의 오류에 영향을 주는 요인에 대해 자세히 알아볼 수 있습니다. 로드 시간을 단축할 수 있습니다.

진단 섹션

통과한 감사

통과한 감사 섹션에는 사이트가 제대로 진행되고 있는 항목이 표시됩니다. 클릭하여 펼치기 섹션으로 이동합니다.

통과한 감사 섹션

2단계: 실험

Lighthouse 보고서의 기회 섹션에는 페이지 성능을 개선하는 방법에 관한 팁이 제공됩니다. 이 섹션에서는 코드베이스에 대한 권장 변경사항을 구현하여 를 사용하여 사이트 속도에 미치는 영향을 측정하세요.

텍스트 압축 사용

보고서에 따르면 텍스트 압축을 사용 설정하는 것이 페이지 실적을 개선할 수 있는 가장 좋은 방법 중 하나라고 합니다.

텍스트 압축은 텍스트 파일을 네트워크를 통해 전송하기 전에 크기를 줄이거나 압축하는 것입니다. 이메일을 보내기 전에 폴더를 압축하여 파일 크기를 줄이는 방법도 있습니다.

압축을 사용 설정하기 전에 다음 몇 가지 방법을 통해 텍스트가 압축되었는지 여부를 직접 확인할 수 있습니다. 압축됩니다

네트워크 패널을 열고 설정 > 대용량 요청 행 사용을 선택합니다.

큰 요청 행이 표시된 Network 패널의 크기 열

크기 셀에는 2개의 값이 표시됩니다. 맨 위 값은 다운로드한 리소스의 크기입니다. 이 bottom 값은 압축되지 않은 리소스의 크기입니다. 두 값이 동일하면 리소스가 네트워크를 통해 전송될 때 압축되지 않습니다. 이 예에서 bundle.js의 최상위 및 하위 값 모두 1.4 MB입니다.

리소스의 HTTP 헤더를 검사하여 압축을 확인할 수도 있습니다.

  1. bundle.js를 클릭하고 Headers 탭을 엽니다.

    헤더 탭

  2. 응답 헤더 섹션에서 content-encoding 헤더를 검색합니다. 전혀 표시되지 않을 것입니다. 즉, bundle.js가 압축되지 않았습니다. 리소스가 압축될 때 이 헤더는 보통 gzip, deflate 또는 br로 설정됩니다. 이러한 값에 대한 설명은 디렉티브를 참고하세요.

설명은 여기까지입니다. 이제 변경할 때입니다. 코드 줄 수:

  1. 편집기 탭에서 server.js을 열고 (강조 표시된) 다음 두 줄을 추가합니다.

    ...
    const fs = require('fs');
    const compression = require('compression');
    
    app.use(compression());
    app.use(express.static('build'));
    ...
    
  2. app.use(express.static('build')) 앞에 app.use(compression())를 입력해야 합니다.

    server.js 수정

  3. Glitch에서 사이트의 새 빌드를 배포할 때까지 기다립니다. 왼쪽 하단에 행복한 이모티콘이 표시되면 배포가 완료된 것입니다.

앞에서 배운 워크플로를 사용하여 압축이 작동하는지 수동으로 확인합니다.

  1. 데모 탭으로 돌아가서 페이지를 새로고침하세요.

    이제 크기 열에 bundle.js와 같은 텍스트 리소스에 대해 두 가지 다른 값이 표시됩니다. bundle.js에 관한 269 KB의 상위 값은 네트워크를 통해 전송된 파일의 크기이고, 1.4 MB의 하위 값은 압축되지 않은 파일 크기입니다.

    이제 크기 열에 텍스트 리소스에 대한 두 개의 다른 값이 표시됩니다.

  2. 이제 bundle.jsResponse Headers 섹션에 content-encoding: gzip 헤더가 포함되어야 합니다.

    이제 응답 헤더 섹션에 콘텐츠 인코딩 헤더가 포함됩니다.

페이지에서 Lighthouse 보고서를 다시 실행하여 텍스트 압축이 페이지 로드에 미치는 영향을 측정합니다. 실적:

  1. Lighthouse 패널을 열고 상단의 작업 모음에서 추가 감사 수행...을 클릭합니다.

    감사 수행 버튼

  2. 설정을 전과 동일하게 두고 페이지 로드 분석을 클릭합니다.

    텍스트 압축을 사용 설정한 후의 Lighthouse 보고서

축하합니다. 발전한 것 같아요. 전반적인 실적 점수가 증가했을 것입니다. 즉, 사이트 속도가 빨라지고 있는 것입니다.

실제 텍스트 압축

대부분의 서버에는 압축을 사용 설정하기 위한 이와 같은 간단한 수정사항이 있습니다. 사용 방법을 검색해 보세요. 텍스트 압축에 사용하는 서버를 구성할 수 있습니다.

이미지 크기 조절

새로 작성한 보고서에 따르면 이미지 크기를 적절하게 조정하는 것도 또 다른 큰 기회가 될 수 있다고 합니다.

이미지 크기를 조절하면 이미지 파일 크기를 줄여 로드 시간을 단축할 수 있습니다. 사용자가 500픽셀 너비의 휴대기기 화면에서 이미지를 볼 때는 실제로 이미지를 너비의 1500픽셀 이미지를 전송하는 경우 너비가 500픽셀 이하인 이미지를 전송하는 것이 좋습니다.

  1. 보고서에서 적절한 이미지 크기 설정을 클릭하여 크기를 조절해야 하는 이미지를 확인합니다. 이미지 4개가 모두 필요한 것보다 큰 것 같습니다.

    '적절한 크기의 이미지'에 대한 세부정보 기회

  2. 편집기 탭으로 돌아가 src/model.js를 엽니다.

  3. const dir = 'big'const dir = 'small'로 바꿉니다. 이 디렉터리에는 크기가 조정된 동일한 이미지의 사본이 포함되어 있습니다.

  4. 이 변경사항이 로드 성능에 어떤 영향을 미치는지 페이지를 다시 감사하세요.

    이미지 크기를 조절한 후의 Lighthouse 보고서

이러한 변화는 전체 실적 점수에 미미한 영향을 미칩니다. 하지만 한 가지 사용자가 얼마나 많은 네트워크 데이터를 절약하고 있는지는 점수가 명확하게 표시되지 않습니다. 합계 이전 사진의 크기는 약 6.1MB였지만 지금은 약 633KB에 불과합니다. 네트워크 패널 하단의 상태 표시줄에서 이를 확인할 수 있습니다.

이미지 크기 조절 전후에 전송되는 데이터의 양

실제 이미지 크기 조절

소규모 앱의 경우 이와 같이 일회성 크기 조절을 수행하는 것으로 충분할 수 있습니다. 하지만 대규모 앱의 경우 확장할 수 없습니다. 다음은 대용량 앱에서 이미지를 관리하기 위한 몇 가지 전략입니다.

  • 빌드 프로세스 중에 이미지 크기를 조절합니다.
  • 빌드 프로세스 중에 각 이미지의 여러 크기를 만든 다음 코드에서 srcset를 사용합니다. 런타임 시 브라우저는 실행되는 기기에 가장 적합한 크기를 선택합니다. 상대 크기의 이미지를 참고하세요.
  • 요청 시 이미지 크기를 동적으로 조절할 수 있는 이미지 CDN을 사용합니다.
  • 적어도 각 이미지를 최적화하세요. 이를 통해 종종 상당한 비용을 절감할 수 있습니다. 최적화란 이미지 파일의 크기를 줄이는 특수 프로그램을 통해 이미지를 실행합니다. 자세한 내용은 필수 이미지 최적화를 참조하세요.

렌더링 차단 리소스 제거

최신 보고서에 따르면 렌더링 차단 리소스를 없애는 것이 현재 가장 큰 기회입니다.

렌더링 차단 리소스는 브라우저가 페이지를 표시하기 전에 다운로드, 파싱, 실행해야 하는 외부 JavaScript 또는 CSS 파일입니다. 목표는 핵심 CSS 및 JavaScript만 실행하는 것입니다. 이 코드가 있어야 합니다.

첫 번째 작업은 페이지 로드 시 실행할 필요가 없는 코드를 찾는 것입니다.

  1. 렌더링 차단 리소스 제거를 클릭하여 차단 중인 리소스(lodash.jsjquery.js)를 확인합니다.

    '렌더링 차단 리소스 줄이기'에 대해 자세히 알아보기 있습니다.

  2. 운영체제에 따라 다음을 눌러 명령어 메뉴를 엽니다.

    • Mac: Command+Shift+P
    • Windows, Linux, ChromeOS: Control+Shift+P
  3. Coverage를 입력하고 범위 표시를 선택합니다.

    Lighthouse 패널에서 명령어 메뉴를 여는 모습

    범위에 열립니다.

    노출 범위 탭

  4. 새로고침을 클릭합니다. 노출 범위 탭에는 페이지가 로드되는 동안 bundle.js, jquery.js, lodash.js에서 실행되고 있는 코드의 양에 관한 개요가 표시됩니다.

    노출 범위 보고서

    이 스크린샷은 jQuery 및 Lodash 파일의 약 74% 와 30% 가 각각 사용되지 않음을 보여줍니다.

  5. jquery.js 행을 클릭합니다. DevTools에서 Sources 패널에 파일이 열립니다. 코드 한 줄은 옆에 초록색 막대가 있으면 실행됩니다. 코드 줄 옆에 빨간색 막대가 표시되면 코드가 실행되지 않았음을 의미하며, 페이지 로드에는 당연히 필요하지 않습니다

    소스 패널에서 jQuery 파일을 봅니다.

  6. jQuery 코드를 조금 스크롤합니다. '실행'되는 줄은 사실 그냥 있습니다. 주석을 제거하는 최소화기를 통해 이 코드를 실행하는 것도 이 파일의 크기입니다.

간단히 말해, 자체 코드로 작업할 때 적용 범위 탭을 사용하면 코드를 분석하고 페이지 로드에 필요한 코드만 제공하세요.

jquery.jslodash.js 파일이 페이지를 로드하는 데에도 필요한가요? Request Blocking 탭에서는 다음 작업을 수행할 수 있습니다. 리소스를 사용할 수 없는 경우 어떤 일이 발생하는지 보여줍니다.

  1. 네트워크 탭을 클릭하고 명령어 메뉴를 다시 엽니다.
  2. blocking를 입력한 후 Show Request Blocking(요청 차단 표시)을 선택합니다. Request Blocking(차단 요청) 탭이 열립니다.

    요청 차단 탭

  3. 추가 패턴 추가를 클릭하고 텍스트 상자에 /libs/*를 입력한 다음 Enter 키를 눌러 확인합니다.

    'libs'에 대한 요청을 차단하는 패턴 추가 디렉터리

  4. 페이지를 새로고침합니다. jQuery 및 Lodash 요청은 빨간색으로, 차단되었음을 의미합니다. 이 페이지는 여전히 로드되고 상호작용하므로 이러한 리소스는 전혀 필요하지 않은 것 같습니다.

    Network 패널에 요청이 차단되었다고 표시됩니다.

  5. 삭제를 탭합니다. 모든 패턴 삭제를 클릭하여 /libs/* 차단 패턴을 삭제합니다.

일반적으로 차단 요청 탭은 소재가 차단되었을 때 페이지가 어떻게 동작하는지 시뮬레이션하는 데 유용합니다. 리소스를 사용할 수 없습니다.

이제 코드에서 이러한 파일에 대한 참조를 삭제하고 페이지를 다시 감사합니다.

  1. 편집기 탭으로 돌아가 template.html를 엽니다.
  2. 상응하는 <script> 태그를 삭제합니다.

    <head>
        ...
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <script src="/libs/lodash.js"></script>
        <script src="/libs/jquery.js"></script>
        <title>Tony's Favorite Foods</title>
    </head>
    
  3. 사이트가 다시 빌드되고 배포될 때까지 기다립니다.

  4. Lighthouse 패널에서 페이지를 다시 감사합니다. 전체 점수가 다시 높아졌을 것입니다.

    렌더링 차단 리소스를 삭제한 후의 Lighthouse 보고서

실제 상황에서 주요 렌더링 경로 최적화

주요 렌더링 경로란 페이지를 로드하는 데 필요한 코드를 말합니다. 일반적으로 페이지 로드 중에 중요한 코드만 전송한 다음 지연 로드하여 페이지 로드 속도를 높일 수 있음 있습니다.

  • 완전히 삭제할 수 있는 스크립트를 찾을 가능성은 거의 없지만 많은 스크립트를 페이지 로드 중에 요청할 필요가 없으며 대신 있습니다. async 또는 defer 사용을 참고하세요.
  • 프레임워크를 사용 중인 경우 프로덕션 모드가 있는지 확인합니다. 이 모드는 트리 쉐이킹으로 간주하여 중요한 렌더링을 차단하는 불필요한 코드를 제거해야 합니다.

기본 스레드 작업 줄이기

최신 보고서의 기회 섹션에는 약간의 잠재적 절감액이 표시되지만 진단 섹션으로 아래로 스크롤하면 가장 큰 병목 현상은 메인 스레드 활동이 너무 많기 때문인 것으로 보입니다.

기본 스레드는 브라우저가 페이지를 표시하는 데 필요한 대부분의 작업(예: HTML, CSS, JavaScript를 실행할 수 있습니다.

목표는 Performance 패널을 사용하여 페이지를 로드하고, 불필요한 작업을 연기하거나 삭제하는 방법을 찾습니다.

  1. 성능 > 설정을 탭합니다. 캡처 설정을 열고 네트워크느린 3G로, CPU6배 감속으로 설정합니다.

    Performance 패널에서 CPU 및 네트워크 제한 설정

    휴대기기에서는 일반적으로 노트북이나 데스크톱보다 하드웨어 제약이 더 많기 때문에 성능이 낮은 기기를 사용하는 것처럼 페이지 로드를 경험할 수 있습니다.

  2. 새로고침을 클릭합니다. DevTools가 페이지를 새로고침한 다음 페이지를 로드하기 위해 수행해야 했던 모든 작업을 시각화합니다. 이러한 시각화를 trace라고 합니다.

    성능 패널의 페이지 로드 트레이스

트레이스는 왼쪽에서 오른쪽 순으로 활동을 시간순으로 표시합니다. 페이지의 FPS, CPU 및 NET 차트는 초당 프레임 수, CPU 활동 및 네트워크 활동에 대한 개요를 제공합니다.

trace의 개요 섹션

Overview(개요) 섹션에 표시되는 노란색 벽은 CPU가 스크립팅 작업으로 완전히 바쁘다는 것을 의미합니다. 이는 JavaScript 작업을 적게 하면 페이지 로드 속도를 높일 수 있다는 증거입니다.

트레이스를 조사하여 JavaScript 작업을 줄이는 방법을 찾습니다.

  1. 시간 섹션을 클릭하여 펼칩니다.

    소요 시간 섹션

    React의 여러 사용자 시간 측정값이 있는데, 토니의 앱은 React의 개발 모드를 사용하는 것 같습니다. React의 프로덕션 모드로 전환하면 쉽게 성능을 얻을 수 있습니다.

  2. 시간을 다시 클릭하면 해당 섹션이 접힙니다.

  3. 기본 섹션을 탐색합니다. 이 섹션에서는 기본 스레드 활동의 시간순 로그를 보여줍니다. 살펴보겠습니다. y축 (위에서 아래로)에는 이벤트가 발생한 이유가 표시됩니다.

    기본 섹션

    이 예시에서는 Evaluate Script 이벤트로 인해 (anonymous) 함수가 실행되어 __webpack__require__가 실행되고 ./src/index.jsx가 실행되는 식이 일어납니다.

  4. 기본 섹션의 하단으로 스크롤합니다. 프레임워크를 사용할 때는 상위 활동은 대부분 관리할 수 있습니다. 앱에서 발생한 활동은 일반적으로 하단에 표시됩니다.

    mineBitcoin 활동입니다.

    이 앱에서는 App라는 함수가 mineBitcoin 함수를 많이 호출하는 것 같습니다. 토니가 암호화폐를 채굴하기 위해 팬의 기기를 사용하는 것 같습니다...

  5. 하단의 Bottom-Up 탭을 엽니다. 이 탭은 시간이 가장 많이 걸린 활동을 분류합니다. Bottom-Up 섹션에 아무 것도 표시되지 않으면 Main 섹션의 라벨을 클릭합니다.

    상향식 탭

    상향식 섹션에는 내가 한 활동 또는 활동 그룹에 관한 정보만 표시됩니다. 현재 선택되어 있습니다. 예를 들어 mineBitcoin 활동 중 하나를 클릭하면 Bottom-Up 섹션에는 해당 활동에 관한 정보만 표시됩니다.

    Self Time(자체 시간) 열에는 각 활동에 직접 소요된 시간이 표시됩니다. 이 경우 기본 스레드 시간의 약 82% 가 mineBitcoin 함수에 사용되었습니다.

프로덕션 모드를 사용하고 JavaScript 활동을 줄이는지 확인해 보겠습니다. 페이지 로드 속도가 빨라집니다. 프로덕션 모드로 시작:

  1. 편집기 탭에서 webpack.config.js를 엽니다.
  2. "mode":"development""mode":"production"로 변경합니다.
  3. 새 빌드가 배포될 때까지 기다립니다.
  4. 페이지를 다시 감사합니다.

    프로덕션 모드를 사용하도록 webpack을 구성한 후의 Lighthouse 보고서

mineBitcoin 호출을 삭제하여 JavaScript 활동을 줄입니다.

  1. 편집기 탭에서 src/App.jsx를 엽니다.
  2. constructor에서 this.mineBitcoin(1500) 호출을 주석 처리합니다.
  3. 새 빌드가 배포될 때까지 기다립니다.
  4. 페이지를 다시 감사합니다.

불필요한 JavaScript 작업을 삭제한 후의 Lighthouse 보고서

늘 그렇듯이 아직 할 일이 있습니다. 예를 들어 최대 콘텐츠 렌더링 시간누적 레이아웃 변경 측정항목을 줄여야 합니다.

실제 환경에서 기본 스레드 작업 줄이기

일반적으로 실적 패널은 사이트에서 어떤 활동을 하는지 파악하는 가장 일반적인 방법입니다. 불필요한 활동을 삭제하는 방법을 찾습니다.

console.log()와 유사한 접근 방식을 원하는 경우 User Timing API를 사용하면 각 단계가 얼마나 긴지 추적하기 위해 앱 수명 주기의 특정 단계를 임의로 마크업합니다. 몇 가지 단계가 필요합니다.

요약

  • 사이트의 로드 성능을 최적화하려고 할 때마다 항상 살펴보겠습니다 감사를 통해 기준을 설정하고, 개선할 수 있습니다
  • 한 번에 하나씩 변경하고 각 변경사항 적용 후 페이지를 감사하여 이러한 개별 변경사항이 성능에 미치는 영향을 확인합니다.

다음 단계

내 사이트에서 감사를 진행하세요. 보고서를 해석하거나 로드 성능을 개선하는 방법을 찾는 데 도움이 필요한 경우 DevTools 커뮤니티에서 도움을 받을 수 있는 모든 방법을 확인하세요.

  • developer.chrome.com 저장소에서 이 문서에 대한 버그를 신고합니다.
  • Chromium 버그에서 DevTools에 관한 버그 신고를 제출합니다.
  • 메일링 리스트에서 기능과 변경사항에 대해 논의합니다. 다음의 경우 메일링 리스트를 사용하지 마세요. 할 수 있습니다. 대신 Stack Overflow를 사용하세요.
  • Stack Overflow에서 DevTools 사용 방법에 관한 일반적인 도움말을 확인하세요. 버그 요청을 제출하려면 항상 Chromium 버그를 사용하세요.
  • @ChromeDevTools로 트윗해 주세요.