React 개발자의 초기 부하 성능 : 조사 깊은 다이빙

웹페이지 첫 화면 로딩 성능과 최적화 전략에 대한 심층 논의

목차

1. 초기 로딩 성능 지표 소개
2. 성능 DevTools 개요
   1. 프로젝트 설정
   2. 필수 DevTools 살펴보기
3. 다양한 네트워크 조건 살펴보기
   1. 서버가 매우 느림
   2. 다양한 대역폭과 지연 시간 시뮬레이션
   3. CDN의 중요성
4. 반복 접속 성능
   1. Cache-Control 헤더를 사용하여 브라우저 캐시 제어
   2. 캐시 제어 및 최신 번들링 도구
   3. 단순한 사용 사례에서 이 모든 것을 알아야 합니까?

AI 기반 코드 생성이 붐을 이루면서 React 코드 작성의 중요성이 줄어들고 있습니다. 이제 누구든지 무엇이든 React로 애플리케이션을 작성할 수 있습니다. 하지만 코드 작성은 언제나 퍼즐의 일부일 뿐입니다. 우리는 여전히 애플리케이션을 어딘가에 배포하고, 사용자에게 공개하고, 강력하게 만들고, 빠르게 만드는 등 수많은 작업을 수행해야 합니다. 어떤 AI도 이를 대신할 수 없습니다. 적어도 아직은 아닙니다.

오늘은 지원서를 빠르게 작성하는 방법에 집중해 보겠습니다. 그러기 위해서는 잠시 React에서 벗어나야 합니다. 왜냐하면 무언가를 빠르게 만들기 전에 먼저 "빠름"이 무엇인지, 이를 측정하는 방법, "빠름"에 영향을 줄 수 있는 것이 무엇인지 알아야 하기 때문입니다.

스포일러 경고: React는 학습 프로젝트를 제외하고 이 글에 등장하지 않습니다. 오늘은 성능 도구 사용 방법, Core Web Vitals 소개, Chrome 성능 패널, 초기 로드 성능이 무엇인지, 이를 측정할 수 있는 측정항목, 캐시 제어 및 다양한 네트워크 조건이 이에 미치는 영향 등 기본 사항에 대해 다룹니다.

초기 로딩 성능 지표 소개

브라우저를 열고 즐겨찾는 웹사이트로 이동하려고 하면 어떻게 되나요? GET 요청을 하기 위해 주소 표시줄에 "https://www.php.cn/link/63ea3fef646010a7255aec506626ea32를 입력하고 그 대가로 HTML 페이지를 받습니다.

이 작업을 수행하는 데 걸리는 시간을 '첫 번째 바이트까지의 시간'(TTFB)이라고 합니다. 즉, 요청이 전송된 시점과 결과가 도착하기 시작하는 시점 사이의 시간입니다. HTML을 수신한 후 브라우저는 이제 가능한 한 빨리 이 HTML을 사용 가능한 웹 사이트로 변환해야 합니다.

먼저 사용자에게 표시할 수 있는 가장 작고 가장 중요한 콘텐츠인 '주요 경로'를 화면에 렌더링합니다.

정확히 크리티컬 경로에 무엇이 포함되어야 하는지는 복잡한 질문입니다. 이상적으로는 모든 것이 사용자가 전체 경험을 즉시 볼 수 있도록 설계되었습니다. 그러나 다시 말하지만, "중요한" 경로이기 때문에 가능한 한 빨라야 하기 때문에 아무것도 아닙니다. 두 가지를 동시에 하는 것은 불가능하므로 절충이 필요합니다.

절충안은 이것이다. 브라우저는 "주요 경로"를 구축하려면 최소한 다음 유형의 리소스가 절대적으로 필요하다고 가정합니다.

• 서버에서 수신하는 초기 HTML - 경험이 구축되는 실제 DOM 요소를 구축하는 데 사용됩니다.
• 이러한 초기 요소에 대해 중요한 CSS 파일의 스타일을 지정하세요. 그렇지 않으면 기다리지 않고 계속 진행하면 사용자는 처음에 스타일이 지정되지 않은 콘텐츠의 이상한 "깜박임"을 보게 될 것입니다.
• 레이아웃을 수정하는 주요 JavaScript 파일을 동기화합니다.

브라우저는 서버에 대한 초기 요청에서 첫 번째 HTML(HTML)을 가져옵니다. 구문 분석을 시작하고 이를 통해 "중요 경로"를 완료하는 데 필요한 CSS 및 JS 파일에 대한 링크를 추출합니다. 그런 다음 서버에서 가져오기 요청을 보내고, 다운로드될 때까지 기다리고, 처리하고, 모두 합친 다음, 특정 순간이 끝나면 화면에 "중요 경로" 픽셀을 그립니다.

이러한 중요한 리소스가 없으면 브라우저는 초기 렌더링을 완료할 수 없기 때문에 이를 "렌더링 차단 리소스"라고 합니다. 물론 모든 CSS 및 JS 리소스가 렌더링을 차단하는 것은 아닙니다. 일반적으로만:

• 인라인 또는 태그를 통한 대부분의 CSS입니다.
비동기 또는 지연되지 않은
• 태그의 JavaScript 리소스입니다.

"주요 경로"를 렌더링하는 전체 프로세스는 대략 다음과 같습니다.

