집 >웹 프론트엔드 >HTML 튜토리얼 >Yahoo의 군사 규정에 대한 자세한 소개

Yahoo의 군사 규정에 대한 자세한 소개

黄舟원래의: 2017-07-24 13:52:031172검색

yahoo군사 규정은 7카테고리총35기사로 나뉩니다.

1. HTTP 요청

Category : Content

80% 최종 사용자 응답 시간의 대부분은 페이지의 다양한 구성 요소(이미지, 스타일시트, 스크립트, Flash)를 다운로드하는 데 소요됩니다. 등 잠깐만요. 구성 요소 수를 줄이면 페이지에서 제출되는 HTTP 요청 수가 필연적으로 줄어듭니다. 이것이 페이지를 더 빠르게 만드는 열쇠입니다.

페이지 구성 요소 수를 줄이는 한 가지 방법은 페이지 디자인을 단순화하는 것입니다. 하지만 응답 시간을 단축하면서 복잡한 페이지를 구축할 수 있는 방법이 있을까요? 글쎄, 실제로 케이크를 갖고 그것을 먹는 방법도 있습니다.

모든 스크립트를 하나의 파일에 넣어 요청 수를 줄이기 위해 파일을 병합합니다. 물론 모든 CSS을 병합할 수도 있습니다. 각 페이지의 스크립트와 스타일이 다른 경우 파일을 병합하는 것은 번거로운 작업이 될 수 있지만 사이트 게시 프로세스의 일부로 이 작업을 수행하면 실제로 응답 시간을 향상시킬 수 있습니다.

CSS Sprites 는 이미지 요청 수를 줄이는 데 선호되는 방법입니다. 모든 배경 이미지를 하나의 이미지로 통합한 다음 CSS의 Background-image 및 Background-position 속성을 사용하여 표시할 부분의 위치를 지정합니다.

이미지 매핑 여러 이미지를 하나의 이미지로 병합할 수 있습니다. 전체 크기는 동일하지만 요청 수가 줄어들고 페이지 로딩이 빨라집니다. 이미지 맵은 탐색 모음과 같이 이미지가 페이지에 연속적으로 표시되는 경우에만 유용합니다. 이미지 맵의 좌표를 설정하는 과정은 지루하고 오류가 발생하기 쉬우며, 이미지 맵을 탐색에 사용하는 것이 쉽지 않으므로 이 방법은 권장하지 않습니다.

인라인 이미지(Base64인코딩)는 data: URL 패턴을 사용하여 이미지를 페이지에 삽입합니다. 이렇게 하면 HTML 파일의 크기가 증가합니다. (캐시된) 스타일 시트에 인라인 이미지를 넣는 것이 페이지가 "무거워지는" 것을 성공적으로 방지하는 것입니다. 그러나 현재 주류 브라우저는 인라인 이미지를 잘 지원하지 않습니다.

페이지에 대한 HTTP 요청 수를 줄이는 것은 사이트의 첫 방문 속도를 향상시키는 중요한 지침 원칙입니다. Tenni Theurer가 자신의 블로그에 쓴 것과 마찬가지로 브라우저 캐시 사용 – 노출됨! 방문자 중 , 40% ~ 60%이 귀하의 사이트를 방문하는 시간입니다. 비어 있는. 따라서 페이지의 첫 번째 방문 속도를 높이는 것은 사용자 경험을 향상시키는 데 매우 중요합니다.

사용 CDN(Content Delivery Network)

Category

: Server

사용자와 서버 사이의 물리적 거리와 응답 시간 비교 또한 영향을 미칩니다. 지리적으로 분산된 여러 서버에 콘텐츠를 배포하면 사용자가 페이지를 더 빠르게 로드할 수 있습니다. 하지만 어떻게 해야 할까요?

지리적으로 분산된 콘텐츠를 구현하는 첫 번째 단계는 분산 구조를 수용하기 위해 웹애플리케이션을 다시 디자인하려고 하지 마세요. 애플리케이션에 따라 구조 변경에는 세션 상태 동기화 및 서버 간 데이터베이스 트랜잭션 복제와 같은 어려운 작업이 포함될 수 있습니다(번역이 정확하지 않을 수 있음). 사용자와 콘텐츠 사이의 거리를 단축하자는 제안은 이런 어려움으로 인해 지연되거나 아예 통과가 불가능할 수도 있습니다.

최종 사용자가 80% ~ 90%임을 기억하세요. 응답 시간은 페이지 구성 요소(이미지, 스타일, 스크립트, Flash 등)를 다운로드하는 데 소요됩니다. 이것이 바로 성능의 황금률입니다. 처음부터 애플리케이션 구조를 다시 디자인하는 것보다 정적 콘텐츠를 먼저 분산시키는 것이 더 좋습니다. 이렇게 하면 응답 시간이 크게 단축될 뿐만 아니라 CDN의 기여도를 더 쉽게 표시할 수 있습니다.

콘텐츠 배포 네트워크(CDN)는 다양한 지리적 위치에 분산된 web 서버 세트로, 사용자에게 콘텐츠를 보다 효율적으로 전달하는 데 사용됩니다. 일반적으로 콘텐츠를 전달하기 위해 선택된 서버는 네트워크 거리 측정에 따라 결정됩니다. 예를 들어 홉 수가 가장 적거나(hop) 응답 시간이 가장 빠른 서버를 선택합니다.

일부 대형 인터넷 기업에는 자체 CDN이 있지만 Akamai Technologies , EdgeCast 과 같은 CDN 서비스 제공업체를 이용하는 것이 더 비용 효율적입니다. , 또는 레벨3 . 이제 막 시작한 기업이나 개인 웹사이트의 경우 CDN 서비스 비용이 매우 높지만, 사용자 기반이 점점 커지고 글로벌화되면 CDN을 사용하세요. 여전히 교환이 필요합니다. 더 빠른 응답 시간을 위해. Yahoo!에서 애플리케이션의 web서버에 있는 정적 콘텐츠를 CDN(위에서 언급한 제3자 및 Yahoo 자체 콘텐츠 포함)으로 이동합니다. CDN ) 최종 사용자의 응답 시간을 20% 이상 향상시킬 수 있습니다. CDN으로 전환하는 것은 매우 간단한 코드 변경이지만 사이트의 응답성을 대폭 향상시킵니다.

3.추가 Expires 또는 Cache-Control HTTPHeader

Category: Server

이 규칙에는 두 가지 측면이 있습니다.

정적 구성 요소의 경우: 먼 미래 시간을 Expires

으로 설정하여 만료되지 않음 중복된 동적 구성 요소의 경우: 적절한 Cache-Control HTTP 헤더를 사용하여 브라우저가 조건부 요청

을 수행할 수 있도록 합니다.

