Lighthouse: 웹사이트 속도 최적화

Kayce Basques

Sofia Emelianova

개요

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

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

... 및 기타 여러 측정항목

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

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

튜토리얼의 목표

이 튜토리얼에서는 Chrome DevTools를 사용하여 웹사이트 로드 속도를 높이는 방법을 찾는 방법을 설명합니다.

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

이 동영상은 Chrome 68으로 제작되었습니다. 세부정보는 대부분 여전히 유효하지만 일부 기능은 업데이트되었습니다. 예를 들어 감사 패널이 이제 Lighthouse로 이름이 바뀌고 모양이 달라졌지만 동일한 옵션을 모두 계속 사용할 수 있습니다.

기본 요건

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

로드 성능에 대해 알 필요는 없습니다.

소개

저는 토니입니다. 토니는 고양이 사회에서 매우 유명합니다. 팬들이 자신의 좋아하는 음식을 알 수 있도록 웹사이트를 만들었습니다. 팬들은 사이트를 좋아하지만 사이트가 느리게 로드된다는 불만이 계속 접수되고 있습니다. 토니님이 사이트 속도를 높이는 데 도움을 요청했습니다.

토니 고양이.

1단계: 사이트 감사

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

• 후속 변경사항을 측정할 수 있는 기준이 생성됩니다.
• 가장 큰 영향을 미치는 변경사항에 대한 실행 가능한 도움말을 제공합니다.

설정

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

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

   

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

2. 편집기 탭 하단에서 미리보기 > 새 창에서 미리보기를 클릭합니다. 데모가 새 탭에서 열립니다. 이 탭을 데모 탭이라고 합니다. 사이트가 로드될 때까지 시간이 걸릴 수 있습니다.

   

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

   

핵심사항: 이 튜토리얼의 나머지 스크린샷에서는 DevTools가 별도의 창에 표시됩니다.

기준 설정

기준점은 성능을 개선하기 전에 사이트가 실적을 기록한 것입니다.

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

   참고: 이 패널은 웹 앱의 품질을 개선하는 자동화 도구인 Lighthouse를 기반으로 합니다.

   

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

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

3. 페이지 로드 분석을 클릭합니다. 10~30초 후 Lighthouse 패널에 사이트 실적 보고서가 표시됩니다.

   

보고서 오류 처리

Lighthouse 보고서에 오류가 발생하면 다른 탭을 열지 않은 시크릿 창에서 데모 탭을 실행해 보세요. 이렇게 하면 초기 상태에서 Chrome을 실행할 수 있습니다. 특히 Chrome 확장 프로그램은 감사 프로세스를 방해할 수 있습니다.

보고서 이해하기

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

측정항목

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

이 섹션에서는 사이트의 실적을 정량적으로 측정합니다. 각 측정항목은 실적의 다양한 측면에 대한 통계를 제공합니다. 예를 들어 콘텐츠가 포함된 첫 페인트는 콘텐츠가 화면에 처음 페인트되는 시점을 알려줍니다. 이는 사용자가 페이지 로드를 인식하는 데 중요한 이정표입니다. 반면 Time To Interactive는 페이지가 사용자 상호작용을 처리할 만큼 준비되었다고 표시되는 지점을 나타냅니다.

스크린샷

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

기회

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

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

자세히 알아보기를 클릭하여 기회가 중요한 이유와 해결 방법에 관한 구체적인 권장사항에 관한 문서를 확인하세요.

진단

진단 섹션에서는 페이지 로드 시간에 영향을 미치는 요인에 관한 자세한 정보를 제공합니다.

감사 통과

감사 통과 섹션에는 사이트에서 올바르게 실행 중인 작업이 표시됩니다. 섹션을 펼치려면 클릭합니다.

2단계: 실험

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

텍스트 압축 사용

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

텍스트 압축은 텍스트 파일을 네트워크를 통해 전송하기 전에 크기를 줄이거나 압축하는 것입니다. 이메일로 보내기 전에 폴더를 압축하여 크기를 줄이는 것과 비슷합니다.

압축을 사용 설정하기 전에 다음과 같은 방법으로 텍스트 리소스가 압축되었는지 수동으로 확인할 수 있습니다.

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

핵심사항: 네트워크 요청 표에 크기 열이 표시되지 않으면 표 헤더를 마우스 오른쪽 버튼으로 클릭하고 크기를 선택합니다.

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

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

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

   