• 브라우저가 초기 HTML 구문 분석을 시작합니다
• 이 과정에서 태그에서 CSS 및 JS 리소스에 대한 링크를 추출합니다.
• 그런 다음 다운로드 프로세스를 시작하고 차단 리소스가 다운로드를 완료할 때까지 기다립니다.
• 기다리는 동안 가능하면 HTML 처리를 계속합니다.
• 모든 주요 리소스를 받은 후 해당 리소스도 처리됩니다.
• 마지막으로 해야 할 일을 수행하고 인터페이스의 실제 픽셀을 그립니다.

이 시점을 첫 번째 추첨(FP)이라고 부릅니다. 사용자가 화면에서 무언가를 볼 수 있는 기회는 이번이 처음입니다. 이런 일이 발생하는지 여부는 서버에서 보낸 HTML에 따라 다릅니다. 거기에 텍스트나 이미지 등 의미 있는 내용이 있는 경우 첫 번째 콘텐츠 페인트(FCP)가 발생하는 시점이기도 합니다. HTML이 빈 div인 경우 FCP는 나중에 발생합니다.

FCP(첫 번째 콘텐츠 페인트)는 인식된 초기 로드를 측정하므로 가장 중요한 성능 지표 중 하나입니다. 기본적으로 이는 사이트 속도에 대한 사용자의 초기 인상입니다.

이 순간까지, 사용자는 손톱을 물기 위해 빈 화면을 쳐다보고있었습니다. Google에 따르면, 좋은 FCP 번호는

1.8 초 미만입니다. 그 후, 사용자는 웹 사이트가 제공 할 수 있고 떠나기 시작할 수있는 콘텐츠에 대한 관심을 잃기 시작합니다. 그러나 FCP는 완벽하지 않습니다. 웹 사이트가 로터 또는 일부로드 화면으로로드를 시작하면 FCP 표시기가 컨텐츠를 나타냅니다. 그러나 사용자가 멋진 로딩 화면을보기 위해 웹 사이트를 탐색 할 가능성은 낮습니다. 대부분의 경우 컨텐츠에 액세스하려고합니다. 이러한 이유로 브라우저는 시작을 완료해야합니다. 나머지 비 차단 JavaScript를 기다리고 있으며 실행하며 화면에서 DOM에 변경 사항을 적용하고 이미지를 다운로드하며 다른 방식으로 사용자 경험을 향상시킵니다.

프로세스의 특정 시점에서 최대 컨텐츠 그리기 시간이 발생합니다. FCP와 같은 첫 번째 요소는 아니지만 페이지의 기본 콘텐츠 영역에서 볼 수있는 가장 큰 텍스트, 이미지 또는 비디오가 보이는 포트입니다. Google에 따르면이 숫자는 2.5 초 미만이어야합니다. 이 숫자보다 사용자는 웹 사이트가 느리다고 생각합니다.

이러한 모든 지표는 페이지의 사용자 경험을위한 Google Web Vitals의 일부입니다. LCP는 세 가지 핵심 웹 생명체 중 하나입니다. lcp 책임있는

로딩 성능

. 이 지표는 등대를 통해 측정 할 수 있습니다. Lighthouse는 Google 성능 도구입니다. Chrome Devtools에 통합되어 쉘 스크립트, 웹 인터페이스 또는 노드 모듈을 실행할 수 있습니다. 구조 중에 실행할 수 있도록 노드 모듈로 사용할 수 있으며 생산 환경에서 돌아 오기 전에 감지 할 수 있습니다. 로컬 디버깅 및 테스트에는 Integrated DevTools 버전을 사용하십시오. 그리고 경쟁 업체의 성과를 확인하는 웹 버전. OvervTools 개요 위의 것은 프로세스에 대한 매우 간단하고 단순화 된 설명입니다. 그러나 사람들을 혼란스럽게 만드는 많은 약어와 이론이 있습니다. 개인적으로 나에게 그러한 내용을 읽는 것은 쓸모가 없습니다. 내가 그것을 실제로 볼 수 있고 직접 작동 할 수 없다면, 나는 즉시 모든 것을 잊을 것입니다.

이 특정 주제의 경우, 이러한 개념을 완전히 이해하는 가장 쉬운 방법은 반 -실시간 페이지의 다른 장면을 시뮬레이션하고 결과가 어떻게 변경되는지 확인하는 것입니다. 그래서 더 많은 이론이 있기 전에 (많은 것들이 있습니다!), 이것을하자.

프로젝트 설정 당신이 기꺼이한다면, 당신은 자신의 프로젝트에서 다음 시뮬레이션을 모두 수행 할 수 있습니다. 결과는 어느 정도 또는 그 이상이어야합니다. 그러나보다 제어 가능하고 단순화 되려면이 기사를 위해 준비한 학습 프로젝트를 사용하는 것이 좋습니다. 여기에서 방문 할 수 있습니다 : https://www.php.cn/link/def14e8541708294d7558fdf2126ef27

먼저 모든 종속성을 설치하십시오

<code>npm install</code>

빌드 프로젝트:

<code>npm run build</code>

서버 시작:

<code>npm run start</code>

"https://www.php.cn/link/66e8d052ec2230c66bd11ee6b5a0e3c8으로 이동하세요.

필수 DevTools 살펴보기

Chrome에서 분석하려는 웹사이트를 열고 Chrome DevTools를 엽니다. 거기에서 Performance 및 Lighthouse 패널을 찾아서 함께 배치합니다. 우리는 둘 다 필요합니다.