웹 디자인이 점점 더 풍부해지고 있으며 이는 페이지에 더 많은 스크립트, 이미지 및 Flash가 있다는 것을 의미합니다. 사이트의 새로운 방문자는 여전히 몇 가지 HTTP 요청을 제출해야 할 수 있지만 만료를 사용하면 구성 요소를 캐시할 수 있게 되어 후속 검색 세션 중에 불필요한 HTTP 요청을 피할 수 있습니다. 유효한 HTTP 헤더는 일반적으로 이미지에 사용되지만 스크립트, 스타일 및 Flash 구성 요소를 포함한 모든 구성 요소에 사용해야 합니다.

브라우저(및 프록시)는 캐싱을 사용하여 HTTP 요청 수와 크기를 줄여 페이지를 더 빠르게 로드할 수 있습니다. web서버는 유효 기간HTTP 응답 헤더를 사용하여 페이지의 각 구성 요소를 캐시해야 하는 기간을 클라이언트에게 알려줍니다. 유효 기간으로 먼 미래의 시간을 사용하면 이 응답이 2010year4month15일 이전에는 변경되지 않을 것임을 브라우저에 알립니다.

만료: 2010년 4월 15일 목요일 20:00:00 GMT

Apache서버를 사용하는 경우 ExpiresDefault 명령을 사용하여 현재 날짜를 기준으로 만료 날짜를 설정하세요. 다음 예에서는 요청 시간으로부터 10년의 만료 날짜를 설정합니다.

ExpiresDefault "access plus 10 year"

만료 날짜에 먼 미래의 시간을 사용하는 경우, 구성 요소가 변경되면 즉시 구성 요소의 파일 이름을 수정해야 합니다. Yahoo!에서는 종종 빌드 프로세스의 일부로 이 작업을 수행합니다. 구성 요소의 파일 이름에 버전 번호를 포함합니다. 예: yahoo_2.0.6.js

먼 미래의 시간을 사용하여 Expiration HTTP 헤더는 사용자가 이미 사이트를 방문한 후에만 페이지 보기에 영향을 미칩니다. 신규 방문자이거나 브라우저 캐시가 지워진 경우 HTTP 요청 수에는 영향을 미치지 않습니다. 따라서 이러한 성능 향상은 개별 구성 요소를 캐시한 사용자가 사이트를 방문하는 빈도에 따라 달라집니다. 이를 Yahoo!에서 측정한 결과 각 구성 요소(PV)에 대해 캐시된 페이지 조회수가 75%에서 85% 범위인 것으로 나타났습니다. 먼 미래의 시간을 HTTP 헤더의 유효 기간으로 사용하면 브라우저에서 캐시하는 구성 요소 수가 늘어나고 이후 페이지 보기에서는 Internet 연결을 사용하여 보낼 필요가 없습니다. 한 바이트라도 더.

4.GzipComponents

Categories: Server

프런트 엔드 엔지니어는 네트워크를 통한 전송 시간을 크게 단축할 수 있는 방법을 찾을 수 있습니다. HTTP 요청 및 응답 시간. 최종 사용자의 대역폭 속도, 네트워크 서비스 제공자, 피어 교환 지점의 거리 등이 모두 개발팀의 통제 범위를 벗어나는 것은 의심의 여지가 없습니다. 그러나 응답 시간에 영향을 줄 수 있는 다른 요소도 있습니다. 압축은 HTTP 응답 크기를 줄여 응답 시간을 향상시킬 수 있습니다.

HTTP/1.1부터 web 클라이언트는 Accept-Encoding HTTP 요청 헤더 압축을 지원했습니다.

Accept-Encoding: gzip, deflate

web서버가 이 요청 헤더를 보면 클라이언트가 나열한 방법 중 하나를 사용하여 응답을 압축합니다. web 서버는 Content-Encoding 해당 헤더를 통해 클라이언트에 알립니다.

콘텐츠 인코딩: gzip

Gzip은 현재 GNU 프로젝트에서 개발하고 RFC 1952 에서 표준화한 가장 일반적이고 효율적인 압축 방법입니다. 볼 수 있는 유일한 다른 압축 형식은 deflate이지만 그다지 효율적이지도 않고 일반적이지도 않습니다.

Gzipping은 일반적으로 응답을 약 70%으로 압축할 수 있습니다. 현재 브라우저를 통한 네트워크 전송의 약 90%이 gzip을 지원합니다. Apache 서버의 경우 gzip을 구성하는 모듈은 버전에 따라 다릅니다. Apache 1.3은 mod_gzip 을 사용하고 Apache 2.x 는 mod_deflate 모듈.

브라우저와 프록시의 특정 요인으로 인해 브라우저가 기대하는 것과 수신되는 압축 콘텐츠가 일치하지 않을 수 있습니다. 다행스럽게도 이전 브라우저가 폐기됨에 따라 이러한 거의 발생하지 않는 상황은 점차 줄어들고 있으며 Apache 모듈은 적절한 Vary 응답 헤더를 자동으로 추가하여 도움을 줄 수 있습니다.

서버는 파일 형식에 따라 gzip 압축 사용 여부를 결정하지만 이는 매우 제한적입니다. 대부분의 웹사이트는 gzip을 사용하여 HTML 파일을 압축합니다. 실제로 스크립트와 스타일 시트를 압축하는 것도 좋은 선택이지만 많은 웹사이트가 이 기회를 놓치고 있습니다. 실제로 XML 및 JSON을 포함한 모든 텍스트 콘텐츠를 압축할 수 있지만, 이미지와 PDF는 gzip을 사용하여 이미 압축되었으므로 압축할 필요가 없습니다. 압축하는 것은 낭비일 뿐만 아니라 CPU 또한 점점 더 스트레스를 받을 수 있습니다.

최대한 gzip압축을 사용하면 페이지의 무게를 줄일 수 있으며 이는 사용자 경험을 향상시키는 가장 쉬운 방법이기도 합니다. ㅋㅋㅋ 스타일 시트를 넣는 것은 문서의

HEAD

섹션을 사용하면 페이지가 더 빠르게 로드되는 것처럼 보입니다. 스타일시트를

head에 배치하면 페이지가 점진적으로 렌더링될 수 있기 때문입니다.

성능에 관심이 있는 프런트엔드 엔지니어는 페이지가 점진적으로 렌더링되기를 원합니다. 즉, 우리는 브라우저가 기존 콘텐츠를 가능한 한 빨리 표시하기를 원합니다. 이는 페이지에 콘텐츠가 많거나 사용자의 인터넷 연결이 매우 느린 경우 특히 중요합니다. 사용자에게 피드백(예: 진행률 표시기)을 표시하는 것의 중요성은 널리 연구되어 문서화 되었습니다. 우리의 경우 HTML 페이지가 진행률 표시기입니다! 브라우저가 페이지 헤더, 탐색 모음, 상단 로고 등을 점진적으로 로드하면 페이지 로드를 기다리는 사용자의 피드백으로 사용되어 전반적인 사용자 경험을 향상시킬 수 있습니다.

