Lighthouse: 웹사이트 속도 최적화

튜토리얼의 목표

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

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

기본 요건

이 웹 개발 소개 강의에서 학습한 내용과 유사한 기본적인 웹 개발 경험이 있어야 합니다.

로드 성능에 대해 아무것도 몰라도 됩니다.

소개

저는 토니입니다. 토니는 고양이 사회에서 매우 유명한 인물입니다. 팬들이 자신이 좋아하는 음식이 무엇인지 알아볼 수 있도록 웹사이트를 구축했습니다. 팬들은 이 사이트를 좋아하지만 토니는 사이트 로드 속도가 느리다는 불만을 계속 듣습니다. 토니는 사이트 속도를 높여달라고 요청했습니다.

1단계: 사이트 감사

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

• 후속 변경사항을 측정할 기준을 만듭니다.
• 실적 개선에 가장 큰 영향을 미칠 변경사항에 대한 실행 가능한 팁을 얻을 수 있습니다.

설정

먼저 Tony의 웹사이트를 위한 새로운 작업 환경을 설정하여 나중에 변경할 수 있도록 해야 합니다.

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

   

   프로젝트 이름이 tony에서 임의로 생성된 이름으로 변경됩니다. 이제 수정할 수 있는 자신만의 코드 사본이 생겼습니다. 나중에 이 코드를 변경합니다.

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

   

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

   

기준 설정

기준은 실적이 개선되기 전의 사이트 실적에 대한 기록입니다.

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

   

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

   • check_box 저장용량 비우기. 이 체크박스를 사용 설정하면 모든 감사 전에 페이지와 연결된 모든 저장용량이 삭제됩니다. 신규 방문자의 사이트 경험을 감사하려면 이 설정을 그대로 둡니다. 재방문 환경을 이용하려면 이 설정을 중지하세요.
   • 시뮬레이션된 제한 (기본값) arrow_drop_down입니다. 이 옵션은 휴대기기에서의 일반적인 브라우징 조건을 시뮬레이션합니다. 이 기능을 '시뮬레이션됨'이라고 하는 이유는 Lighthouse가 감사 프로세스 중에 실제로 제한을 받지 않기 때문입니다. 대신 모바일 환경에서 페이지를 로드하는 데 걸리는 시간을 추정합니다. 반면 DevTools 제한 (고급) 설정은 실제로 CPU와 네트워크를 제한하지만 감사 프로세스의 시간이 길어집니다.
   • 모드 > radio_button_checked 탐색 (기본값) 이 모드는 단일 페이지 로드를 분석하며, 이것이 이 튜토리얼에서 필요한 부분입니다. 자세한 내용은 세 가지 모드를 참고하세요.
   • 기기 > radio_button_checked 모바일. 모바일 옵션은 사용자 에이전트 문자열을 변경하고 모바일 표시 영역을 시뮬레이션합니다. 데스크톱 옵션은 모바일 변경사항을 거의 비활성화합니다.
   • 카테고리 > check_box 실적 카테고리를 하나만 사용 설정하면 Lighthouse에서 해당하는 감사 집합이 있는 보고서만 생성합니다. 다른 카테고리가 제공되는 추천 유형을 보려면 해당 카테고리를 사용 설정된 상태로 둘 수 있습니다. 관련 없는 카테고리를 사용 중지하면 감사 프로세스의 속도가 다소 빨라집니다.

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

   

보고서 오류 처리

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

보고서 이해하기

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

측정항목

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

이 섹션에서는 사이트 실적을 정량적으로 측정합니다. 각 측정항목은 실적의 다양한 측면에 대한 유용한 정보를 제공합니다. 예를 들어 콘텐츠가 포함된 첫 페인트는 콘텐츠가 화면에 처음 그려질 때를 알려주며, 이는 사용자가 페이지 로드를 인식하는 데 있어 중요한 시점이고, 상호작용 시작 시간은 페이지가 사용자 상호작용을 처리할 준비가 된 것으로 보이는 지점을 나타냅니다.

스크린샷

다음은 로드될 때 페이지가 어떻게 표시되는지 보여주는 스크린샷 모음입니다.

기회

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

추천을 클릭하여 자세히 알아보세요.

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

진단

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

통과한 감사