또한 이 문서에서 다른 작업을 수행하기 전에 '캐시 비활성화' 확인란이 활성화되어 있는지 확인하세요. 이는 최상위 네트워크 패널에 있어야 합니다.

이렇게 하면 처음 방문자, 즉 웹사이트를 방문한 적이 없고 아직 리소스를 캐시하지 않은 사람들을 시뮬레이션할 수 있습니다.

Lighthouse 패널 살펴보기

이제 Lighthouse 패널을 엽니다. 여기에는 몇 가지 설정과 "페이지 로드 분석" 버튼이 표시됩니다.

이 섹션에서는 페이지의 초기 로드에 대한 자세한 분석을 제공하는 "탐색" 패턴에 관심이 있습니다. 보고서는 다음과 같은 점수를 제공합니다.

로컬 성능은 완벽합니다. 놀랄 일도 아닙니다. 모든 것이 "내 컴퓨터에서 실행"됩니다.

다음 지표도 있습니다.

이 기사에 필요한 FCP 및 LCP 값이 바로 상단에 있습니다.

아래에서 점수를 높이는 데 도움이 될 수 있는 제안 목록을 확인할 수 있습니다.

각 제안을 확장하여 더 자세한 정보를 찾을 수 있으며 특정 주제를 설명하는 링크도 찾을 수 있습니다. 이 모든 것이 실행 가능한 것은 아니지만 성능에 대해 배우고 이를 개선할 수 있는 다양한 사항을 이해하기 시작하는 데 훌륭한 도구입니다. 이 보고서와 관련 링크를 읽는 것만으로도 몇 시간을 보낼 수 있습니다.

그러나 Lighthouse는 표면 정보만 제공하며 느린 네트워크 또는 낮은 CPU와 같은 다양한 시나리오를 시뮬레이션하는 것을 허용하지 않습니다. 이는 시간 경과에 따른 성과를 추적하기 위한 훌륭한 진입점이자 훌륭한 도구입니다. 무슨 일이 일어나고 있는지 더 깊이 이해하려면 성능 패널이 필요합니다.

성능 패널 살펴보기

처음 로드하면 성능 패널이 다음과 같이 표시됩니다.

3 가지 핵심 웹 생명 지표가 표시되는데, 그 중 하나는 LCP이며, 느린 네트워크 및 CPU의 능력을 시뮬레이션하고 시간이 지남에 따라 성능 세부 사항을 기록 할 수 있습니다. 패널 상단의 "스크린 샷"확인란을 찾아 선택한 다음 웹 사이트 자체가 다시로드 될 때 "레코드 및 다시로드"버튼을 클릭하십시오. 이것은 초기 로딩 기간 동안 페이지의 상황에 대한 자세한 보고서가 될 것입니다.

이 보고서에는 여러 부분이 포함됩니다.

상단은 기존의 " 타임 축 개요"입니다.

여기 웹 사이트에서 무슨 일이 일어나고 있지만 더 이상 내용이 없습니다. 마우스를 걸 때 -발생하는 화면의 스크린 샷이 표시되며 특정 범위로 선택하고 확대하여 신중하게 확인할 수 있습니다.

아래는 네트워크 부품 입니다. 확장 후 다운로드 된 모든 외부 리소스와 타임 라인에 정확한 시간이 표시됩니다. 특정 리소스에 마우스를 걸을 때 다운로드 한 단계에서 얼마나 많은 세부 정보를 소비하는지 알 수 있습니다. 빨간 뿔이있는 자원은 차단 자원을 나타냅니다.

학습 프로젝트를 사용하는 경우 정확히 같은 그림이 표시 되며이 그림은 이전 섹션에서 우리의 단어 내용과 일치합니다. 처음에는 파란색 블록이 있습니다. 로딩이 완료된 후 약간의 일시 정지 (Parsing HTML), 더 많은 자원을 얻기위한 두 가지 요청이 발행됩니다. JavaScript -non -Blocking의 (노란색) 중 하나입니다.

CSS의 또 다른 (보라색), 이것은 블록입니다.

학습 프로젝트 코드를 열고 지금 원위 폴더를 보면 소스 코드 가이 동작과 일치합니다.

는 index.html 파일과 .css 및 .js 파일에 index.html 파일과 .css 및 .js 파일이 있습니다 폴더 . index.html 파일의 일부에는 CSS 파일에

태그가 있습니다. 우리가 알다시피, 레이블의 CSS 리소스는 장애물로 렌더링되므로 확인할 수 있습니다.

또한 자산 폴더에 javaScript 파일에 레이블이 있습니다. 지연되거나 비동기식은 아니지만 유형 = "모듈"이 있습니다. 이것들은 자동으로 지연되므로 패널의 JavaScript 파일도 블로킹되지 않습니다.

추가 운동 프로젝트를 다루는 경우 초기 로딩 성능을 기록하고 "네트워크"패널을보십시오. 더 많은 리소스가 다운로드 될 수 있습니다.

