오늘은 브라우저 캐싱이라고 불리우는 웹 브라우저에서 캐싱을 통해서 워드프레스 속도를 높이는 방법에 대해서 살펴 보도록 하겠습니다.

1. 브라우저 캐싱(Browser Caching)이란?

사용자와 서버간 응답 속도를 높이기 위해서는 웹 페이지 구성 요소들을 압축하는 방법과 사용자 PC에 관련 내용을 저장해 놓고 재방문시 사용하는 브라우저 캐싱(Browser Caching)이 있습니다. 이 중 압축방법에 대해서는 앞에서 설명을 드렸습니다.

브라우저 캐싱(Browser Caching)은 보다 전문적이 용어로는 HTTP 캐싱이라고 불리우는데요. 가장 간단하게 설명해서 웹 페이지 구성요소(즉 이미지, CSS 파일 등)을 사용자의 PC에 저장했다가 그 페이지를 다시 방문 시 사용자 PC에 저장된 요소를 꺼내 보여줌으로써 속도를 빠르게 하고 트랙픽 절감 효과를 주는 기법입니다.

이는 사이트를 처음 방문할땐 효과가 없지만 재방문시는 속도를 빠르게 할 수 있습니다. SEO에서 중요시하는 TTFB(Time To First Byte)에는 도움은 안되지만 전체 사용에서는 효과를 볼 수 있습니다.
흔히 컴퓨터 Temp 폴더를 보면 그동안 방문했던 사이트의 이미지 등등이 모여 있는 것을 볼 수 있는데요. 이게 바로 그 사이트에서 브라우저 캐싱(Browser Caching)을 설정했기 때문에 남아 있는 것입니다.

브라우저 캐싱(Browser Caching)을 위해 HTTP1.1 프로토콜에서는 만기일 (Expiration) 메커니즘과 검증 (Validation) 메커니즘을 사용합니다.

• 만기일 매커니즘 : 브라우저가 웹 페이지를 재방문 시 사용자 PC에 저장(caching)된 구성 요소의 만기일을 확인하고, 만기일이 지나지 않았으면 저장(Caching)된 구성 요소를 불러와 웹 페이지를 보여주는 방식입니다. 이 만기일은 서버 응답 헤더의 expires 항목 또는 Cache-Control 항목의 max-age를 통해서 설정 가능합니다.
• 검증(Validation) 매커니즘 : 사용자 PC에 저장(Caching)된 구성 요소가 캐쉬가 최신 상태인지를 확인하기위해 서버에 유효성 검사(validation) 요청을 보내서 저장(Caching)된 구성 요소 데이터를 새로 내려받을지를 검사하는 메커니즘입니다. 그 사이 서버에서 내용이 변경되었다면 다시 데이타를 받아 업데이트를 하고, 변경이 없다면 데이타를 새로 받지않고 저장(Caching)된 구성 요소의 만기일만 새롭게 업데이트 합니다.

2. 워드프레스에서 브라우저 캐싱(Browser Caching) 적용하기

워드프레스에서 브라우저 캐싱(Browser Caching) 적용하는 방법은 여러가지가 있습니다. 하나는 워드프레스 사용자라면 궁하면 떠올리는 플러그인이 있습니다. 워드프레스는 브라우저 캐싱(Browser Caching)을 도와주는 많은 플러그인이 있습니다. 또 하나는 서버 설정을 변경해 브라우저 캐싱(Browser Caching)이 가능토록 하는 방법입니다.

2.1. 브라우저 캐싱(Browser Caching)을 지원하는 플러그인

브라우저 캐싱(Browser Caching)을 적용하는 가장 간단한 방법은 플러그인을 사용하는 것입니다. 워드프레스에는 별의별 플러그인이 있는데 당연히 브라우저 캐싱(Browser Caching)를 지원하는 많은 플러그인이 있습니다.
우리가 흔히 캐시 플러그인이라고 불리우는 것들 중 많은 플러그인들이 브라우저 캐싱(Browser Caching)을 지원합니다.

이런 플러그인의 설정에서 속도를 향상 시키는 방법의 하나로 브라우저 캐싱(Browser Caching) 적용 여부를 선택하도록 되어 있습니다.

예를들어 W3 Total cache에는 아래에서 보는 것처럼 정말 많은 설정이 있는데요. 이중 아래 부분을 보면 브라우저 캐싱(Browser Caching)을 적용하는 부분이 있습니다. 다만 상세한 설정 옵션이 없어서 이를 반영하려면 별도 작업이 필요합니다.

다소 길드라도 워드프레스를 최적으로 사용하려면 얼마나 많은 항목들을 조정할 수 있는지를 보여주기 위해서 이미지를 첨부합니다.

저는 이러한 플러그인 사용을 별로 좋아하지 않기 때문에 이어서 서버에서 플러그인을 사용하지 않고 브라우저 캐싱(Browser Caching) 적용 방법을 살펴 보고자 합니다.

2.2. HTML 문서 내 meta 태그 활용

조금 오랜된 방법으로 HTML 문서내의 meta 태그 내에 브라우저 캐싱(Browser Caching) 관련 정보를 삽입하는 방법이 있습니다.

예를들면 아래와 같이 meta 태그안에 브라우저 캐싱(Browser Caching) 명령을 넣은 것입니다.

<HTML><HEAD>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
</HEAD><BODY>
</BODY>
</HTML>

