최근에 나는 "고성능 웹 사이트의 건설에 대한 가이드"를 연구하고 있습니다. 이 기사는 연구 노트입니다. 나중에 쉽게 볼 수 있도록 배운 것을 정리하겠습니다.
Performance Golden Rule은 최종 사용자 응답 시간의 10% ~ 20%만이 요청 된 사용자 HTML 문서를 수락하는 데 소비되는 반면, 시간의 나머지 80% ~ 90%는 HTML 문서에서 언급 한 모든 구성 요소 (이미지, 스크립트, 스타일 시트 등)에 대한 HTTP 요청에 소비되며 최종 사용자 응답 시간은 페이지 구성 요소에 소비됩니다.
-스티브 사운 더
1 파일 병합 (HTTP 요청 수 감소)
CSS 스프라이트
CSS Sprites를 사용하여 웹 사이트에 사용 된 그림을 하나의 이미지로 병합하고 배경 위치, 너비 및 높이를 통해 아이콘을 사용하여 배경 이미지 위치를 제어하십시오. 이 방법은 여러 이미지 요청을 한 번 줄일 수 있습니다. CSS 스프라이트를 생성하는 도구가 많이 있습니다. Grunt 및 Gulp에는 관련 플러그인이 있으며 CSSGAGA도 좋습니다.
JS 및 CSS를 병합하십시오
스프라이트 맵과 마찬가지로 CSS 및 JS 파일 병합도 HTTP 요청을 줄이는 중요한 방법입니다. 현재 CSS 파일의 합병에 대한 논란은 없지만 JS 모듈 식의 현재 유병률에 대해서는 모든 JS 파일을 하나의 파일로 병합하는 것이 거꾸로 된 것 같습니다. 올바른 방법은 컴파일 된 언어 패턴을 준수하고, JS의 모듈성을 유지하며, 생성 프로세스 중 초기 요청에 사용 된 JS 파일에 대해서만 대상 파일을 생성하는 것입니다.
2 콘텐츠를 사용하여 네트워크를 게시합니다 (HTTP 요청 시간을 줄이십시오)
HTTP 요청 시간에 영향을 미치는 또 다른 요소는 웹 사이트 웹 서버와의 거리입니다. 분명히 거리가 길수록 요청이 더 길어 CDN을 통해 크게 향상 될 수 있습니다.
CDN은 여러 지리적 위치에 배포 된 웹 서버로, 사용자에게보다 효과적으로 컨텐츠를 게시하는 데 사용됩니다. CDN의 주요 기능은 최종 사용자를위한 정적 파일을 저장하고 다운로드, 보안 서비스 및 기타 기능도 제공하는 것입니다.
3 브라우저 캐시 설정 (중복 HTTP 요청을 피하십시오)
Expire/Cache-Control 사용
브라우저는 캐시를 사용하여 매번 반복 요청을 피할 수 있습니다. HTTP 1.0 및 HTTP 1.1에는 다른 캐시 구현 방법이 있으며 (1.0) 및 캐시 제어 (1.1)가 만료됩니다. 웹 서버는 만료를 사용하여 클라이언트에게 파일의 모든 캐시 된 사본이 지정된 시간 내에 사용되며 더 이상 서버에 반복적으로 요청하지 않음을 클라이언트에게 알립니다.
만료 : Thu, 2016 년 12 월 1 일 16:00:00 GMT (GMT 형식)
이 설정은 2016 년 12 월 1 일 현재 추가 요청없이 캐시 된 사본을 사용할 수 있음을 의미합니다.
Expires는 마감일을 전달하는 방법에 제한이 있습니다. 클라이언트와 서버 시계 간의 엄격한 동기화가 필요하지만 HTTP 1.1에 의해 도입 된 캐시 제어는 몇 초 만에 시간을 지정하여 캐시 날짜를 지정합니다.이 제한은 다음과 같습니다.
캐시 제어 : MAX-AGE = 31536000
이 설정은 캐시 시간이 1 년임을 의미하며 캐시 제어를 사용하는 것이 좋습니다. 그러나 HTTP 1.1이 지원되면 캐시 제어 및 만료가 동시에 존재하면 캐시 제어는 우선 순위가 높습니다.
ETAG를 구성하거나 제거하십시오
EXPIRE/CACHE-CONTROL을 사용하면 두 번째 방문을 피하고 로컬 캐시를 사용하여 HTTP 요청 중복을 피하고 웹 사이트 속도를 향상시킬 수 있습니다. 그러나 사용자가 브라우저 새로 고침을 클릭하거나 만료되면 HTTP GET 요청이 서버에 여전히 발행됩니다. 현재 파일이 변경되지 않으면 서버는 전체 파일을 반환하지 않지만 304 수정되지 않은 상태 코드를 반환합니다.
서버가 파일이 변경되었는지 여부를 결정하기위한 두 개의 Basiss가 있습니다 : 최후의 수정 (최신 수정 날짜) 및 ETAG (Entity Tag);
ETAG (Entity Tags)는 HTTP 1.1에 도입되었으며 최종 수정과 동시에 존재할 때 우선 순위가 높습니다. 서버는 클라이언트가 전송 한 ETAG (if-none-match)를 현재 ETAG와 비교하고 동일한 경우 304를 수정하지 않으면 전체 파일과 200 OK가 반환됩니다.
ETAG에는 문제가 있습니다. 브라우저가 하나의 서버에 GET 요청을 보내고 다른 서버에서 구성 요소를 요청하면 ETAG가 일치하지 않습니다. 물론 웹 사이트가 하나의 서버에서 호스팅되고 이제 많은 웹 사이트가 여러 서버를 사용하는 경우 ETAG의 존재는 확인 유효성의 성공률을 크게 줄입니다.
이 문제에 대한 해결책은 ETAG를 구성하고, 서버 인노 노드 값을 제거하고, 수정 타임 스탬프와 크기를 ETAG 값으로 만 유지하거나 ETAG를 직접 제거하고 마지막으로 변형되어 파일의 유효성을 확인하는 것입니다.
4 구성 요소 압축 (HTTP 요청 크기 감소)
HTTP 전송 파일을 압축하여 HTTP 요청의 크기를 줄이고 요청 속도를 향상시켜 GZIP는 현재 가장 일반적으로 사용되고 효과적인 압축 방법입니다.
그러나 모든 리소스 파일을 압축 할 필요는 없습니다. 압축 비용에는 서버가 압축에 CPU 사이클을 소비해야하며 클라이언트는 자체 웹 사이트와 함께 압축 된 파일을 압축해야합니다. 이제 대부분의 웹 사이트는 HTML 문서를 압축하고 일부 웹 사이트는 JS 및 CSS를 압축하도록 선택합니다. 사진, PDF 및 기타 파일에 GZIP 압축을 사용하는 웹 사이트는 거의 없습니다. 그 이유는 이러한 파일이 압축되었고 HTTP를 사용하여 압축 된 것을 압축하면 더 작을 수 없습니다. 실제로 헤더를 추가하고 사전을 압축하고 응답 본문을 확인하면 실제로 CPU를 낭비하게됩니다.
웹 사이트에서 GZIP를 활성화하는 방법은 웹 서버 (IIS, NGINX, APACHE 등)에서 설정해야합니다.
5 개의 CSS 파일이 먼저 배치됩니다
CSS 파일을 첫 번째 및 마지막에 넣는 것은 HTTP 요청에 영향을 미치지 않으므로 요청 시간 측면에서 일관됩니다. 그러나 사용자 경험의 관점에서 CSS 파일을 첫 번째에 넣으면 더 나은 사용자 경험이 제공됩니다.
그 이유는 브라우저가 HTML 문서를 위에서 아래로 구문 분석하고 CSS 파일을 헤드에 배치하기 때문입니다. 페이지는 먼저 CSS 파일에 요청을 한 다음 DOM 트리를로드하여 렌더링합니다. 페이지는 점차 사용자에게 제공됩니다.
반대로 CSS 파일이 끝에 배치되면 페이지가 전체 DOM을로드하고 CSS 파일을 요청한 다음 전체 DOM 트리를 렌더링하여 사용자에게 제공합니다. 사용자의 관점에서 CSS 파일이 요청되기 전에 전체 페이지가 흰색 화면 상태에 있습니다. 흰색 화면은 브라우저의 동작입니다. David Hyatt의 설명은 다음과 같습니다
스타일 트리가 완전히로드되기 전에 Dom 트리 렌더링은 폐기물입니다. 스타일 트리가로드 된 후에 다시 렌더링되기 때문에 Fouc (스타일 컨텐츠 플리커) 문제가 발생하기 때문입니다.
주목해야 할 또 다른 점은 @import 대신 링크를 사용하여 CSS 스타일 시트를 소개하는 것입니다. @import가 소개 한 스타일이 헤더로 작성 되더라도 문서 끝에로드됩니다.
6 JS 파일은 끝에 배치됩니다
HTTP 요청은 평행하고 다른 브라우저의 병렬 다운로드 수는 다릅니다 (2, 4 또는 8). 병렬 다운로드는 HTTP 요청의 속도를 향상시킵니다. JS 파일을 처음에 올리면 후속 파일의 다운로드를 차단할뿐만 아니라 페이지 렌더링도 차단됩니다.
왜 이런 일이 일어나고 있습니까? 두 가지 이유가 있습니다.
JS 파일에 Page의 내용을 수정하기 위해 hodect.write가 존재할 수 있으므로 스크립트가 실행 된 후에 페이지가 렌더링되지 않습니다.
다른 JS 파일은 크기에 관계없이 종속성을 가질 수 있으므로 순서대로 실행해야하므로 스크립트를로드 할 때 금지됩니다.
따라서 가장 좋은 방법은 JS 파일을 마지막에 배치하고 사용자 경험을 향상시키기 위해 요청하기 전에 페이지의 모든 시각적 구성 요소가로드 될 때까지 기다리는 것입니다.
위는 편집자가 귀하에게 소개 한 JavaScript의 웹 사이트 성능 향상에 대한 몇 가지 제안입니다 (1). 나는 그것이 당신에게 도움이되기를 바랍니다. 더 알고 싶다면 Wulin.com에주의를 기울이십시오. 다음 기사에서 편집자는 JavaScript (II)의 웹 사이트 성능 최적화 개선을위한 제안을 소개합니다.