많은 브라우저(IE 포함)에서 스타일 시트를 HTML 문서 하단에 배치하면 페이지가 점진적으로 렌더링되지 않습니다. 이러한 브라우저는 스타일 변경으로 인해 페이지 요소를 다시 그리는 것을 방지하기 위해 렌더링 프로세스를 차단하여 사용자가 빈 페이지를 보게 됩니다.

HTML공식 문서에는 스타일 시트가 페이지의 HEAD 안에 배치되어야 한다고 명확하게 설명되어 있습니다. "A와 달리 [LINK]는 문서의 HEAD 섹션에만 나타날 수 있습니다. 여러 번 나타날 수도 있습니다." (a 태그와 달리 link 태그는 HEAD 섹션에만 나타날 수 있지만 여러 번 나타날 수 있습니다.) . 빈 화면이나 스타일이 지정되지 않은 falsh 콘텐츠는 허용되지 않습니다. 이상적인 해결책은 HTML 공식 문서를 따르고 스타일 시트를 HTML 문서의 HEAD 섹션에 넣는 것입니다. 6. 脚 스크립트를 맨 아래에 넣으세요

카테고리 : javascript

will block 병렬 다운로드,

http/1.1

공식 문서에서는 브라우저 이름이 Do not download라고 나와 있습니다. 2개 이상의 구성 요소가 병렬로 실행되는 경우 이미지가 여러 호스트 이름에서 제공되는 경우 병렬 다운로드 수가 2개 이상이 될 수 있습니다. 스크립트가 다운로드되는 경우 브라우저는 다른 호스트 이름을 사용해도 다른 다운로드 작업을 시작하지 않습니다.

가끔 스크립트를 하단으로 옮기기가 쉽지 않은 경우가 있습니다. 예를 들어

document.write

를 사용하여 페이지 콘텐츠에 스크립트를 삽입한 경우 아래로 이동할 방법이 없습니다. 범위 지정 문제가 있을 수도 있으며 대부분의 경우 해결이 가능합니다.

일반적인 제안은 지연된(

deferred

) 스크립트를 사용하는 것입니다. DEFER 속성이 있는 스크립트는 document.write를 포함할 수 없으며 브라우저에 계속할 수 있다는 메시지를 표시합니다. 렌더링. 안타깝게도 Firefox는 DEFER 속성을 지원하지 않습니다. IE에서는 스크립트가 지연될 수 있지만 예상한 것과는 다릅니다. 스크립트를 연기할 수 있는 경우 이를 페이지 하단에 배치하면 페이지가 더 빠르게 로드됩니다.

CSSexpressions

Classification

사용을 피하세요: css

CSS 표현식을 사용하여 CSS 속성을 동적으로 설정하는 것은 강력하면서도 위험한 방법입니다. IE5부터 지원되지만 IE8부터 더 이상 사용되지 않습니다. 예를 들어, CSS 표현식을 사용하여 배경색을 시간별로 번갈아 표시하도록 설정할 수 있습니다.

위 코드에서 표현식 메소드는 JavaScript 표현식을 허용할 수 있습니다. . CSS 속성은 표현식의 계산된 결과로 설정됩니다. expression 메서드는 다른 브라우저에서 무시되므로 IE과 일치하는 브라우저 간 사용자 환경을 달성하는 방법을 찾는 데에만 유용합니다.

표현식의 가장 큰 문제점은 우리가 생각하는 것보다 훨씬 더 자주 다시 계산된다는 것입니다. 페이지가 렌더링되고 크기가 조정될 때뿐만 아니라 페이지가 스크롤될 때, 심지어 사용자가 페이지 주위로 마우스를 움직일 때에도 표현식이 재평가됩니다. CSS 표현식에 카운터를 추가하여 재계산 시기와 빈도를 추적하고, 페이지에서 마우스를 움직이면 10000 여러 재계산이 실행될 수 있습니다.

CSS 표현식 재계산을 줄이는 한 가지 방법은 일회성 표현식을 사용하는 것입니다. 즉, 표현식이 처음 평가된 후 스타일 속성을 명시적인 값으로 설정하고 표현식을 바꾸는 것입니다. 페이지 수명 주기 전체에 걸쳐 스타일 속성을 동적으로 설정해야 하는 경우 CSS 표현식 대신 이벤트 핸들러를 사용할 수 있습니다. CSS 표현식을 사용해야 하는 경우 표현식이 수천 번 다시 계산되어 전체 페이지의 성능에 영향을 미칠 수 있다는 점을 기억하세요.

8.Put JavaScript 및 CSS 외부

Categories: javascript, css

많은 성과 원칙은 외부와 함께 관리하는 방법에 관한 것입니다. 그러나 이러한 문제가 발생하기 전에 더 기본적인 질문을 던져야 합니다. JavaScript 및 CSS를 외부 파일에 넣어야 할까요, 아니면 페이지에 직접 써야 할까요?

실제로 JavaScript 및 CSS 파일이 브라우저에 캐시되기 때문에 외부 파일을 사용하면 페이지 속도가 더 빨라질 수 있습니다. HTML 문서의 인라인 JavaScript 및 CSS은 HTML 문서가 요청될 때마다 다시 다운로드됩니다. 이렇게 하면 필요한 HTTP 요청 수가 줄어들지만 HTML 문서 크기가 늘어납니다. 반면에 JavaScript 및 CSS이 외부 파일에 있고 브라우저에 의해 캐시된 경우 크기를 늘리지 않고 HTML 문서를 더 작게 만든 것입니다. HTTP 요청 횟수.

핵심 요소는 외부 파일이 캐시되는 빈도와 페이지 요청 수 사이의 관계입니다. 이 요소는 정량화하기 어렵지만 다양한 지표를 사용하여 측정할 수 있습니다. 사용자가 세션당 여러 페이지를 방문하는 경우 외부 파일 캐싱은 큰 이점이 될 수 있으므로 동일한 스크립트와 스타일시트를 여러 페이지에서 재사용할 수 있습니다.

많은 사이트가 측정항목에서 중간에 속하며 이러한 사이트의 경우 일반적으로 가장 좋은 솔루션은 JavaScript 및 CSS을 외부 파일로 배포하는 것입니다. 유일한 예외는 Yahoo! 및 My Yahoo! 홈페이지와 같은 홈페이지의 인라인 모드 우선순위입니다. 세션당 방문 수가 적은 홈페이지에서는 인라인 JavaScript 및 CSS을 통해 최종 사용자의 응답 시간이 더 빨라집니다.

일반적인 사이트의 경우 홈페이지는 많은 트래픽이 시작되는 곳이며 외부 파일 캐싱 사용의 이점과 같이

HTTP 요청을 줄이기 위해 활용할 수 있는 많은 기술이 있습니다. 그러한 기술 중 하나는 홈페이지에서 인라인 JavaScript 및 CSS을 사용하지만 페이지가 로드된 후 외부 파일을 동적으로 로드하여 후속 페이지에 필요한 외부 파일이 이미 브라우저에 배치되도록 하는 것입니다. 캐시.

