WPML이 상용화된 이후, wpml.org는 훨씬 더 많은 트래픽을 처리하고 있습니다. 2주 전만 해도 서버 부하가 95%에 달했고 응답 시간은 10초가 넘었습니다. W3TC를 사용한 후에는 부하가 5%로 떨어졌고 응답 시간은 약 300 ms로 단축되었습니다.
W3TC에 익숙하지 않은 분들을 위해 설명하자면, W3TC는 사이트 성능 최적화 플러그인입니다. 페이지 캐시 기능이 포함되어 있지만 이는 시작에 불과합니다. 기본 페이지 캐싱 외에도 JS 및 CSS 파일을 축소하고 모든 항목을 압축하며 CDN(콘텐츠 전송 네트워크)을 실행합니다. 이러한 기능이 결합되면 사이트 속도를 크게 높일 수 있어 복잡한 WordPress 사이트에서도 대량의 트래픽을 처리할 수 있습니다.
WordPress 사이트에 중요한 이유
백문이 불여일견입니다. 다음은 캐싱 없이 사이트가 로드되는 모습입니다(Pingdom Tools에서 생성).
이 수치가 무섭게 느껴진다면 실제로는 더 심각했다는 점을 기억하세요. 이 로드 시간 차트는 실제로 서버가 5% 부하로 실행될 때 측정된 것입니다. 캐시 없이 실행되었을 때는 서버 부하가 95%에 달했고 처리 시간도 훨씬 길었습니다. 이 차트에서 볼 수 있는 1/2초가 아니라 첫 번째 바이트가 나오는 데만 5초가 걸렸습니다.
홈페이지를 완전히 표시하기 위해 서버는 77개의 파일을 전송해야 했습니다. 5% 서버 부하로 실행되는 이 차트조차도 30초에 시간 초과로 끝납니다(빨간색 선 참조).
엉성한 프로그래밍과 잘못된 디자인 관행 때문일까요? 아닙니다.
WordPress의 강력함은 모듈성에서 비롯됩니다. 원하는 테마를 선택하고 플러그인을 자유롭게 조합할 수 있습니다. 즉, 각각 독립적으로 개발되며 자체 리소스로 실행됩니다. 활성화하는 대부분의 플러그인에는 여러 CSS 및 Javascript 파일이 포함되어 있으며 PHP 및 MySQL 처리 작업에 영향을 미칩니다. 수동으로 최적화할 수도 있지만, 그렇게 하면 이 훌륭한 모듈성을 모두 잃게 되고 원점으로 돌아가게 됩니다.
Pingdom 도구나 다른 페이지 로드 시간 측정 도구(이를 위한 Firefox 애드온도 있습니다)를 통해 사이트를 테스트해 보세요. 어떤 파일이 로드되고 어떤 순서로 로드되는지 확인하세요. CSS 파일이 이미지와 다른 CSS를 로드하고 각 페이지마다 수많은 Javascript 파일이 로드된다는 것을 알 수 있습니다.
흥미를 돋우기 위해 W3TC의 모든 기능을 사용하여 달성한 결과를 보여드리겠습니다.
여기서 볼 수 있는 수치는 정확합니다. 페이지를 표시하기 위해 총 28개의 파일을 가져옵니다. 5개의 파일은 wpml.org(자체 서버)에서 가져오고 나머지는 CDN(콘텐츠 전송 네트워크)에서 가져옵니다. PHP는 캐시에 있는지 확인하고 몇 가지 사소한 검사를 수행하는 것 외에는 이 페이지를 제공하기 위해 거의 아무 작업도 수행할 필요가 없습니다.
전체 페이지가 2초 이내에 로드되며 서버에서 거의 측정할 수 없을 정도의 부하만 발생합니다. 우리도 만족하고, 방문자도 만족하며, Google도 만족합니다.
1단계) 페이지 캐시
가장 먼저 해야 할 기본 작업은 페이지 캐싱을 활성화하는 것입니다. Performance로 이동하여 W3TC를 활성화하고 Page Caching 섹션을 구성하세요.
페이지 캐싱의 경우 기본 설정을 유지했습니다. 한 가지 추가한 것은 W3TC가 WPML 고객 계정 및 WPML 다운로드와 충돌하지 않도록 페이지 캐시에서 고객 계정 및 다운로드 섹션을 제외한 것입니다.
opcode 캐시를 사용하는 경우 W3TC는 이를 활용하여 사이트 속도를 더욱 높입니다. 우리는 사용하지 않지만 캐시되지 않는 복잡한 PHP 처리를 실행하는 경우 유용합니다.
2단계) Minify – CSS 및 JavaScript 묶기 및 압축
테마와 플러그인이 추가하는 모든 CSS 및 JS 파일을 기억하시나요? 이제 이로 인해 발생하는 부하를 해결할 때입니다.
Minify는 여러 리소스 파일을 수집하여 하나의 파일로 묶고 압축합니다. 그 결과 수십 개의 작은 파일 대신 하나의 더 큰 파일이 생성됩니다.
전체 크기는 50%만 줄어들 수 있지만 이로 인해 절약되는 부하는 엄청납니다. 브라우저가 여러 HTTP 요청을 보내고 작은 파일을 많이 가져오는 대신 단일 요청을 보내고 모두 함께 가져옵니다. 이러한 변화는 사이트의 응답성을 향상시키는 데 가장 큰 기여를 할 것입니다. 특히 CSS 및 JS가 아직 캐시되지 않은 신규 방문자에게 더욱 그렇습니다.
페이지 상단의 Help 버튼을 클릭하세요. W3TC가 전체 사이트를 실행하며 리소스 파일을 찾습니다. 그런 다음 결합할 파일을 선택할 수 있습니다. 일반적으로 모두 선택할 수 있지만 로드 순서가 변경될 수 있으므로 주의를 기울여야 합니다.
축소할 CSS 및 JS 파일을 선택한 후에는 순서가 올바른지 확인해야 합니다.
CSS 파일의 경우 목록에서 파일을 위아래로 드래그하세요.
이 목록에 표시되는 순서는 Minify 없이 CSS 파일이 로드되는 순서와 일치해야 합니다. HTML 페이지 소스에서 확인할 수 있습니다.
Javascript 파일은 조금 더 까다롭습니다. 순서가 잘못되면 JS 오류가 발생하고 기능이 손상될 수 있으므로 여기서 로드 순서는 더욱 중요합니다.
W3TC를 사용하면 어떤 JS 파일을 헤더 섹션에 넣고 어떤 파일을 본문에 넣을지 선택할 수 있습니다. 예를 들어 Google Analytics 스크립트는 바로 앞에 배치되고, jQuery는 먼저 실행되어야 하므로(그리고 Minify 목록 외부에 있으므로) 헤더에 배치됩니다.
3단계) 콘텐츠 전송 네트워크(CDN)
우리에게 있어 금상첨화는 훌륭하게 작동하는 CDN이었습니다.
CDN을 구성하고 실행하는 것은 타사 서비스에서 계정을 설정해야 하므로 이 글의 범위를 벗어납니다.
자체 사이트의 경우 스토리지로 Amazon S3를 사용하고 전송을 위해 CloudFront를 사용합니다. 탐색하고 비교해 볼 수 있는 다른 훌륭한 옵션도 있습니다.
CDN 계정이 설정되면 W3TC는 로컬 파일을 CDN으로 전송하고 서버의 링크를 CDN의 파일로 바꿉니다. 그러면 서버는 HTML 파일만 전송하고 나머지는 CDN이 처리합니다.
서버는 단일 컴퓨터인 반면 CDN은 실제 서버 네트워크입니다. 가장 가까운 서버에서 각 방문자에게 파일을 전송합니다. CDN은 단일 서버보다 정적 파일을 훨씬 빠르게 제공할 수 있습니다. CDN을 사용하면 방문자의 경험을 향상시키고 서버의 대역폭 및 네트워크 사용률을 크게 줄일 수 있습니다.
W3TC의 CDN 설정 마법사를 따르세요. 미디어 라이브러리, 테마 및 플러그인 리소스를 CDN으로 전송하는 데 도움이 됩니다.
사이트 성능 최적화가 흥미로우신가요? 여기에 댓글을 남겨 알려주세요!
