Yahoo Fourteen: 웹사이트 프런트엔드 웹페이지 최적화를 위한 14가지 원칙

웹 애플리케이션 성능 최적화의 황금률: 최종 사용자 응답 시간의 80% 이상이 소요되는 프론트엔드 프로그램(front-end)의 성능을 먼저 최적화하십시오. .

규칙 1. HTTP 요청 수를 줄이세요

최종 사용자 응답 시간의 80%는 프런트 엔드 프로그램에 소비되며, 이 시간의 대부분은 이미지, 스타일 시트, 스크립트, 플래시 등과 같은 다양한 페이지 요소를 다운로드하는 데 소비됩니다. 페이지 요소를 줄이면 HTTP 요청 수가 줄어듭니다. 이는 페이지를 빠르게 표시하는 데 중요합니다.

페이지 요소 수를 줄이는 한 가지 방법은 페이지 디자인을 단순화하는 것입니다. 하지만 풍부한 콘텐츠와 빠른 응답 시간을 모두 달성할 수 있는 또 다른 방법이 있을까요? 다음은 그러한 기술 중 일부입니다.

이미지 맵여러 이미지를 하나의 이미지로 결합합니다. 전체 파일 크기는 크게 변하지 않지만, HTTP 요청 수가 줄어들고 페이지가 더 빠르게 표시됩니다. 이 방법은 연속적인 그림에만 적합하며 좌표 정의는 번거롭고 오류가 발생하기 쉬운 작업입니다.

CSS Sprites가 더 나은 방법입니다. 페이지의 이미지를 단일 파일로 결합하고 CSS background-image 및 background-position 속성을 사용하여 이미지의 필요한 부분을 구현합니다.

인라인 이미지는 data: URL 구성표를 사용하여 페이지에 이미지를 삽입합니다. 이렇게 하면 HTML 파일의 크기가 늘어납니다. 인라인 이미지를 (캐시된) 스타일시트에 결합하는 것은 HTTP 요청을 줄이고 HTML 파일 크기 증가를 방지하는 방법입니다.

결합된 파일은 여러 스크립트 파일을 단일 파일로 결합하여 HTTP 요청 수를 줄입니다. 스타일 시트도 비슷하게 처리할 수 있습니다. 이 방법은 간단하지만 대규모로 사용되지는 않았습니다. 미국 상위 10개 웹사이트에는 페이지당 평균 7개의 스크립트 파일과 2개의 스타일 시트가 있습니다. 이 접근 방식은 스크립트와 스타일시트가 페이지마다 크게 다를 때 어려울 수 있지만, 완료하면 응답 시간을 단축할 수 있습니다.

HTTP 요청 수를 줄이는 것이 성능 최적화의 출발점입니다. 이는 첫 방문의 효율성을 높이는 데 중요한 역할을 합니다. Tenni Theurer의 기사 Browser Cache Usage - Exposed!에 따르면 일일 방문의 40~60%가 최초 방문이므로 최초 방문자의 페이지 액세스 속도를 높이는 것이 사용자 경험의 핵심입니다.

저희 앱:

대외 무역: 홈페이지에 있는 수십 개의 작은 아이콘을 하나로 병합하고 CSS를 통해 표시를 제어하며 HTTP 요청 수를 줄입니다.

규칙 2. CDN(Content Delivery Network, Content Delivery Network)을 사용하세요

사용자와 웹 서버의 거리도 응답 시간에 큰 영향을 미칩니다. 사용자 관점에서 보면 지리적으로 분산된 여러 서버에 콘텐츠를 배포하면 페이지 로딩 속도가 효과적으로 향상됩니다. 하지만 어디서부터 시작해야 할까요?

콘텐츠의 지리적 배포를 향한 첫 번째 단계에서는 배포 아키텍처에 맞게 웹 애플리케이션을 리팩터링하려고 하지 마세요. 스키마를 변경하면 세션 상태 동기화, 여러 서버 간의 데이터베이스 트랜잭션 복제 등 여러 주기적인 작업이 수행됩니다. 사용자와 콘텐츠 사이의 거리를 단축하려는 이러한 시도는 애플리케이션 아키텍처의 변화로 인해 지연되거나 차단될 수 있습니다.