2. 응답 헤더 섹션에서 content-encoding 헤더를 검색합니다. bundle.js가 압축되지 않았음을 의미하는 1이 표시되지 않습니다. 리소스가 압축되면 이 헤더는 일반적으로 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())를 넣어야 합니다.

   

   참고: 일반적으로 npm i -S compression와 같은 것을 통해 compression 패키지를 설치해야 하지만 이미 설치되었습니다.

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

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

1. 데모 탭으로 돌아가서 페이지를 새로고침합니다.

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

   

2. 이제 bundle.js의 응답 헤더 섹션에 content-encoding: gzip 헤더가 포함됩니다.

   

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

1. Lighthouse 패널을 열고 상단의 작업 표시줄에서 감사 실행...을 클릭합니다.

   

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

   

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

실제 텍스트 압축

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

이미지 크기 조절

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

이미지 크기를 조정하면 이미지 파일 크기가 줄어 로드 시간이 단축됩니다. 사용자가 너비가 500픽셀인 휴대기기 화면에서 이미지를 보는 경우 너비가 1, 500픽셀인 이미지를 전송하는 것은 아무런 의미가 없습니다. 가로 500픽셀 이하의 이미지를 전송하는 것이 가장 좋습니다.

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

   

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

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

4. 페이지를 다시 감사하여 변경사항이 로드 실적에 어떤 영향을 미치는지 확인합니다.

   

변경사항이 전반적인 실적 점수에 미치는 영향은 미미한 것으로 보입니다. 그러나 이 점수는 사용자가 절약하는 네트워크 데이터의 양을 명확하게 보여주지 않습니다. 이전 사진의 총 크기는 약 6.1MB였지만 지금은 약 633KB에 불과합니다. 네트워크 패널 하단의 상태 표시줄에서 이를 확인할 수 있습니다.

실제 크기로 이미지 크기 조정

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

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

렌더링을 지연시키는 리소스 제거

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

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

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

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

   

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

   • Mac의 경우 Command+Shift+P
   • Windows, Linux 또는 ChromeOS: Control+Shift+P

3. Coverage를 입력하다가 노출 범위 표시를 선택합니다.

   

   기본 자료함에서 범위 탭이 열립니다.

   

4. 새로고침 새로고침을 클릭합니다. 적용 범위 탭에는 페이지가 로드되는 동안 bundle.js, jquery.js, lodash.js의 코드가 얼마나 실행되는지에 대한 개요가 표시됩니다.

   

   이 스크린샷은 jQuery 및 Lodash 파일의 약 74% 와 30% 가 각각 사용되지 않는다고 나타냅니다.

5. jquery.js 행을 클릭합니다. DevTools에서 Sources 패널에 파일이 열립니다. 코드 줄 옆에 녹색 막대가 있으면 코드 줄이 실행된 것입니다. 코드 줄 옆에 빨간색 막대가 표시되면 코드가 실행되지 않았으며 페이지 로드 시 확실히 필요하지 않다는 의미입니다.

   

6. jQuery 코드를 조금 스크롤합니다. '실행'되는 일부 줄은 실제로 주석일 뿐입니다. 주석을 삭제하는 미니파이저를 통해 이 코드를 실행하는 것도 이 파일의 크기를 줄이는 또 다른 방법입니다.

즉, 자체 코드로 작업할 때 범위 탭을 사용하면 코드를 한 줄씩 분석하고 페이지 로드에 필요한 코드만 전송할 수 있습니다.

페이지를 로드하는 데 jquery.js 및 lodash.js 파일이 필요한가요? 요청 차단 탭에서 리소스를 사용할 수 없는 경우 어떤 일이 발생하는지 확인할 수 있습니다.

1. 네트워크 탭을 클릭하고 명령어 메뉴를 다시 엽니다.

2. blocking를 입력한 다음 요청 차단 표시를 선택합니다. 요청 차단 탭이 열립니다.

   

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

   

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

   

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 패널에서 페이지를 다시 감사합니다. 전체 점수가 다시 개선되었을 것입니다.

   

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

주요 렌더링 경로는 페이지를 로드하는 데 필요한 코드를 나타냅니다. 일반적으로 페이지 로드 중에 중요한 코드만 전송하고 나머지는 모두 지연 로드하여 페이지 로드 속도를 높일 수 있습니다.

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

기본 스레드 작업 줄이기

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

메인 스레드는 브라우저가 HTML, CSS, JavaScript 파싱 및 실행과 같이 페이지를 표시하는 데 필요한 대부분의 작업을 실행하는 곳입니다.

