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%이 귀하의 사이트를 방문하는 시간입니다. 비어 있는. 따라서 페이지의 첫 번째 방문 속도를 높이는 것은 사용자 경험을 향상시키는 데 매우 중요합니다.
2.사용 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에서는 스크립트가 지연될 수 있지만 예상한 것과는 다릅니다. 스크립트를 연기할 수 있는 경우 이를 페이지 하단에 배치하면 페이지가 더 빠르게 로드됩니다.
7.
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을 사용하지만 페이지가 로드된 후 외부 파일을 동적으로 로드하여 후속 페이지에 필요한 외부 파일이 이미 브라우저에 배치되도록 하는 것입니다. 캐시.
9.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% 줄였습니다. 난독화는 더 높은 수준의 축소를 제공하지만 압축보다 더 위험합니다.
외부 스크립트 및 스타일을 압축하는 것 외에도 인라인 <script> <span style="font-family: 宋体"> 및 </span><span style="font-family: Calibri"><style> 블록도 압축할 수 있습니다. </span><span style="font-family: 宋体">gzip</span><span style="font-family: Calibri"> 모듈이 활성화되어 있어도 먼저 압축하면 크기가 </span><span style="font-family: 宋体">5%</span><span style="font-family: Calibri"> 이상 줄어들 수 있습니다. </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri">와 </span><span style="font-family: 宋体">CSS</span><span style="font-family: Calibri">는 점점 더 유용해지고 있으므로 코드를 압축하면 좋은 효과를 얻을 수 있습니다. </span><span style="font-family: 宋体"></span> </p> <p></p>11.<p>리디렉션 방지<strong><span style="font-family: 宋体"></span></strong> </p> <p></p>Categories<p>: <span style="font-family: 宋体">Content</span><span style="font-family: 宋体"></span> </p> <p></p>리디렉션 <p>301<span style="font-family: 宋体"> 및 </span> <span style="font-family: 宋体">302</span><span style="font-family: Calibri"> 상태 코드, 다음은 </span> <span style="font-family: 宋体">301입니다. </span><span style="font-family: Calibri"> 상태 코드 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 헤더: </span><span style="font-family: 宋体"></span> </p> <p>HTTP/1.1 301 영구적으로 이동됨</p> <p> 위치:</p> <p> 콘텐츠 유형: text/html</p> <p> </p>브라우저가 자동으로 <p> 위치로 이동합니다. <span style="font-family: 宋体"></span>URL <span style="font-family: 宋体"></span> <span style="font-family: Calibri">도메인에서 지정합니다. 리디렉션에 필요한 모든 정보는 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 헤더에 있으며 응답 본문은 일반적으로 비어 있습니다. 실제로 </span><span style="font-family: 宋体">Expires </span><span style="font-family: Calibri"> 및 </span><span style="font-family: 宋体">Cache-Control </span><span style="font-family: Calibri">과 같은 추가 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 헤더도 리디렉션을 나타냅니다. 그 밖에도 </span><span style="font-family: 宋体">refresh</span><span style="font-family: Calibri"> 메타 태그와 </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri"> 등 다른 리디렉션 방법도 있지만 리디렉션을 해야 한다면 주로 표준 </span><span style="font-family: 宋体">3xxHTTP</span><span style="font-family: Calibri"> 상태 코드를 사용하는 것이 가장 좋습니다. 돌아가기 버튼이 제대로 작동합니다. </span><span style="font-family: 宋体"></span> </p> <p></p>리디렉션은 사용자 경험을 저하시킬 수 있다는 점을 명심하십시오. 사용자와 <p>HTML<span style="font-family: 宋体"> 문서 사이에 리디렉션을 삽입하면 페이지의 모든 내용이 지연되고 페이지가 렌더링되지 않으며 구성 요소가 다운로드를 시작하지 않습니다. 까지 </span><span style="font-family: 宋体">HTML</span> <span style="font-family: Calibri">문서가 브라우저에 제공됩니다. </span><span style="font-family: 宋体"></span> </p> <p></p>리소스를 극도로 낭비하는 일반적인 리디렉션이 있으며 <p>web<span style="font-family: 宋体">개발자는 일반적으로 이를 인식하지 못합니다. 이는 </span><span style="font-family: 宋体">URL</span><span style="font-family: Calibri"> 끝에 슬래시가 누락된 경우입니다. 예를 들어 </span><span style="font-family: 宋体"> </span><span style="font-family: Calibri">로 점프하면 </span><span style="font-family: 宋体"> </span><span style="font-family: Calibri">로 리디렉션되는 </span><span style="font-family: 宋体">301</span><span style="font-family: Calibri"> 응답이 반환됩니다(뒤에 슬래시가 있음). </span><span style="font-family: 宋体">Apache</span><span style="font-family: Calibri">에서는 </span><span style="font-family: 宋体">Alias </span><span style="font-family: Calibri">, </span><span style="font-family: 宋体">mod_rewrite </span><span style="font-family: Calibri"> 또는 </span><span style="font-family: 宋体">DirectorySlash </span><span style="font-family: Calibri"> 명령을 사용하여 불필요한 리디렉션을 취소할 수 있습니다. </span><span style="font-family: 宋体"></span></p> <p><span style="font-family: 宋体">리디렉션의 가장 일반적인 용도는 이전 사이트를 새 사이트에 연결하는 것입니다. 또한 동일한 사이트의 다른 부분을 연결하고 사용자의 다양한 상황(브라우저 유형, 사용자 계정 유형 등)에 따라 일부 처리를 수행할 수도 있습니다. .). 리디렉션을 사용하여 두 웹사이트를 연결하는 것이 가장 간단하며 약간의 추가 코드만 필요합니다. 이 때 리디렉션을 사용하면 개발자의 개발 복잡성이 줄어들지만 사용자 경험은 감소합니다. 대안은 두 코드 경로가 동일한 서버에 있는 경우 </span> Alias <span style="font-family: 宋体"> 및 </span><span style="font-family: Calibri">mod_rewrite </span><span style="font-family: 宋体">을 사용하는 것입니다. 도메인 이름 변경으로 인해 리디렉션이 사용되는 경우 </span><span style="font-family: Calibri">별칭 </span><span style="font-family: 宋体"> 또는 </span><span style="font-family: Calibri">과 결합된 </span><span style="font-family: 宋体">CNAME</span><span style="font-family: Calibri">(다른 도메인 이름을 별칭으로 가리키는 </span><span style="font-family: 宋体">DNS</span><span style="font-family: Calibri"> 레코드 만들기)을 만들 수 있습니다. mod_rewrite </span><span style="font-family: 宋体"> 명령 . </span></p> <p></p> <p><strong>12.<span style="font-family: 宋体">중복 스크립트 제거</span></strong></p> <p></p> <p><span style="font-family: 宋体">Category</span>: javascript</p> <p></p> <p><span style="font-family: 宋体">페이지 성능에 영향을 미치며, 이는 여러분이 생각하는 것과 다를 수 있습니다. 미국 내 상위 </span><span style="font-family: 宋体">web</span><span style="font-family: Calibri"> 사이트를 검토한 결과, 중복된 스크립트가 포함된 사이트는 </span><span style="font-family: 宋体">2</span><span style="font-family: Calibri">개에 불과했습니다. 단일 페이지에 중복 스크립트가 있을 가능성이 높아지는 두 가지 주요 이유는 팀 규모와 스크립트 수입니다. 이 경우 중복 스크립트는 불필요한 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 요청을 생성하고 쓸모 없는 </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri"> 코드를 실행하며 페이지 성능에 영향을 미칩니다. </span><span style="font-family: 宋体"></span> </p> <p>IE</p>는 불필요한 <p><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 요청을 생성하지만 </span><span style="font-family: 宋体">Firefox</span><span style="font-family: Calibri">는 그렇지 않습니다. </span><span style="font-family: 宋体">IE</span><span style="font-family: Calibri">에서 캐시할 수 없는 외부 스크립트가 페이지에 두 번 도입되면 페이지가 로드될 때 두 개의 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 요청이 생성됩니다. 스크립트가 캐시 가능하더라도 사용자가 페이지를 다시 로드하면 추가 </span><span style="font-family: 宋体">HTTP</span><span style="font-family: Calibri"> 요청이 생성됩니다. </span><span style="font-family: 宋体"></span> </p> <p></p> 의미 없는 <p>HTTP<span style="font-family: 宋体"> 요청을 생성하는 것 외에도 스크립트를 여러 번 평가하는 것도 시간 낭비입니다. 스크립트의 캐시 가능 여부에 관계없이 중복된 </span><span style="font-family: 宋体">JavaScript</span><span style="font-family: Calibri"> 코드는 </span><span style="font-family: 宋体">Firefox</span><span style="font-family: Calibri"> 및 </span><span style="font-family: 宋体">IE</span><span style="font-family: Calibri">에서 실행됩니다. </span><span style="font-family: 宋体"></span> </p> <p></p>실수로 동일한 스크립트를 두 번 도입하는 것을 방지하는 한 가지 방법은 템플릿 시스템에 스크립트 관리 모듈을 구현하는 것입니다. 스크립트를 소개하는 일반적인 방법은 <p>HTML<span style="font-family: 宋体"> 페이지에서 </span><span style="font-family: 宋体">SCRIPT</span><span style="font-family: Calibri"> 태그를 사용하는 것입니다. </span><span style="font-family: 宋体"></span> </p> <p><script type="text/javascript" src="menu_1.0.17.js?1.1.11 "> </script>
PHP
의 대안은insertScript 라는 함수를 만드는 것입니다. <?php insertScript("menu.js?1.1.11") ?>
"영구적인" 유효성 HTTP 헤더를 지원하기 위해 스크립트 파일 이름에 버전 번호 추가 등의 기타 스크립트 관련 문제.
13.ConfigurationETags
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 헤더가 있더라도 사용자가 다시 로드하거나 새로 고치기 위해 클릭하면 조건부 ETags에서 제공하는 유연한 검증 모델을 사용하지 않으려면 Etag를 모두 제거하고 구성요소 기반 타임스탬프 Last-Modified HTTP 헤더를 사용하는 것이 가장 좋습니다. 확인하고 ETag를 제거하면 HTTP 응답 헤더 및 후속 요청의 크기를 줄일 수 있습니다. Microsoft 지원 문서 에서는 ETags를 제거하는 방법을 설명합니다. Apache에서는 Category: Content 의 장점 중 하나는 백엔드 서버에서 비동기적으로 정보를 요청할 수 있기 때문에 사용자에게 즉각적인 피드백을 제공할 수 있다는 것입니다. 그러나 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文件，这样就可以让浏览器在后台还在处理的时候就开始并行获取组件。 例如： 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 요소는 신호입니다. 페이지에 정리해야 할 관련 없는 태그가 있습니다. 레이아웃에 중첩 테이블을 사용하고 있나요? 아니면 레이아웃 문제를 해결하기 위해 YUI CSS 유틸리티 는 레이아웃에 매우 유용합니다. grids.css전체 레이아웃의 경우 fonts.css 및 reset.css을 사용하여 브라우저의 기본값을 제거할 수 있습니다. 체재. 개행을 렌더링하기 때문이 아니라 의미상 의미가 있을 때만 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을 이해하는 것입니다. 작동 방식 및 효율적으로 사용합니다. ... <!-- css, js -->
</head>
<?php flush(); ?>
<body>
... <!-- content -->