ReduceDNSLookup

Classification

: Content

도메인 이름 시스템 구축 호스트 이름과

IP주소 간의 매핑은 다음과 같습니다. 전화번호부의 이름과 번호 매핑은 동일합니다. 브라우저에 www.yahoo.com을 입력하면 브라우저는 DNS 확인자에 접속하여 서버의 IP 주소를 반환합니다. DNS에는 비용이 발생하며 특정 호스트 이름에 대한 IP 주소를 찾는 데 20 ~ 120ms가 걸립니다. 브라우저는 DNS 조회가 완료될 때까지 호스트 이름에서 아무것도 다운로드할 수 없습니다.

DNS

조회는 사용자의

ISP(인터넷 서비스 제공업체) 또는 로컬 네트워크에서 호스팅하는 특수 캐싱 서버에 더 효율적으로 캐시되지만, 개별 사용자의 컴퓨터에도 캐시될 수 있습니다. DNS 정보는 Windows 운영 체제의 DNS 캐시(Microsoft"DNSClient Service")에 저장됩니다. 대부분의 브라우저에는 운영 체제와 관계없이 자체 cache이 있습니다. 브라우저가 cache에 이 기록을 유지하는 한 운영 체제 DNS에 쿼리하지 않습니다.

IE기본 캐시 DNS조회 30분, DnsCacheTimeout 레지스트리 설정에 기록됩니다. Firefoxcache1분. network.dnsCacheExpiration 구성 항목을 사용하여 설정할 수 있습니다. (Fasterfox는 캐시 시간을 1hourP.S로 변경했습니다. Fasterfox는 FF용 속도 향상 플러그인입니다.)

고객의 인 경우 DNS 캐시가 비어 있습니다(브라우저 및 운영 체제 포함). DNS조회 수는 페이지 URL, 이미지, 스크립트 파일, 스타일 시트를 포함하여 페이지의 다양한 호스트 이름 수와 같습니다. , Flash 객체 및 기타 구성 요소의 호스트 이름을 사용하면 다른 호스트 이름을 줄이면 DNS 조회가 줄어들 수 있습니다.

다른 호스트 이름 수를 줄이면 페이지에서 병렬로 다운로드할 수 있는 구성 요소 수도 줄어듭니다. DNS 조회를 피하면 응답 시간이 줄어들고 병렬 다운로드 수를 줄이면 응답 시간이 늘어납니다. 내 원칙은 구성 요소를 2에서 4 호스트 이름으로 분산시키는 것입니다. 이는 DNS 조회를 동시에 줄이고 높은 동시 다운로드를 허용하는 절충안입니다.

10.CompressionJavaScript 및 CSS

Category: 자바스크립트, css

압축은 특히 코드에서 불필요한 문자를 제거하여 크기를 줄입니다. 로딩 속도를 향상시킵니다. 코드 최소화는 모든 주석과 불필요한 공백 문자(공백, 줄 바꿈 및 tab)를 제거하는 것을 의미합니다. JavaScript에서 이 작업을 수행하면 다운로드할 파일이 작아지기 때문에 응답성이 향상됩니다. 가장 일반적으로 사용되는 두 가지 JavaScript 코드 압축 도구는 JSMin 이고 YUI Compressor , YUI 압축기도 CSS를 압축할 수 있습니다.

난독화는 선택적 소스 코드 최적화 조치로 압축보다 복잡하므로 난독화 프로세스에서 버그가 생성될 가능성도 더 높습니다. 미국의 상위 10개 웹사이트를 대상으로 한 조사에 따르면 압축은 크기를 21% 줄인 반면, 난독화는 크기를 25% 줄였습니다. 난독화는 더 높은 수준의 축소를 제공하지만 압축보다 더 위험합니다.

외부 스크립트 및 스타일을 압축하는 것 외에도 인라인 3f1c4e4b6b16bbbd69b2ee476dc4f83a 및 c9ccee2e6ea535a969eb3f532ad9fe89 블록도 압축할 수 있습니다. gzip 모듈이 활성화되어 있어도 먼저 압축하면 크기가 5% 이상 줄어들 수 있습니다. JavaScript와 CSS는 점점 더 유용해지고 있으므로 코드를 압축하면 좋은 효과를 얻을 수 있습니다.

11.

리디렉션 방지

Category

: Server

엔티티 태그(ETags)는 브라우저 캐시의 구성 요소가 원본 서버의 구성 요소와 일치하는지 확인하기 위해 서버와 브라우저에서 사용하는 메커니즘입니다("엔티티"는 이미지, 스크립트, 스타일 시트 등의 구성 요소입니다). ETags를 추가하면 마지막 수정 날짜보다 더 유연한 엔터티 확인 메커니즘을 제공할 수 있습니다. ETag는 구성 요소의 특정 버전에 대한 고유 식별자 역할을 하는 문자열입니다. 유일한 형식 제한은 문자열을 따옴표로 묶어야 하며 원본 서버가 해당 헤더의 ETag 을 사용하여 구성 요소의 ETag을 지정한다는 것입니다.

HTTP/1.1 200 OK

: Tue, 12 Dec 2006 03:03:59 GMT

ETag: "10c24bc-4ab-457e1c1f"

Content-Length: 12195

그런 다음 브라우저가 구성 요소의 유효성을 검사해야 하는 경우 If-를 사용합니다. 없음- 요청 헤더를 일치시켜 ETag을 원본 서버로 다시 전달합니다. ETags가 성공적으로 일치하면 304 상태 코드가 반환되므로 응답 본문이 12195바이트만큼 줄어듭니다.

GET /i/yahoo.gif HTTP/1.1

호스트: us.yimg.com

If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT

If-None- Match : "10c24bc-4ab-457e1c1f"

HTTP/1.1 304 Not Modified

ETags 문제는 이 태그가 특정 서버에 의해 구성된다는 것입니다. 따라서 브라우저가 한 서버에서 초기 구성 요소를 가져온 다음 다른 서버에 인증하려는 경우 서버 ETags의 동일한 구성 요소는 성공적으로 일치할 수 없으며 서버 그룹을 사용하여 요청을 처리하는 것은 web 사이트에서 매우 일반적입니다. 기본적으로 Apache 및 IIS는 ETag에 데이터를 삽입하여 다중 서버 사이트에서 유효성 테스트가 성공할 가능성을 크게 줄입니다.

Apache 1.3

및

2.x에서 형식은 inode-size-timestamp 입니다. 특정 파일이 여러 서버의 동일한 디렉터리에 있을 수 있고 파일 크기, 액세스 권한, 타임스탬프 등이 모두 동일하더라도 해당 파일의 inode(P.S. inode, UNIX 인덱스 파일)도 서버마다 다릅니다. IIS5.0

및

6.0