• 렌더링 차단 리소스가 몇 개 있나요? 이 모든 것이 필요합니까?
• 프로젝트의 "진입" 지점이 어디인지, <script> 섹션에 차단 리소스가 어떻게 나타나는지 알고 계시나요? npm 빌드 변형을 사용하여 프로젝트를 빌드하고 검색해 보세요. 팁:- 순수 웹팩 기반 프로젝트가 있는 경우 webpack.config.js 파일을 찾으세요. HTML 진입점에 대한 경로는 내부에 있어야 합니다. </script>
• Vite를 사용하는 경우 학습 프로젝트와 동일하게 dist 폴더를 찾으세요
• Next.js 앱 라우터를 사용하는 경우 - .next/server/app을 확인하세요

'네트워크' 섹션에서 '프레임' 및 '타이밍' 섹션을 찾을 수 있습니다.

정말 멋지네요. "타이밍" 섹션에서는 이전에 논의한 모든 지표(FP, FCP, LCP)와 아직 논의하지 않은 일부 지표를 볼 수 있습니다. 측정항목 위에 마우스를 올리면 소요된 정확한 시간을 확인할 수 있습니다. 이를 클릭하면 맨 아래에 있는 "요약" 탭이 업데이트되며, 여기서 이 측정항목에 대한 정보와 자세한 내용을 확인할 수 있는 링크를 찾을 수 있습니다. DevTools는 이제 사람들을 교육하는 데 중점을 두고 있습니다.

마지막으로 메인 부분입니다. 이는 기록된 타임라인 동안 메인 스레드에서 일어나는 일입니다.

여기서 'HTML 구문 분석' 또는 '레이아웃'과 같은 항목과 소요 시간을 확인할 수 있습니다. 노란색 부분은 JavaScript와 관련된 부분으로, 축소된 JavaScript가 포함된 프로덕션 버전을 사용하고 있기 때문에 약간 쓸모가 없습니다. 하지만 이 상태에서도 예를 들어 HTML 구문 분석 및 그리기 레이아웃과 비교하여 JavaScript 실행에 걸리는 시간을 대략적으로 알 수 있습니다.

네트워크와 메인을 모두 열어서 전체 화면을 차지할 때 성능 분석에 특히 유용합니다.

여기서 보면 내 서버가 매우 빠르고 번들이 매우 빠르고 작다는 것을 알 수 있습니다. 어떤 네트워크 작업도 병목 현상이 발생하지 않습니다. 상당한 시간이 필요하지 않으며 그 사이에 브라우저는 그냥 대기하고 자체 작업을 수행합니다. 따라서 여기에서 초기 로드 속도를 높이려면 "HTML 구문 분석"이 왜 그렇게 느린지 조사해야 합니다. 이는 그래프에서 가장 긴 작업입니다.

또는 절대적인 숫자를 보면 성능 ​​측면에서 여기서는 아무것도 하면 안 됩니다. 전체 초기 로드 시간은 200ms 미만으로 Google이 권장하는 임계값보다 훨씬 낮습니다. 하지만 이 테스트를 매우 빠른 노트북에서 로컬로 실행하고(따라서 실제 네트워크 비용이 없음) 매우 기본적인 서버를 사용하기 때문에 이런 현상이 발생합니다.

실제 생활을 시뮬레이션할 시간입니다.

다른 네트워크 조건을 탐색 매우 느린 서버 먼저 서버를보다 현실적으로 만들어 보자. 이제 첫 번째 "파란색"단계는 약 50 밀리 초이며, 그 중 40 밀리 초가 기다리고 있습니다.

실생활에서 서버는 특정 작업을 수행하고, 권한을 확인하고, 특정 컨텐츠를 생성하며, 권한을 다시 확인합니다 (남은 코드가 많고 수표가 세 번 손실되기 때문에). 매우 바쁘다.

