日本語에서 번역 • 원문 보기 이것은 제가 워드프레스로 다국어 사이트를 구축할 때 작성한 메모입니다. 통합 테스트가 거의 끝날 무렵 전체 건설 현장의 성능 튜닝을 하고 있었습니다.
대상 사이트가 크지 않아 AWS m3.medium 인스턴스에서 구축했지만, 개발 중반 이후 사이트 성능이 떨어져 매우 무거운 공간이 되었습니다. 사이트 성능 검증 "GTmetrix" 보고서를 보면, 사이트에 사용된 이미지의 반응이 지연 시간뿐이며, 당분간은 최대한 이미지를 최적화했고 프론트엔드 성능은 크게 향상되었지만 워드프레스 관리 화면은 여전히 무겁게 유지되었습니다. 웹 서버 쪽에서는 정적 콘텐츠의 GZIP 압축 작업, 설정을 httpd.conf로 이전하는 등 여러 조치를 시도했습니다. MySQLTuner로 DB 설정을 검증하고 조정해보았지만 변화가 없었습니다.
음~음, CloudWatch를 보면 CPU 사용량이 매우 많아서 AWS 인스턴스의 무능함 때문일 수도 있겠네요... 그렇다면 결국 m3.medium 인스턴스에서 c3 시스템으로 인스턴스를 변경해야 할 수도 있겠네요... 저도 생각해봤는데, 관리 화면이 개발 중인 사이트에 너무 많이 집중되어 있고 회사 내 소수만 접근한다는 근본적인 요인이 있을 것 같아요. 사이트 전체와 관련된 건 테마나 플러그인뿐이에요. 그래서 제가 도입하려는 플러그인의 성능을 테스트해봤는데, 그 결말을 찾았어요! … 성능 저하의 원인은 플러그인이었습니다.
이번에는 "P3 (Plugin Performance Profiler)"를 사용해 플러그인의 성능을 검증했습니다. 플러그인 성능을 검증하기 위해 다른 플러그인을 포함하는 것은 이상하지만, 이 P3 플러그인은 워드프레스 사이트에서 플러그인과 테마의 성능을 세세하게 스캔하고 보고하는 데 매우 뛰어납니다. 설치가 쉽고, 플러그인을 다운로드하고 활성화하면 관리자 메뉴의 "도구" 섹션에서 언제든지 성능을 스캔할 수 있습니다.
이 P3 플러그인으로 스캔한 결과는 다음과 같습니다.
다국어 플러그인 "Polylang"과 커스텀 게시물 타입 플러그인 "Types"가 런타임에 부담을 주고 있음을 알 수 있습니다. 예상대로 다국어 사이트이기 때문에 "Polylang"을 빼놓을 수 없지만, 많은 커스텀 게시물 타입 플러그인은 비슷한 플러그인이 많아 대체 가능합니다. "Types"는 공식적으로 "Polylang"을 지원하는 플러그인이라 사용했지만, 커스텀 포스트를 확장하는 것만으로도 런타임이 너무 많이 걸려서 사용하기 쉽지 않습니다.
그래서 "Types" 플러그인을 제거하고 같은 시스템에서 익숙한 "Custom PostType UI" 플러그인을 도입했습니다.
"타입"이 차지하는 런타임이 사라졌고, 플러그인 로딩 시간과 영향도 개선되었습니다. 관리 화면의 속도도 수십 배 개선되었고, 편집이 명확했던 원래의 UX도 복원되었습니다. 한 개의 플러그인이 성능을 크게 바꿀 수 있다는 것을 깨달았습니다... 그걸 깨달았습니다.
이 사건을 통해 개인적으로 앞으로 워드프레스 사이트를 만들 때는 플러그인 기능보다는 성능에 집중하는 것이 낫다고 생각했습니다. 이는 플러그인 기능에 없는 기능을 나중에 원하는 만큼 추가할 수 있지만, 플러그인의 핵심에 따라 성능을 수정하는 것은 매우 어렵기 때문입니다.
특히 관리 화면이 무거우면 사이트 운영을 담당하는 웹 담당자의 동기부여가 크게 떨어지므로, 기능은 조금 부족해도 스트레스 없이 운영할 수 있는 관리 화면이 있으면 더 만족스러울 것 같습니다.