참고: 이 섹션에서는 실적 패널에 대해 간단히 소개합니다. 성능 기능 참조에서 이 기능을 사용하여 페이지 성능을 분석하는 방법을 자세히 알아보세요.

목표는 성능 패널을 사용하여 페이지가 로드되는 동안 기본 스레드에서 실행 중인 작업을 분석하고 불필요한 작업을 지연하거나 삭제하는 방법을 찾는 것입니다.

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

   

   휴대기기는 일반적으로 노트북이나 데스크톱보다 하드웨어 제약이 많으므로 이러한 설정을 사용하면 성능이 낮은 기기를 사용하는 것처럼 페이지 로드를 경험할 수 있습니다.

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

   

트레이스는 활동을 왼쪽에서 오른쪽으로 시간순으로 보여줍니다. 상단의 FPS, CPU, NET 차트는 초당 프레임 수, CPU 활동, 네트워크 활동을 개략적으로 보여줍니다.

개요 섹션에 노란색 벽이 표시되면 CPU가 스크립팅 활동으로 완전히 과부하된 것을 의미합니다. 이는 JavaScript 작업을 줄여 페이지 로드 속도를 높일 수 있다는 신호입니다.

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

1. 타이밍 섹션을 클릭하여 펼칩니다.

   

   React의 사용자 시간 측정값이 많이 있습니다. 토니의 앱이 React의 개발 모드를 사용하는 것 같습니다. React의 프로덕션 모드로 전환하면 간단하게 성능을 개선할 수 있습니다.

2. 타이밍을 다시 클릭하여 섹션을 접습니다.

3. 기본 섹션을 탐색합니다. 이 섹션에는 기본 스레드 활동의 시간순 로그가 왼쪽에서 오른쪽으로 표시됩니다. y축 (위에서 아래)에는 이벤트가 발생한 이유가 표시됩니다.

   

   이 예에서 Evaluate Script 이벤트로 인해 (anonymous) 함수가 실행되고, 이로 인해 __webpack__require__가 실행되고, 이로 인해 ./src/index.jsx가 실행되는 등 계속됩니다.

4. 기본 섹션 하단으로 스크롤합니다. 프레임워크를 사용하면 대부분의 상위 활동이 프레임워크에 의해 발생하며 이는 일반적으로 개발자가 제어할 수 없습니다. 앱으로 인한 활동은 일반적으로 하단에 있습니다.

   

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

   참고: 프레임워크에서 실행하는 호출은 일반적으로 개발자가 제어할 수 없지만, 프레임워크가 비효율적으로 실행되도록 앱을 구성할 수도 있습니다. 프레임워크를 효율적으로 사용하도록 앱을 재구성하면 기본 스레드 작업을 줄일 수 있습니다. 이를 위해서는 프레임워크의 작동 방식과 프레임워크를 더 효율적으로 사용하기 위해 자체 코드에서 어떤 종류의 변경사항을 적용할 수 있는지 깊이 이해해야 합니다.

5. 하단에서 하향식 탭을 엽니다. 이 탭에는 가장 많은 시간을 소비한 활동이 분류되어 표시됩니다. 하향식 섹션에 아무것도 표시되지 않으면 기본 섹션의 라벨을 클릭합니다.

   

   하향식 섹션에는 현재 선택한 활동 또는 활동 그룹에 대한 정보만 표시됩니다. 예를 들어 mineBitcoin 활동 중 하나를 클릭하면 하향식 섹션에 해당 활동에 대한 정보만 표시됩니다.

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

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

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

4. 페이지를 다시 감사합니다.

   

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

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

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

성공: 하지만 마지막 변경으로 인해 실적이 크게 상승한 것으로 보입니다.

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

일반적으로 성능 패널은 사이트가 로드될 때 어떤 활동을 실행하는지 파악하고 불필요한 활동을 삭제하는 방법을 찾는 가장 일반적인 방법입니다.

console.log()에 더 가까운 접근 방식을 선호하는 경우 User Timing API를 사용하면 앱 수명 주기의 특정 단계를 임의로 마크업하여 각 단계에 걸리는 시간을 추적할 수 있습니다.

요약

• 사이트의 로드 성능을 최적화하려고 할 때는 항상 감사로 시작합니다. 감사를 통해 기준을 설정하고 개선 방법에 관한 팁을 제공합니다.
• 한 번에 하나씩 변경하고 각 변경사항 적용 후 페이지를 감사하여 이러한 개별 변경사항이 성능에 미치는 영향을 확인합니다.

다음 단계

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

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