또한 최종 사용자 응답 시간의 80-90%가 이미지 파일, 스타일시트, 스크립트, 플래시 등과 같은 페이지의 다양한 요소를 다운로드하는 데 소요된다는 점을 기억합니다. 시스템을 리팩터링하는 어려운 작업을 수행하는 대신 정적 콘텐츠를 먼저 배포하세요. 이는 응답 시간을 크게 단축할 뿐만 아니라 CDN 덕분에 정적 콘텐츠 배포가 매우 쉽게 구현됩니다.

CDN은 콘텐츠를 보다 효율적으로 게시하는 데 사용되는 지리적으로 분산된 웹 서버 모음입니다. 특정 사용자에게 서비스를 제공하는 웹 서버는 일반적으로 네트워크 거리에 따라 선택됩니다.

일부 대형 웹사이트에는 자체 CDN이 있지만 Akamai Technologies, Mirror Image Internet, Limelight Networks 등 CDN 서비스 제공업체의 서비스를 이용하는 것이 비용 효율적입니다. Yahoo!에서는 정적 콘텐츠를 CDN에 배포하면 사용자 영향 시간이 20% 이상 단축됩니다. 코드를 변경하여 CDN으로 전환하는 것은 쉽지만 웹사이트 속도를 높일 수 있습니다.

저희 앱:

아직 사용되지는 않았지만 고객 보고에 따르면 광동성, 산동성 등의 네트워크 상태가 상대적으로 좋지 않다고 합니다. CDN을 통해 주 대역폭을 차지하는 정적 리소스를 해제할 수 있다면 크게 도움이 될 것이라고 믿습니다. 현재 웹 사이트 액세스 속도 문제를 완화합니다.

규칙 3. 만료 헤더 추가

웹 콘텐츠가 점점 더 풍부해지고 있으며 이는 더 많은 스크립트 파일, 스타일 시트, 이미지 파일 및 플래시를 의미합니다. 처음 방문자는 여러 HTTP 요청에 직면해야 하지만 Expires 헤더를 사용하면 클라이언트 측에서 이러한 요소를 캐시할 수 있습니다. 이렇게 하면 후속 방문 시 불필요한 HTTP 요청을 방지할 수 있습니다. Expires 헤더는 이미지 파일에 가장 일반적으로 사용되지만 스크립트 파일, 스타일시트 및 플래시에도 사용해야 합니다.

브라우저(및 프록시)는 캐싱을 사용하여 HTTP 요청 수와 크기를 줄여 웹페이지가 더 빠르게 로드되도록 합니다. 웹 서버는 Expires 헤더를 통해 요소를 캐시할 수 있는 기간을 클라이언트에게 알려줍니다.

서버가 Apache인 경우 ExpiresDefault를 사용하여 다음과 같이 현재 날짜를 기준으로 만료 날짜를 설정할 수 있습니다.

ExpiresDefault '액세스 플러스 10년'은 만료 시간을 요청 시간으로부터 10년으로 설정합니다.

매우 긴 만료 시간을 사용하는 경우 콘텐츠가 변경되면 파일 이름을 수정해야 한다는 점을 기억하세요. Yahoo!에서는 릴리스 프로세스의 한 단계에서 이름을 바꾸는 경우가 많습니다. 버전 번호는 yahoo_2.0.6.js와 같이 파일 이름에 포함됩니다.

저희 앱:

외국 무역: JS, CSS 및 이미지의 캐시는 Apache에서 구성됩니다. 정적 리소스를 업데이트해야 하는 경우 클라이언트가 최신 버전을 얻을 수 있도록 파일 버전 번호를 수정하는 솔루션이 채택됩니다. 🎜>

E-Network: E-Network의 프로브 규칙(JS)은 고객의 설정에 따라 생성되지만 기본적으로 오랜 기간 동안 변경되지 않으므로 규칙 생성 시 만료 응답 헤더를 추가합니다. 클라이언트 요청 수와 프로브 규칙 생성을 최소화합니다.

규칙 4. 페이지 요소 압축

HTTP 응답 콘텐츠를 압축하여 페이지 응답 시간을 줄입니다. HTTP/1.1부터 웹 클라이언트는 HTTP 요청의 Accept-Encoding 헤더를 통해 지원되는 압축 유형을 나타냅니다. 예:

인코딩 허용: gzip, deflate.