backend/index.ts 파일 ( https://www.php.cn/link/def14e8541708294d7558fdf2126ef27). 주석을 찾으십시오 > // 잠자기 (500)를 기다리고 주석을 취소하십시오. 이렇게하면 HTML을 반환하기 전에 서버가 500 밀리 초 지연됩니다. 이는 오래된 복잡한 서버에게 합리적으로 보입니다.

프로젝트 (NPM 실행 빌드)를 다시 구성하고 다시 시작하고 (NPM 실행 시작) 성능 레코드를 다시 연결하십시오.

초기 파란색 선을 제외하고 나머지와 비교 한 타임 라인에는 변경 사항이 없습니다. 이제는 매우 길다.

이 상황은 성능 최적화를 수행하기 전에 글로벌을 확인하고 병목 현상을 식별하는 것의 중요성을 강조합니다. LCP 값은 약 650 밀리 초이며, 그 중 약 560 밀리 초가 초기 HTML을 기다리는 데 사용됩니다. 반응 부분은 약 50 밀리 초입니다. 그것을 줄이고 25 밀리 초로 줄이려면 전체 상황에서는 4%에 불과합니다. 그것의 감소는 많은 노력이 필요합니다. 보다 효과적인 전략은 서버에 집중하고 왜 그렇게 느린 지 알아내는 것입니다.

다른 대역폭을 시뮬레이션하고 지연

모든 사람이 1 기가비트 연결의 세계에 사는 것은 아닙니다. 예를 들어, 호주에서는 50 조/초가 높은 속도의 인터넷 연결 중 하나이며 한 달에 약 90 달러를 소비하게됩니다. 물론, 그것은 3G가 아니며 전 세계의 많은 사람들이 갇혀 있습니다. 그러나 여전히 유럽인의 1 기가비트 1/초 또는 10 유로 인터넷 계획을들을 때마다 울 것입니다.

어쨌든. 이 불쾌한 호주 인터넷을 시뮬레이션하고 성능 지표에서 어떤 일이 발생하는지 살펴 보겠습니다. 이를 위해 성능 탭에서 기존 레코드를 지우십시오 (재 장전 및 레코드 버튼 근처 버튼). 네트워크 설정 패널을 표시해야합니다 Chrome 버전에 표시되지 않으면 "네트워크"탭에서 동일한 설정을 사용할 수 있어야합니다. "네트워크"드롭 다운 메뉴에 새 구성 파일을 추가하고 다음 숫자를 사용하십시오.

• 프로필 이름: "평균 인터넷 대역폭"
• 다운로드: 50000(50Mbps)
• 업로드: 15000(15Mbps)
• 지연 시간: 40(일반 인터넷 연결의 평균)

이제 드롭다운 메뉴에서 프로필을 선택하고 공연 녹화를 다시 실행하세요.

무엇을 보셨나요? 나에게는 이렇게 보입니다.

LCP 값은 거의 변경되지 않았습니다. 640ms에서 700ms로 약간 증가했습니다. 설명할 수 있는 초기 파란색 "서버" 섹션에는 변경 사항이 없습니다. 가장 기본적인 HTML만 전송하므로 다운로드하는 데 시간이 오래 걸리지 않습니다.

그러나 다운로드 가능한 리소스와 메인 스레드 간의 관계는 극적으로 변했습니다.

이제 렌더링 차단 CSS 파일의 영향을 확실히 볼 수 있습니다. "HTML 구문 분석" 작업이 완료되었지만 브라우저는 유휴 상태이며 CSS를 기다리고 있습니다. 다운로드될 때까지 아무것도 그릴 수 없습니다. 브라우저가 HTML을 구문 분석하는 동안 리소스가 거의 즉시 다운로드되었던 이전 이미지와 비교해 보세요.

이후에는 기술적으로 브라우저가 뭔가를 그릴 수도 있었지만 아무 것도 없고 HTML 파일에 빈 div만 전송되었습니다. 따라서 브라우저는 자바스크립트 파일이 다운로드되어 실행될 때까지 계속 대기합니다.

이 ~60ms의 대기 간격은 바로 LCP의 증가로 보이는 것입니다.

속도를 더 줄여서 어떻게 진행되는지 확인하세요. 새 네트워크 프로필을 만들고 이름을 "낮은 인터넷 대역폭"으로 지정한 다음 "낮은 인터넷 대역폭" 프로필에서 다운로드/업로드 번호를 복사하고 지연 시간을 40밀리초로 설정합니다.

그리고 다시 테스트를 실행해 보세요.

LCP 값이 이제 거의 500ms로 증가했습니다. JavaScript 다운로드에는 약 300밀리초가 소요됩니다. 상대적으로 말하면 "HTML 구문 분석" 작업과 JavaScript 실행 작업의 중요성이 줄어들고 있습니다.

추가 연습

자신만의 프로젝트가 있다면 이 테스트를 실행해 보세요.

모든 주요 경로 리소스를 다운로드하는 데 얼마나 걸립니까?
• 모든 JavaScript 파일을 다운로드하는 데 얼마나 걸립니까?
"Parsing HTML"작업 후 다운로드는 얼마입니까?
• 메인 스레드에서 "HTML 분석"의 리소스 다운로드 및 리소스 다운로드를위한 JavaScript는 얼마입니까?
LCP 지수에 어떤 영향을 미칩니 까?
리소스 바에서 일어난 일도 매우 흥미 롭습니다. 옐로우 자바 스크립트 막대에 마우스를 걸십시오. 이 내용을 거기에서 볼 수 있어야합니다.
가장 흥미로운 부분은 "요청 보내기 및 대기"입니다. 약 40 밀리 초가 소요됩니다. 나머지 네트워크 리소스에 마우스를 걸어 다니면서 모두가 있습니다. 이것이 우리의 대기 시간입니다. 우리는 네트워크 지연을 40으로 설정합니다. 많은 것들이 지연 숫자에 영향을 미칩니다. 네트워크 연결 유형은 그 중 하나입니다. 예를 들어, 평균 3G 연결 대역폭은 10/1 mbps이며 100 ~ 300 밀리 초 사이로 지연됩니다.
• 이를 시뮬레이션하려면 새 네트워크 구성 파일을 작성하고 "평균 3G"이름을 지정하고 "낮은 인터넷 대역폭"구성 파일에서 다운로드/업로드 번호를 복사 한 다음 지연을 300 밀리 초로 설정하십시오.

다시 실행하십시오. 모든 네트워크 리소스의 "요청 및 대기"는 약 300 밀리 초로 늘려야합니다. 이것은 또한 lcp

숫자를 촉진 할 것입니다.

지금은 흥미로운 부분입니다. 대역폭을 초고속 속도로 복원하지만 낮은 지연을 유지하면 어떻게 될까요? 이 설정을 시도해 봅시다 :

다운로드

: 1000 mbps 업로드

: 100 mbps 지연 : 300 밀리 초

서버가 노르웨이 어딘가에 있고 고객이 호주인이 풍부하다면, 이런 일이 쉽습니다.

이것은 결과입니다 : lcp 숫자는 약 입니다. 우리가 전에 시도한 인터넷에서 가장 느린 것보다 나쁩니다! 이 경우 번들 패키지의 크기는 중요하지 않으며 CSS의 크기는 전혀 중요하지 않습니다. 두 가지를 모두 마이너스하더라도 LCP 표시기는 거의 움직이지 않습니다. 높은 지연은 모든 것보다 낫습니다. 이것은 아직 달성하지 않은 경우 모든 사람이 달성 해야하는 첫 번째 성능 개선을 상기시켜줍니다. "CDN을 통해 서비스를 제공하기 위해 정적 자원

항상

보장"이라고합니다.

cdn 의 중요성 CDN (Content Distribution Network)은 기본적으로 전면 엔드 성능 작업의 0 번째 단계이며 심지어 더 멋진 것들 (예 : 코드 세분화 또는 서버 구성 요소)을 고려하기 전에도됩니다.

모든 CDN (Content Distribution Network)의 주요 목적은 지연을 줄이고 가능한 빨리 최종 사용자에게 컨텐츠를 전달하는 것입니다. 그들은 이것을 위해 다양한 전략을 구현했습니다. 이 기사에서 가장 중요한 두 가지는 "분산 서버"와 "캐시"입니다.

CDN 제공업체는 다양한 지리적 위치에 여러 서버를 보유합니다. 이러한 서버는 정적 리소스의 복사본을 저장하고 브라우저가 요청할 때 이를 사용자에게 보낼 수 있습니다. CDN은 기본적으로 원본 서버 주변의 소프트 레이어로, 외부 영향으로부터 서버를 보호하고 외부 세계와의 상호 작용을 최소화합니다. 실제 사람을 참여시키지 않고도 일반적인 대화를 처리할 수 있는 내성적인 사람들을 위한 AI 비서와 같습니다.

위의 예에서 서버는 노르웨이에 있고 클라이언트는 호주에 있으며 다음과 같은 이미지가 있습니다.

CDN을 중간에 두고 이미지가 달라집니다. CDN은 예를 들어 호주 어딘가에 사용자와 더 가까운 서버를 보유하게 됩니다. 어느 시점에서 CDN은 원본 서버로부터 정적 리소스의 복사본을 받게 됩니다. 호주 또는 인근 지역의 사용자는 노르웨이 서버의 원본 대신 이러한 복사본을 받게 됩니다.

두 가지 중요한 목표를 달성합니다. 첫째, 사용자가 더 이상 직접 접속할 필요가 없기 때문에 원본 서버의 부하가 줄어듭니다. 둘째, 이제 사용자는 일부 JavaScript 파일을 다운로드하기 위해 바다를 건너지 않아도 되므로 이러한 리소스를 더 빠르게 얻을 수 있습니다.

그리고 위 시뮬레이션의 LCP 값은 960ms에서 640ms로 떨어졌습니다.

반복 접속 성능

지금까지는 최초 방문 성능, 즉 사이트를 방문한 적이 없는 사람들을 위한 성능에 대해서만 논의했습니다. 하지만 사이트가 너무 좋아서 대부분의 처음 방문자가 일반 방문자가 되기를 바랍니다. 아니면 최소한 첫 번째 로드 후에 떠나지 않고 몇 페이지를 탐색하고 무언가를 구매할 수도 있습니다. 이 경우 일반적으로 브라우저는 정적 리소스(CSS 및 JS 등)를 캐시할 것으로 예상합니다. 즉, 리소스를 항상 다운로드하는 대신 로컬에 복사본을 저장합니다.

이 경우 성능 그래프와 수치가 어떻게 변하는지 살펴보겠습니다.

학습 프로젝트를 다시 엽니다. 개발 도구에서 네트워크를 이전에 생성한 "평균 3G"로 설정합니다. 대기 시간은 길고 대역폭은 낮으므로 차이를 즉시 확인할 수 있습니다. 그리고 "네트워크 캐시 비활성화" 확인란이 선택 해제되어 있는지 확인하세요.

먼저 브라우저를 새로 고쳐 최초 방문자를 제거하세요. 그런 다음 성능을 새로 고치고 측정합니다.

학습 프로젝트를 사용하는 경우 최종 결과는 다음과 같으므로 다소 놀랄 수 있습니다.

CSS 및 JavaScript 파일은 여전히 ​​네트워크 탭에서 매우 눈에 띄며 "요청 보내기 및 대기"("평균 3G" 프로필에서 설정한 대기 시간 설정)에서 약 300ms로 표시됩니다. 결과적으로 LCP는 가능한 한 낮지 않으며 브라우저가 CSS 차단을 기다리는 동안 300ms의 간격이 있습니다.

무슨 일이 일어났나요? 브라우저가 이 항목을 캐시하면 안 되나요?

Cache-Control 헤더를 사용하여 브라우저 캐시 제어

이제 무슨 일이 일어나고 있는지 이해하기 위해 네트워크 패널을 사용해야 합니다. 그것을 열고 거기에서 CSS 파일을 찾으십시오. 다음과 같아야 합니다.

여기서 가장 흥미로운 점은 '상태' 열과 '크기'입니다. "크기"에서는 전체 CSS 파일의 크기가 아닙니다. 너무 작습니다. "상태"에서는 일반적인 200 "모든 것이 괜찮습니다" 상태가 아니라 뭔가 다른 304 상태입니다.

여기서 두 가지 질문이 있습니다. 200이 아닌 304인 이유와 요청이 전송된 이유는 무엇입니까? 캐싱이 작동하지 않는 이유는 무엇입니까?

먼저 304 응답입니다. 이는 잘 구성된 서버가 조건부 요청에 대해 보내는 응답입니다. 여기서 응답은 다양한 규칙에 따라 변경됩니다. 이러한 요청은 브라우저 캐시를 제어하는 ​​데 자주 사용됩니다.

예를 들어 서버가 CSS 파일에 대한 요청을 받으면 파일이 마지막으로 수정된 시간을 확인할 수 있습니다. 이 날짜가 브라우저 측 캐시 파일의 날짜와 동일한 경우 본문이 비어 있는 304를 반환합니다(그래서 223B만 반환됩니다). 이는 브라우저가 이미 소유한 파일을 안전하게 재사용할 수 있음을 의미합니다. 대역폭을 낭비하고 다시 다운로드할 필요가 없습니다.

이것이 성능 사진에서 큰 "요청 보내기 및 대기" 숫자를 보는 이유입니다. 브라우저는 CSS 파일이 여전히 최신인지 확인하기 위해 서버에 요청하고 있습니다. 이것이 "콘텐츠 다운로드"가 0.33ms인 이유입니다. 서버는 "304 Unmodified"를 반환하고 브라우저는 이전에 다운로드한 파일을 재사용합니다.

추가 연습

1. 학습 프로젝트에서 dist/assets 폴더로 이동하여 CSS 파일 이름을 변경하세요
2. dist/index.html 파일로 이동하여 이름이 바뀐 CSS 파일의 경로를 업데이트하세요
3. 열린 페이지를 새로 고치고 네트워크 탭을 열면 CSS 파일이 새 이름, 200 상태 및 올바른 크기로 표시됩니다. 해당 파일은 다시 다운로드되었습니다. 이를 "캐시 무효화"라고 합니다. 이는 브라우저가 캐시했을 수 있는 리소스를 강제로 다시 다운로드하도록 하는 방법입니다.
4. 페이지를 다시 새로고침했습니다. 304 상태로 돌아가고 캐시된 파일을 재사용했습니다.

이제 두 번째 질문 - 이 요청이 전송된 이유는 무엇인가요?

이 동작은 서버가 응답으로 설정하는 Cache-Control 헤더에 의해 제어됩니다. 요청/응답 세부 정보를 보려면 네트워크 패널에서 CSS 파일을 클릭하세요. "헤더" 탭의 "응답 헤더" 블록에서 "Cache-Control" 값을 찾습니다.

이 헤더에서는 다른 조합이있는 쉼표로 분리 할 수 ​​있습니다. 이 예에는 두 가지가 있습니다 max -age 숫자가있는 길이는 얼마나 길게 제어 하는지이 특정 응답은 (초) 저장됩니다. -반응이 만료되면 항상 신선한 버전의 요청을 서버에 보냅니다. 응답이 최대 연령 값보다 더 많은 캐시에 존재하면 응답이 만료됩니다.

따라서 기본적으로 헤더는 브라우저를 알려줍니다
• 캐시 에이 응답을 저장할 수 있지만 잠시 후에 다시 확인해야합니다. 그건 그렇고, 캐시 시간을 정확히 zero
두 번째로 유지할 수 있습니다. 행운을 빌어요.
• 결과적으로 브라우저는 항상 서버로 확인하고 즉시 캐시를 사용하지 마십시오. 그러나 그러나 우리는 이것을 쉽게 변경할 수 있습니다 -우리는 최대 숫자를 0에서 31536000 (1 년, 최대 초)로만 변경하면됩니다. 이를 위해 학습 프로젝트에서 백엔드/index.ts 파일로 전송하고 최대 age = 0을 설정하고 31536000 (1 년)으로 변경하십시오. 페이지를 여러 번 새로 고침하면 "네트워크"탭에서 CSS 파일의 다음 내용이 표시됩니다.
"상태"열은 이제 "size"(메모리 캐시)에 회색이되었습니다. CSS 파일은 이제 브라우저의 캐시에서 서비스를 제공하며 항상 1 년 안에 해당됩니다. 페이지를 여러 번 새로 고치려면 변경하지 않습니다.

이제 캐시 헤더 처리의 모든 주요 지점에 대해서는 페이지의 성능을 다시 측정하겠습니다. "평균 3G"구성 파일 설정을 설정하는 것을 잊지 말고 "캐시 비활성화"설정을 유지하십시오.

결과는 다음과 비슷해야합니다

지연이 높지만 "보내기 요청 및 대기"섹션은 "HTML의 분석"과 JavaScript 평가 사이의 간격이 거의 사라지고 LCP 값은 ~ 650 밀리 초로 돌아갑니다.

추가 연습

1. max-age 값을 10(10초)으로 변경
2. 캐시를 삭제하려면 '캐시 비활성화' 확인란을 선택하고 페이지를 새로 고치세요.
3. 확인란을 선택 취소하고 페이지를 다시 새로고침하세요. 이번에는 메모리 캐시에서 제공되어야 합니다.
4. 10초 정도 기다린 후 페이지를 다시 새로고침하세요. max-age는 10초에 불과하므로 브라우저는 리소스를 다시 확인하고 서버는 304를 다시 반환합니다.
5. 지금 페이지를 새로 고치세요. 메모리에서 다시 제공되어야 합니다.

캐시 제어 및 최신 번들링 도구

위 정보는 캐싱이 성능 만병통치약이며 모든 것을 최대한 적극적으로 캐시해야 한다는 것을 의미합니까? 절대 그렇지 않습니다! 무엇보다도, "기술에 정통하지 않은 고객"과 "브라우저 캐시를 지우는 방법을 전화로 설명해야 하는" 조합을 만들 가능성은 최고 수준의 개발자라도 공황 발작을 일으킬 수 있습니다.

캐싱을 최적화하는 방법은 수백만 가지가 있으며, 캐시 기간에 영향을 줄 수도 있고 그렇지 않을 수도 있는 다른 헤더와 함께 Cache-Control 헤더의 지시어 조합이 서버 구현에 따라 달라질 수도 있고 그렇지 않을 수도 있는 수백만 가지가 있습니다. 아마도 이 주제에 대해서만 여러 권의 책을 쓸 수 있을 것입니다. 캐싱 전문가가 되고 싶다면 https://web.dev/ 및 MDN 리소스의 기사부터 시작하여 탐색경로를 따르십시오.

안타깝게도 "여기에 모든 것에 대한 5가지 최고의 캐싱 전략이 있습니다."라고 말할 수 있는 사람은 없습니다. 기껏해야 대답은 다음과 같습니다. "이것, 이것, 이것과 결합된 이 사용 사례가 있다면 이 캐시 설정 조합은 좋은 선택이지만 이러한 문제에 유의하십시오." 모든 것은 리소스, 빌드 시스템, 리소스가 얼마나 자주 변경되는지, 캐시가 얼마나 안전한지, 잘못된 작업의 결과를 이해하는 것으로 귀결됩니다.

단, 한 가지 예외가 있습니다. 명확한 "모범 사례"가 있는 한 가지 예외는 최신 도구를 사용하여 구축된 웹 사이트용 JavaScript 및 CSS 파일입니다. Vite, Rollup, Webpack 등과 같은 최신 패키징 도구는 "불변" JS 및 CSS 파일을 생성할 수 있습니다. 물론 그것들은 실제로 "불변"하지는 않습니다. 그러나 이러한 도구는 파일 내용에 따라 달라지는 해시 문자열을 사용하여 파일 이름을 생성합니다. 파일 내용이 변경되면 해시도 변경되고 파일 이름도 변경됩니다. 결과적으로 웹 사이트가 배포되면 브라우저는 캐시 설정에 관계없이 파일의 새로운 복사본을 다시 가져옵니다. 이전에 CSS 파일의 이름을 수동으로 바꿨을 때와 마찬가지로 캐시가 "삭제"됩니다.

예를 들어 학습 프로젝트의 dist/assets 폴더를 살펴보세요. JS 및 CSS 파일에는 index-[hash] 파일 이름이 있습니다. 이 이름을 기억하고 npm run build를 몇 번 실행하세요. 이러한 파일의 내용은 변경되지 않았으므로 이름은 동일하게 유지됩니다.

이제 src/App.tsx 파일로 이동하여 console.log('bla') 같은 항목을 어딘가에 추가하세요. npm run build를 다시 실행하고 생성된 파일을 확인하세요. CSS 파일 이름은 동일하게 유지되지만 JS 파일 이름은 변경된 것을 볼 수 있습니다. 이 웹 사이트가 배포되면 다음에 반복 사용자가 이 웹 사이트를 방문할 때 브라우저는 캐시에 전혀 나타나지 않는 완전히 다른 JS 파일을 요청합니다. 캐시가 지워졌습니다.

추가 운동 프로젝트의 디자인 폴더의 동등성을 찾고 구성 명령을 실행하십시오.

파일 이름은 무엇입니까? HASH와 유사하거나 일반 index.js, index.css 등입니까?

명령을 다시 실행하면 파일 이름이 변경됩니까?

코드에서 특정 위치를 간단하게 변경하면 몇 개의 파일 이름이 변경됩니까?
건설 시스템이 구성된 경우 -운이 좋다. 서버를 안전하게 구성하여 최대 최대 연령 헤더를 설정하여 자산을 생성 할 수 있습니다. 모든 이미지를 제어하면 이미지를 목록에 포함시킬 수도 있습니다.
• 웹 사이트 및 사용자 및 해당 행동에 따르면, 이는 초기 로딩에 대한 매우 우수한 성능 향상을 제공 할 수 있습니다.
내 간단한 사례는이 모든 것을 모두 알아야합니까?
• 현재, 당신은 그런 것들에 대해 생각하고있을 것입니다. "당신은 미쳤습니다. 나는 주말에 Next.js와 함께 간단한 웹 사이트를 만들어 2 분 이내에 Vercel/netlify/HottestNewProvider에 배포했습니다. 물론,이 현대식. 도구는이 모든 것을 처리합니다. "이것은 공정합니다. 나도 그렇게 생각합니다. 그러나 나는 그것을 실제로 확인했다, 와우, 나는 놀랐다 내 두 항목은 CSS 및 JS 파일에 대해 최대 age = 0이고 꼭 봐야합니다. 이것은 내 CDN 제공 업체의 기본 설정입니다. 물론, 그들은 에 대한 이유가 있습니다

위 내용은 React 개발자의 초기 부하 성능 : 조사 깊은 다이빙의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!