개요
Lighthouse 패널을 사용하여 웹사이트를 포괄적으로 감사할 수 있습니다. Lighthouse 패널에서는 웹사이트에 대한 다음 정보를 제공하는 보고서를 생성합니다.
- 성능
- 접근성
- 권장사항
- 검색엔진 최적화
... 그 외 많은 측정항목
다음 튜토리얼은 Chrome DevTools에서 Lighthouse를 시작하는 데 도움이 됩니다.
Lighthouse에서 웹사이트 품질을 개선하는 다른 방법을 자세히 알아보려면 Lighthouse 문서를 참고하세요.
튜토리얼의 목표
이 튜토리얼에서는 Chrome DevTools를 사용하여 웹사이트를 더 빠르게 로드하는 방법을 찾는 방법을 알려줍니다.
이 튜토리얼의 동영상 버전을 읽거나 시청하세요.
기본 요건
이 과정에서 배운 것과 유사한 기본적인 웹 개발 경험이 있어야 합니다. 이 웹 개발 소개 클래스를 참조하세요.
로드 성능에 대해 전혀 몰라도 됩니다.
소개
저는 토니입니다. 토니는 고양이 협회에서 매우 유명합니다. 그는 웹사이트를 통해 자신이 좋아하는 콘텐츠를 팬들에게 보여줄 수 있습니다. 있습니다. 팬들은 사이트를 좋아하지만 토니는 사이트 로드 속도가 느립니다. 토니는 사이트 속도를 높일 수 있도록 도와달라고 요청했습니다.
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">1단계: 사이트 감사하기
사이트의 로드 성능을 향상하려고 할 때마다 항상 있습니다. 감사에는 두 가지 중요한 기능이 있습니다.
- 후속 변경사항을 측정할 수 있는 기준을 만듭니다.
- 어떤 변화가 가장 큰 영향을 미칠지에 대한 실천 가능한 팁을 제공합니다.
설정
먼저, 새로운 작업 환경을 설정해야 하며 Tony 웹사이트에서 원하는 항목을 직접 수정할 수 있습니다. 할 수 있습니다.
Glitch에서 웹사이트 프로젝트를 리믹스하기 새 프로젝트가 탭에서 열립니다. 이 탭을 편집기 탭이라고 합니다.
프로젝트 이름이 tony에서 무작위로 생성된 이름으로 변경됩니다. 이제 편집 가능한 코드 사본이 만들어졌습니다. 나중에 이 코드를 변경합니다.
편집기 탭 하단에서 미리보기를 클릭합니다. 새 창에서 미리 봅니다. 새 탭에서 데모가 열립니다. 이 탭은 데모 탭이라고 합니다. 사이트를 로드하는 데 다소 시간이 걸릴 수 있습니다.
데모와 함께 DevTools를 엽니다.
기준 설정
기준선이란 실적이 개선되기 전의 사이트 실적에 대한 기록을 말합니다.
Lighthouse 패널을 엽니다. 패널 더보기 뒤에 숨겨져 있을 수 있습니다.
Lighthouse 보고서 구성 설정을 스크린샷에 있는 설정과 일치시킵니다. 다음은 다양한 옵션이 있습니다.
- check_box 저장용량 비우기를 탭합니다. 이 체크박스를 선택하면 모든 감사 전에 페이지와 연결된 모든 스토리지가 삭제됩니다. 신규 방문자의 사이트 경험을 감사하려면 이 설정을 켜진 상태로 둡니다. 재방문 환경을 사용하려면 이 설정을 사용 중지하세요.
- check_box JS 샘플링 사용 설정. 이 옵션은 기본적으로 사용 중지되어 있습니다. 이 옵션을 사용 설정하면 자세한 자바스크립트 호출 스택이 성능 추적에 추가되지만 보고서 생성 속도가 느려질 수 있습니다. more_vert 도구 메뉴 > Lighthouse 보고서가 생성된 후 제한되지 않은 트레이스 보기
- 시뮬레이션된 제한 (기본값) 입니다. 이 옵션은 휴대기기에서 검색할 때의 일반적인 조건을 시뮬레이션합니다. 이를 '시뮬레이션됨'이라고 합니다. Lighthouse는 감사 과정 동안 실제로 제한되지 않기 때문입니다 대신 모바일 상황에서 페이지가 로드되는 데 걸리는 시간을 추정합니다. 반면 DevTools 제한 (고급) 설정은 실제로 CPU와 네트워크를 제한하므로 감사 프로세스가 길어진다는 단점이 있습니다.
- 모드 > 탐색 (기본값). 이 모드는 단일 페이지 로드를 분석하므로 이 튜토리얼에서는 이것이 필요합니다. 자세한 내용은 세 가지 모드를 참조하세요.
- 기기 > 모바일. 모바일 옵션은 사용자 에이전트 문자열을 변경하고 모바일 표시 영역입니다. 데스크톱 옵션을 선택하면 모바일 변경사항이 거의 사용되지 않습니다.
- 카테고리 > check_box 성능. 카테고리를 하나만 사용 설정하면 Lighthouse는 해당하는 감사 모음이 포함된 보고서만 생성합니다. 제공되는 추천 유형을 보려면 다른 카테고리를 사용 설정한 상태로 두면 됩니다. 관련 없는 카테고리를 사용 중지하면 감사 프로세스가 약간 더 빨라집니다.
페이지 로드 분석을 클릭합니다. 10~30초 후에 Lighthouse 패널에 사이트의 성능 보고서가 표시됩니다.
보고서 오류 처리
Lighthouse 보고서에 오류가 발생하면 데모 탭을 실행해 보세요. 다른 탭이 열려 있지 않은 시크릿 창에서 열립니다. 이렇게 하면 제거하면 됩니다. 특히 크롬 확장 프로그램은 방해가 되지 않도록 하는 것이 중요합니다.
보고서 이해하기
보고서 상단에 있는 숫자는 사이트의 전체 실적 점수입니다. 나중에 코드를 변경하면 이 숫자가 증가하는 것을 볼 수 있습니다. 점수가 높을수록 성능이 향상됩니다.
측정항목
측정항목 섹션까지 아래로 스크롤한 다음 보기 펼치기를 클릭합니다. 측정항목에 관한 문서를 읽으려면 자세히 알아보기...를 클릭합니다.
이 섹션에서는 사이트 성능을 정량적으로 측정한 결과를 제공합니다. 각 측정항목은 실적의 다양한 측면에 대한 통계를 제공합니다. 예를 들어 콘텐츠가 포함된 첫 페인트는 는 콘텐츠가 화면에 처음 그려지는 시점을 알려주며, 이는 사용자가 콘텐츠를 감상하는 데 있어 중요한 시점입니다. 상호작용까지의 시간은 페이지가 사용자 상호작용을 처리할 준비가 되어 있어야 합니다
스크린샷
다음은 페이지가 로드될 때의 모습을 보여주는 스크린샷 모음입니다.
기회
다음은 특정 페이지의 로드를 개선하는 방법에 대한 구체적인 팁을 제공하는 추천 섹션입니다. 확인할 수 있습니다
추천을 클릭하여 자세히 알아보세요.
추천이 중요한 이유에 대한 구체적인 문서를 보려면 자세히 알아보기...를 클릭합니다. 추천 해결 방법을 찾을 수 있습니다.
진단
진단 섹션에서는 페이지의 오류에 영향을 주는 요인에 대해 자세히 알아볼 수 있습니다. 로드 시간을 단축할 수 있습니다.
통과한 감사
통과한 감사 섹션에는 사이트가 제대로 수행되고 있는 항목이 표시됩니다. 클릭하여 펼치기 섹션으로 이동합니다.
2단계: 실험
Lighthouse 보고서의 기회 섹션에서는 페이지의 품질을 개선하는 방법에 대한 팁을 제공합니다. 확인할 수 있습니다 이 섹션에서는 코드베이스에 대한 권장 변경사항을 구현하여 를 사용하여 사이트 속도에 미치는 영향을 측정하세요.
텍스트 압축 사용
보고서에 따르면 텍스트 압축을 사용 설정하면 확인할 수 있습니다.
텍스트 압축은 텍스트 파일의 크기를 줄이거나 압축한 다음 네트워크에 속합니다. 이메일을 보내기 전에 폴더를 압축하여 파일 크기를 줄이는 방법도 있습니다.
압축을 사용 설정하기 전에 다음 몇 가지 방법을 통해 텍스트가 압축되었는지 여부를 직접 확인할 수 있습니다. 압축됩니다
네트워크 패널을 열고 설정 > 큰 요청 행 사용
각 크기 셀에는 2개의 값이 표시됩니다. 맨 위 값은 다운로드한 리소스의 크기입니다. 이
bottom 값은 압축되지 않은 리소스의 크기입니다. 두 값이 동일하면
리소스가 네트워크를 통해 전송될 때 압축되지 않습니다. 이 예에서
bundle.js의 최상위 및 하위 값 모두 1.4 MB입니다.
리소스의 HTTP 헤더를 검사하여 압축을 확인할 수도 있습니다.
bundle.js를 클릭하고 Headers 탭을 엽니다.
응답 헤더 섹션에서
content-encoding헤더를 검색합니다. 전혀 표시되지 않을 것입니다. 즉,bundle.js가 압축되지 않았습니다. 리소스가 압축될 때 이 헤더는 보통gzip,deflate또는br로 설정됩니다. 이에 대한 설명은 지시어를 참조하세요. 값으로 사용됩니다.
설명은 여기까지입니다. 이제 변경사항을 적용해 보세요. 코드 줄 수:
편집기 탭에서
server.js을 열고 (강조 표시된) 다음 두 줄을 추가합니다.... const fs = require('fs'); const compression = require('compression'); app.use(compression()); app.use(express.static('build')); ...app.use(express.static('build'))앞에app.use(compression())를 입력해야 합니다.
Glitch에서 사이트의 새 빌드를 배포할 때까지 기다립니다. 왼쪽 하단에 행복한 그림 이모티콘은 배포가 성공적으로 완료되었음을 나타냅니다.
앞에서 배운 워크플로를 사용하여 압축이 작동하는지 수동으로 확인합니다.
데모 탭으로 돌아가서 페이지를 새로고침하세요.
이제 Size 열에
bundle.js과 같은 텍스트 리소스에 관한 두 개의 값이 표시됩니다.bundle.js에 관한269 KB의 상위 값은 네트워크를 통해 전송된 파일의 크기이고,1.4 MB의 하위 값은 압축되지 않은 파일 크기입니다.
이제
bundle.js의 Response Headers 섹션에content-encoding: gzip헤더가 포함되어야 합니다.
페이지에서 Lighthouse 보고서를 다시 실행하여 텍스트 압축이 페이지 로드에 미치는 영향을 측정합니다. 실적:
Lighthouse 패널을 열고 상단의 작업 모음에서
감사 수행...을 클릭합니다.
설정을 전과 동일하게 두고 페이지 로드 분석을 클릭합니다.
축하합니다. 발전한 것 같아요. 전반적인 실적 점수가 높아졌을 것입니다. 이는 사이트 로드 속도가 더 빨라졌다는 뜻입니다.
실제 텍스트 압축
대부분의 서버에는 압축을 사용할 수 있도록 이와 같은 간단한 수정사항이 있습니다. 사용 방법을 검색해 보세요. 텍스트 압축에 사용하는 서버를 구성할 수 있습니다.
이미지 크기 조절
새로 작성한 보고서에 따르면 이미지 크기를 적절하게 조정하는 것도 또 다른 큰 기회가 될 수 있다고 합니다.
이미지 크기를 조절하면 이미지 파일 크기를 줄여 로드 시간을 단축할 수 있습니다. 사용자가 500픽셀 너비의 휴대기기 화면에서 이미지를 볼 때는 실제로 이미지를 너비의 1500픽셀 이미지를 전송하는 경우 너비가 500픽셀 이하인 이미지를 전송하는 것이 좋습니다.
보고서에서 적절한 이미지 크기 조절을 클릭하여 크기를 조정해야 하는 이미지를 확인합니다. 이미지 4개가 모두 필요한 것보다 큰 것 같습니다.
편집기 탭으로 돌아가서
src/model.js를 엽니다.const dir = 'big'를const dir = 'small'로 바꿉니다. 이 디렉터리에는 크기가 조정된 동일한 이미지의 사본이 포함되어 있습니다.이 변경사항이 로드 성능에 어떤 영향을 미치는지 페이지를 다시 감사하세요.
이러한 변화는 전체 실적 점수에 미미한 영향을 미칩니다. 하지만 한 가지 사용자가 얼마나 많은 네트워크 데이터를 절약하고 있는지는 점수가 명확하게 표시되지 않습니다. 합계 이전 사진의 크기는 약 6.1MB였지만 지금은 약 633KB에 불과합니다. 네트워크 패널 하단의 상태 표시줄에서 이를 확인할 수 있습니다.
실제 이미지 크기 조절
작은 앱의 경우 이와 같이 일회성으로 크기를 조절하는 것으로 충분할 수 있습니다. 하지만 큰 앱의 경우 당연히 확장할 수 없습니다. 다음은 대용량 앱에서 이미지를 관리하기 위한 몇 가지 전략입니다.
- 빌드 프로세스 중에 이미지 크기를 조절합니다.
- 빌드 프로세스 중에 각 이미지의 크기를 여러 가지로 만든 다음 코드에서
srcset를 사용합니다. 런타임 시 브라우저는 실행되는 기기에 가장 적합한 크기를 선택합니다. 상대 크기 이미지를 참고하세요. - 요청 시 이미지 크기를 동적으로 조절할 수 있는 이미지 CDN을 사용합니다.
- 적어도 각 이미지를 최적화하세요. 이를 통해 종종 상당한 비용을 절감할 수 있습니다. 최적화란 이미지 파일의 크기를 줄이는 특수 프로그램을 통해 이미지를 실행합니다. 자세한 내용은 필수 이미지 최적화를 참조하세요.
렌더링 차단 리소스 제거
최신 보고서에 따르면 렌더링 차단 리소스를 없애는 것이 현재 가장 큰 기회입니다.
렌더링 차단 리소스는 브라우저가 다운로드해야 하는 외부 JavaScript 또는 CSS 파일입니다. 파싱하고 실행할 수 있습니다. 목표는 핵심 CSS 및 JavaScript만 실행하는 것입니다. 이 코드가 있어야 합니다.
첫 번째 작업은 페이지 로드 시 실행할 필요가 없는 코드를 찾는 것입니다.
렌더링 차단 리소스 제거를 클릭하여 차단 중인 리소스를 확인합니다.
lodash.js및jquery.js.
운영체제에 따라 다음을 눌러 명령어 메뉴를 엽니다.
- Mac: Command+Shift+P
- Windows, Linux, ChromeOS: Control+Shift+P
Coverage를 입력하고 범위 표시를 선택합니다.
범위 탭이 창에 열립니다.
새로고침 새로고침을 클릭합니다. 노출 범위 탭에는 페이지가 로드되는 동안
bundle.js,jquery.js,lodash.js에서 실행되고 있는 코드의 양에 관한 개요가 표시됩니다.
이 스크린샷은 jQuery 및 Lodash 파일의 약 74% 와 30% 가 각각 사용되지 않음을 보여줍니다.
jquery.js 행을 클릭합니다. DevTools가 Sources 패널에서 파일을 엽니다. 코드 한 줄은 옆에 초록색 막대가 있으면 실행됩니다. 코드 줄 옆에 빨간색 막대가 표시되면 코드가 실행되지 않았음을 의미합니다. 페이지 로드에는 당연히 필요하지 않습니다
jQuery 코드를 살짝 스크롤합니다. '실행'되는 줄은 사실 그냥 있습니다. 주석을 제거하는 최소화기를 통해 이 코드를 실행하는 것도 이 파일의 크기입니다.
간단히 말해, 자체 코드로 작업할 때 적용 범위 탭을 사용하면 코드를 분석하고 페이지 로드에 필요한 코드만 제공하세요.
jquery.js 및 lodash.js 파일이 페이지를 로드하는 데에도 필요한가요? Request Blocking 탭에서는 다음 작업을 수행할 수 있습니다.
리소스를 사용할 수 없는 경우 어떤 일이 발생하는지 보여줍니다.
- 네트워크 탭을 클릭하고 명령어 메뉴를 다시 엽니다.
blocking를 입력한 후 Show Request Blocking(요청 차단 표시)을 선택합니다. Request Blocking(차단 요청) 탭이 열립니다.
패턴 추가를 클릭하고 텍스트 상자에 /libs/*를 입력한 후 Enter를 눌러 확인합니다.
페이지를 새로고침합니다. jQuery 및 Lodash 요청은 빨간색으로, 차단되었음을 의미합니다. 이 페이지는 여전히 로드되고 상호작용하므로 이러한 리소스는 전혀 필요하지 않은 것 같습니다.
모든 패턴 삭제를 클릭하여 /libs/*차단 패턴을 삭제합니다.
일반적으로 차단 요청 탭은 소재가 차단되었을 때 페이지가 어떻게 동작하는지 시뮬레이션하는 데 유용합니다. 리소스를 사용할 수 없습니다.
이제 코드에서 이러한 파일에 대한 참조를 삭제하고 페이지를 다시 감사합니다.
- 편집기 탭으로 돌아가서
template.html를 엽니다. 상응하는
<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>사이트가 다시 빌드되고 배포될 때까지 기다립니다.
Lighthouse 패널에서 페이지를 다시 감사합니다. 전체 점수가 다시 높아졌을 것입니다.
실제 상황에서 주요 렌더링 경로 최적화
주요 렌더링 경로란 페이지를 로드하는 데 필요한 코드를 말합니다. 일반적으로 페이지 로드 중에 중요한 코드만 전송한 다음 지연 로드하여 페이지 로드 속도를 높일 수 있음 있습니다.
- 완전히 삭제할 수 있는 스크립트를 찾을 가능성은 거의 없지만 많은 스크립트를 페이지 로드 중에 요청할 필요가 없으며 대신 있습니다. async 또는 defer 사용을 참고하세요.
- 프레임워크를 사용 중인 경우 프로덕션 모드가 있는지 확인합니다. 이 모드는 트리 쉐이킹으로 간주하여 중요한 렌더링을 차단하는 불필요한 코드를 제거해야 합니다.
기본 스레드 작업 줄이기
최신 보고서의 추천 섹션에 약간의 잠재적 절감 효과가 나와 있지만 스크롤하면 진단 섹션으로 내려가 보면 가장 큰 병목 현상은 기본 스레드가 너무 많은 것 같습니다. 있습니다.
기본 스레드는 브라우저가 페이지를 표시하는 데 필요한 대부분의 작업(예: HTML, CSS, JavaScript를 실행할 수 있습니다.
목표는 Performance 패널을 사용하여 페이지를 로드하고, 불필요한 작업을 연기하거나 삭제하는 방법을 찾습니다.
실적을 열고 >
캡처 설정에서 네트워크를 느린 3G로, CPU를 6배 감속으로 설정합니다.
휴대기기에서는 일반적으로 노트북이나 데스크톱보다 하드웨어 제약이 더 많기 때문에 성능이 낮은 기기를 사용하는 것처럼 페이지 로드를 경험할 수 있습니다.
새로고침 새로고침을 클릭합니다. DevTools가 페이지를 새로고침한 다음 페이지를 로드하기 위해 수행해야 했던 모든 작업을 시각화합니다. 이러한 시각화를 trace라고 합니다.
트레이스는 왼쪽에서 오른쪽 순으로 활동을 시간순으로 표시합니다. 페이지의 FPS, CPU 및 NET 차트는 초당 프레임 수, CPU 활동 및 네트워크 활동에 대한 개요를 제공합니다.
Overview(개요) 섹션에 표시되는 노란색 벽은 CPU가 스크립팅 작업으로 완전히 바쁘다는 것을 의미합니다. 이는 JavaScript 작업을 적게 하면 페이지 로드 속도를 높일 수 있다는 증거입니다.
트레이스를 조사하여 JavaScript 작업을 줄이는 방법을 찾습니다.
시간 섹션을 클릭하여 펼칩니다.
React의 여러 사용자 시간 측정값이 있는데, 토니의 앱은 React의 개발 모드를 사용하는 것 같습니다. React의 프로덕션 모드로 전환하면 쉽게 성능을 얻을 수 있습니다.
시간을 다시 클릭하면 해당 섹션이 접힙니다.
기본 섹션으로 이동합니다. 이 섹션에서는 기본 스레드 활동의 시간순 로그를 보여줍니다. 살펴보겠습니다. y축 (위에서 아래로)에는 이벤트가 발생한 이유가 표시됩니다.
이 예시에서는
Evaluate Script이벤트로 인해(anonymous)함수가 실행되어__webpack__require__가 실행되고./src/index.jsx가 실행되는 식이 일어납니다.기본 섹션의 하단으로 스크롤합니다. 프레임워크를 사용할 때는 상위 활동은 대부분 관리할 수 있습니다. 앱에서 발생한 활동은 일반적으로 하단에 표시됩니다.
이 앱에서는
App라는 함수가mineBitcoin함수를 많이 호출하는 것 같습니다. 토니가 암호화폐를 채굴하기 위해 팬의 기기를 사용하는 것 같습니다...하단에서 Bottom-Up 탭을 엽니다. 이 탭은 시간이 가장 많이 걸린 활동을 분류합니다. Bottom-Up 섹션에 아무 것도 표시되지 않으면 Main 섹션의 라벨을 클릭합니다.
상향식 섹션에는 내가 가지고 있는 활동이나 활동 그룹에 관한 정보만 표시됩니다. 현재 선택되어 있습니다. 예를 들어
mineBitcoin활동 중 하나를 클릭하면 Bottom-Up 섹션에는 해당 활동에 관한 정보만 표시됩니다.Self Time(자체 시간) 열에는 각 활동에 직접 소요된 시간이 표시됩니다. 이 경우 기본 스레드 시간의 약 82% 가
mineBitcoin함수에 사용되었습니다.
프로덕션 모드를 사용하고 JavaScript 활동을 줄이는지 확인해 보겠습니다. 페이지 로드 속도가 빨라집니다. 프로덕션 모드로 시작:
- 편집기 탭에서
webpack.config.js를 엽니다. "mode":"development"를"mode":"production"로 변경합니다.- 새 빌드가 배포될 때까지 기다립니다.
페이지를 다시 감사합니다.
mineBitcoin 호출을 삭제하여 JavaScript 활동을 줄입니다.
- 편집기 탭에서
src/App.jsx를 엽니다. constructor에서this.mineBitcoin(1500)호출을 주석 처리합니다.- 새 빌드가 배포될 때까지 기다립니다.
- 페이지를 다시 감사합니다.
늘 그렇듯 콘텐츠가 포함된 최대 페인트 및 누적 레이아웃 변경 측정항목을 줄이는 등의 작업이 남아 있습니다.
실제 환경에서 기본 스레드 작업 줄이기
일반적으로 실적 패널은 사이트에서 어떤 활동을 하는지 파악하는 가장 일반적인 방법입니다. 불필요한 활동을 삭제하는 방법을 찾습니다.
console.log()와 유사한 접근 방식을 원하는 경우 User Timing API를 사용하면
각 단계가 얼마나 긴지 추적하기 위해 앱 수명 주기의 특정 단계를 임의로 마크업합니다.
몇 가지 단계가 필요합니다.
요약
- 사이트의 로드 성능을 최적화하려고 할 때마다 항상 살펴보겠습니다 감사를 통해 기준을 설정하고, 개선할 수 있습니다
- 한 번에 하나씩 변경하고, 매번 변경한 후 페이지를 감사하여 각 변경사항이 성능에 어떤 영향을 미치는지 확인할 수 있습니다.
다음 단계
내 사이트에서 감사를 진행하세요. 보고서를 해석하거나 로드 성능을 개선하는 방법을 찾는 데 도움이 필요한 경우 DevTools 커뮤니티에서 도움을 받을 수 있는 모든 방법을 확인하세요.
- developer.chrome.com 저장소에서 이 문서에 대한 버그를 신고합니다.
- Chromium 버그에서 DevTools에 대한 버그 신고를 제출합니다.
- 메일링 리스트에서 기능과 변경사항에 대해 논의합니다. 다음의 경우 메일링 리스트를 사용하지 마세요. 할 수 있습니다. 대신 Stack Overflow를 사용하세요.
- Stack Overflow에서 DevTools 사용 방법에 관한 일반적인 도움말을 확인하세요. 버그 요청을 제출하려면 항상 Chromium 버그를 사용하세요.
- @ChromeDevTools에서 트윗을 보내주세요.