웹 서버가 Accept-Encoding 헤더를 확인하면 클라이언트가 지원하는 방법을 사용하여 HTTP 응답을 압축하고 Content-Encoding: gzip과 같은 Content-Encoding 헤더를 설정합니다.

Gzip은 현재 가장 널리 사용되고 효과적인 압축 방법입니다. 수축과 같은 다른 방법은 덜 효과적이며 충분히 대중적이지 않습니다. Gzip을 사용하면 일반적으로 콘텐츠를 70%까지 줄일 수 있습니다. Apache의 경우 버전 1.3에서는 mod_gzip 모듈을 사용해야 하고, 버전 2.x에서는 mod_deflate를 사용해야 합니다.

웹 서버는 파일 형식에 따라 압축 여부를 결정합니다. 대부분의 웹사이트는 HTML 파일을 압축합니다. 그러나 스크립트 파일과 스타일시트를 압축하는 것도 가치가 있습니다. 실제로 XML 및 JSON을 포함한 작업 텍스트 정보를 압축하는 것은 가치가 있습니다. 이미지 파일과 PDF 파일은 본질적으로 압축되어 있으므로 압축하면 안 됩니다. 압축하면 CPU가 낭비될 뿐만 아니라 파일 크기도 커질 수 있습니다.

따라서 가능한 한 많은 파일 형식을 압축하는 것은 페이지 크기를 줄이고 사용자 경험을 향상시키는 쉬운 방법입니다.

저희 앱:

대외 무역, E-net 소진, K 계획: 사람들은 600K 이상의 ext2 패키지를 압축한다고 생각할 것입니다. 압축 효과는 나쁘지 않고 150K만 넘습니다. 게다가 JS, CSS, HTML도 최대한 압축해 놓았습니다. 아직도 많은 고객들이 1M ADSL을 사용하고 있다는 사실을 아셔야 합니다.

Rule 5. 스타일 시트를 머리 위로 올려주세요

스타일 시트를 HEAD 섹션으로 이동하면 인터페이스 로딩 속도가 향상되어 페이지 요소가 순차적으로 표시될 수 있다는 것을 확인했습니다.

IE 등 많은 브라우저에서 스타일 시트를 문서 하단에 배치할 때의 문제점은 웹 페이지 콘텐츠의 순차적 표시를 금지한다는 것입니다. 페이지 요소를 다시 그리는 것을 방지하기 위해 브라우저 블록이 표시되며 사용자에게는 빈 페이지만 표시됩니다. Firefox는 표시를 차단하지 않지만 이는 스타일시트를 다운로드한 후 일부 페이지 요소를 다시 그려야 할 수 있으며 이로 인해 깜박이는 문제가 발생할 수 있음을 의미합니다.

HTML 사양 에서는 스타일 시트를 HEAD에 정의해야 합니다. 따라서 빈 화면이나 깜박임 문제를 피하려면 HTML 사양을 따르고 스타일 시트를 HEAD에 배치하는 것이 가장 좋습니다.

저희 앱:

스타일시트를 문서 뒤에 넣는 상황은 없으셨나요?

Rule 6. 스크립트 파일은 하단에 배치하세요

스타일 파일과 마찬가지로 스크립트 파일의 위치에 주의해야 합니다. 페이지 하단에 배치하여 한편으로는 순차적으로 표시하고 다른 한편으로는 최대 병렬 다운로드를 달성할 수 있도록 해야 합니다.

스타일 시트가 다운로드될 때까지 브라우저가 표시를 차단하므로 스타일 시트를 HEAD 섹션에 넣어야 합니다. 스크립트의 경우 스크립트 뒤에 있는 콘텐츠의 순차적 표시가 차단되므로 스크립트를 최대한 하단에 배치하면 더 많은 콘텐츠를 빠르게 표시할 수 있습니다.

스크립트로 인해 발생하는 두 번째 문제는 병렬 다운로드 횟수를 차단한다는 것입니다. HTTP/1.1 사양에서는 브라우저가 호스트당 병렬 다운로드 수를 2개 이하로 제한할 것을 권장합니다. 따라서 이미지 파일을 여러 시스템에 배포하는 경우 2개 이상의 병렬 다운로드를 달성할 수 있습니다. 그러나 스크립트 파일이 다운로드되면 브라우저는 다른 병렬 다운로드를 시작하지 않으며 다른 호스트에서의 다운로드도 시작하지 않습니다.

