워드프레스 빠르게 하기

[ 이글은 2018년 06월 13일에 최종 수정되었습니다. ]
§

일단 웹사이트의 속도를 결정하는 요소는, 웹사이트 마다 다르지만, 대략적으로 서버성능이 7~80%, front-end scripting 구조 가 2~30% 정도의 영향을 끼친다고 볼 수 있습니다.

서버의 성능을 높히고 최적화 하는 작업을 통해 사이트 속도를 높힐 수 있지만, 대다수 소규모 웹사이트의 경우 웹호스팅 회사를 통해 사이트가 호스팅 되고 있는게 현실 입니다.

그래서 서버성능이나 세팅, 또 Nginx 같은 사이트 속도에 유리한 서버사용이 불가능 한 경우, 차선책으로 최대한 front-end 에서 속도를 높혀주는 수 밖에 없습니다.

워드프레스 는 크게 보면 워드프레스 core 파일에 테마와 플러그인이 얹혀진 형태 입니다. 당연히 테마의 속도를 빠르게 하면 사이트 속도도 빨라집니다.

워드프레스_구조

1. 테마 속도 높이기

일단 테마의 모습을 한번 살펴 봅시다.

wp_layout

크게 나눠서 헤더, 사이드바, footer, (한국어로 쓰려니 “뿌..” 어감이 좋지 않아서. ㅎㅎ), 그리고 loop 되서 보여지는 컨텐츠 area 로 나눠져 있습니다. 경우에 따라서 여러개의 사이드바가 달려있을 수 도 있고, 없을수도 있고, footer 가 없을 수 도 있습니다.

헤더

시판되는/공유되는 테마를 보면 사이트 로고 나 로그인 같은 부분에 단순한 링크를 걸기위해 php 를 사용해 relative path (상대경로) 를 이용 하는데 (테마가 어느 사이트에서나 작동될 수 있기 위해 어쩔수 없죠.) 이 부분을 모두 absolute path (절대경로) 로 대체하여 php 사용을 줄여 줍니다.

왜 php 사용을 줄여야 하는가?

a. 서버의 부담을 덜어주기 위해서 입니다.
b. html 은 항상 php 보다 빠릅니다.

메뉴

php 로 생성되는 메뉴/메뉴들을 html 로 대체합니다. 헤더와 footer 등에 걸려있는 메뉴에 자주 변동사항이 없는 경우 (사이트가 완성된 경우), 워드프레스를 통해 메뉴를 생성하지 말고, html 로 메뉴를 짜 넣습니다. 물론 기본적인 html 과 css, 혹은 javascript 에 대한 이해가 있어야 가능한 작업입니다.

사이드 바

경우에 따라서 (use case 가 가능한 경우) sidebar 부분역시 html 로 대체 합니다. 단순한 제품이나 서비스 관련 광고 배너를 걸어 놓는 용도로 사이드바를 사용하는 경우가 많은데, 이런경우 사이드바를 워드프레스에서 생성할 필요가 없습니다.

*물론 이 작업들을 하기전, 내가 사용하려는 테마가 어떻게 만들어졌는지를 먼저 살펴볼 필요가 있습니다. 테마 프레임워크를 사용한 무거운 테마는 아닌지, 페이지 빌더 같은 쓸데 없는 기능이 달려 있지는 않은지 확인해 봐야 합니다. 한 예로 ftp 를 사용할 줄 알고, 기본적인 html 에 대한 이해가 있다면, 로고이미지 하나를 바꾸기 위해, 테마 기능을 사용해야 할 필요가 전혀 없습니다.

Footer

Footer 역시 html 로만 만들어질 수 있습니다. 보통 footer 에서 사용하게 되는 copyright 연도를 php 로 보여주는데 <?php echo date("Y"); ? > 이 부분은 javascript 으로 대체할 수 있습니다. <script >document.write(new Date().getFullYear())</script >

Footer 에 포함되는 메뉴 역시 위에서 설명드린데로 사이트가 완성된 후, html 로 작성하시면 됩니다.

여기서 의문하나. php 대신 javascript 을 쓰면 오히려 로딩속도가 더 늦어지는게 아닌가?

그렇지 않습니다. php 는 서버에서 가동되는 것 이지만, javascript 은 방문자의 브라우져를 가동시키는 것 입니다. 따라서 동접자가 100명인 경우, 내 서버는 100번 php 를 execute 하게 되지만, javascript 은 각 방문자의 브라우져에서 한번만 execute 됩니다. 동접자가 많을수록 javascript 을 쓰는 것이 로딩속도에 이득입니다.

2. 플러그인

많은 수의 플러그인 코드를 살펴보면, 플러그인 자체의 기능보다 사용자 옵션을 위해 짜여진 php 스트립트 부분이 훨씬 더 많습니다. 이런 옵션들은 한번 설정하면 그만인데, 그 한번 설정하는 옵션때문에 많은 수의 query 가 발생합니다. 플러그인을 사용해야 한다면, 플러그인을 site specific 플러그인 화 해서 사용합니다. 가능하다면, 내가 직접 그 기능을 짜서 사용 합니다.

슬라이더 플러그인의 예를 들자면, 웹디자이너 수준의 html 과 css, 그리고 js 를 이해한다면 (슬라이더가 js 를 쓰는 경우) 슬라이더 플러그인을 사용하지 않고, 직접 슬라이더를 작성해 사이트에 적용할 수 있습니다. (개인적으로 슬라이더를 하나 만들어 붙이는게 복잡한 슬라이더 사용설명을 읽고 적용하는 것 보다 더 시간이 적게 걸립니다.)