에도 비슷한 문제가 있습니다. IIS의 ETags 형식은 Filetimestamp:ChangeNumber 이고, ChangeNumber 는 IIS에서 구성 변경 사항을 추적하는 데 사용되는 카운터입니다. 서로 다른 IIS 서버에 있는 사이트의 ChangeNumber 는 동일할 수 없습니다.

최종 결과는 Apache 및 IIS에 의해 생성된 ETags가 브라우저 간에 일치할 수 없으며, ETags가 일치하지 않으면 사용자가 수신할 수 없다는 것입니다. ETags는 작고 빠른 304반응형 디자인 ETags입니다. 대신 구성 요소에 대한 모든 데이터가 포함된 200정상 응답을 받게 됩니다. 사이트가 단일 서버에 배포된 경우에는 이 문제가 전혀 존재하지 않습니다. 그러나 사이트가 여러 서버에 배포되어 있고 Apache 또는 IIS의 기본 ETags 구성을 사용하려는 경우 사용자는 페이지 속도가 느려지고 서버 로드가 높아지며 대역폭 소비가 커집니다. , 프록시는 페이지 콘텐츠를 효과적으로 캐시할 수 없습니다. 구성 요소에 "영구" Expires HTTP 헤더가 있더라도 사용자가 다시 로드하거나 새로 고치기 위해 클릭하면 조건부

GET

요청이 계속 실행됩니다.

ETags에서 제공하는 유연한 검증 모델을 사용하지 않으려면 Etag를 모두 제거하고 구성요소 기반 타임스탬프 Last-Modified HTTP 헤더를 사용하는 것이 가장 좋습니다. 확인하고 ETag를 제거하면 HTTP 응답 헤더 및 후속 요청의 크기를 줄일 수 있습니다. Microsoft 지원 문서 에서는 ETags를 제거하는 방법을 설명합니다. Apache에서는

Apache

구성 파일에 다음 코드를 추가하면 됩니다.

Category: Content

Ajax

의 장점 중 하나는 백엔드 서버에서 비동기적으로 정보를 요청할 수 있기 때문에 사용자에게 즉각적인 피드백을 제공할 수 있다는 것입니다. 그러나 Ajax를 사용하면 비동기

JavaScript

및 XML 응답이 반환될 때까지 기다리는 동안 사용자가 지루하지 않을 것이라는 보장이 없습니다. 많은 애플리케이션에서 사용자가 기다릴 수 있는 능력은 Ajax이 어떻게 사용되는지에 따라 달라집니다. 예를 들어, web 기반 이메일 클라이언트에서 사용자는 검색 기준과 일치하는 이메일 메시지를 찾기 위해 Ajax 요청에 의해 반환된 결과에 계속 주의를 기울일 것입니다. "비동기"가 "즉시"를 의미하는 것은 아니라는 점을 기억하는 것이 중요합니다. 성능을 향상하려면 이러한 Ajax 응답을 최적화하는 것이 중요합니다. Ajax

의 성능을 향상시키는 가장 중요한 방법은

Expires 또는 Cache-Control HTTP 헤더 추가에서 설명한 대로 응답을 캐시 가능하게 만드는 것입니다. Ajax에는 다음 추가 규칙이 적용됩니다. GzipComponent

减少DNS查找

压缩JavaScript

避免重定向

配置ETags

我们一起看看例子，一个Web 2.0的电子邮件客户端用了Ajax来下载用户的通讯录，以便实现自动完成功能。如果用户从上一次使用之后再没有修改过她的通讯录，而且Ajax响应是可缓存的，有尚未过期的Expires或者Cache-Control HTTP头，那么之前的通讯录就可以从缓存中读出。必须通知浏览器，应该继续使用之前缓存的通讯录响应，还是去请求一个新的。可以通过给通讯录的Ajax URL里添加一个表明用户通讯录最后修改时间的时间戳来实现，例如 &t=1190241612 。如果通讯录从上一次下载之后再没有被修改过，时间戳不变，通讯录就将从浏览器缓存中直接读出，从而避免一次额外的HTTP往返消耗。如果用户已经修改了通讯录，时间戳也可以确保新的URL不会匹配缓存的响应，浏览器将请求新的通讯录条目。

即使Ajax响应是动态创建的，而且可能只适用于单用户，它们也可以被缓存，而这样会让你的Web 2.0应用更快。

15.尽早清空缓冲区

分类: 服务器

当用户请求一个页面时，服务器需要用大约200到500毫秒来组装HTML页面，在这期间，浏览器闲等着数据到达。PHP中有一个 flush() 函数，允许给浏览器发送一部分已经准备完毕的HTML响应，以便浏览器可以在后台准备剩余部分的同时开始获取组件，好处主要体现在很忙的后台或者很“轻”的前端页面上（P.S. 也就是说，响应时耗主要在后台方面时最能体现优势）。

比较理想的清空缓冲区的位置是HEAD后面，因为HTML的HEAD部分通常更容易生成，并且允许引入任何CSS和JavaScript文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。

例如：

... <!-- css, js -->
    </head>
    <?php flush(); ?>
    <body>
      ... <!-- content -->

Yahoo!搜索开创了这项技术，而且真实用户测试研究也证明了使用这种技术的诸多好处。

16.对Ajax用GET请求

分类: 服务器

Yahoo!mail 팀은 XMLHttpRequest 를 사용할 때 브라우저의 POST 요청이 2단계 프로세스를 통해 구현된다는 사실을 발견했습니다. 먼저 HTTP 헤더를 보낸 다음 데이터를 보내는 것입니다. 따라서 하나의 TCP 메시지만 보내면 되는 GET 요청을 사용하는 것이 가장 좋습니다(너무 많은 쿠키가 아닌 한). IE의 URL 최대 길이는 2K이므로 전송할 데이터가 2K를 초과하면 GET 사용할 수 없습니다.

POST 요청의 흥미로운 부작용은 GET 요청과 같이 실제로 데이터가 전송되지 않는다는 것입니다. HTTP 문서에 설명된 대로 GET 요청은 정보를 검색하는 데 사용됩니다. 따라서 그 의미는 서버에 저장해야 하는 데이터를 보내는 것이 아니라 GET 요청으로 데이터를 요청하는 것입니다.

17.지연 로딩 구성 요소

Category: Content

페이지를 자세히 살펴보고 스스로에게 물어볼 수 있습니다. 안으로 첫 번째 장소는? 나머지는 기다릴 수 있습니다.

JavaScript는 onload 이벤트 전후를 구분하는 데 이상적입니다. 예를 들어 JavaScript 코드와 드래그 앤 드롭 및 애니메이션을 지원하는 라이브러리가 있는 경우 페이지가 처음 렌더링된 후 드래그 앤 드롭 요소가 발생할 때까지 기다릴 수 있습니다. 지연 로드될 수 있는 다른 섹션에는 숨겨진 콘텐츠(상호작용 후 나타나는 콘텐츠)와 축소된 이미지가 포함됩니다.