어떤 경우에는 스크립트를 하단으로 옮기기가 쉽지 않은 경우가 있습니다. 예를 들어 스크립트는 document.write 메서드를 사용하여 페이지 콘텐츠를 삽입합니다. 도메인 문제도 있을 수 있습니다. 그러나 많은 경우에는 여전히 몇 가지 방법이 있습니다.

대안은 지연된 스크립트를 사용하는 것입니다. DEFER 속성은 스크립트에 document.write가 포함되어 있지 않음을 나타내며 브라우저에 이를 즉시 계속 표시하도록 지시합니다. 불행하게도 Firefox는 DEFER 속성을 지원하지 않습니다. IE에서는 스크립트가 지연될 수 있지만 필요한 만큼 오래 지연될 필요는 없습니다. 하지만 다른 관점에서 보면 스크립트가 지연될 수 있다면 맨 아래에 배치할 수도 있습니다.

저희 앱:

이전에 깨닫지 못했을 수도 있지만 우리는 XCube XUI에 이 규칙을 구현했으며 이를 통해 페이지 액세스 성능을 더욱 향상시킬 수 있다고 믿습니다.

규칙 7. CSS 표현을 피하세요

CSS 표현식은 CSS 속성을 동적으로 설정하는 강력하면서도 위험한 방법입니다. IE는 버전 5부터 backgourd-color:expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”), 즉 배경색 전환과 같은 CSS 표현식을 지원합니다. 매시간 .

CSS 표현식의 문제점은 대부분의 사람들이 원하는 것보다 더 많이 실행된다는 것입니다. 표현식은 페이지가 표시되고 크기가 조정될 때뿐만 아니라 페이지가 스크롤될 때나 마우스가 페이지 위로 이동할 때에도 평가됩니다.

CSS 표현식이 실행되는 횟수를 줄이는 한 가지 방법은 표현식이 처음 실행될 때 명시적인 값으로 대체하는 원샷 표현식을 사용하는 것입니다. 동적으로 설정해야 하는 경우 이벤트 핸들러를 대신 사용할 수 있습니다. CSS 표현식을 사용해야 한다면 수천 번 실행되어 페이지 성능에 영향을 미칠 수 있다는 점을 기억하세요.

저희 앱:

현재 CSS 유지 관리 작업은 주로 UI 담당자의 책임이며, 이러한 상황을 피하기 위해 최선을 다하고 있습니다.

규칙 8. JavaScript와 CSS를 외부 파일에 넣기

위의 성능 최적화 규칙 중 다수는 외부 파일을 기반으로 최적화되었습니다. 이제 우리는 질문해야 합니다. JavaScript와 CSS를 외부 파일에 포함해야 할까요, 아니면 페이지 파일 내에 포함해야 할까요?

실제 환경에서는 외부 파일을 사용하면 브라우저에서 외부 파일을 캐시하므로 페이지 표시 속도가 빨라집니다. JavaScript와 CSS를 페이지에 내장하면 HTTP 요청 수는 줄어들지만 페이지 크기는 늘어납니다. 반면, 외부 파일을 사용하면 브라우저가 캐시하므로 HTTP 요청 수를 늘리지 않고도 페이지 크기가 줄어듭니다.

따라서 일반적으로 외부 파일을 사용하는 것이 더 실행 가능한 방법입니다. 유일한 예외는 Yahoo!와 My Yahoo!가 모두 인라인 방식을 사용하는 경우 인라인 방식이 더 효과적이라는 것입니다. 일반적으로 세션에서는 홈페이지 방문 횟수가 적기 때문에 인라인 방식을 사용하면 사용자 응답 시간이 더 빨라질 수 있습니다.

저희 앱:

대외 무역, E-net, K 계획: ext2 코드는 좋은 가이드를 제공합니다. 현재 프런트 엔드 개발자는 클라이언트 모듈의 캡슐화 및 재사용에 큰 관심을 기울이고 있으며 외부 JS를 통해 코드 재사용을 개선하려고 노력합니다. 물론 외부 리소스를 너무 많이 도입하지 않도록 주의해야 합니다. 이는 규칙 1을 위반하기 때문입니다.
현재 CSS 캡슐화도 좋지만 주로 IE 시리즈용 솔루션입니다. 브라우저 호환성 문제를 쉽게 해결하려면 YAML 및 Blueprint와 같은 CSS 프레임워크를 도입하는 것을 고려해 볼 수 있습니다.

