wp-caching-featured

워드프레스 캐시 제대로 쓰기

워드프레스에서 캐싱(caching)은 사이트의 성능 향상이 필요한 경우 가장 먼저 검토하게 되는 옵션 중 하나입니다. 사실 웬만한 사이트에는 ‘묻지도 따지지도 않고’ 그냥 WP Super Cache 같은 플러그인 하나 쯤은 기본으로 장착하고 시작하는 경우도 많이 볼 수 있습니다. 그도 그럴 밖에 없는 게, 웹사이트가 세상에 알려지기 시작해 트래픽이 늘어나는 어느 시점부터 워드프레스는 필연적으로 성능에 대한 이슈에 직면할 수 밖에 없고 이 때 가장 먼저 떠올리게 되는 해결책이 캐싱이기 때문입니다.

— 참고: WordPress Optimization/Caching Codex

물론 웹사이트의 트래픽이 늘어나면서 겪는 성능 문제는 비단 워드프레스만의 문제는 아닙니다. 세상의 모든 웹사이트들이 트래픽이 늘어나면 성능에 대한 문제에 직면합니다. 마치 연예인의 인기와 공인으로서의 부담(책임)감이 함께 느는 것처럼 웹사이트에서는 인기(트래픽)와 성능에 대한 부담은 트레이드오프(tradeoff)이기 때문입니다.

워드프레스 캐싱 플러그인 선택하기

워드프레스 사이트의 방문자수가 늘어나고 사이트 속도가 조금씩 느려지고 있다는 느낌(?)이 들 때 캐싱을 적용하는 것은 좋은 선택입니다. 시중에는 워드프레스에 캐싱을 추가하는 플러그인들이 많이 나와 있으며, 통상적으로 이들 중 하나를 골라 설치하는 것만으로 캐싱 적용은 끝이 납니다. 캐싱 플러그인들 중에는 무료로 제공되는 것도 많지만 유료로 판매되는 플러그인들도 있습니다. 가장 흔히 사용되는 플러그인은 워드프레스 제작사인 Automattic에서 지원하는 WP Super Cache 플러그인이지만, 이 밖에도 다양한 기능을 갖춘 좋은 플러그인들이 많이 나와 있으니, 그 중 적당한 것을 골라 적용하면 됩니다.

— 참고: 워드프레스 캐싱 플러그인

캐싱 플러그인 들여다 보기

이 글에서는 캐싱 플러그인의 선택에 도움을 주기 위해 실제로 캐싱 플러그인이 어떤 기능을 수행하는지를 간략하게 소개해 보기로 하겠습니다. 이를 위해, 워드프레스에 캐싱 기능을 제공하는 여러 플러그인들 중 하나인 W3 Total Cache 플러그인(이하 ‘W3TC’)을 예로 듭니다. 이 플러그인을 채택한 이유는 오랜 기간 동안 비교적 안정된 기능을 수행해 온 검증되고 인기있는 플러그인이며 또 무엇보다도 페이지 캐시(Page Cache), 데이터베이스 캐시(Database Cache), 브라우저 캐시(Browser Cache), 오브젝트 캐시(Object Cache), CDN 연동 등 캐싱에 관한 거의 모든 기능이 망라된 플러그인이기 때문입니다.

W3 Total Cache 플러그인

이 플러그인을 설치하고 활성화시키면 “Performance” 메뉴가 어드민 대시보드에 추가됩니다. 이 상태에서 “Performance \> General Settings” 메뉴를 클릭하면 다음과 같이 W3TC에서 사용가능한 다양한 캐싱 방법들을 확인할 수 있습니다.

Performance \> General Settings

물론 여기에 여러 가지 방법들이 나와 있다고 해서 이 모든 방법들을 내 사이트에 전부 적용해야 하는 것은 아니며 또 어떤 경우에는 잘못 적용하면 오히려 사이트의 성능을 저하시키거나 서버 오류를 발생시키는 원인이 될 수도 있기 때문에 주의해서 사용해야 합니다.

여기서는 이들 여러 캐싱 방법들 중 자주 사용되는 몇 가지 주요한 방법들만 골라 그 개념과 적용방법을 알아 보기로 하겠습니다.

LAMP 스택과 워드프레스의 작동 흐름

그에 앞서 간단하게 워드프레스의 작동 원리를 먼저 설명하겠습니다. 갑자기 왠 작동 원리냐구요? 워드프레스에서 캐싱을 제대로 이해하고 적용하려면 워드프레스의 작동 원리를 간단하게라도 이해하는 것이 많은 도움이 되기 때문입니다.

알다시피 워드프레스는 LAMP (Linux/Apache/MySQL/PHP) 기반입니다. 사용자가 웹브라우저를 통해 워드프레스 사이트에 접속하여 어떤 페이지를 볼 경우, 워드프레스 내에서는 매번 사용자가 페이지에 접속할 때마다 다음과 같이 여러 단계의 작업이 이루어지게 됩니다.