도구를 사용하면 작업 부하를 줄일 수 있습니다. YUI 이미지 로더 는 접힌 이미지 로드를 지연할 수 있으며 YUI Get 유틸리티 는 JS 및 CSS을 도입하는 방법입니다. 단순한 방법. Yahoo!홈페이지는 Firebug의 네트워크 패널을 열고 자세히 살펴볼 수 있습니다.

성능 목표를 "점진적 향상"과 같은 다른 웹 개발 모범 사례에 맞추는 것이 가장 좋습니다. 클라이언트가 JavaScript를 지원하면 사용자 경험이 향상될 수 있지만 JavaScript가 지원되지 않는 경우에도 페이지가 제대로 작동할 수 있는지 확인해야 합니다. 따라서 페이지가 제대로 작동한다고 확신하면 지연 로딩 스크립트를 사용하여 페이지를 향상시켜 드래그 앤 드롭 및 애니메이션과 같은 멋진 효과를 지원할 수 있습니다.

18. 미리 로드 구성 요소

Category : Content

미리 로드는 지연 로딩과 반대처럼 보일 수 있지만 실제로는 다른 목표. 구성 요소를 미리 로드하면 브라우저의 유휴 시간을 최대한 활용하여 향후 사용할 구성 요소(이미지, 스타일 및 스크립트)를 요청할 수 있습니다. 사용자가 다음 페이지에 액세스하면 대부분의 구성 요소가 이미 캐시에 있으므로 사용자 관점에서 페이지가 더 빠르게 로드됩니다.

실제 애플리케이션에는 다음과 같은 유형의 사전 로드가 있습니다.

무조건 사전 로드 – 가능한 한 빨리 로드를 시작하고 추가 구성 요소를 얻으세요. google.com은 sprite이미지 사전 로드의 좋은 예입니다. 이 sprite이미지는 google.com홈 페이지에 필요한 것이 아니라 검색결과 페이지의 콘텐츠입니다.

Conditional Preloading - 사용자 행동에 따라 사용자가 점프할 위치를 추측하고 그에 따라 미리 로드합니다. search.yahoo.com 의 입력 상자에 입력하면 해당 추가 구성 요소가 어떻게 로드되도록 요청되는지 확인할 수 있습니다.

Ahead of Time Preloading - 새로운 디자인이 출시되기 전에 미리 로드하세요. 우리는 디자인 변경 후 "새 웹사이트는 좋지만 이전보다 속도가 느립니다."라는 말을 자주 듣습니다. 그 이유 중 하나는 사용자가 방문한 이전 페이지에는 오래된 캐시가 있지만 새 페이지에는 빈 캐시 환경이 있기 때문입니다. . 새 디자인이 출시되기 전에 일부 구성 요소를 미리 로드하면 이러한 부정적인 영향을 완화할 수 있습니다. 이전 사이트는 브라우저의 유휴 시간을 사용하여 새 사이트에 필요한 이미지와 스크립트를 요청할 수 있습니다.

19. DOMelements

Categories 수 줄이기: Content

복잡한 페이지는 더 많은 바이트를 의미합니다. 다운로드하고 JavaScriptaccess DOM도 느려질 것입니다. 예를 들어 이벤트 핸들러를 추가하려는 경우 페이지의 500 DOM 요소와 5000 DOM 요소를 반복하는 것에는 차이가 있습니다.

많은 수의 DOM 요소는 신호입니다. 페이지에 정리해야 할 관련 없는 태그가 있습니다. 레이아웃에 중첩 테이블을 사용하고 있나요? 아니면 레이아웃 문제를 해결하기 위해 dc6dce4a544fdca2df29d5ac0ea9906b s을 많이 추가하셨나요? 아마도 더 나은 의미론적 마크업을 사용해야 할 것입니다.

YUI CSS 유틸리티 는 레이아웃에 매우 유용합니다. grids.css전체 레이아웃의 경우 fonts.css 및 reset.css을 사용하여 브라우저의 기본값을 제거할 수 있습니다. 체재. 개행을 렌더링하기 때문이 아니라 의미상 의미가 있을 때만 dc6dce4a544fdca2df29d5ac0ea9906b 을 사용하는 등 마크업을 정리하고 생각해볼 수 있는 좋은 기회입니다.

DOM요소 수는 테스트하기 쉽습니다. Firebug 콘솔에 입력하기만 하면 됩니다.

document.getElementsByTagName('*').length

얼마나 많은지 돔 요소가 너무 많나요? Yahoo!홈페이지는 꽤 바쁜 페이지이지만 700 요소(HTML 태그)보다 적습니다.

20.도메인 간 분리 구성 요소

Category: Content

구성 요소를 분리하면 병렬 다운로드를 최대화할 수 있지만 DNS 조회 비용 때문에 도메인을 2-4개 이하만 사용하세요. 예를 들어 HTML 및 동적 콘텐츠를 www.example.org 에 배포하고 정적 구성 요소를 static1.example.org 및 static2.example.org 로 분리할 수 있습니다.

자세한 내용은 Tenni Theurer 및 Patty Chi의 기사를 확인하세요. 카풀 차선에서 병렬 다운로드 극대화

21. 가능한 적게 iframe

Category: Content

을 사용하여 HTML 문서를 상위 문서에 삽입하세요. 중요한 것은 iframe을 이해하는 것입니다. 작동 방식 및 효율적으로 사용합니다.

d5ba1642137c3f32f4f4493ae923989c

장점:

로고 및 광고와 같은 느린 타사 콘텐츠 도입

보안 샌드박스

스크립트 병렬 다운로드

d5ba1642137c3f32f4f4493ae923989c

단점:

비용이 많이 들고 빈

iframe 페이지 로딩을 차단합니다.

비의미적

22.

Content HTTP 요청은 비용이 많이 듭니다.

요청 쓸모없는 응답(예:

404 Not Found)을 얻으면 아무런 이점도 없이 사용자 경험이 느려질 뿐입니다.

일부 사이트에서는 404을 사용하는 것이 도움이 됩니다. - "xxx을 의미합니까?" 이것은 사용자 경험에는 좋지만 서버 리소스(예: 데이터베이스 등)를 낭비합니다. 기다리다). 가장 나쁜 점은 링크된 외부 JavaScript에 오류가 있어서 결과가

404

이라는 것입니다. 첫째, 이러한 다운로드는 병렬 다운로드를 차단합니다. 둘째, 브라우저는 404 응답 본문이 JavaScript 코드이고 어떤 부분을 사용할 수 있는지 알아내야 하기 때문에 구문 분석을 시도합니다. 23.기부 쿠키체중 감량

카테고리

: 쿠키

사용 이유 cookie 권한 부여 및 개인화와 같은 많은 것입니다. HTTP

cookie의 정보는

web

서버와 브라우저 간에 교환됩니다. 사용자 응답 시간에 미치는 영향을 최소화하려면 쿠키를 가능한 한 작게 유지하는 것이 중요합니다.