통과된 감사 섹션에서는 사이트가 제대로 운영되고 있는지 확인할 수 있습니다. 섹션을 클릭하여 펼칩니다.

2단계: 실험

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

텍스트 압축 사용

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

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

압축을 사용 설정하기 전에 텍스트 리소스가 압축되었는지 여부를 수동으로 확인할 수 있는 몇 가지 방법이 있습니다.

네트워크 패널을 열고 settings 설정 > check_box 넓은 요청 행 사용을 선택합니다.

각 Size 셀에는 2개의 값이 표시됩니다. 맨 위 값은 다운로드한 리소스의 크기입니다. 맨 아래 값은 압축되지 않은 리소스의 크기입니다. 두 값이 같으면 리소스를 네트워크를 통해 전송할 때 압축되지 않습니다. 이 예에서 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(compression())는 app.use(express.static('build')) 앞에 배치해야 합니다.

   

3. Glitch에서 사이트의 새 빌드를 배포할 때까지 기다립니다. 왼쪽 하단에 있는 행복한 이모티콘은 배포가 완료되었음을 나타냅니다.

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

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

   이제 Size 열에는 텍스트 리소스(예: 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에 불과합니다. Network 패널 하단의 상태 표시줄에서 이를 확인할 수 있습니다.

실제 이미지 크기 조절

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

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

렌더링 차단 리소스 제거

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

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

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

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

   

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

   • Mac: Command+Shift+P
   • Windows, Linux 또는 ChromeOS의 경우 Control+Shift+P를 누릅니다.

3. Coverage를 입력하다가 Show Coverage를 선택합니다.

   

   창에 범위 탭이 열립니다.

   

4. Reload를 클릭합니다. 색인 생성 범위 탭에는 페이지가 로드되는 동안 bundle.js, jquery.js, lodash.js에서 실행되는 코드의 양이 간략하게 표시됩니다.

   

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

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

   

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

즉, 자체 코드로 작업하는 경우 색인 생성 범위 탭을 사용하면 코드를 한 줄씩 분석하고 페이지 로드에 필요한 코드만 전달할 수 있습니다.

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

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

2. blocking를 입력한 다음 Show Request Blocking을 선택합니다. Request Blocking(요청 차단) 탭이 열립니다.

   

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

   

4. 페이지를 새로고침합니다. jQuery 및 Lodash 요청이 빨간색으로 표시되어 차단되었음을 의미합니다. 페이지는 계속 로드되고 대화형이므로 이러한 리소스는 전혀 필요하지 않은 것처럼 보입니다.

   

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

일반적으로 Request Blocking 탭에서는 사용할 수 있는 리소스가 없을 때의 페이지 동작을 시뮬레이션하는 데 유용합니다.

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

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, 자바스크립트 파싱 및 실행)을 하는 곳입니다.

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

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

   

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

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

   

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

Overview(개요) 섹션에 보이는 노란색 벽은 CPU에서 스크립팅 활동으로 완전히 사용 중이라는 의미입니다. 이는 자바스크립트 작업을 줄여 페이지 로드 속도를 높일 수 있다는 것을 보여줍니다.

트레이스를 조사하여 JavaScript 작업을 줄이는 방법을 찾아보세요.

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

   

   React에서 다양한 사용자 타이밍 측정값이 있습니다. 토니의 앱이 React의 개발 모드를 사용하는 것 같습니다. React의 프로덕션 모드로 전환하면 몇 가지 쉬운 성능 이점을 얻을 수 있습니다.

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

3. 기본 섹션을 찾습니다. 이 섹션에서는 기본 스레드 활동의 시간순 로그를 왼쪽에서 오른쪽으로 보여줍니다. y축 (위에서 아래로)은 이벤트가 발생한 이유를 보여줍니다.

   

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

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

   

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

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

   

   Bottom-Up 섹션에는 현재 선택한 활동 또는 활동 그룹에 관한 정보만 표시됩니다. 예를 들어 mineBitcoin 활동 중 하나를 클릭하면 Bottom-Up 섹션에는 이 하나의 활동에 관한 정보만 표시됩니다.

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

프로덕션 모드를 사용하고 자바스크립트 활동을 줄이면 페이지 로드 속도가 빨라지는지 확인해 보겠습니다. 프로덕션 모드로 시작합니다.

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로 트윗을 보냅니다.