이들 작업의 단계를 줄이거나 각각의 작업을 처리하는데 걸리는 시간과 병목(CPU, 메모리 등에서 발생하는)을 줄임으로써 웹사이트의 성능을 향상시키는 것이 결국 캐싱의 목적입니다.

페이지 캐시(Page Cache)

페이지 캐시는 워드프레스에서 사용할 수 있는 대표적인 캐싱 방법입니다. 워드프레스 사이트의 모든(또는 일부) 웹페이지들을 디스크나 메모리 공간 등 어딘가에 저장해 두고, 다음 번에 똑같은 페이지 요청이 들어올 경우 위 LAMP 스택 처리의 전 과정을 거치지 않고 어딘가에 저장해 둔 웹페이지를 바로 사용자에게 반환하는 방식이죠. 말하자면 위 그림에서 ②와 ③ 단계를 거치지 않고, 바로 ①에서 ④로 넘어가는 방식입니다.

W3TC 페이지 캐시

W3TC의 Page Cache 메뉴에서 보면 다양한 캐시 저장 방법을 지원하는 것을 알 수 있습니다(W3TC는 현재의 시스템 환경을 파악하여 가용한 방법들만 활성화시킵니다). 그림에서 보듯, 디스크(Disk)에 저장하는 방법과 APC(Alternative PHP Cache)XCache 같은 PHP OpCode Cacher에 저장하는 방법, 그리고 MemcachedRedis 서버 같은 외부 데이터 저장소를 이용하는 방법이 가능합니다(웬만한 사이트라면 Disk를 선택하면 되고 Disk Enhanced 방식을 권장합니다).

또한 “Performance \> Page Cache” 세부 메뉴를 통해 캐싱을 적용할 페이지를 지정하거나 캐시 만료 시간 등을 설정할 수 있습니다(페이지 캐싱의 세부적인 설정 방법은 설명을 생략합니다).

최소화(Minify)

W3TC Minify

말 그대로 웹페이지 속에 들어 있는 각종 CSS나 자바스크립트(JavaScript) 파일을 하나로 합치거나 압축하고 HTML파일에서 공백 등 불필요한 용량을 줄임으로써 페이지의 로드 속도를 높이는 방법입니다. 앞선 페이지 캐시 만큼의 성능 향상은 기대할 수 없겠지만, Google PageSpeed 같은 웹페이지 성능 분석도구의 결과치를 향상시키는데 많은 도움이 될 수 있습니다. 위 LAMP 스택 흐름도 상으로는 ④ 단계에 해당합니다.

Opcode 캐시(Opcode Cache)

PHP는 스크립트 언어이기 때문에 매번 웹 호출이 들어올 때마다 소스코드를 컴파일하는 과정을 거치게 됩니다. 이 때 PHP는 소스코드를 ‘Opcode’라고 부르는 바이트코드(bytecode)로 한번 컴파일을 하게 되는데, Opcode 캐시는 바로 이렇게 컴파일된 바이트코드를 저장하였다가 다음 번에 같은 호출이 들어올 경우 별도 컴파일 없이 이미 컴파일된 바이트코드를 재활용하는 캐싱 메커니즘입니다. 위 LAMP 스택 흐름도 상으로는 ② 단계에 해당합니다.

Opcode 캐시

W3TC에서는 Zend OpCache와 APC, 이렇게 2가지 옵션을 제공합니다만, 워드프레스를 설치한 LAMP 환경의 PHP 버전이 5.5 이상이라면 Zend OpCache가 PHP 속에 이미 포함되어 있기 때문에 W3TC 플러그인 측에서 별다른 설정은 필요 없습니다(물론 OpCache 자체의 최적화는 별개 문제입니다).

데이터베이스 캐시(Database Cache)

앞서 설명했듯 워드프레스는 웹페이지를 사용자에게 보여줄 때마다 매번 데이터베이스를 호출합니다. 예를 들어 우리가 어떤 포스트 하나를 볼 경우에도 워드프레스는 그 포스트의 제목과 내용 같은 모든 포스트 데이터를 데이터베이스로부터 불러 오게 됩니다. 데이터베이스 캐시는 이렇게 질의(쿼리)한 데이터베이스의 쿼리값을 어딘가 저장(캐싱)해 두어 다음 번에 동일한 데이터베이스 쿼리가 들어 올 경우 그 저장된 쿼리값을 사용하는 캐싱 방법입니다. 위 LAMP 스택 흐름도 상으로는 ②와 ③ 단계 사이에서 이루어지는 캐싱에 해당합니다.

W3TC Database Cache