자세한 내용은 Tenni Theurer 및 Patty Chi의 기사 When the Cookie Crumbles 를 확인하세요. 관련 경험적 원칙은 다음과 같이 요약할 수 있습니다.

불필요한 쿠키를 삭제합니다.

쿠키 를 가능한 한 작게 만들어 사용자 응답 시간에 미치는 영향을 최소화합니다.

쿠키 설정에 주의하세요. 다른 하위 도메인에 영향을 미치지 않도록 도메인 수준을 적절히 설정하세요.

적절한 유효 기간을 설정하세요. 유효 기간을 더 일찍 설정하거나 없음을 사용하면 쿠키를 더 빠르게 삭제하고 사용자 응답 시간을 개선할 수 있습니다

24. 구성 요소를 cookie

category: cookie

을 포함하지 않는 도메인 아래에 배치합니다. 브라우저가 정적 이미지에 대한 요청을 보내면 cookie도 함께 전송되며 서버에서는 이러한 쿠키가 필요하지 않습니다. 따라서 의미 없는 네트워크 트래픽만 발생시키므로 정적 구성 요소에 대한 요청에 cookies가 포함되지 않도록 해야 합니다. 하위 도메인을 생성하고 여기에 모든 정적 구성 요소를 배포할 수 있습니다.

도메인 이름이 www.example.org 인 경우 정적 구성 요소를 static.example.org 에 배포할 수 있습니다. 그러나 cookies가 최상위 도메인 example.org 또는 www.example.org 에 설정된 경우 static.example.org 에 대한 모든 요청에는 다음이 포함됩니다. 이것들은 쿠키입니다. 이때 새 도메인 이름을 구입하고 모든 정적 구성 요소를 배포하며 새 도메인 이름에 cookies이 없도록 유지할 수 있습니다. Yahoo!는 yimg.com을 사용하고 있습니다. Images-amazon.com 등. cookie이 포함되지 않은 도메인에 정적 구성 요소를 배포할 때의 또 다른 이점은 일부 프록시가 cookie가 포함된 구성 요소 캐시를 거부할 수 있다는 것입니다. 한 가지 참고할 점: 홈페이지로 example.org 또는

www.example.org

중 무엇을 사용할지 모르는 경우

cookies의 영향을 고려해 볼 수 있습니다. www를 생략하면 cookie를 *.example.org 에 쓸 수 있으므로 성능상의 이유로 www 하위 도메인을 사용하고 cookie를 넣는 것이 가장 좋습니다. 이 하위 도메인에 글을 쓰세요. 25.최소화DOMvisit

Category: javascript

JavaScript를 사용하여 DOM 요소에 액세스하는 것은 매우 느리므로 페이지 응답 속도를 높이려면 다음을 수행해야 합니다.

노드를 DOM 트리

에 추가하기 전에 노드를 먼저 "오프라인"으로 업데이트하세요.

레이아웃 문제를 해결하기 위해

JavaScript 사용을 피하세요자세한 내용은 YUI를 확인하세요. Cinema Julien Lecomte

의 기사:

High Performance Ajax Application

26.

스마트 이벤트 핸들러 사용

Category

: javascript 가끔은 그럴때도 있어요 페이지가 반영하는 것처럼 너무 많은 자주 실행되는 이벤트 핸들러가 DOM 트리의 다른 요소에 추가되기 때문에 충분히 민감하지 않습니다. 이것이 이벤트 위임이 권장되는 이유입니다. div 에 10 버튼이 있는 경우 각 버튼에 이벤트 핸들러를 추가하는 대신

div

컨테이너에만 이벤트 핸들러를 추가해야 합니다. 이벤트가 버블링될 수 있으므로 이벤트를 캡처하고 어떤 버튼이 이벤트 소스인지 알 수 있습니다.

DOM 트리를 처리하기 위해 onload 이벤트를 기다릴 필요가 없습니다. 일반적으로 DOM 트리에서 대상 요소에 액세스할 수 있으면 됩니다. 모든 이미지가 다운로드될 때까지 기다릴 필요가 없습니다. onload 이벤트 대신 DOMContentLoaded 사용을 고려할 수 있지만 모든 브라우저에서 사용할 수 있도록 하려면 onAvailable 메서드가 있는

YUI 이벤트

도구를 사용할 수 있습니다.

자세한 내용은 YUI Cinema Julien Lecomte

의 기사를 확인하세요.

High Performance Ajax Application

27.선택 7a6a6e6fc80b42f5186c39fb2e6badd5

@import

Classification

삭제: css

앞서 언급한 모범 사례: 프로그레시브 렌더링을 달성하려면

CSS

를 맨 위에 배치해야 합니다.

IE에서 @import 를 사용하는 것은 하단의

2cdf5bf648cf2f33323966d7f58a7f3f

을 사용하는 것과 같은 효과가 있으므로 사용하지 않는 것이 가장 좋습니다.

28.

필터 사용을 피하세요

Category

: cssIEProprietaryAlphaImageLoader 필터를 사용하여 IE7을(를) 수정할 수 있습니다. 해당 버전의 반투명

PNG

이미지에 문제가 있습니다. 이미지 로딩 과정에서 이 필터는 렌더링을 차단하고, 브라우저를 정지시키며, 메모리 소모를 늘리고, 각 이미지가 아닌 각 요소에 적용되므로 많은 문제가 발생하게 됩니다. 🎜🎜🎜🎜

가장 좋은 방법은 AlphaImageLoader 를 사용하지 않고 IE에서 잘 지원되는 PNG8 이미지를 사용하도록 정상적으로 다운그레이드하는 것입니다. AlphaImageLoader 를 사용해야 하는 경우 IE7 사용자에게 영향을 주지 않도록 밑줄 hack: _filter 을 사용해야 합니다.

29.사진 최적화

Category: 사진

디자이너가 사진을 만든 후 에 업로드하세요. web 서버 이전에는 우리가 할 수 있는 몇 가지 일.

팔레트 크기에 해당하는 색상 수가 그림에 사용되었는지 확인하려면

GIF 그림을 확인하세요. imagemagick 을 사용하여 간단히 확인하세요. identify -verbose image.gif

4 컬러 사진이 팔레트의 256 색상 "슬롯"을 사용하는 경우 개선의 여지가 있습니다.

GIF 사진을 PNG로 변환해 보세요. 크기를 줄일 수 있다면 종종 그렇게 할 수 있습니다. 개발자들은 제한된 브라우저 지원으로 인해 PNG 이미지 사용을 꺼리는 경우가 많았지만 이는 과거의 일입니다. 진짜 문제는 PNG 이미지는 alpha 투명도를 완벽하게 지원하는 반면 GIF 이미지는 투명도 그라디언트를 지원하지 않으므로 GIF는 무엇이든 할 수 있습니다. PNG 예( 애니메이션 제외). 다음의 간단한 명령으로 PNG 이미지를 안전하게 사용할 수 있습니다. convert image.gif image.png