3. 사이트 Asset 관리

사이트에 로딩되는 front-end asset 들을 살펴보면 그 크기가

이미지 >>>>>>>>>>>>>>> javscript >>>>>> css 순서로 이미지 파일의 크기가 압도적 입니다.

asset_management

이미지 하나가 사이트 전체를 담당하는 css 보다 더 느리게 로딩되고 있음을 볼 수 있습니다.

테마의 UI 를 담당하는 버튼같은 경우, raster 이미지 사용을 하지말고 (jpg 나 png 를 쓰지 말라는 것 입니다), 파일사이즈가 작은 vector 이미지나, 아이콘 폰트, css 등으로 대체 합니다. *물론 내가 svg 같은 vector 이미지를 만들 수 있는 아도비 일루스트레이터 같은 프로그램 사용을 할 줄 모른다면 이 역시 가능한 작업이 아닙니다.

*이글을 읽고 있는 분이 웹디자이너라면 svg 를 적극적으로 사용하십시오. 잘알고 계시겠지만, svg 는 vector 라서 이미지를 아무리 크게 키우더라도 깨짐 현상이 나타나지 않습니다. 고로 16pt X 16pt 정도의 매우 작은 svg 파일을 페이지 전체를 덮는 이미지로 사용하더라도 이미지가 깔끔하게 구현됩니다. (페이지 로딩속도는 빨라지고, 이미지는 어느 기기에서나 더 샤프하게 구현되고. 1석2조 인 것 입니다.)

HTTP Request 숫자 줄이기

js 이건 css 이건 이미지 파일이건, 브라우저가 한번에 fetch 할 수 있는 파일 숫자는 다음과 같습니다.

Firefox 3+: 6
Opera 9.26: 4
Opera 12: 6
Safari 3: 4
Safari 5: 6
IE 7: 2
IE 8: 6
IE 10: 8
Chrome: 6

예를들어 크롬의 경우 18개의 파일을 페이지로 불러와야 한다면 6개씩 세번에 걸쳐 파일을 불러와야 합니다. 그리고 이 프로세스가 많이 질수록 로딩 속도가 늦어 집니다.

따라서 이미지를 써야 한다면 가능한 경우 inline 으로 적용하는것이 속도 향상에 도움이 됩니다. 이미지의 파일크기가 작은경우 base64 encode 를 하는 것 도 좋은 방법입니다.


위 방법들은 워드프레스 자체에 관련된 내용이라기 보다, 기본적인 사이트 구축및 관리에 대한 내용이 대부분 입니다.

결국, 워드프레스가 느려지는 이유는 워드프레스 자체의 문제라기 보다는 html 과 css, 또 이미지 등이 사이트에 어떻게 적용이 되고 로딩속도에 어떤 영향을 끼치는지에 대한 기본적인 상식이나 개념이 부족해서임을 알 수 있습니다. 워드프레스가 느린게 아니라 사용하시는 테마나 플러그인이 느린 것 입니다.

명언

그럼에도 왜 대다수의 웹사이트들을 보면 front-end 가 엉망인가?

한국에 국한된 문제가 아닙니다. front-end 개발자가 턱없이 부족하기 때문입니다. front-end 개발자는 기술적으로 깊게 들어가지 않지만, 대신 알아야 할 영역 과 구사해야하는 여러가지 technique (기법) 들이 상당히 많습니다. 1~2년 정도 경력을 쌓아서 모두 터득할 수 있는 수준이 아닙니다. 그래서 대다수 소규모 사이트들의 front-end 는 엉망이고, 사이트가 느릴 수 밖에 없는 구조로 구축됩니다. 여기다 호스팅까지 웹호스팅을 쓰니 총체적 난국이 되어버리는거죠.

프론트엔드 개발자는 왜 구하기 어렵나요? : 참조하실 분들은 참조하세요. 어떻게/왜 미국에서는 front-end 개발자들이 프로그래머 보다 더 높은 임금을 받고 일하는지 납득하지 못하는 한국 개발자분들이 계시더라구요.

워드프레스가 우수한 점은, XE 나 드루팔과는 달리, front-end 를 내가 수정하는 것이 그리 어렵지 않다는 점 입니다. 하지만 이 front-end 까지 깔끔하게 정리해 줄 수 있는 솔루션은 지구상에 존재하지 않습니다.

워드프레스를 옹호하는 것 이 아니라, 아무 탓도 없는 워드프레스를 내 사이트가 느린 이유 나 대상 (culprit) 으로 지목하는 것은 옳지 않습니다.

‘나는 이런거 하나도 할줄 모른다. 그런데 플러그인은 많이 쓰고 싶고, 사이트 속도는 빨랐으면 좋겠다.’ 라는 희망을 갖고 계신 분이라면 그 해결책도 워드프레스 내에 존재 합니다.

a. 실력있는/시간많은 front-end 개발자 고용하기
b. Cache 플러그인 사용하기 (https://wordpress.org/plugins/w3-total-cache/)

cache 플러그인을 썼는데도 속도가 만족스럽지 않다면, 그게 현실이고, 그 현실에 수긍해야 합니다.

*개발자라면, 개발하실때, query 모니터, debugging 툴등을 사용하여, 내가 짜고 있는 script 이 bottle-neck 을 유발하지는 않는지, 로딩속도에 악영향을 끼치지는 않는지 확인해 가며 개발을 한다면 쾌적한 속도를 자랑하는 사이트 구축이 가능합니다.

Query Monitor

Debug Objects

hackya 는

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Tags: , ,

카테고리: , , ,

Ω