규칙 9. DNS 쿼리 수를 줄이세요

DNS는 호스트 이름과 IP 주소를 매핑하는 데 사용됩니다. 일반적으로 확인하는 데 20~120밀리초가 걸립니다. 더 높은 성능을 달성하기 위해 DNS 확인은 일반적으로 ISP 또는 LAN에서 유지 관리하는 캐싱 서버, 로컬 컴퓨터 운영 체제(예: Windows의 DNS 클라이언트 서비스) 캐시 및 브라우저와 같은 여러 수준에서 캐시됩니다. IE의 기본 DNS 캐시 시간은 30분이고, Firefox의 기본 버퍼 시간은 1분입니다.

호스트 이름을 줄이면 DNS 쿼리 수는 줄어들 수 있지만 병렬 다운로드 수는 줄어들 수 있습니다. DNS 쿼리를 피하면 응답 시간이 줄어들 수 있고, 병렬 다운로드 수를 줄이면 응답 시간이 늘어날 수 있습니다. 실행 가능한 절충안은 최소 2개에서 최대 4개의 서로 다른 호스트 이름에 콘텐츠를 배포하는 것입니다.

저희 앱:

해외 무역: 브라우저의 다운로드 스레드 수 제한을 우회하기 위해 정적 리소스에 대해 여러 도메인 이름을 활성화했지만 그렇게 하면 이 규칙을 위반했습니다. 그러나 Windows IE의 경우 DNS 캐싱을 사용하면 이 문제를 완화할 수 있습니다.

규칙 10. JavaScript 코드 최소화

JavaScript 코드를 최소화한다는 것은 JS 코드에서 불필요한 문자를 제거하여 다운로드 시간을 줄이는 것을 의미합니다. 널리 사용되는 두 가지 도구는 #JSMin과 YUI Compressor입니다.

난독화는 소스 코드를 최소화하는 또 다른 방법입니다. 축소와 마찬가지로 주석과 공백을 제거하여 소스 코드 크기를 줄이고 코드를 난독화할 수도 있습니다. 난독화의 일환으로 함수 및 변수 이름이 짧은 문자열로 대체되어 코드가 더 간결해지고 가독성이 떨어지게 되어 리버스 엔지니어링이 어려워집니다. Dojo Compressor(ShrinkSafe)는 가장 일반적인 난독화 도구입니다.

최소화는 안전하고 간단한 프로세스인 반면, 난독화는 더 복잡하고 문제가 발생하기 쉽습니다. 미국 상위 10개 웹사이트를 조사한 결과, 최소화를 통해 파일을 21%, 난독화를 25% 줄일 수 있었습니다.

외부 스크립트 파일을 최소화하는 것 외에도 내장된 스크립트 코드도 최소화해야 합니다. 규칙 4에 따라 스크립트를 압축하여 전송하더라도 스크립트를 최소화하면 파일 크기가 5% 이상 줄어듭니다.

저희 앱:

JS 압축을 직접 사용하지는 않지만 ext2, jquery 등 우리가 사용하는 많은 구성 요소에서는 이미 이 규칙을 실행하고 있습니다.

규칙 11. 리디렉션 방지

리디렉션 기능은 다음과 같은 두 개의 HTTP 상태 코드 301 및 302를 통해 완료됩니다.

      HTTP/1.1 301 Moved Permanently

<span style="color: #000000">      Location: http://example.com/newuri</span>

      Content-Type: text/html

브라우저가 위치에 지정된 URL로 요청을 자동으로 리디렉션합니다. 리디렉션의 주요 문제는 사용자 경험을 감소시킨다는 것입니다.

리소스를 가장 많이 소모하고 자주 간과되기 쉬운 리디렉션 중 하나는 URL 끝에 /가 없다는 것입니다. 예를 들어 http://astrology.yahoo.com/astrology를 방문하면 http로 리디렉션됩니다. :/ /astrology.yahoo.com/astrology/. Apache에서는 Alias, mod_rewrite 또는 DirectorySlash를 통해 이 문제를 해결할 수 있습니다.

저희 앱:

숙련된 SA는 이 문제를 고려했습니다. 관심 있는 학생은 온라인 환경에 대한 Apache 구성 파일인 httpd.conf를 살펴볼 수 있습니다.

