개요: 직장에서든 인터뷰에서든 웹 프런트엔드 성능을 최적화하는 것은 매우 중요합니다. 그렇다면 최적화를 시작하려면 어떤 측면이 필요합니까? 프런트엔드 최적화를 위해서는 Yahoo의 34 Catch-Rules를 따를 수 있지만, 이제는 35가 되어서 프런트엔드 최적화를 위한 Yahoo의 Catch-35라고 할 수 있습니다. 분류가 되어 있어서 최적화 방향이 더 명확해졌습니다.
내용 부분 1. HTTP 요청 수를 최소화하세요.최종 사용자 응답 시간의 80%는 프런트 엔드에서 소요되며, 대부분의 시간은 이미지, 스타일시트, 스크립트, 플래시 등 페이지의 다양한 구성 요소를 다운로드하는 데 소요됩니다. 구성 요소 수를 줄이면 페이지에서 제출되는 HTTP 요청 수가 필연적으로 줄어듭니다. 이것이 페이지를 더 빠르게 만드는 열쇠입니다.
페이지 구성 요소 수를 줄이는 한 가지 방법은 페이지 디자인을 단순화하는 것입니다. 하지만 응답 시간을 단축하면서 복잡한 페이지를 구축할 수 있는 방법이 있을까요? 글쎄, 실제로 케이크를 갖고 그것을 먹는 방법도 있습니다.
파일을 병합하면 모든 스크립트를 하나의 파일에 저장하여 요청 수를 줄일 수 있습니다. 물론 모든 CSS를 병합할 수도 있습니다. 각 페이지의 스크립트와 스타일이 다른 경우 파일을 병합하는 것은 번거로운 작업이 될 수 있지만 사이트 게시 프로세스의 일부로 이 작업을 수행하면 실제로 응답 시간을 향상시킬 수 있습니다. CSS 스프라이트 는 이미지 요청 수를 줄이는 데 선호되는 방법입니다. 모든 배경 이미지를 하나의 이미지로 통합한 후 CSS background-image, background-position 속성을 이용하여 표시할 부분의 위치를 지정합니다. 이미지 매핑은 여러 이미지를 단일 이미지로 결합할 수 있으며 전체 크기는 동일하지만 요청 수를 줄이고 페이지 로딩 속도를 높입니다. 이미지 매핑은 탐색 모음과 같이 이미지가 페이지에 연속적으로 표시되는 경우에만 유용합니다. 이미지 맵의 좌표를 설정하는 과정은 지루하고 오류가 발생하기 쉽고, 네비게이션을 위해 이미지 맵을 사용하는 것이 쉽지 않기 때문에 이 방법은 권장되지 않습니다. 인라인 이미지(Base64 인코딩)는 data: URL 패턴을 사용하여 이미지를 페이지에 삽입합니다. 이렇게 하면 HTML 파일의 크기가 증가하며 (캐시된) 스타일 시트에 인라인 이미지를 넣는 것이 페이지를 무겁게 만드는 것을 방지하는 좋은 방법입니다. 그러나 현재 주류 브라우저는 인라인 이미지를 잘 지원하지 않습니다.페이지에 대한 HTTP 요청 수를 줄이는 것은 사이트의 첫 방문 속도를 향상시키기 위한 중요한 지침 원칙입니다.
2. DNS 조회 감소도메인 이름 시스템은 전화번호부의 이름과 번호 간의 매핑과 유사하게 호스트 이름과 IP 주소 간의 매핑을 설정합니다. 브라우저에 www.yahoo.com을 입력하면 브라우저는 DNS 확인자에 접속하여 서버의 IP 주소를 반환합니다. DNS에는 비용이 듭니다. 특정 호스트 이름에 대한 IP 주소를 찾는 데 20~120밀리초가 걸립니다. 브라우저는 DNS 조회가 완료될 때까지 호스트 이름에서 아무것도 다운로드할 수 없습니다.
DNS 조회는 사용자의 ISP(인터넷 서비스 공급자) 또는 로컬 네트워크의 특수 캐싱 서버에 보다 효율적으로 캐시되지만 개별 사용자의 컴퓨터에도 캐시될 수 있습니다. DNS 정보는 운영 체제의 DNS 캐시(Microsoft Windows의 DNS 클라이언트 서비스)에 저장됩니다. 대부분의 브라우저에는 운영 체제와 독립적인 자체 캐시가 있습니다. 브라우저가 이 기록을 캐시에 유지하는 한 운영 체제에 DNS를 쿼리하지 않습니다.
IE는 DnsCacheTimeout 레지스트리 설정에 기록된 대로 기본적으로 30분 동안 DNS 조회를 캐시합니다. Firefox는 1분 동안 캐시하며, 이는 network.dnsCacheExpiration 구성 항목을 사용하여 설정할 수 있습니다. (Fasterfox는 캐시 시간을 1시간으로 변경했습니다. PS Fasterfox는 FF용 속도 향상 플러그인입니다.)
클라이언트의 DNS 캐시가 비어 있는 경우(브라우저 및 운영 체제 포함) DNS 조회 수는 페이지 URL, 이미지, 스크립트 파일, 스타일 시트, 플래시 개체 및 기타를 포함하여 페이지의 다양한 호스트 이름 수와 동일합니다. 호스트 이름 구성 요소를 변경하여 다른 호스트 이름을 줄이면 DNS 조회가 줄어들 수 있습니다.
서로 다른 호스트 이름 수를 줄이면 페이지가 병렬로 다운로드할 수 있는 구성 요소 수도 줄어듭니다. DNS 조회를 피하면 응답 시간이 줄어들고, 병렬 다운로드 수를 줄이면 응답 시간이 늘어납니다. 내 규칙은 구성 요소를 2~4개의 호스트 이름에 분산시키는 것입니다. 이는 DNS 조회를 줄이고 높은 동시 다운로드를 허용하는 것 사이의 절충안입니다.
3. 리디렉션 방지리디렉션은 301 및 302 상태 코드를 사용합니다. 다음은 301 상태 코드가 있는 HTTP 헤더입니다.
HTTP/1.1 301 영구적으로 이동됨위치: http://example.com/newuriContent-Type: text/html
브라우저는 위치 필드에 지정된 URL로 자동으로 이동합니다. 리디렉션에 필요한 모든 정보는 HTTP 헤더에 있으며 응답 본문은 일반적으로 비어 있습니다. 실제로 Expires 및 Cache-Control과 같은 추가 HTTP 헤더도 리디렉션을 나타냅니다. 리디렉션하는 다른 방법도 있습니다. 메타 태그와 JavaScript를 새로 고치는 것입니다. 하지만 리디렉션을 수행해야 하는 경우 주로 뒤로 버튼이 제대로 작동할 수 있도록 표준 3xx HTTP 상태 코드를 사용하는 것이 가장 좋습니다.
사용자와 HTML 문서 사이에 리디렉션을 삽입하면 HTML 문서가 제공될 때까지 페이지가 렌더링되지 않고 구성 요소 다운로드가 시작되지 않습니다. 브라우저.
리소스를 극도로 낭비하는 일반적인 리디렉션이 있으며 웹 개발자는 일반적으로 이를 인식하지 못하며 URL 끝에 슬래시가 누락된 경우입니다. 예를 들어, http://astrology.yahoo.com/astrology로 이동하면 http://astrology.yahoo.com/astrology/로 리디렉션되는 301 응답이 반환됩니다(후행 슬래시 참고). Apache에서는 Alias, mod_rewrite 또는 DirectorySlash 명령을 사용하여 불필요한 리디렉션을 취소할 수 있습니다.
리디렉션의 가장 일반적인 용도는 이전 사이트를 새 사이트에 연결하는 것입니다. 또한 동일한 사이트의 다른 부분을 연결하고 사용자의 다양한 상황(브라우저 유형, 사용자 계정 유형 등)에 따라 일부 처리를 수행할 수도 있습니다. . 리디렉션을 사용하여 두 웹사이트를 연결하는 것이 가장 간단하며 약간의 추가 코드만 필요합니다. 이 때 리디렉션을 사용하면 개발자의 개발 복잡성이 줄어들지만 사용자 경험은 감소합니다. 대안은 두 코드 경로가 모두 동일한 서버에 있는 경우 Alias 및 mod_rewrite를 사용하는 것입니다. 도메인 이름이 변경되어 리디렉션을 사용하는 경우 Alias 또는 mod_rewrite 지시문과 결합된 CNAME(다른 도메인 이름을 별칭으로 가리키는 DNS 레코드 생성)을 생성할 수 있습니다.
4. Ajax를 캐시 가능하게 만들기Ajax의 장점 중 하나는 백엔드 서버에서 비동기적으로 정보를 요청할 수 있기 때문에 사용자에게 즉각적인 피드백을 제공할 수 있다는 것입니다. 그러나 Ajax를 사용하면 비동기 JavaScript 및 XML 응답이 돌아올 때까지 기다리는 동안 사용자가 지루해하지 않을 것이라는 보장이 없습니다. 많은 애플리케이션에서 사용자가 기다릴 수 있는 능력은 Ajax가 어떻게 사용되는지에 따라 달라집니다. 예를 들어, 웹 기반 이메일 클라이언트에서 사용자는 검색 기준과 일치하는 이메일 메시지를 찾기 위해 Ajax 요청에서 반환된 결과에 계속 집중합니다. 비동기식은 즉각적인 것을 의미하지 않는다는 점을 기억하는 것이 중요합니다.
성능을 향상시키려면 이러한 Ajax 응답을 최적화하는 것이 중요합니다. Ajax 성능을 향상시키는 가장 중요한 방법은 만료 또는 Cache-Control HTTP 헤더 추가에서 설명한 대로 응답을 캐시 가능하게 만드는 것입니다. Ajax에는 다음과 같은 추가 규칙이 적용됩니다.
자동 완성 기능을 위해 사용자의 주소록을 다운로드하기 위해 Ajax를 사용하는 Web 2.0 이메일 클라이언트의 예를 살펴보겠습니다. 사용자가 마지막 사용 이후 주소록을 수정하지 않았고 Ajax 응답이 캐시 가능하고 만료되지 않은 Expires 또는 Cache-Control HTTP 헤더가 있는 경우 이전 주소록을 캐시에서 읽을 수 있습니다. 브라우저는 이전에 캐시된 주소록 응답을 계속 사용해야 하는지 아니면 새 응답을 요청해야 하는지 알려야 합니다. 이는 사용자 주소록의 마지막 수정 시간을 나타내는 타임스탬프를 주소록의 Ajax URL에 추가하여 달성할 수 있습니다(예: &t=1190241612). 마지막 다운로드 이후 주소록이 수정되지 않았고 타임스탬프가 변경되지 않은 경우 주소록은 브라우저 캐시에서 직접 읽혀지므로 추가 HTTP 왕복이 방지됩니다. 사용자가 주소록을 수정한 경우 타임스탬프는 새 URL이 캐시된 응답과 일치하지 않고 브라우저가 새 주소록 항목을 요청하도록 보장합니다.
Ajax 응답은 동적으로 생성되고 단일 사용자에게만 제공될 수 있지만 캐시될 수 있으므로 Web 2.0 애플리케이션이 더 빨라집니다.
5. 구성요소의 지연 로딩페이지를 자세히 살펴보고 자문해 보세요. 먼저 페이지를 렌더링하려면 무엇이 필요한가요? 나머지는 기다릴 수 있습니다.
JavaScript는 onload 이벤트 전후를 분리하는 데 이상적인 선택입니다. 예를 들어 끌어서 놓기 및 애니메이션을 지원하는 JavaScript 코드 및 라이브러리가 있는 경우 페이지가 처음 렌더링된 후에 끌어서 놓기 요소가 발생하므로 기다릴 수 있습니다. 지연 로드될 수 있는 다른 섹션에는 숨겨진 콘텐츠(상호작용 후 나타나는 콘텐츠)와 축소된 이미지가 포함됩니다.
도구는 작업량을 줄이는 데 도움이 됩니다. YUI Image Loader는 축소된 이미지를 지연 로드할 수 있으며 YUI Get 유틸리티는 JS 및 CSS를 가져오는 쉬운 방법입니다. Yahoo! 홈페이지가 예입니다. Firebug의 네트워크 패널을 열고 자세히 살펴볼 수 있습니다.
성능 목표를 점진적인 향상과 같은 다른 웹 개발 모범 사례에 맞추는 것이 가장 좋습니다. 클라이언트가 JavaScript를 지원하면 사용자 경험이 향상될 수 있지만 JavaScript가 지원되지 않는 경우에도 페이지가 제대로 작동하는지 확인해야 합니다. 따라서 페이지가 제대로 작동한다고 확신하면 지연 로딩 스크립트를 사용하여 페이지를 향상시켜 드래그 앤 드롭 및 애니메이션과 같은 멋진 효과를 지원할 수 있습니다.
6. 구성요소를 예압하세요
사전 로딩은 지연 로딩의 반대처럼 보일 수 있지만 실제로는 다른 목표를 가지고 있습니다. 구성 요소를 미리 로드하면 브라우저의 유휴 시간을 최대한 활용하여 향후 사용할 구성 요소(이미지, 스타일 및 스크립트)를 요청할 수 있습니다. 사용자가 다음 페이지에 액세스하면 대부분의 구성 요소가 이미 캐시에 있으므로 사용자 관점에서 페이지가 더 빠르게 로드됩니다.
실제 애플리케이션에는 다음과 같은 유형의 사전 로드가 있습니다.
페이지가 복잡할수록 다운로드할 바이트가 늘어나고 JavaScript를 사용하여 DOM에 액세스하는 속도가 느려집니다. 예를 들어, 이벤트 핸들러를 추가하려는 경우 페이지에서 500개의 DOM 요소를 반복하는 것과 5,000개의 DOM 요소를 반복하는 것에는 차이가 있습니다.
DOM 요소가 많다는 것은 페이지에 정리해야 할 관련 없는 마크업이 있다는 신호입니다. 레이아웃에 중첩 테이블을 사용하고 있나요? 아니면 레이아웃 문제를 해결하기 위해 <div>를 여러 개 추가했습니까? 아마도 더 나은 의미론적 마크업을 사용해야 할 것입니다.
YUI CSS 유틸리티는 레이아웃에 매우 유용합니다. Grids.css는 전체 레이아웃을 위한 것이고, Fonts.css 및 Reset.css는 브라우저의 기본 서식을 제거하는 데 사용할 수 있습니다. 개행을 렌더링하기 때문이 아니라 의미상 의미가 있을 때만 <div>를 사용하는 등 마크업을 정리하고 생각해볼 수 있는 좋은 기회입니다.
DOM 요소의 수는 테스트하기 쉽습니다. Firebug 콘솔에 다음을 입력하기만 하면 됩니다.
document.getElementsByTagName('*').length그렇다면 얼마나 많은 DOM 요소가 너무 많습니까? 예를 들어, Yahoo! 홈페이지는 매우 바쁜 페이지이지만 요소(HTML 태그)가 700개 미만입니다.
8. 구성 요소의 도메인 간 분리구성 요소를 분리하면 병렬 다운로드를 최대화할 수 있지만 DNS 조회 패널티가 있으므로 도메인을 2~4개 이하만 사용하도록 하십시오. 예를 들어 www.example.org에 HTML 및 동적 콘텐츠를 배포하고 정적 구성 요소를 static1.example.org 및 static2.example.org로 분리할 수 있습니다.
9. iframe을 가능한 적게 사용하세요iframe을 사용하여 HTML 문서를 상위 문서에 삽입할 수 있습니다. iframe의 작동 방식을 이해하고 효율적으로 사용하는 것이 중요합니다.
<iframe>의 장점:
<iframe>의 단점:
HTTP 요청은 비용이 많이 듭니다. 쓸모 없는 응답(예: 404 찾을 수 없음)을 얻기 위해 HTTP 요청을 사용할 필요는 없습니다. 이는 아무런 이점도 없이 사용자 경험을 저하시킬 뿐입니다.
일부 사이트에서는 유용한 404 - xxx를 의미합니까?를 사용합니다. , 이는 사용자 경험에 도움이 되지만 서버 리소스(예: 데이터베이스 등)를 낭비하기도 합니다. 최악의 상황은 연결한 외부 JavaScript에 오류가 있어 결과가 404라는 것입니다. 첫째, 이 다운로드는 병렬 다운로드를 차단합니다. 둘째, 브라우저는 404 응답 본문이 JavaScript 코드이고 사용 가능한 부분을 찾아야 하기 때문에 구문 분석을 시도합니다.
CSS 부분 11. CSS 표현식 사용을 피하세요CSS 표현식을 사용하여 CSS 속성을 동적으로 설정하는 것은 강력하면서도 위험한 방법입니다. IE5에서는 지원되지만 IE8에서는 더 이상 사용되지 않습니다. 예를 들어 CSS 표현식을 사용하여 배경색을 시간별로 번갈아 표시하도록 설정할 수 있습니다.
배경색: 표현식( (new Date()).getHours()%2 ? #B8D4FF : #F08A00 );12. @import를 삭제하려면 <link>를 선택하세요.
앞서 언급한 모범 사례는 프로그레시브 렌더링을 달성하려면 CSS를 맨 위에 배치해야 한다는 것입니다.
IE에서 @import를 사용하면 하단의 <link>를 사용하는 것과 같은 효과가 있으므로 사용하지 않는 것이 가장 좋습니다.
13. 필터 사용을 피하세요IE의 독점 AlphaImageLoader 필터를 사용하면 IE7 이전 버전의 반투명 PNG 이미지 문제를 해결할 수 있습니다. 이미지 로딩 과정에서 이 필터는 렌더링을 차단하고, 브라우저를 정지시키며, 메모리 소모를 늘리고, 각 이미지가 아닌 각 요소에 적용되므로 많은 문제가 발생하게 됩니다.
가장 좋은 방법은 단순히 AlphaImageLoader를 사용하지 않고 대신 IE에서 잘 지원되는 PNG8 이미지를 사용하도록 우아하게 다운그레이드하는 것입니다. AlphaImageLoader를 사용해야 하는 경우 IE7 이상의 사용자에게 영향을 주지 않도록 밑줄 hack:_filter를 사용해야 합니다.
14. 스타일 시트를 상단에 배치Yahoo!에서 성능을 연구할 때 문서의 HEAD 섹션에 스타일 시트를 배치하면 페이지가 더 빠르게 로드되는 것처럼 보인다는 사실을 발견했습니다. 이는 스타일 시트를 헤드에 배치하면 페이지가 점진적으로 렌더링될 수 있기 때문입니다.
성능에 관심이 있는 프런트엔드 엔지니어는 페이지가 점진적으로 렌더링되기를 원합니다. 즉, 우리는 브라우저가 기존 콘텐츠를 가능한 한 빨리 표시하기를 원합니다. 이는 페이지에 콘텐츠가 많거나 사용자의 인터넷 연결이 매우 느린 경우 특히 중요합니다. 사용자에게 피드백(예: 진행률 표시기)을 표시하는 것의 중요성은 널리 연구되고 문서화되었습니다. 우리의 경우에는 HTML 페이지가 진행률 표시기입니다! 브라우저가 페이지 헤더, 탐색 모음, 상단 로고 등을 점진적으로 로드하면 페이지 로드를 기다리는 사용자의 피드백으로 사용되어 전반적인 사용자 경험을 향상시킬 수 있습니다.
js 부분 15. 중복 스크립트 제거중복된 스크립트 파일이 포함된 페이지는 생각보다 성능에 더 많은 영향을 미칠 수 있습니다. 미국 내 상위 10개 웹사이트를 검토한 결과 중복된 스크립트가 포함된 사이트는 단 2개뿐이었습니다. 단일 페이지에 중복 스크립트가 나타날 가능성이 높아지는 두 가지 주요 이유는 팀 규모와 스크립트 수입니다. 이 경우 중복 스크립트는 불필요한 HTTP 요청을 생성하고 쓸모 없는 JavaScript 코드를 실행하며 페이지 성능에 영향을 미칩니다.
IE는 불필요한 HTTP 요청을 생성하지만 Firefox는 그렇지 않습니다. IE에서는 캐시할 수 없는 외부 스크립트가 페이지에 두 번 도입되면 페이지가 로드될 때 두 개의 HTTP 요청이 생성됩니다. 스크립트가 캐시 가능하더라도 사용자가 페이지를 다시 로드하면 추가 HTTP 요청이 생성됩니다.
의미 없는 HTTP 요청을 생성하는 것 외에도 스크립트를 여러 번 평가하면 시간이 낭비됩니다. 스크립트의 캐시 가능 여부에 관계없이 중복된 JavaScript 코드가 Firefox 및 IE에서 실행되기 때문입니다.
실수로 동일한 스크립트를 두 번 가져오는 것을 방지하는 한 가지 방법은 템플릿 시스템에 스크립트 관리 모듈을 구현하는 것입니다. 스크립트를 도입하는 일반적인 방법은 HTML 페이지에서 SCRIPT 태그를 사용하는 것입니다.
<script type=text/javascript src=menu_1.0.17.js></script>16. DOM 액세스 최소화
JavaScript를 사용하여 DOM 요소에 액세스하는 것은 매우 느리므로 페이지의 반응성을 높이려면 다음을 수행해야 합니다.
자주 실행되는 이벤트 핸들러가 DOM 트리의 다른 요소에 너무 많이 추가되었기 때문에 페이지가 충분히 응답하지 않는 것처럼 느껴질 때가 있습니다. 이것이 바로 이벤트 위임이 권장되는 이유입니다. div에 10개의 버튼이 있는 경우 각 버튼에 하나씩 이벤트 핸들러를 추가하는 대신 div 컨테이너에 이벤트 핸들러를 하나만 추가해야 합니다. 이벤트가 버블링될 수 있으므로 이벤트를 캡처하고 어떤 버튼이 이벤트 소스인지 알 수 있습니다.
18. 스크립트를 하단에 넣어주세요스크립트는 병렬 다운로드를 차단합니다. 공식 HTTP/1.1 문서에서는 브라우저가 호스트 이름당 두 개 이상의 구성 요소를 병렬로 다운로드하지 말 것을 권장합니다. 이미지가 여러 호스트 이름에서 제공되는 경우 병렬 다운로드 수가 2개를 초과할 수 있습니다. 스크립트가 다운로드되는 경우 브라우저는 다른 호스트 이름을 사용해도 다른 다운로드 작업을 시작하지 않습니다.
때로는 스크립트를 하단으로 이동하는 것이 쉽지 않습니다. 예를 들어 document.write를 사용하여 스크립트가 페이지 콘텐츠에 삽입된 경우 더 아래로 이동할 수 있는 방법이 없습니다. 범위 지정 문제가 있을 수도 있으며 대부분의 경우 해결이 가능합니다.
일반적인 제안은 지연된 스크립트를 사용하는 것입니다. DEFER 속성이 있는 스크립트는 document.write를 포함할 수 없으며 브라우저에 렌더링을 계속할 수 있다는 메시지를 표시합니다. 불행하게도 Firefox는 DEFER 속성을 지원하지 않습니다. IE에서는 스크립트가 지연될 수 있지만 예상한 것과는 다릅니다. 스크립트를 연기할 수 있는 경우 이를 페이지 하단으로 이동하면 페이지가 더 빠르게 로드됩니다.
자바스크립트, CSS 19. 자바스크립트와 CSS를 외부에 두세요많은 성능 원칙은 외부 구성 요소를 관리하는 방법과 관련되어 있지만 이러한 문제가 발생하기 전에 보다 기본적인 질문을 던져야 합니다. JavaScript와 CSS를 외부 파일에 배치해야 할까요, 아니면 페이지에 직접 작성해야 할까요?
실제로 외부 파일을 사용하면 JavaScript 및 CSS 파일이 브라우저에 캐시되므로 페이지 속도가 더 빨라질 수 있습니다. HTML 문서가 요청될 때마다 HTML 문서의 인라인 JavaScript 및 CSS가 다시 다운로드됩니다. 이렇게 하면 필요한 HTTP 요청 수가 줄어들지만 HTML 문서의 크기가 늘어납니다. 반면에 JavaScript와 CSS가 외부 파일에 있고 브라우저에 의해 캐시된 경우 HTTP 요청 수를 늘리지 않고도 HTML 문서를 더 작게 만드는 데 성공했습니다.
20. JavaScript와 CSS를 최소화하세요압축은 특히 코드에서 불필요한 문자를 제거하여 크기를 줄이고 로딩 속도를 향상시킵니다. 코드 최소화는 모든 주석과 불필요한 공백 문자(공백, 줄 바꿈 및 탭)를 제거하는 것을 의미합니다. JavaScript에서 이 작업을 수행하면 다운로드할 파일이 더 작기 때문에 응답성이 향상될 수 있습니다. 가장 일반적으로 사용되는 두 가지 JavaScript 코드 압축 도구는 JSMin과 YUI 압축기로 CSS를 압축할 수도 있습니다.
난독화는 압축보다 더 복잡한 선택적 소스 코드 최적화 방법이므로 난독화 프로세스에서 버그가 발생할 가능성도 더 높습니다. 미국 상위 10개 웹사이트를 대상으로 한 조사에 따르면 압축은 크기를 21%, 난독화는 25% 줄일 수 있습니다. 난독화는 더 높은 수준의 축소를 제공하지만 압축보다 더 위험합니다.
외부 스크립트 및 스타일을 압축하는 것 외에도 인라인 <script> 및 <style> 블록도 압축할 수 있습니다. gzip 모듈이 활성화된 경우에도 먼저 압축하면 크기가 5% 이상 줄어들 수 있습니다. JavaScript와 CSS를 점점 더 많이 사용하므로 코드를 압축하면 좋은 효과가 있습니다.
그림 21. 이미지 최적화GIF 형식을 PNG 형식으로 변환해 보고 공간이 절약되는지 확인해 보세요. 모든 PNG 이미지에 대해 pngcrush(또는 기타 PNG 최적화 도구) 실행
22. CSS 스프라이트 최적화HTML에서 너비와 높이를 설정할 수 있다고 해서 필요한 것보다 더 큰 이미지를 사용하지 마세요. 필요한 경우
<img width=100 height=100 src=mycat.jpg 호스트: us.yimg.com If-Modified-Since: 2006년 12월 12일 화요일 03:03:59 GMT If-None-Match: 10c24bc-4ab-457e1c1f HTTP/ 1.1 304 수정되지 않음32. Ajax에 GET 요청 사용
Yahoo! Mailbox 팀은 XMLHttpRequest를 사용할 때 브라우저의 POST 요청이 먼저 HTTP 헤더를 보낸 다음 데이터를 보내는 2단계 프로세스를 통해 구현된다는 사실을 발견했습니다. 따라서 (쿠키가 너무 많지 않은 경우) TCP 메시지만 보내면 되는 GET 요청을 사용하는 것이 가장 좋습니다. IE의 최대 URL 길이는 2K이므로 전송할 데이터가 2K를 초과하는 경우 GET을 사용할 수 없습니다.
POST 요청의 흥미로운 부작용은 GET 요청처럼 실제로 데이터가 전송되지 않는다는 것입니다. HTTP 문서에 설명된 대로 GET 요청은 정보를 검색하는 데 사용됩니다. 따라서 그 의미는 서버에 저장해야 하는 데이터를 보내는 것이 아니라 데이터를 요청하기 위해 GET 요청을 사용하는 것입니다.
33. 가능한 한 빨리 버퍼를 지우십시오.사용자가 페이지를 요청하면 서버는 HTML 페이지를 조합하는 데 약 200~500밀리초가 걸리며, 이 시간 동안 브라우저는 유휴 상태에서 데이터가 도착할 때까지 기다립니다. PHP에는 플러시() 함수가 있는데, 이를 통해 준비된 HTML 응답의 일부를 브라우저에 보낼 수 있으므로 브라우저는 백그라운드에서 나머지 부분을 준비하는 동안 구성 요소를 가져오기 시작할 수 있습니다. 이점은 주로 반영됩니다. 매우 바쁜 배경이나 매우 가벼운 프런트 엔드에서 (PS 즉, 응답 시간이 주로 배경에 있을 때 장점이 가장 잘 반영됩니다.)
버퍼를 지우는 이상적인 위치는 HEAD 다음입니다. HTML의 HEAD 부분은 일반적으로 생성하기가 더 쉽고 CSS 및 JavaScript 파일을 도입할 수 있어 배경이 계속 처리되는 동안 브라우저가 병렬로 구성 요소 가져오기를 시작할 수 있기 때문입니다. .
예를 들어:
... <!-- CSS, js --> </head> <?php 플러시() ?> <body> ... <!-- 내용 -->34. CDN(콘텐츠 전송 네트워크) 사용
사용자와 서버의 물리적 거리도 응답 시간에 영향을 미칩니다. 지리적으로 분산된 여러 서버에 콘텐츠를 배포하면 사용자가 페이지를 더 빠르게 로드할 수 있습니다. 하지만 어떻게 해야 할까요?
지리적으로 분산된 콘텐츠를 구현하는 첫 번째 단계는 다음과 같습니다. 분산된 구조를 수용하도록 웹 애플리케이션을 다시 디자인하려고 하지 마십시오. 애플리케이션에 따라 구조 변경에는 세션 상태 동기화 및 서버 간 데이터베이스 트랜잭션 복제와 같은 어려운 작업이 포함될 수 있습니다(번역이 정확하지 않을 수 있음). 사용자와 콘텐츠 사이의 거리를 단축하자는 제안은 이런 어려움으로 인해 지연되거나 아예 통과가 불가능할 수도 있습니다.
최종 사용자 응답 시간의 80~90%가 페이지 구성 요소(이미지, 스타일, 스크립트, 플래시 등)를 다운로드하는 데 소요된다는 점을 기억하십시오. 이는 성능에 대한 황금률입니다. 처음부터 애플리케이션 구조를 다시 디자인하는 것보다 정적 콘텐츠를 먼저 분산시키는 것이 더 좋습니다. 이는 응답 시간을 크게 단축할 뿐만 아니라 CDN의 기여도를 더 쉽게 입증할 수 있게 해줍니다.
CDN(콘텐츠 전송 네트워크)은 사용자에게 콘텐츠를 보다 효율적으로 전달하기 위해 서로 다른 지리적 위치에 분산된 웹 서버 그룹입니다. 일반적으로 콘텐츠를 전달하기 위해 선택된 서버는 네트워크 거리 측정에 따라 결정됩니다. 예를 들어 홉 수가 가장 적거나 응답 시간이 가장 빠른 서버를 선택합니다.
35. Expires 또는 Cache-Control HTTP 헤더 추가이 규칙에는 두 가지 측면이 있습니다.
웹 디자인이 더욱 풍부해지고 있으며 이는 페이지에 더 많은 스크립트, 이미지 및 플래시가 있다는 것을 의미합니다. 사이트의 새로운 방문자는 여전히 몇 가지 HTTP 요청을 제출해야 할 수 있지만 만료 날짜를 사용하면 구성 요소를 캐시할 수 있게 되어 후속 검색 세션 중에 불필요한 HTTP 요청을 피할 수 있습니다. 만료 HTTP 헤더는 일반적으로 이미지에 사용되지만 스크립트, 스타일, 플래시 구성요소를 포함한 모든 구성요소에도 사용해야 합니다.
브라우저(및 프록시)는 캐싱을 사용하여 HTTP 요청의 수와 크기를 줄여 페이지가 더 빠르게 로드되도록 합니다. 웹 서버는 Expiration HTTP 응답 헤더를 사용하여 페이지의 각 구성 요소를 캐시해야 하는 기간을 클라이언트에게 알려줍니다. 만료 날짜로 먼 미래의 시간을 사용하면 이 응답이 2010년 4월 15일 이전에는 변경되지 않을 것임을 브라우저에 알립니다.
만료: 2010년 4월 15일 목요일 20:00:00 GMT
Apache 서버를 사용하는 경우 ExpiresDefault 지시어를 사용하여 현재 날짜를 기준으로 만료 날짜를 설정합니다. 다음 예에서는 요청 시간으로부터 10년의 유효 기간을 설정합니다.
ExpiresDefault 액세스 + 10년
위의 내용은 이 기사의 전체 내용입니다. 모든 분들의 학습에 도움이 되기를 바랍니다. 또한 모든 분들이 VeVb Wulin Network를 지지해 주시길 바랍니다.