사이트 성능은 잠재적으로 가장 중요한 메트릭입니다. 성능이 좋을수록 사용자가 페이지에 머무르거나 콘텐츠를 읽거나 구매하거나 필요한 모든 일에 대한 가능성이 높아집니다. Akamai의 2017 년 연구에 따르면 페이지 부하가 100ms 지연조차도 전환이 7% 감소하고 100ms마다 판매량의 1%를 잃을 수 있다고 밝혔다. 2018 년의 Google의 업계 벤치 마크는 또한 매 초의 적재량이 이탈률에 어떤 영향을 미치는지에 대한 놀라운 고장을 제공합니다.
반면에 Firefox는 웹 페이지를 평균 2.2 초 더 빠르게로드했으며 연간 6 천만 개의 Firefox 다운로드를 주도했습니다. 속도는 또한 모바일에서 웹 사이트 배치 순위를 매길 때 Google이 고려하는 것입니다. 사이트가 느리면 다른 메트릭에 관계없이 검색 결과 452 페이지에 남을 수 있습니다.
이 모든 것을 염두에두고 느린 사이트의 내 버전의 속도를 향상시키는 것은 재미있는 운동이라고 생각했습니다. 사이트의 코드는 GitHub에서 참조 할 수 있습니다.
이것은 간단한 HTML, CSS 및 JavaScript로 만든 매우 기본 사이트입니다. 나는 의도적으로 이것을 가능한 한 단순하게 유지하려고 노력했는데, 이는 느린 이유가 사이트 자체의 복잡성과 관련이 없거나 사용하는 일부 프레임 워크와 관련이 없습니다. 가장 복잡한 부분은 사람들이 페이지를 공유 할 수있는 소셜 미디어 버튼입니다.
다음은 다음과 같습니다. 성능은 일회성 작업 이상입니다. 그것은 본질적으로 우리가 구축하고 개발하는 모든 것과 관련이 있습니다. 따라서 모든 것을 한 번에 해결하려는 유혹이 있지만 성능 향상을위한 최선의 접근 방식은 반복적 인 것일 수 있습니다. 매달린 과일이 있는지 확인하고 더 크거나 장기적인 노력이 무엇인지 파악하십시오. 다시 말해, 점진적인 개선은 성능을 얻는 좋은 방법입니다. 다시 한번, 모든 밀리 초 카운트.
그 정신으로, 우리 가이 기사에서보고있는 것은 점진적인 승리에 더 중점을두고 있으며, 완전한 목록이나 성과 전략의 점검 목록을 제공하는 데 덜 집중됩니다.
우리는 등대와 함께 일할 것입니다. 많은 사람들이 이미 그것에 익숙 할 수 있습니다. CSS- 트릭에서 바로 여기에서 다루어졌습니다. 성능, 접근성, SEO 및 모범 사례를 감사하는 것은 Google 서비스입니다. 이 기사에서 우리가 다루는 것들 전후에 느린 사이트의 성능을 감사 할 것입니다. Lighthouse 보고서는 Chrome의 DevTools에서 직접 액세스 할 수 있습니다.
Lighthouse가 웹 사이트에 잘못되었다고 말한 것을 간단히 살펴보십시오. 바로 다이빙하기 전에 무엇을 해결 해야하는지 아는 것이 좋습니다.
우리는 이것을 완전히 고칠 수 있으므로 시작합시다!
우리가 다른 일을하기 전에 처음 웹 사이트를 방문했을 때 어떤 일이 일어나는지 보자. 리디렉션됩니다. 이 사이트는 한 URL에 있었고 이제는 다른 URL에 살고 있습니다. 즉, 이전 URL이 새 URL로 리디렉션되는 링크가 의미합니다.
리디렉션은 종종 웹 사이트에 추가하는 대기 시간 측면에서 꽤 가벼우지만 확인하기가 가장 쉬운 일이며 일반적으로 거의 노력하지 않고 제거 할 수 있습니다.
우리는 사이트의 이전 URL을 사용하는 곳을 업데이트하여 제거하고 업데이트 된 URL을 지적하여 사용자를 리디렉션 대신 직접 가져 오도록 시도 할 수 있습니다. 네트워크 요청 검사관을 사용하여 DevTools의 네트워크 패널을 통해 제거 할 수있는 것이 있는지 확인하겠습니다. 우리는 또한 Postman과 같은 도구를 사용할 수 있지만 단순성을 위해 작업을 가능한 한 DevTools로 제한 할 것입니다.
먼저 HTTP 또는 HTML 리디렉션이 있는지 살펴 보겠습니다. 나는 Fiddler를 사용하는 것을 좋아하고 네트워크 요청을 검사 할 때 실제로 유래 한 URL과 리디렉션이 떠 다니는 것을 알 수 있습니다.
나는 최근에 Anonrobot 에서 Kealanparr 로의 github의 이름을 바꿨으므로 도메인 이름을 제외한 모든 것이 동일합니다.
html이 https://anonrobot.github.io/slow-site/로 리디렉션하기 전에 https://anonrobot.github.io/redirect-to-slow-site/입니다. 모든 리디렉션-슬로우 사이트 URL을 업데이트 된 URL로 다시 포괄 할 수 있습니다. DevTools에서 네트워크 검사관은 첫 번째 웹 페이지가 무엇을하고 있는지 볼 수 있도록 도와줍니다. 피들러의 내 견해에서 그것은 다음과 같습니다.
이것은 사이트가 HTML 리디렉션을 다음 사이트로 리디렉션하고 있음을 알려줍니다. 초기 페이지로드에 드래그를 추가하는 대기 시간을 줄이기 위해 참조 된 URL을 새 사이트로 업데이트 할 것입니다.
다음으로 DevTools의 성능 패널과 함께 SIT를 프로파일 링하겠습니다. 나는 사이트가 컨텐츠를 최대한 빨리 렌더링하여 사이트를 차단 해제하는 데 가장 관심이 있습니다. 이것은 HTML, CSS 및 JavaScript를 완전히 대단한 대화식 웹 사이트로 전환하는 과정입니다.
서버에서 HTML을 검색하고이를 문서 개체 모델 (DOM)으로 변환하는 것으로 시작합니다. 우리는 인라인 JavaScript를 볼 수 있듯이 모든 인라인 JavaScript를 실행하거나 HTML을 구문 분석 할 때 외부 자산 인 경우 다운로드합니다. 또한 CSS를 CSS 객체 모델 (CSSOM)으로 구축하겠습니다. CSSOM과 DOM은 결합하여 렌더 트리를 만듭니다. 거기에서 우리는 페인트를 마침내 실행하기 전에 화면의 모든 것을 올바른 위치에 놓는 레이아웃을 실행합니다.
이 프로세스는 실행되기 전에 리소스를로드 할 때까지 기다려야하는 경우 "차단"할 수 있습니다. 그것이 우리가 중요한 렌더링 경로 라고 부르는 것이며, 경로를 차단하는 것은 중요한 자원 입니다.
가장 일반적인 중요한 자원은 다음과 같습니다.
글꼴과 같이 중요한 렌더링 경로를 차단할 수있는 몇 가지 유형의 리소스가 있지만 위의 두 가지가 가장 일반적입니다. 브라우저가 페이지가 "미완성"이라고 생각하고 어떤 자원이 필요한지 또는 가지고 있는지 전혀 모른다. 브라우저가 알고있는 모든 브라우저에 대해 사이트는 브라우저가 스타일링이나 색상 변경과 같이 더 많은 작업을 수행 할 것으로 기대하는 것을 다운로드 할 수 있습니다. 따라서 사이트는 브라우저에 불완전하므로 최악의 것으로 가정하고 렌더링을 차단합니다.
렌더링을 차단하지 않는 예제 CSS 파일은 다음과 같습니다.
<link href="printing.css" rel="Stylesheet" media="print">
"media ="print "속성은 사용자가 웹 페이지를 인쇄 할 때 스타일 만 다운로드합니다 (아마도 인쇄물에서 다르게 스타일을 지정하기 때문에).
Chris가 좋아하는 것처럼 프론트 엔드 개발자가 알고 있습니다. 렌더링 시작 전에 페이지가 다운로드 해야하는 것을 알고 성능 감사 점수를 향상시키는 데 매우 중요합니다.
렌더 경로를 차단하는 것은 즉시 속도를 높일 수있는 한 가지이며, JavaScript에주의를 기울이지 않으면 구문 분석을 차단할 수도 있습니다. 구문 분석은 HTML 요소를 DOM의 일부로 만드는 이유이며, 지금 실행 해야하는 JavaScript를 만날 때마다 HTML 구문 분석이 발생하지 않도록 차단합니다.
느린 웹 페이지의 JavaScript 중 일부는 구문 분석을 차단할 필요가 없습니다. 다시 말해, 스크립트를 비동기로 다운로드하고 지연없이 HTML을 DOM으로 계속 구문 분석 할 수 있습니다.
여기에는 javaScript를 수감하는 것 (실행 중 네트워크 요청이 필요하지 않음)과 자체 JavaScript 파일 (모듈성 및 코드 리용)에 배치하는 것 사이에 트레이드 오프가 있습니다. 최상의 경로가 사용 사례에 따라 다르기 때문에 여기에서 자신의 판단을 자유롭게 요청하십시오. CSS 및 JavaScript를 웹 페이지에 적용하는 실제 성능은 외부 자산이든 상관 관계없이 동일합니다. 우리가 인라인시 할 때 제거하는 유일한 것은 외부 자산을 얻기위한 네트워크 요청 시간입니다 (때로는 큰 차이를 만듭니다).
우리가 목표로하는 가장 중요한 것은 우리가 할 수있는 한 적은 일을하는 것입니다. 로딩 자산을 연기하고 동시에 자산을 최대한 작게 만들고 싶습니다. 이 모든 것이 더 나은 성능 결과로 해석됩니다.
내 느린 사이트는 브라우저가 다음 html의 다음 줄을 읽고 기다려야하는 다음 다른 자산을 확인한 다음 기다린 다음 기다려야하는 여러 중요한 요청을 연쇄하고 있습니다. 자산의 크기, 다운로드시킬 때, 블록이 모두 웹 페이지로드가 얼마나 빨리로드 될 수 있는지에 대해 크게 재생 될 것입니다.
나는 DevTools Performance 패널에서 사이트를 프로파일 링하여 이것에 접근했습니다. 이것은 단순히 시간이 지남에 따라 사이트가로드되는 방식을 기록합니다. HTML과 다운로드 한 내용을 간단히 스캔 한 다음 물건을 차단하는 외부 JavaScript 스크립트에
Chrome은 도메인 이름 당 6 개의 인내 HTTP 연결 만 처리 할 수있는 브라우저 제한이 있다는 것이 흥미 롭습니다. 6 개의 기내가 시작되면 다른 사람을 요청하기 전에 자산이 반환 될 때까지 기다릴 것입니다. 이로 인해 HTML 파싱에 대해 여러 임계 자산을 더 악화시킵니다. 브라우저가 구문 분석을 계속할 수있게하면 사용자에게 무언가를 보여주고 성능 감사를 향상시키는 데 걸리는 시간의 속도가 빨라집니다.
사이트의 총 크기는 얼마나 빨리로드 될지에 대한 큰 결정 요인입니다. Web.dev에 따르면, 사이트는 10 초 이내에 1,600kb의 대화식 이하인 것을 목표로해야합니다. 큰 페이로드는 장시간로드하는 데 크게 상관됩니다. 대규모 다운로드에는 더 많은 비용이 드는 더 큰 데이터 요금제가 필요할 수 있으므로 최종 사용자에게 큰 페이로드를 고려할 수도 있습니다.
이 정확한 시점에서, 나의 느린 사이트는 무려 9,701 kb이며, 이상적인 크기의 6 배 이상입니다. 그것을 다듬겠습니다.
개발이 시작될 때 특정 자산이나 프레임 워크가 필요할 수 있다고 생각했습니다. 나는 내 페이지에 그것들을 다운로드했고 이제 실제로 어떤 것이 사용되는지를 기억조차 할 수 없습니다. 나는 분명히 시간과 공간을 낭비하는 것 외에는 아무것도하지 않는 자산이 있습니다.
DevTools의 네트워크 검사관 (또는 편안한 도구)을 사용하여 기본 행동을 변경하지 않고 사이트에서 분명히 제거 할 수있는 몇 가지 사항을 볼 수 있습니다. DevTools의 적용 범위 패널에서 모든 것이 다운로드 된 후 얼마나 많은 코드가 사용되는지를 보여주기 때문에 많은 가치를 발견했습니다.
우리가 이미 논의했듯이 CSS 및 JavaScript와 외부 자산을 사용하는 것과 관련하여 항상 균형이 잘 맞습니다. 그러나 바로이 순간, 사이트가 실제로 필요한 것보다 너무 많이 다운로드하는 것으로 보입니다.
물건을 다듬는 또 다른 빠른 방법은 사이트의 자산이 404를로드하려고하는지 여부를 찾는 것입니다. 이러한 요청은 어쨌든로드하지 않기 때문에 사이트에 부정적인 영향을 미치지 않으면 서 분명히 제거 될 수 있습니다. Fiddler가 나에게 보여주는 것은 다음과 같습니다.
적용 범위 보고서를 다시 살펴보면 다운로드되었지만 사용되지 않은 코드가 여전히 많다는 것을 알고 있습니다. 다시 말해, 이러한 자산은 무언가를하고 있지만, 우리가 할 필요가없는 일을 할 준비가되어 있습니다. 여기에는 React, JQuery 및 Vue가 포함되므로 실제 영향없이 느린 사이트에서 제거 할 수 있습니다.
왜 그렇게 많은 JavaScript 라이브러리? 글쎄, 우리는 요구 사항을 충족하기 때문에 무언가에 도달 할 실제 시나리오가 있다는 것을 알고 있습니다. 그러나 그러한 요구 사항이 변경되면 다른 것에 도달해야합니다. 다시 말하지만, 우리는 프론트 엔드 개발자로 인식해야하며, 사이트와 관련된 리소스를 지속적으로 주시하는 것은 전반적인 인식의 일부입니다.
우리가 자산을 제공해야한다고해서 자산을 전체 크기로 사용하거나 다음에 사용자가 사이트를 방문 할 때 해당 자산을 다시 제공해야한다는 의미는 아닙니다. 우리는 자산을 압축하고 스타일과 스크립트를 미리 채우고 책임감있게 캐시 할 수 있으므로 사용자가 가장 효율적으로 필요한 작업을 제공 할 수 있습니다.
세 가지 유형의 자산과 이러한 전술로 그들을 위기를 일으키는 방법을 살펴 보겠습니다.
여기에는 HTML, CSS 및 JavaScript와 같은 텍스트 파일이 포함됩니다. 우리는 가능한 한 가볍게 만들기 위해 힘으로 모든 것을하고 싶어서 가능한 경우 압축, 미소화 및 캐시를 원합니다.
매우 높은 수준에서 GZIP는 컨텐츠에서 일반적이고 반복되는 부분을 찾아 이러한 시퀀스를 한 번 저장 한 다음 소스 텍스트에서 제거합니다. 사전과 같은 조회를 유지하므로 저장된 조각을 빠르게 참조하여 Gunzping으로 알려진 프로세스에서 소속 된 곳에 다시 배치 할 수 있습니다. 이 gziped 예제 시가 포함 된 파일을 확인하십시오.
우리는 텍스트 기반 다운로드를 최대한 작게 만들기 위해이 작업을 수행하고 있습니다. 우리는 이미 GZIP를 사용하고 있습니다. Gidnetwork 의이 도구를 사용하여 확인했습니다. 느린 사이트의 내용이 59.9% 압축되었음을 보여줍니다. 그것은 아마도 물건을 더 작게 만들 수있는 기회가 더 많다는 것을 의미합니다.
여러 CSS 파일을 Styles.css라는 하나의 단일 파일로 통합하기로 결정했습니다. 이렇게하면 필요한 네트워크 요청 수를 제한하고 있습니다. 게다가, 세 가지 파일을 열면 각 파일에는 세 가지 네트워크 요청이 단순히 정당화되지 않은 소량의 CSS가 포함되어 있습니다.
그리고이 작업을 수행하면서 DOM에 적용되지 않은 불필요한 CSS 선택기를 제거하여 사용자에게 전송 된 바이트의 수를 줄일 수있는 기회를 얻었습니다.
Ilya Grigorik은 텍스트 기반 자산을 압축하기위한 전략과 함께 훌륭한 기사를 썼습니다.
또한 느린 사이트에서 이미지를 최적화 할 수 있습니다. 보고서가 지속적으로 알 수 있듯이 이미지는 가장 일반적인 자산 요청입니다. 실제로 이미지의 중간 데이터 전송은 데스크탑의 경우 948.1 KB, 2016 년부터 2021 년까지 모바일 장치의 경우 902 KB입니다. 이미 전체 페이지로드에 이상적인 1,600KB 크기의 절반 이상입니다.
내 느린 사이트는 많은 이미지를 제공하지 않지만, 그것이 제공하는 이미지는 더 작을 수 있습니다. Squoosh라는 온라인 도구를 통해 이미지를 실행했으며 40% 절약 (18.6 KB ~ 11.2 KB)을 달성했습니다. 그것은 승리입니다! 물론 이것은 ImageOptim과 같은 데스크탑 응용 프로그램을 사용하여 업로드하기 전에 또는 빌드 프로세스의 일부로 할 수있는 일입니다.
원래 이미지와 최적화 된 버전 (훌륭합니다) 사이의 시각적 차이를 볼 수 없었으며 실제 파일을 크기를 조정하고 이미지의 품질을 줄이며 색상 팔레트를 변경하여 크기를 더 줄일 수있었습니다. 그러나 이것이 이미지 편집 소프트웨어에서 한 일입니다. 이상적으로, 그것은 처음에 자산을 만들 때 당신이나 디자이너가 할 일입니다.
우리는 미니 화와 압축, 그리고 우리가이를 활용하기 위해 노력할 수있는 일에 대해 다루었습니다. 우리가 확인할 수있는 마지막 것은 캐싱입니다.
나는 느린 사이트를 계속해서 요청해 왔으며 지금까지, 나는 그것이 캐싱없이 매번 신선한 요청을받는 것처럼 보일 수 있습니다. 나는 HTML을 살펴 보았고 캐싱이 여기에서 비활성화되는 것을 보았다.
<meta http-equiv="캐시 제어" content="no-cache, no-store, 꼭 봐야 할 반복">
나는 그 라인을 제거 했으므로 브라우저 캐싱이 이제 일어날 수있어서 콘텐츠를 더 빨리 제공 할 수 있어야합니다.
우리가 모든 웹 사이트에서 만들 수있는 또 다른 큰 개선은 CDN (Content Delivery Network)에서 최대한 많은 서비스를 제공하는 것입니다. David Attard는 CDN을 추가하고 활용하는 방법에 대한 매우 철저한 부분을 가지고 있습니다. 컨텐츠 제공의 전통적인 경로는 서버를 치고 데이터를 요청하며 반환을 기다리는 것입니다. 그러나 사용자가 데이터가 제공되는 곳에서 전 세계의 다른 쪽에서 데이터를 요청하는 경우 시간이 추가됩니다. 바이트가 서버로부터 응답으로 더 많이 이동하면 다른 모든 것이 번개가 되더라도 속도 손실이 크게 추가 될 수 있습니다.
CDN은 전 세계의 분산 서버 세트로, 서비스를 제공하기로 선택한 여러 위치가 있기 때문에 사용자에게 컨텐츠를 지능적으로 전달할 수 있습니다.
우리는 실제로 다운로드 된 코드를 사용하지 않을 때 사용자가 jQuery를 다운로드하는 방법에 대해 앞에서 논의했으며 제거했습니다. 실제로 jQuery가 필요한 경우 여기서 쉬운 수정 사항 중 하나는 CDN에서 자산을 요청하는 것입니다. 왜?
우리는 Google의 CDN에서 jQuery를 잡는 것만 큼 간단한 일을 할 수 있으며, 누구나 자신의 사이트에서 참조 할 수 있습니다.
<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"> </script>
그것은 내 서버의 표준 요청보다 jQuery가 훨씬 빠르게 제공됩니다.
지금까지 나와 함께 구현했거나 읽은 적이 있다면, 지금까지 우리가 한 일에 대한 개선이 이루어 졌는지 다시 비판 할 때입니다.
우리가 시작한 곳을 상기하십시오.
우리의 변화 후 :
이것이 도움이 되었기를 바랍니다. 귀하가 귀하의 사이트에서 점진적인 성능 승리를 검색하도록 권장합니다. 자산을 최적으로 요청함으로써 일부 자산을로드하여 일부 자산을 연기하고 사이트 크기의 전체 크기를 줄이면 가능한 한 빨리 사용자 앞에서 기능적이고 완전히 대화식 사이트가 얻을 수 있습니다.
대화를 계속하고 싶습니까? 더 많은 것을보고 싶거나 연결하고 싶다면 트위터에서 내 글을 공유합니다.
위 내용은 느린 사이트를 반복적으로 고정합니다의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
