효과적으로 웹 페이지의 효율성을 높여주는 14 지침

중간 거래 SEO 진단 Taobao 게스트 클라우드 호스트 기술 홀

콘텐츠 다시 풍부한 사이트를 액세스할 수 하는 경우는 의미가 없다; 좋은 사이트, 검색 스파이더 잡을 수 없는 경우는 또한 SEO 할 헛; UE 디자인 humanized 사이트, 사용자도 볼 수 없는 경우의 빈 얘기입니다.

그래서 웹 페이지의 효율성은 확실히 가장 주목할 만한 측면 이다. 당신은 어떻게 웹 페이지의 효율성을 향상 시킬 수 있습니다.? 스티브 Souders (스티브 Souders의 데이터는 웹 페이지의 효율성을 향상 시키기 위한 14 지침을 제공 합니다 및 이러한 지침 또한 YSlow 도구는 다음 장에서 소개 하 고 있을 거 야 우리에 대 한 근거를 있을 것입니다:

첫째: 확인 적은 HTTP 요청을 http 요청 요청 수를 줄이기 위해 가능한 만큼.

사용자 응답 시간의 80%는 프런트 엔드에 낭비입니다. 이 시대는 주로 사진, 스타일 시트, 자바 스크립트, 플래시 파일 등을 다운로드 하 여 발생 합니다. 이러한 리소스 파일에 대 한 요청 요청을 줄이는 웹 페이지 디스플레이의 효율 향상의 열쇠 될 것입니다.

모순, 있을 것은 만약 내가 사진, 스타일, 스크립트의 많은 감소 또는 플래시, 다음 웹 페이지 맨, 얼마나 추한? 사실, 이것은 오해 이다. 우리는 가능한 한 많이, 그것은 완전히 불가능 하지 사용 하 말한 그냥. 이러한 파일에 대 한 요청 요청 수는 감소 하 고 일부의 팁 및 제안:

1: 큰 그림 여러 작은 그림을 바꿉니다.

이것은 전통적인 생각의 반전의 조금 이다. 우리는 여러 작은 그림의 다운로드 속도 큰 그림의 다운로드 속도 보다는 더 적은 있을 것 이라고 생각 하는데. 하지만 지금은 HttpWatch 도구를 사용 하 여 여러 페이지의 분석에서 결과 표시이 경우 아니다.

첫 번째 그림은 40528bytes의 크기의 큰 그림의 분석 이다 337 * 191px.

두 번째는 13883bytes의 크기의 작은 그림의 분석은 280 * 90px.

크기 40528bytes의 큰 그림의 분석 결과 (전체 그림을 보고 그림에 클릭 하십시오) 337 * 191px

크기 13883bytes의 작은 그림의 분석 280 * 90px (전체 그림을 보고 그림에 클릭 하십시오)

첫 번째 큰 그림에 대 한 시간이 걸립니다.

차단: 13.034s

보내기: 0.001s

대기: 0.163s

수신: 4.596s

ttfb:0.164s

네트워크: 4.760s

소비 전력: 17.795s

실제 시간 전송 큰 파일 reveive, 또는 4.596s, 대부분의 시간은 캐시를 검색 하 고 13.034s, 73.2%의 총 시간에 대 한 링크 차단 시간의 유효성을 결정 하는 데 사용 됩니다.

시간이 두 번째 작은 사진:

차단: 16.274s

0.001s 미만 보내기:

대기: 0.117s

수신: 0.397s

Ttfb:0.118s

네트워크: 0.516s

소비 전력: 16.790s

실시간으로 파일을 전송 하는 큰 파일의 4.596s 보다 정말 훨씬 작습니다 reveive 시간, 즉, 0.397s, 이다. 하지만 그의 차단된 시간 16.274s, 총 시간의 97%를 차지 했다.

당신을 설득 하기에 충분 하지 경우, 아래에이 그림을 봐 보자. 여기에 웹 페이지의 모든 그림에 소요 하는 시간의 목록이입니다. 물론, 작은, 다른 규격의 사진 많이 있다.

시간의 80% 이상 캐시를 검색 하 고 링크 유효한 차단된 시간 인지 확인 하는 데 사용 됩니다. 파일을 전송 하기 위한 블루에서 보낸 reveive 시간 그리고 전면 화이트 차단 캐시를 검색 하 고 연결이 유효한 확인을 위한 시간. 철 같은 사실 우리에 게 알려줍니다.

크고 작은 파일 다운로드에 필요한 시간은 실제로 다르다, 그리고 차이 절대 아니다. 그리고 다운로드 소요 시간 매우 작습니다.

시간의 80% 이상 캐시를 검색 하 고 링크 유효한 차단된 시간 인지 확인 하는 데 사용 됩니다. 이 시간의 비용은 대략 파일 크기에 관계 없이 동일 합니다. 그리고 거 대 한 소요 된 총 시간 비율입니다.

100 k 큰 그림의 작은 그림 총 시간이 소요 총 시간이 소요 4 25 보다 절대적으로 k. 그리고 가장 큰 차이점은 차단 된 시간의 4 작은 그림은 차단 된의 1 대형 사진 보다 확실히 더 큰 이다.

그래서 만약에 너무 많은 사소한 작은 사진을 대체 하 큰 사진을 사용할 수 있습니다. 이 때문에 플립 문의 효율은 그림 교체의 슬라이딩 도어 보다 높은.

그러나, note는 너무 큰 단일 그림을 사용할 수 없습니다 때문에 그 사용자 경험에 영향을 미칠 것입니다. 예를 들어 배경 이미지의 몇 가지 메가바이트의 사용이 아니다 확실히 좋습니다.

2: CSS 파일을 병합.

그림: 병합 및 병합 실수를 하기 전에, 그리고 당신이 내 일련의 조직에 기사 및 스타일 시트의 계획에 그것을 볼 것 이다. 당시, 난 다른 목적을 위한 스타일 시트 파일을 분리 하 고 조직 하 고 스타일 시트의 계획을 촉진 하기 위하여 다른 CSS 파일을 형성. 페이지에서 필요에 따라 다음 여러 CSS 파일을 참조 하십시오.

"가능한 최소화 HTTP 요청 요청" 지침을 바탕으로, 우리는 그 것 적당 한 그것은 더 많은 HTTP 요청 요청 생성 하기 때문에 알고 있다. 따라서 웹 페이지의 효율성을 감소. 그래서,의 관점에서 웹 페이지의 효율성을 개선, 우리 여전히 작성 해야 모든 CSS 같은 CSS 파일에. 그러나 문제가 다시 온다. 어떻게 할 구성 당신과 당신의 스타일 시트를 잘 계획? 이것이 참으로 모순. 내 현재의 접근 방식을 사용 하는 버전의 두 세트입니다. 에디션 및 버전 편집 버전은 여전히 쉽게 계획 및 조직에 대 한 여러 개의 CSS 파일을 사용합니다. 그리고는 출시 될 때까지 기다릴 다음 HttpRequest 요청 수를 줄일 수 있도록 파일에 여러 개의 CSS 파일을 병합.

3: 자바 스크립트 파일을 병합.

이유 고 치료 방법 동감, 더 이상 동화.

기사 II: CDN을 사용 하 여 콘텐츠 전송 네트워크 사용

이 매우 비 모습 처럼 보이지만 중국 인터넷 특성의 조합으로이 이해 하기 어렵지 않다. "북 서버", "남쪽 서버", "통신 서버", "넷 컴 서버"... 이 단어는 너무 친숙 하 고 우울 소리. 베이징 통신 사용자 "벽지 컬렉션" 게시물에 비슷한 광 동 넷 컴 서버에서 웹 페이지를 열려고, 당신은 깊은 이해를 해야 합니다.

이 우리의 개발자에 대 한 가이드라인 하지, 여기에 할 말이 좀 있다.

제 3 조: 추가 Expires 헤더 추가 주기 머리

이건 개발자 제어, 하지만 웹 서버 관리자의 책임입니다. 그래서 만약 당신이 이해 하지 않고 개발자로 서 이해 상관 없습니다. 또는 회사의 웹 서버 관리자에 게.

넷째: Gzip 구성 요소 gzip 압축 사용

이 모든 사람에 게 더 친숙 한 되어야 합니다. Gzip의 아이디어 먼저 서버측에서 파일을 압축 하 고 그들을 전송 하는 것 이다. 이것은 큰, 텍스트 전용 파일에 대 한 특수 효과. 이 개발자, 하지만 사이트 서버 관리자의 작업, 이것은 하지 자세히 설명 됩니다. 당신은 이것에 관심이 있다면, 귀하의 회사의 웹 서버 관리 직원에 대 한 정보를 수 있습니다.

5: 페이지 위쪽의 CSS 스타일을 넣어 가기에 CSS를 넣어.

HTML과 XHTML과 CSS는 컴파일되지 인터프리터 언어입니다. 그래서 다음 브라우저 구문 분석 구조, 단어의 상단에 CSS 렌더링할 수 있습니다 이미 페이지. 이 표시 되지 것입니다, 페이지 구조 맨 첫 번째 아웃, 그리고 CSS 렌더링, 페이지, 갑자기 화려한 그래서 너무 브라우징 경험 "극적인" 페이지를 있다.

6: 이동 스크립트는 아래 하단에 스크립트를 삽입

같은 기사로 다섯 번째 이유는. 단지 스크립트는 일반적으로 사용자 상호 작용에 사용 됩니다. 그래서 페이지 밖으로 오지는, 사용자가 페이지의 어떤 모양을 알고도 할 상호 작용에 대 한 이야기는 단순히 얘기가입니다. 스크립트와 CSS는 반대, 그래서 스크립트는 페이지의 하단에 있어야 합니다.

7: 방지 CSS 식 CSS 식을 사용 하지 않습니다

이미지: CSS에서 식은 실제로 if 판사는 우선 어떤 CSS 식은 것은 설명할 필요가. 그것은 사실, if 같은...은 다른 언어에서 다른... Statement。 CSS에서 간단한 논리 판단 가능합니다. 간단한 예

이 방법은 경우에 따라 다른 스타일을 사용 하 여 CSS를 뿌리 수 있습니다. 당신은 이것에 관심이 있다면, 당신은 내 블로그를 읽고 관련 기사-"CSS 식 시리즈 기사." 갈 수 있다 하지만 CSS에서 식의 비용은 매우 높다. 귀하의 페이지를 렌더링 효과의 요소가 많은 시간을 판단 하는 경우 다음 브라우저 있을 것입니다 중단 애니메이션에서 오랜 시간 그래서 사용자가 매우 가난 사용자 경험을가지고.

8: 만들기 자바 스크립트와 CSS 외부 자바 스크립트와 CSS를 외부 파일로 분리

이 하나는 부정 하는 첫 번째 것으로 보인다. 사실, 만약 당신이 HTTP 요청 요청에서 말하고,이 효율성을 줄어들지입니다. 하지만 이것은 또 다른 중요 한 고려 사항은 캐시 때문입니다. 외부 참조 파일은 브라우저에 의해 캐시 하기 때문에 우리가 그들을 분리 외부 파일에 JavaScript와 CSS는 크기에서 더 큰 경우. 이 방법에서는, 사용자가 한 번 찾아볼 때 이러한 큰 JS와 CSS 파일 캐시 수 있습니다, 사용자의 효율성을 개선 하 고 지상에 액세스.

아홉째: DNS 조회 감소 DNS 쿼리를 줄이기 위해

DNS 도메인 이름 확인 시스템 우리 모두가 알고는 우리가 우리가 기억 하는 단어, 하지 http://202.153.125.45 같은 것 들 때문에 너무 많은 Url을 기억 하 고 도움이 우리에 게 그 단어와 202.153.125.45 같은 IP 주소는 DNS. 따라서 무엇이이 우리에 게 정말로 의미 하나? 실제로 두 개의 기사가:

1: 필요 하지 않은 경우 제발 넣지 마십시오 사이트 두 서버에.

2: 웹 페이지, CSS 파일, JS 파일, 플래시 파일, 사진과, 너무 많이 다른 사이버 공간에 흩어져. 그 이유는 웹 사이트에서의 바탕 화면 사진을 보낼 게시물은 다른 웹 사이트에서 온 것 보다 훨씬 빠릅니다.

자바 스크립트와 CSS 줄일을 10 분의 1: 자바 스크립트와 CSS 파일의 볼륨 작게

이것은 잘 이해 된다. 불필요 한 빈 줄, 공백 및 주석이 최종 릴리스에서 제거 합니다. 그것은 분명 그 수동 처리 너무 효율적 이며 인터넷은 이러한 것 들을 압축 공구의 가득입니다. 자바 스크립트 코드의 크기를 압축 도구는 어디에 나, 그리고 그들을 나열 하지 않을.

그것은 다양 한 압축 방법 제공, 다양 한 요구에 적응할 수 있습니다.

11: 방지 리디렉션 점프 피하기

나는 단지 웹 개발자의 관점에서이 기사를 읽었다. 그래서 우리가 읽은 수? 2 시-

1:이 문장 보이는 정말 익숙한 "이 도메인 이름 만료, 5 초 후, 페이지 http://www.xxxxxx.com/index.html 페이지로 이동 합니다". 하지만, 왜 그 페이지에 직접 연결 하는 것이 궁금해?

2: 일부 링크 주소 작성 하시기 바랍니다 자세한 내용을 명확 하 게. 예: http://justinyoung.cnblogs.com/as http://justinyoung.cnblogs.com를 작성 (참고 마지막 "/" 기호). 물론,이 두 Url은 내 블로그에 액세스할 수 있지만, 사실, 그들은 다른. http://justinyoung.cnblogs.com의 결과 다음 http://justinyoung.cnblogs.com/ 다시 지적 301 응답 이다. 그러나 분명히, 중간에 시간 낭비 많이 있다.

12 제거 중복 스크립트 제거 복제 스크립트

그림: 반복, "아니오!" 이 규칙의 원리는 매우 간단 하지만 정말 작품, 많은 사람들은 때문 에"프로젝트 시간 꽉", "너무 피곤", "일찍 계획 좋지 않다"... 에 이유입니다. 정말 많은 이유는 귀하의 사이트 높은 효율성 및 나중에 유지 보수를 필요로 하지 않습니다 경우이 여분의 반복적인 스크립팅 코드 처리 하지 찾을 수 있습니다.

이것은 포인트, 나 상기, 일부 자바 스크립트 프레임 워크, 자바 스크립트 패키지를 주의 하 여 사용 해야 합니다. 적어도 물어: 결국에서이 JS 키트를 사용 하 여 우리에 게 얼마나 많은 편의 제공, 업무 효율의 양을 향상. 그런 다음, 중복, 반복적인 코드를 가져오는 부정적인 영향을 비교 합니다.

13: 구성 ETags 엔터티 레이블 구성

첫째, ETag에 대 한 얘기 하자. Etag (엔터티 태그) 엔터티 레이블입니다. 이 태그는 태그 인터넷에 보면 조금 다릅니다. 이 etag 아니라 사용자, 하지만 브라우저 캐시 이다. ETag는 서버 알려주는 브라우저 캐시에 캐시의 내용이 변경 되었는지 여부는 메커니즘입니다. ETag, 브라우저 현재 캐시 콘텐츠를 최신 상태로 하 고 서버에서 다시 다운로드 받이 필요가 알 것 이다. 이것은 "마지막으로 수정한"의 개념 처럼 조금입니다. 그것은 당신이 웹 개발자로 그것에 대해 할 수 있는 아무것도입니다. 그는 여전히 웹 서버 담당자의 작품입니다. 이에 관심이 있다면, 귀하의 회사의 웹 서버 관리자에 게 참조 하십시오.

14: Ajax 캐시 위의 가이드라인은 또한 Ajax를 적용 하 게

이미지: Ajax Ajax 될 것 약간의 신화, 웹 페이지, Ajax로 효율성 문제가 다음 마치 지금 적절 한 수를 사용 합니다. 사실,이 오해입니다. Ajax의 가난한 사용 됩니다 하지 보다 효율적으로 귀하의 웹 페이지, 하지만 귀하의 웹 페이지 효율성을 줄일 수 있습니다. Ajax 정말 좋은 건, 하지만 제발 그것을 과장 하지 말라. 또한 AJAX를 사용 하는 경우 위의 지침을 고려해 야 합니다.

포스트 스크립트:

물론, 이들은 단지 당신의 참고를 위한 이론적 지침입니다. 특정 상황 또는 치료에 구체적으로. 이론 및 지침만 현실, 작품 안내를 사용 하지만 그들은 기계적 하드 세트.