규칙 12. 중복된 스크립트 파일 삭제

페이지에 중복된 JS 스크립트 파일을 포함하면 성능에 영향을 미칩니다. 즉, 불필요한 HTTP 요청과 추가 JS 실행이 생성됩니다.

IE에서는 불필요한 HTTP 요청이 발생하지만 Firefox는 불필요한 HTTP 요청을 생성하지 않습니다. IE 또는 Firefox 여부에 관계없이 추가 JS 실행이 발생합니다.

스크립트 파일 중복을 방지하는 한 가지 방법은 템플릿 시스템을 사용하여 스크립트 관리 모듈을 만드는 것입니다. 중복된 스크립트 파일을 방지하는 것 외에도 이 모듈은 종속성 검사를 구현하고 스크립트 파일 이름에 버전 번호를 추가하여 매우 긴 만료 시간을 허용합니다.

저희 앱:

이 문제는 이전 버전의 Xplatform에서 더욱 심각하지만, 새 버전의 XCube에서는 같은 실수를 반복하지 않을 것이라고 믿습니다.

규칙 13. ETag 구성

ETags는 브라우저 캐시의 요소가 웹 서버의 요소와 일치하는지 확인하는 데 사용되는 메커니즘으로, 마지막 수정 날짜보다 더 유연한 요소 확인 메커니즘입니다. ETag는 요소의 버전을 고유하게 나타내는 문자열이며 따옴표로 묶어야 합니다. 웹 서버는 먼저 응답에서 ETag를 지정합니다.

      HTTP/1.1 200 OK

      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT

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

      Content-Length: 12195

나중에 브라우저가 요소를 확인해야 하는 경우 If-None-Match 헤더를 사용하여 ETag가 일치하면 서버는 304 코드를 반환하므로 다운로드가 저장됩니다. 시간:

      GET /i/yahoo.gif HTTP/1.1

      Host: 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의 문제점은 Apache1.3 및 2.x와 같은 서버 고유의 특정 속성을 기반으로 구성되고 형식이 inode-size-timestamp인 반면 IIS5.0 및 6.0의 경우 형식은 Filetimestamp:ChangeNumber입니다. 이러한 방식으로 서로 다른 웹 서버에 있는 동일한 요소의 ETag가 다릅니다. 이와 같이 다중 웹 서버 환경에서는 브라우저가 먼저 server1에 요소를 요청한 후 server2로 요소를 확인하므로 ETag가 다르기 때문에 캐시가 무효화되어 다시 다운로드해야 합니다.

따라서 ETags 시스템에서 제공하는 유연한 확인 메커니즘을 사용하지 않는 경우 ETag를 삭제하는 것이 가장 좋습니다. ETag를 제거하면 HTTP 응답의 크기와 후속 요청의 HTTP 헤더가 줄어듭니다. Microsoft 지원 문서에서는 ETag를 제거하는 방법을 설명하고, Apache에서는 구성 파일에서 FileETag none을 설정하면 됩니다.

저희 앱:

E-Net: ETag 생성 전략을 맞춤화하여 프로브 규칙 생성 횟수를 최소화합니다. 서버의 기본 ETag를 사용하지 않으므로 이 문제는 발생하지 않습니다.

다른 제품 라인: 주의하세요. 아무도 이것에 관심을 두지 않았습니다. Apache의 구성을 빨리 확인하세요.

규칙 14. Ajax 캐싱

성능 최적화 규칙은 Web 2.0 애플리케이션에도 적용됩니다. Ajax의 성능을 향상시키는 가장 중요한 방법은 "규칙 3: 만료 헤더 추가"에서 설명한 대로 응답을 캐시할 수 있도록 만드는 것입니다. 다음의 다른 규칙도 Ajax에 적용됩니다. 물론 규칙 3이 가장 효과적인 방법입니다.

규칙 4. 페이지 요소 압축

규칙 9. DNS 쿼리 수를 줄이세요

규칙 10. 스크립트 파일 최소화

규칙 11. 리디렉션 방지

규칙 13. ETag를 구성합니다.

저희 앱:

Ajax 요청이 캐시되는 것을 원하지 않는 경우가 더 많습니다. 이때는 각 Ajax 요청의 URL에 타임스탬프를 추가하기만 하면 됩니다.