W3TC에서는 이런 데이터베이스 캐시를 저장하는 저장소로 여러 가지 옵션들을 지원합니다. 저장소 옵션은 앞서 페이지 캐시에서처럼 다양한 옵션들을 지원합니다.

오브젝트 캐시(Object Cache)

오브젝트 캐시는 페이지 캐시와 함께 워드프레스의 대표적인 캐싱 메커니즘입니다. 워드프레스는 내부적으로 웹페이지를 처리하면서 발생하는 여러 처리 작업들이 중복해서 일어나지 않도록 하기 위해 한번 발생한 처리 결과(값)를 메모리 상에 저장하여 동일한 값을 다시 요청한 경우에는 똑같은 처리를 다시 수행하지 않고 이미 있는 값을 재활용하는데, 이를 ‘오브젝트 캐시’라 부릅니다. 조금 기술적인 내용이긴 합니다만, 워드프레스는 이를 위해 WP_Object_Cache라는 표준 API를 제공합니다.

그렇지만 워드프레스가 기본으로 제공하는 오브젝트 캐시는 메모리에 저장되어 매번 웹페이지를 호출할 때마다 만들어졌다 없어지기를 반복하는 문제가 있습니다. W3TC의 ‘Object Cache’ 메뉴는 이를 확장한 것입니다. 이 기능을 켜면 앞서의 그 처리값을 메모리가 아닌 여러 유형의 다른 저장소에 저장하여 반복되는 페이지 호출 간에도 계속해서 캐시된 값을 사용할 수 있도록 해 줍니다. 앞서의 데이터베이스 캐시와 마찬가지로 위 LAMP 스택 흐름도 상으로는 ②와 ③ 단계 사이에서 이루어지는 캐싱입니다.

W3TC Object Cache

W3TC 오브젝트 캐시는 앞서 설명한 데이터베이스 캐시와 동일한 옵션을 갖습니다. 다만 데이터베이스 캐시와 오브젝트 캐시의 저장소를 Disk로 설정할 경우 빈번한 디스크 I/O가 발생하게 되어 오히려 사이트 성능을 저하시킬 수 있습니다. 반드시 APC/APCu나 Memcached 같은 메모리 저장소 방식의 사용을 권합니다.

브라우저 캐시(Browser Cache)

마지막으로 소개할 캐싱 유형은 브라우저 캐시입니다. 브라우저 캐시는 이름에서도 알 수 있듯 웹브라우저와 관계가 있는 캐시입니다. 웹브라우저와 웹서버 간에는 동일한 콘텐츠를 중복해서 불러오는 것을 방지하여 웹 페이지의 로딩 속도를 향상시키기 위한 여러 규약들이 정해져 있습니다. 이를 흔히 ‘HTTP Cache’라 부르며, W3TC의 브라우저 캐시는 바로 이 HTTP Cache에 대한 것입니다.

W3TC Browser Cache

브라우저 캐시는 W3TC를 처음 설치하면 디폴트로 활성화되며, 별다른 문제가 없는 한 디폴트 값 그대로 사용하면 무난합니다. 다만 이 HTTP Cache는 워드프레스로만 처리할 수 있는 문제는 아닙니다. 웹서버나 여타 다른 시스템 쪽에서 다룰 내용이 더 많습니다. HTTP Cache 및 그 설정에 관한 더 자세한 내용은 아래 문서를 참조하면 좋을 것입니다.

Best Practices for Speeding Up Your Web Site

그 밖의 방법들

그 밖에도 W3TC 플러그인에서는 CDN과 Reverse Proxy, Fragment Cache 같은 방법들도 제공합니다만 범용으로 사용되는 방법은 아니기에 별도의 설명은 생략합니다. W3TC에 대한 더 상세한 정보는 W3TC 플러그인 페이지나 W3TC FAQ 메뉴를 통해 확인할 수 있습니다.

여기까지입니다. 캐싱 사용법이라고 말해 놓고, 쓰다 보니 결국 W3TC 플러그인 사용법이 되어 버린 느낌이군요. 하지만 W3TC에는 워드프레스에서 적용할 수 있는 (거의) 모든 캐싱 메커니즘이 다 구현되어 있기 때문에 아마 다른 캐싱 플러그인을 사용하더라도 어렵잖게 적용할 수 있을 것입니다.

물론 워드프레스 사이트의 성능 향상을 위해 할 수 있는 방법이 캐싱을 적용하는 것만 있는 것은 아닙니다. 테마나 플러그인에서 처리할 부분도 있고 웹서버나 데이터베이스 서버와 같은 서버 시스템이나 네트워크 단에서 처리할 부분도 있습니다. 워드프레스 성능 향상에 필요한 다른 여러 방법들은 다음에 또 기회가 되면 소개하기로 하겠습니다. 🙂

“워드프레스 캐시 제대로 쓰기”에 대한 0개의 생각