그러나 이런 방식을 지원하는 브라우저가 한정되어 있으므로 최근에는 거의 사용되지 않는 방법입니다. 마이크로소프트에서 제공하는 IE 계열에서는 지원합니다.

2.3. 플러그인 없이 서버 설정으로 브라우저 캐싱(Browser Caching) 적용하기

서버에서 브라우저 캐싱(Browser Caching) 적용하는데 사용할 수 있는 명령 옵션은 아래와 같습니다.

Pragma

이전 버젼인 HTTP 1.0에서 사용하던 캐시를 제어하기 위해 사용되던 명령 옵션으로 esponse에 대한 HTTP 명세가 없고 request에서만 사용 가능해 처리되지 못하는 것들이 많은 명령 옵션입니다.
HTTP 1.1.로 업그레이드되면서 이를 대부분 대체 되었기에 사용하지 않토록 권장되고 있습니다.
(사실 조도 이렇게 공부하기 전까지는 이 명령 옵션을 같이 사용하고 있었습니다.)

Expires

저장(Caching)된 구성 요소의 만료 일자를 정의합니다. HTTP date 형태로 날짜를 지정하며 로컬타임이 아닌 GMT를 사용합니다.

Expires: Fri, 30 Oct 2018 20:11:21 GMT

규칙적으로 컨텐츠가 변경되는 경우는 유리하나 일일이 일정을 지정하기 어렵기 때문에 별로 상요되지는 않습니다.

Cache-Control

요즘 대부분 사용하는 명령 옵션으로 max-age로 마료 기간을 표시하고, Public/Private 등으로 cache 방식을 지정하는등 여러가지 옵션을 가지고 있습니다.

• max-age=[seconds] : 앞서 설명된 Expires와 동일한 의미지만 고정된 절대시간이 아닌 요청 시간으로부터 상대적 시간을 표시
• s-maxage=[seconds] : max-age와 동일한 의미지만 shared caches (예: proxy)에만 적용됨.
• public : 일반적으로 HTTP 인증이 된 상태에서 일어나는 응답은 자동으로 private 이 되지만 public을 명시적으로 설정하면 인증이된 상태더라도 캐시하도록 한다.
• private : 특정 유저의 브라우저에서만 캐쉬하도록 설정. 여러 사람이 사용하는 네트워크상의 중간자 (intermediaries)역할의 shared caches에는캐쉬되지 않음
• no-cache : 응답 데이터를 캐쉬하고는 있지만, 일단 먼저 서버에 요청해서 유효성 검사(validation)을 하도록 강제. 어느 정도 캐쉬의 효용을 누리면서도 컨텐츠의 freshness를 강제로 유지하는데 좋음.
• no-store : 어떤 상황에서도 해당 response 데이터를 저장하지 않음.
• no-transform : 이미지나 문서를 자동으로 최적화된 포멧으로 변환하지 않토록 함.
• must-revalidate : 금융거래등엑서 특정 상황(네트워크 연결이 끊어졌을때 등)에서는 fresh하지 않은 캐쉬 데이터는 상요하지 않토록 함.
• proxy-revalidate ; must-revalidate와 비슷하지만 proxy caches 에만 적용.

2..3.1. 아파치 서버 적용 예

아파치 서버에서는 적용하는 법입니다. 아파치에서는 Htaccess파일 앞부분에 관련 명령을 넣습니다.

먼저 Expires 헤더를 정의하는 방법입니다.

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType text/html "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType text/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 1 month"
</IfModule>
## EXPIRES CACHING ##

또 다른 방법으로는 Cache-Control 헤더를 추가하는 것이죠. 여기서는 max-age로 캐시 기간을 설정합니다.

# 1 Month for most static assets
<filesMatch ".(css|jpg|jpeg|png|gif|js|ico)


quot;>

Header set Cache-Control "max-age=2592000, public"

</filesMatch>


2.3.2. Nginx에서 브라우저 캐싱(Browser Caching) 설정
    # Aggressive caching for static files that rarely/never change
    location ~ \.(?:asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|ogv|otf|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|t?gz|tif|tiff|ttf|wav|webm|wma|woff|wri|xla|xls|xlsx|xlt|xlw|zip)$ {
    expires 31536000s;
    #add_header Pragma public; # HTTP1.0에서 사용하던 명령으로 같이 사용하지 않음
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    }

    location ~ \.(?:css|js)$ {
    expires 86400s; 
    #add_header Pragma public; # HTTP1.0에서 사용하던 명령으로 같이 사용하지 않음
    add_header Cache-Control "public, must-revalidate, proxy-revalidate";
    }

이렇게 브라우저 캐싱(Browser Caching) 적용토록 세팅했다면 이게 제대로 반영되고 있는지 확인해 봅시다.

이는 크롬 개발자도구 - 네트워크의 헤더 정보에서 확인할 수 있습니다.
▽ 크롬 개발자 도구에서 브라우저 캐싱(Browser Caching)이 적용된 모습을 확인

광고 - Vultr 25$ 프로모션
Vultr에 관심이 있다면 아래 프로모션으로 Vultr에 가입해 보세요.

물론 그전에 더 좋은 프로모션이 있는지 체크해 봐야 합니다.
Vultr의 좋은 점이 다양한 프로모션이 많아서 초기에 저렴하게 이용할 수 있다는 점이었죠. 최근에는 그런 좋은 조건들이 많이 사라진 것 같긴 합니다.
25$ 프로모션으로 Vultr 가입하기