인터넷이 사람들의 삶에 없어서는 안될 부분이되었다고 생각합니다. Ajax, Flex 등과 같은 풍부한 고객의 응용 프로그램은 사람들이 C/S에서만 구현할 수있는 많은 기능을 경험하게되어 더 행복합니다. 예를 들어, Google Opportunity는 가장 기본적인 사무실 응용 프로그램을 인터넷으로 옮겼습니다. 물론, 편리하지만 의심 할 여지없이 페이지가 느리고 느리게 만듭니다. 저는 프론트 엔드 개발을하고 있습니다. Yahoo의 설문 조사에 따르면 성능 측면에서 백엔드는 5%만을 차지하는 반면 프론트 엔드는 95%로 높으며 그 중 88%는 최적화 될 수 있습니다.
위는 Web2.0 페이지의 수명주기 다이어그램입니다. 엔지니어는 임신, 출생, 졸업 및 결혼의 네 단계로 나뉘어져 있다고 생생하게 말합니다. 웹 링크를 클릭 할 때 간단한 요청-응답 대신이 프로세스를 실현할 수 있다면 성능을 향상시킬 수있는 많은 세부 사항을 파헤칠 수 있습니다. 오늘 저는 Yahoo Development 팀의 Taobao에서 Xiao Ma Ge의 웹 성과 연구에 관한 강의를 들었습니다. 나는 많은 것을 얻었고 블로그에서 그것을 공유하고 싶다고 느꼈다.
많은 사람들이 웹 사이트 성능을 최적화하기위한 14 가지 규칙에 대해 들었다고 생각합니다. 자세한 내용은 Developer.yahoo.com에서 확인할 수 있습니다
1. HTTP 요청 수를 가능한 한 많이 줄입니다 [Content]
2. CDN (Content Delivery Network) [서버] 사용
3. 만료 헤더 (또는 캐시 제어) [서버] 추가
4. GZIP 구성 요소 [서버]
5. CSS 스타일을 페이지 위에 놓습니다 [CSS]
6. 스크립트를 하단으로 이동 (인라인 포함) [JavaScript]
7. CSS [CSS]에서 표현식 사용을 피하십시오.
8. 외부 파일에 별도의 JavaScript와 CSS를 별도로 분리합니다 [JavaScript] [CSS]
9. DNS 쿼리 감소 [컨텐츠]
10. JavaScript 및 CSS (인라인 포함) [JavaScript] [CSS] 압축합니다.
11. [서버] 리디렉션을 피하십시오.
12. 중복 스크립트 제거 [JavaScript]
13. 엔티티 태그 (ETAGS) [CSS] 구성
14. Ajax 캐시를 만듭니다
Firebug에 통합 된 Firefox 아래에 플러그인 YSLOW가 있습니다. 이를 사용하여 웹 사이트가 이러한 측면에서 어떻게 수행되는지 쉽게 확인할 수 있습니다.
이것은 내 웹 사이트 xifengfang을 평가하기 위해 yslow를 사용한 결과입니다. 불행히도, 그것은 51 점에 불과합니다. 헤헤. 중국의 주요 웹 사이트의 점수는 높지 않습니다. 방금 테스트했고 Sina와 Netease는 모두 31 점이었습니다. 그런 다음 Yahoo (US)의 점수는 실제로 97 점입니다! 야후는 이와 관련하여 노력을 기울 였음을 알 수 있습니다. 그들이 요약 한 14 가지 규칙으로 판단하면, 현재 우리에게 추가 된 많은 세부 사항이 있으며, 일부 관행은 약간 왜곡되어 있습니다.
제 1 조 : HTTP 요청 수를 최대한 최소화합니다 (HTTP 요청을 줄이면)
HTTP 요청은 오버 헤드이며 요청 수를 줄이는 방법을 찾으면 웹 페이지의 속도가 자연스럽게 증가 할 수 있습니다. 일반적인 방법은 CSS, JS (각각 페이지에 CSS 및 JS 파일 병합) 및 이미지 맵 및 CSS 스프라이트 등을 병합하고 있습니다. 물론 CSS 및 JS 파일을 분할하는 것은 CSS 구조, 공유 등의 고려 사항에 기인 한 다음 Alibaba Chinese 웹 사이트는 개발 중에 별도로 개발 한 다음 배경에서 JS 및 CSS를 합병해야합니다. 이것은 여전히 브라우저에 대한 요청 이었지만 개발 중에는 여전히 여러 번 복원 될 수 있으며, 이는 관리 및 반복 참조에 편리했습니다. Yahoo는 홈페이지 CSS 및 JS를 외부 참조 대신 페이지 파일에 직접 작성하는 것이 좋습니다. 홈페이지에는 방문이 너무 많기 때문에 그렇게하면 두 가지 요청 수가 줄어들 수 있습니다. 실제로 많은 국내 포털이이를 수행합니다.
CSS Sprites는 페이지의 배경 이미지를 하나로 결합한 다음 CSS의 배경 위치 속성으로 정의 할 수없는 값을 사용하여 배경을 얻는 것을 말합니다. Taobao와 Alibaba Chinese 웹 사이트가 현재이 작업을 수행하고 있습니다. 관심이 있으시면 Taobao와 Alibaba의 배경 사진을 볼 수 있습니다.
http://www.cssssprites.com/ 이것은 업로드 사진을 자동으로 병합하고 해당 배경 위치 좌표를 제공 할 수있는 도구 웹 사이트입니다. 결과를 PNG 및 GIF 형식으로 출력하십시오.
제 2 조 : 콘텐츠 전달 네트워크 사용
솔직히 말해서, 나는 CDN에 대해 많이 모른다. 간단히 말해서, 기존 인터넷에 새로운 네트워크 아키텍처를 추가하여 웹 사이트의 내용을 사용자와 가장 가까운 캐시 서버에 게시합니다. DNS로드 밸런싱 기술을 통해 사용자의 소스가 필요한 콘텐츠를 얻기 위해 근처의 캐시 서버에 액세스하고 있다고 판단합니다. Hangzhou의 사용자는 Hangzhou 근처의 서버의 콘텐츠에 액세스하고 베이징의 콘텐츠는 베이징 근처의 서버의 콘텐츠에 액세스합니다. 이렇게하면 네트워크에서 데이터 전송 시간을 효과적으로 줄이고 속도를 향상시킬 수 있습니다. 자세한 내용은 Baidu 백과 사전에서 CDN에 대한 설명을 참조하십시오. 야후! 정적 컨텐츠를 CDN으로 배포하면 사용자 영향 시간이 20% 이상 줄어 듭니다.
CDN 기술 다이어그램 :
CDN 네트워킹 다이어그램 :
제 3 조 : 만료/캐시 제어 헤더 추가 : 만료 헤더 추가
이제 점점 더 많은 사진, 스크립트, CSS 및 플래시가 페이지에 내장되어 있으며 액세스 할 때 필연적으로 많은 HTTP 요청을합니다. 실제로, 우리는 헤더가 만료되어 이러한 파일을 캐시 할 수 있습니다. 만료는 실제로 헤더 메시지를 통해 브라우저에서 특정 유형의 파일의 캐시 시간을 지정합니다. 대부분의 이미지는 게시 후 자주 수정할 필요가 없습니다. 캐시 된 후 브라우저는 더 이상 서버에서 이러한 파일을 다운로드하여 캐시에서 직접 읽을 필요가 없습니다. 이렇게하면 페이지에 다시 액세스 할 수 있습니다. 일반적인 HTTP 1.1 프로토콜은 헤더 정보를 반환합니다.
HTTP/1.1 200 OK
날짜 : 금요일, 1998 년 10 월 30 일 13:19:41 GMT
서버 : Apache/1.3.3 (UNIX)
캐시 제어 : Max-AGE = 3600, 꼭 봐야 할 반복
만료 : 금요일, 1998 년 10 월 30 일 14:19:41 GMT
마지막 수정 : Mon, 1998 년 6 월 29 일 02:28:12 GMT
ETAG : 3E86-410-3596FBBC
컨텐츠 길이 : 1040
내용 유형 : Text/HTML
캐시 제어를 설정하여 수행 할 수 있으며 서버 측 스크립트를 통해 만료됩니다.
예를 들어, PHP에 설정된 경우 30 일 후에 만료됩니다.
<!-PHEADER (캐시 제어 : Must-Revalidate); $ 오프셋 = 60 * 60 * 24 * 30; $ extstr = 만료 :. gmdate (d, d myh : i : s, time () + $ 오프셋). gmt; header ($ extstr);-> 서버 자체를 구성하여 수행 할 수도 있으므로 명확하지 않습니다. 더 알고 싶다면 http://www.web-caching.com/을 참조하십시오.
내가 아는 한, Alibaba Chinese 웹 사이트의 만료 시간은 30 일입니다. 그러나이 기간 동안, 특히 스크립트 만료 시간을 설정할 때 문제가 있었으며, 신중하게 고려해야합니다. 그렇지 않으면 해당 스크립트 함수가 업데이트 된 후 클라이언트가 그러한 변경 사항을 인식하는 데 시간이 오래 걸릴 수 있습니다. [제안 프로젝트] 작업을 할 때이 문제가 발생했습니다. 그러므로 우리는 어떤 것들을 캐시 해야하는지 신중하게 고려하고 어떤 것들을 캐시해서는 안되는 지 신중하게 고려해야합니다.
제 4 조 : GZIP 압축 활성화 : GZIP 구성 요소
GZIP의 아이디어는 먼저 서버 측에서 파일을 압축 한 다음 전송하는 것입니다. 이것은 파일 전송 크기를 크게 줄일 수 있습니다. 변속기가 완료되면 브라우저는 압축 된 컨텐츠를 다시 검출하여 실행합니다. 현재 브라우저는 GZIP를 잘 지원할 수 있습니다. 브라우저는이를 인식 할 수있을뿐만 아니라 주요 크롤러도 인식 할 수 있습니다. 모든 seoers는 안심할 수 있습니다. 또한, GZIP의 압축 비율은 매우 크며, 일반적으로 압축 비율은 85%이며, 이는 서버의 100K 페이지를 클라이언트에게 전송하기 전에 약 25K로 압축 할 수 있음을 의미합니다. 특정 GZIP 압축 원칙의 경우 CSDN의 "GZIP 압축 알고리즘"을 참조하십시오. 야후는 특히 모든 텍스트 내용이 gzip : html (php), js, css, xml, txt에 의해 압축되어야한다고 강조합니다. 우리 웹 사이트는 이와 관련하여 좋은 일을하고 있습니다. 과거에는 홈페이지에 많은 JS가 있었기 때문에 A가 아니 었습니다. 이 광고 코드 소유자의 웹 사이트의 JS는 GZIP에 의해 압축되지 않았으며 웹 사이트를 끌어 올릴 것입니다.
위의 세 점의 대부분은 서버 측 컨텐츠이며, 간단한 이해 만하고 있습니다. 잘못된 것은 수정되는 것입니다.
제 5 조 : 스타일 시트를 맨 위에 놓습니다
페이지 위에 CSS를 넣으십시오. 왜 이런 일입니까? IE와 같은 브라우저이므로 Firefox는 모든 CSS가 완전히 전송 될 때까지 아무것도 렌더링하지 않습니다. 그 이유는 Ma 형제가 말한 것처럼 간단합니다. CSS, 성명 : 계단식 스타일 시트. 계단식은 뒤에있는 CSS가 이전 CSS를 커버 할 수 있음을 의미하고 수준이 높은 CSS는 낮은 수준의 CSS를 커버 할 수 있습니다. [CSS! 중요]이 계층 관계는이 기사의 맨 아래에서 언급되었으며, 여기서는 CSS를 덮어 쓸 수 있음을 알아야합니다. 이전의 것을 덮어 쓸 수 있으므로 브라우저가 완전히로드 된 후 렌더링하는 것이 의심 할 여지없이 합리적입니다. IE와 같은 많은 브라우저에서 스타일 시트를 페이지 하단에 넣는 문제는 웹 페이지 컨텐츠 표시 순서를 금지한다는 것입니다. 브라우저가 페이지 요소를 다시 칠하지 않도록 디스플레이를 차단하면 사용자는 빈 페이지 만 볼 수 있습니다. Firefox는 디스플레이를 차단하지 않지만 스타일 시트를 다운로드 할 때 일부 페이지 요소를 다시 칠해야하므로 깜박 거리는 문제가 발생할 수 있습니다. 그래서 우리는 가능한 빨리 CSS를 적재해야합니다.
이 의미에 따라, 우리가 신중하게 보면 실제로 최적화 할 수있는 영역이 있습니다. 예를 들어이 사이트에 포함 된 두 CSS 파일은 <link rel = stylesheet rev = stylesheet href = http : //www.space007.com/themes/google/style/google.css type = text/css media = screen/> 및 <link rel = stylesheet rev = stylesheet입니다. href = http : //www.space007.com/css/print.css type = text/css media = print/>. 미디어에서 첫 번째 CSS는 브라우저 용이고 두 번째 CSS 파일은 인쇄 스타일입니다. 사용자의 행동 습관에서 페이지 페이지가 표시된 후 페이지를 인쇄하는 동작이 발생해야합니다. 따라서 더 나은 방법은 페이지가로드 된 후 페이지에 CSS를 동적으로 추가하여 속도를 향상시킬 수 있어야합니다. (하하)
제 6 조 : 맨 아래에 스크립트를 넣으십시오
페이지 하단에 스크립트를 배치하기위한 두 가지 목적이 있습니다. 페이지의로드 프로세스 중에 브라우저가 JS 실행 명령문을 읽을 때 모든 것을 설명하고 다음 내용을 다음 내용을 읽습니다. 믿지 않으면 JS 루프를 작성하여 페이지 아래의 물건이 여전히 나올지 확인할 수 있습니다. (Settimeout 및 SetInterval의 실행은 멀티 스레딩과 약간 유사하며, 다음 컨텐츠 렌더링은 해당 응답 시간 전에 계속됩니다.) 브라우저 뒤의 논리는 JS가 위치를 실행할 수 있다는 것입니다. href 또는 기타 기능은 언제든지이 페이지 프로세스를 완전히 중단 할 수 있습니다. 따라서 페이지 끝에 놓으면 페이지의 시각적 요소의 로딩 시간이 효과적으로 줄어들 수 있습니다. 2. 스크립트로 인한 두 번째 문제는 병렬 다운로드 수를 차단한다는 것입니다. HTTP/1.1 사양은 브라우저의 각 호스트에 대한 병렬 다운로드 수가 2를 초과해서는 안되며 (즉, FF와 같은 다른 브라우저는 기본적으로 2로 설정되지만 새 IE8은 6에 도달 할 수 있습니다). 따라서 이미지 파일을 여러 시스템에 배포하면 2 개 이상의 병렬 다운로드를 달성 할 수 있습니다. 그러나 스크립트 파일이 다운로드되면 브라우저는 다른 병렬 다운로드를 시작하지 않습니다.
물론 각 웹 사이트에 대해 페이지 하단에 모든 스크립트를 넣을 수있는 타당성은 여전히 의문의 여지가 있습니다. 예를 들어, Alibaba Chinese 웹 사이트 페이지. 많은 장소에 인라인 JS가 있으며 페이지 표시는 이것에 크게 의존합니다. 나는 이것이 비 침습적 스크립트의 개념과는 거리가 멀지 만 많은 역사적 문제는 해결하기가 쉽지 않습니다.
제 7 조 : CSS에서 표현식 사용을 피하십시오 (CSS 표현 방지)
그러나 두 개의 의미없는 중첩 층이있을 것입니다. 더 나은 솔루션이 필요합니다.
제 8 조 : JavaScript와 CSS를 외부 파일에 넣습니다 (JavaScript 및 CSS 외부 제작)
나는 이것이 여전히 이해하기 쉽다고 생각합니다. 이는 성능 최적화의 관점뿐만 아니라 쉬운 코드 유지 보수의 관점에서도 수행됩니다. 페이지 콘텐츠에 CSS 및 JS를 작성하면 2 개의 요청이 줄어들 수 있지만 페이지 크기도 증가 할 수 있습니다. CSS 및 JS가 캐시 된 경우 추가 HTTP 요청이 두 번 없습니다. 물론, 나는 또한 일부 특별 페이지 개발자들이 여전히 인라인 CSS 및 JS 파일을 선택할 것이라고 말했다.
제 9 조 : DNS 조회 감소
인터넷의 도메인 이름과 IP 주소 사이에는 일대일 서신이 있습니다. 도메인 이름 (kuqin.com)은 기억하기 쉽지만 컴퓨터는이를 인식하지 못합니다. 컴퓨터 간의 인식은 IP 주소로 변환되어야합니다. 네트워크의 각 컴퓨터에는 독립적 인 IP 주소가 있습니다. 도메인 이름과 IP 주소 사이의 변환 작업을 DNS 쿼리라고도하는 도메인 이름 해상도라고합니다. DNS 해상도 프로세스는 20-120 밀리 초가되며 브라우저는 DNS 쿼리가 끝날 때까지 도메인 이름으로 아무것도 다운로드하지 않습니다. 따라서 DNS 쿼리 시간을 줄이면 페이지의로드 속도 속도가 빨라질 수 있습니다. Yahoo는 페이지에 포함 된 도메인 이름 수를 가능한 한 2-4로 제어해야한다고 권장합니다. 이를 위해서는 전체 페이지에 대한 좋은 계획이 필요합니다. 우리는 현재 잘 지내지 못하고 있으며 포인트를 관리하는 많은 광고 시스템으로 인해 우리를 끌어 들였습니다.
제 10 조 : JavaScript 및 CSS 압축 (JavaScript Minify)
JS와 CSS의 왼쪽과 오른쪽을 압축하여 페이지 바이트 수를 줄이는 것이 명백합니다. 용량이 적은 경우 페이지 로딩 속도가 자연스럽게 빠릅니다. 부피를 줄이는 것 외에도 압축은 일정량의 보호를 제공 할 수 있습니다. 우리는 이것에서 좋은 일을했습니다. 일반적인 압축 도구에는 jsmin, yui compressor 등이 포함됩니다. 또한 http://dean.edwards.name/packer/와 같은 매우 편리한 온라인 압축 도구를 제공합니다. JQuery 웹 페이지에서 압축 JS 파일과 압축되지 않은 JS 파일 간의 용량 차이를 볼 수 있습니다.
물론 압축의 한 가지 단점은 코드의 가독성이 사라 졌다는 것입니다. 많은 프론트 엔드 친구들 이이 문제에 직면했다고 생각합니다. Google을 보는 효과는 매우 시원하지만 소스 코드를 볼 때 많은 캐릭터가 함께 혼잡하고 기능 이름조차 대체되었습니다. 나는 너무 땀이 나다! 자신의 코드가 동일하다면 유지 관리에 매우 불편하지 않습니까? 모든 알리바바 중국 웹 사이트의 현재 관행은 JS와 CSS가 출시 될 때 서버 측에서 압축하는 것입니다. 이런 식으로 우리는 자신의 코드를 쉽게 유지할 수 있습니다.
제 11 조 : 리디렉션을 피하십시오
얼마 전, 나는 IEBLOG에서 "Internet Explorer and Connection Limits"기사를 보았습니다. 예를 들어, http://www.kuqin.com/을 입력하면 서버가 301 서버를 자동으로 생성하고 http://www.kuqin.com/으로 전환합니다. 브라우저의 주소 표시 줄을 보면 볼 수 있습니다. 이런 종류의 리디렉션은 자연스럽게 시간이 걸립니다. 물론 이것은 단지 예일뿐입니다. 리디렉션에는 여러 가지 이유가 있지만 변하지 않는 것은 리디렉션이 추가 될 때마다 웹 요청이 추가되므로 최소화해야한다는 것입니다.
제 12 조 : 중복 스크립트를 제거하십시오
나는 이것을 말하고 싶지 않지만 성능의 관점뿐만 아니라 코드 사양의 관점에서도 마찬가지입니다. 그러나 그래프가 빠르기 때문에 여러 번 중복 코드를 추가 할 것임을 인정해야합니다. 아마도 통합 된 CSS 프레임 워크와 JS 프레임 워크가 우리의 문제를 더 잘 해결할 수있을 것입니다. Xiaozhu의 관점은 반복 불가능뿐만 아니라 재사용 할 수있는 것입니다.
제 13 조 : 엔티티 태그 (ETAG) 구성 (ETAG 구성)
나도 이해가 안 돼요, 하하. "Etags를 사용하여 웹 응용 프로그램의 대역폭 및로드를 줄이기 위해"Inforq에 대한 자세한 설명을 찾았습니다. 관심있는 학생들은 가서 살펴볼 수 있습니다.
제 14 조 : Ajax 캐시 가능
Ajax는 여전히 캐시해야합니까? AJAX 요청을 할 때는 종종 캐시를 피하기 위해 타임 스탬프를 추가해야합니다. 비동기식은 즉각적인 것을 의미하지 않는다는 것을 기억하는 것이 중요합니다. Ajax가 동적으로 생성되어 한 사용자를 위해서만 작동하더라도 여전히 캐시 될 수 있습니다.