"우리가 강조하는 것은

PNG

에게 기회를

사용하라는 것입니다." pngcrush

(또는 기타 PNG 최적화 도구)는 모든 PNG 이미지를 처리합니다. 예: pngcrush image.png -rem alla -reduce -brute result.png

jpegtran

Pro 사용 세스 모든 JPEG이미지 이 도구는 회전과 같은 JPEG이미지에 대한 무손실 작업을 지원하며 주석 및 기타 불필요한 정보(예: EXIFinformationP.S. )를 제거하는 데에도 사용할 수 있습니다. 디지털 사진 정보, 초점 거리, 조리개 등): jpegtran -copy none -optimize -perfect src.jpg dest.jpg

30.

Optimization

CSS Sprite

Classification

Pictures

Sprite

가로로 배열된 이미지는 일반적으로 세로로 배열된 최종 파일보다 작습니다이미지의 iningsprite

smilar 색상 이미지의 색상은 색상 수를 낮게 유지할 수 있습니다. 사진에 큰 공백이 있습니다. 이미지 파일 크기에 큰 영향을 미치지는 않지만, 그렇게 하면 이미지를 픽셀 맵으로 압축 해제할 때 사용자 에이전트가 소비하는 메모리를 절약할 수 있습니다. 100 1만 픽셀. 31.사용하지 마세요

HTML

사진 확대 Category: 사진사용하지 마세요 HTML 너비와 높이를 설정할 수 있습니다 에서는 이 Big Picture 필수를 사용할 수 없습니다. 필요한 경우 1acf00d8da3c1b4d1e485bf03581baac 그런 다음 이미지 자체(mycat.jpg)

500x500px 사진을 축소하는 대신 100x100px이어야 합니다. ㅋㅋㅋ Pictures

favicon .ico은 서버의 루트 디렉토리에 있는 이미지는 무시해도 브라우저가 자동으로 요청하므로 404 Not Found

응답을 제공하지 않는 것이 가장 좋습니다. 그리고 동일한 서버에 있는 한

는 요청될 때마다 전송되며, 이 이미지는 예를 들어 IE

에서 추가 요청 시 다운로드 순서를 방해합니다.

onload

구성 요소를 설치하면

favicon이 먼저 다운로드됩니다. 따라서 favicon.ico의 단점을 완화하려면 다음 사항을 확인해야 합니다.

은 충분히 작고, 바람직하게는 1K 미만이어야 합니다. 적절한 유효 기간을 설정합니다. HTTP 헤더(나중에) 변경하려면 이름을 바꿀 수 없습니다.) 일반적으로 유효 기간을 몇 달 이후로 설정하는 것이 마지막 수정 날짜를 확인하여 브라우저에 적용되는지 확인할 수 있습니다. 현재 favicon.ico

Imagemagick 은 작은 즐겨찾기 아이콘을 처리하는 데 사용할 수 있습니다

33.

모든 구성 요소가 25K Category보다 작음을 보장합니다. 모바일

这个限制是因为iPhone不能缓存大于25K的组件，注意这里指的是未压缩的大小。这就是为什么缩减内容本身也很重要，因为单纯的gzip可能不够。

更多信息请查看Wayne Shea和Tenni Theurer的文章： Performance Research, Part 5: iPhone Cacheability – Making it Stick

34.把组件打包到一个复合文档里

分类: 移动

把各个组件打包成一个像有附件的电子邮件一样的复合文档里，可以用一个HTTP请求获取多个组件（记住一点：HTTP请求是代价高昂的）。用这种方式的时候，要先检查用户代理是否支持（iPhone就不支持）。

35.避免图片src属性为空

分类: 服务器

Image with empty string src 属性是空字符串的图片很常见，主要以两种形式出现：

straight HTML

<img src=””>

JavaScript

var img = new Image();img.src = 
“”
;

这两种形式都会引起相同的问题：浏览器会向服务器发送另一个请求。

IE 向页面所在目录发起一个请求

Safari和Chrome 想当前页面本身发送一个请求

Firefox 3及更早版本与Safari和Chrome处理方式一样，但3.5解决了这个问题 [bug 444931] ，不会再发送请求了

Opera 遇到有空src属性的图片不做任何处理

为什么图片src属性为空不好？

意外发送大量的通信量对服务器来说是很伤的，尤其是在每天有几百万访问量页面的时候。

浪费服务器资源去生成一个根本不可能被看到的页面

可能会污染用户数据，如果追踪请求状态，要么通过cookie要么是其它方式，可能会破坏用户数据。即使图片请求并没有返回图片，整个HTTP头部也会被浏览器接受并读取，包括所有的cookie。虽然其余部分会被丢弃，但这可能已经造成破坏了。

문제의 근본 원인은 브라우저가 URI를 처리하는 방식의 차이입니다. 이는 RFC 3986 – Uniform Resource Identifiers 문서에 명확하게 정의되어 있습니다. URI가 빈 문자열인 경우 상대 URI로 처리되며 섹션 5.2에 정의된 알고리즘에 따라 처리됩니다. 실제 상황은 문서의 섹션 5.4에 나열된 사양에 따라 that Firefox, safari 및 chrome 모두 빈 문자열을 처리하는 반면, ie는 그렇지 않다는 것입니다. 올바르게 처리하십시오. 사양 문서 RFC 2396 – Uniform Resource Identifiers(RFC 3986에 의해 폐기됨)의 이전 버전에서는 엄격한 의미에서 브라우저가 상대 URI를 처리한다고 합니다. 모두 정답입니다. 문제는 이 경우 빈 문자열이 의도하지 않은 것이 분명하다는 것입니다(P.S. 및 일부 친척 URI이 아님).

HTML5

의

4.8.2 섹션에는 브라우저가 더 이상 추가 요청을 보내지 않도록 지정하는 a1f02c36ba31691bcfe87b2722de723b 태그 src 속성에 대한 설명이 있습니다.

src 속성이 있어야 하며, 요소의 기본 URI가 문서와 동일한 경우 비대화형, 선택적으로 애니메이션, 이미지 리소스를 참조하는 유효한 URL을 포함해야 합니다.

s 주소인 경우 src 속성's 값은 빈 문자열이 아니어야 합니다.（P.S. 대화형 애니메이션 또는 이미지 리소스는 요소의 기본 URI에 페이지를 매기거나 스크립트를 포함할 수 없습니다. 문서 주소와 동일하면 src 속성 값은 빈 문자열일 수 없습니다.").

위 내용은 Yahoo의 군사 규정에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!

성명：

이전 기사：완전한 프론트엔드 개발 매뉴얼 문서(html css jquery html5 포함) 매뉴얼 다운로드다음 기사：완전한 프론트엔드 개발 매뉴얼 문서(html css jquery html5 포함) 매뉴얼 다운로드