이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Lighthouse: 웹사이트 속도 최적화

Kayce Basques

Sofia Emelianova

튜토리얼의 목표

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

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

기본 요건

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

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

소개

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

1단계: 사이트 감사하기

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

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

설정

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

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

프로젝트 이름이 tony에서 무작위로 생성된 이름으로 변경됩니다. 이제 편집 가능한 코드 사본이 만들어졌습니다. 나중에 이 코드를 변경합니다.
편집기 탭 하단에서 미리보기 > 새 창에서 미리보기를 클릭합니다. 새 탭에서 데모가 열립니다. 이 탭은 데모 탭이라고 합니다. 사이트가 로드되는 데 다소 시간이 걸릴 수 있습니다.
데모와 함께 DevTools를 엽니다.

기준 설정

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

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

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

보고서 오류 처리

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

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

보고서 이해하기

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

전체 성능 점수입니다.

측정항목

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

측정항목 섹션

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

스크린샷

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

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

기회

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

진단

진단 섹션에서는 페이지의 로드 시간에 기여하는 요소에 관한 자세한 정보를 제공합니다.

진단 섹션

통과한 감사

통과한 감사 섹션에는 사이트가 제대로 수행되고 있는 항목이 표시됩니다. 클릭하여 섹션을 펼칩니다.

통과한 감사 섹션

2단계: 실험

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

텍스트 압축 사용

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

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

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

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

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

각 크기 셀에는 2개의 값이 표시됩니다. 맨 위 값은 다운로드한 리소스의 크기입니다. 최저값은 압축되지 않은 리소스의 크기입니다. 두 값이 동일하면 리소스가 네트워크를 통해 전송될 때 압축되지 않습니다. 이 예에서 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())를 입력해야 합니다.

참고: 일반적으로 npm i -S compression 등을 통해 compression 패키지를 설치해야 하지만 이 작업은 이미 완료되어 있습니다.
Glitch에서 사이트의 새 빌드를 배포할 때까지 기다립니다. 왼쪽 하단에 행복한 그림 이모티콘은 배포가 성공적으로 완료되었음을 나타냅니다.

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

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

이제 Size 열에 bundle.js과 같은 텍스트 리소스에 관한 두 개의 값이 표시됩니다. bundle.js에 관한 269 KB의 상위 값은 네트워크를 통해 전송된 파일의 크기이고, 1.4 MB의 하위 값은 압축되지 않은 파일 크기입니다.
이제 bundle.js의 Response Headers 섹션에 content-encoding: gzip 헤더가 포함되어야 합니다.

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

Lighthouse 패널을 열고 상단의 작업 모음에서 감사 수행...을 클릭합니다.
설정을 전과 동일하게 두고 페이지 로드 분석을 클릭합니다.

축하합니다. 발전된 것 같아요. 전반적인 실적 점수가 높아졌을 것입니다. 이는 사이트 로드 속도가 더 빨라졌다는 뜻입니다.

실제 텍스트 압축

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

이미지 크기 조절

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

이미지 크기를 조절하면 이미지 파일 크기를 줄여 로드 시간을 단축할 수 있습니다. 사용자가 너비가 500픽셀인 휴대기기 화면에서 이미지를 보고 있다면 너비가 1, 500픽셀인 이미지를 전송하는 것은 무의미합니다. 너비가 500픽셀 이하인 이미지를 전송하는 것이 이상적입니다.

보고서에서 적절한 이미지 크기 조절을 클릭하여 크기를 조정해야 하는 이미지를 확인합니다. 이미지 4개가 모두 필요한 것보다 큰 것 같습니다.
편집기 탭으로 돌아가서 src/model.js를 엽니다.
const dir = 'big'를 const dir = 'small'로 대체했습니다. 이 디렉터리에는 크기가 조정된 동일한 이미지의 사본이 포함되어 있습니다.
이 변경사항이 로드 성능에 어떤 영향을 미치는지 페이지를 다시 감사하세요.

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

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

실제 이미지 크기 조절

작은 앱의 경우 이와 같이 일회성으로 크기를 조절하는 것으로 충분할 수 있습니다. 그러나 대규모 앱에서는 당연히 확장이 불가능합니다. 다음은 대용량 앱에서 이미지를 관리하기 위한 몇 가지 전략입니다.

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

렌더링 차단 리소스 제거

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

렌더링 차단 리소스는 브라우저에서 페이지를 표시하기 전에 다운로드하고 파싱하고 실행해야 하는 외부 자바스크립트 또는 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 파일이 페이지를 로드하는 데에도 필요한가요? 요청 차단 탭에서 리소스를 사용할 수 없을 때 발생하는 상황을 확인할 수 있습니다.

네트워크 탭을 클릭하고 명령어 메뉴를 다시 엽니다.
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 활동, 네트워크 활동에 대한 개요를 제공합니다.

trace의 개요 섹션

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

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

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

React의 여러 사용자 시간 측정값이 있는데, 토니의 앱은 React의 개발 모드를 사용하는 것 같습니다. React의 프로덕션 모드로 전환하면 쉽게 성능을 얻을 수 있습니다.
시간을 다시 클릭하면 해당 섹션이 접힙니다.
기본 섹션으로 이동합니다. 이 섹션에서는 기본 스레드 활동의 시간순 로그를 왼쪽에서 오른쪽으로 보여줍니다. y축 (위에서 아래로)에는 이벤트가 발생한 이유가 표시됩니다.

이 예시에서는 Evaluate Script 이벤트로 인해 (anonymous) 함수가 실행되어 __webpack__require__가 실행되고 ./src/index.jsx가 실행되는 식이 일어납니다.
기본 섹션의 하단으로 스크롤합니다. 프레임워크를 사용하면 상위 활동의 대부분이 프레임워크로 인해 발생하며 이는 일반적으로 제어할 수 없는 프레임워크입니다. 앱에서 발생한 활동은 일반적으로 하단에 표시됩니다.

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

참고: 일반적으로 프레임워크에서 호출하는 호출을 개발자가 제어할 수 없는 경우도 있지만, 프레임워크가 비효율적으로 실행되도록 앱을 구조화하는 경우도 있습니다. 프레임워크를 효율적으로 사용하도록 앱을 재구성하면 기본 스레드 작업을 줄일 수 있습니다. 이를 위해서는 프레임워크의 작동 방식과 프레임워크를 보다 효율적으로 사용하기 위해 코드에서 변경할 수 있는 사항에 대한 깊이 있는 이해가 필요합니다.
하단에서 Bottom-Up 탭을 엽니다. 이 탭은 시간이 가장 많이 걸린 활동을 분류합니다. Bottom-Up 섹션에 아무 것도 표시되지 않으면 Main 섹션의 라벨을 클릭합니다.

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

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

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

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

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

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

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

늘 그렇듯 콘텐츠가 포함된 최대 페인트 및 누적 레이아웃 변경 측정항목을 줄이는 등의 작업이 남아 있습니다.

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

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

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

요약

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

다음 단계

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

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