이러면 설치를 시작하고 중간에 아래와 같은 메세지가 뜹니다. 이는 데이타베이스 관련한 세팅을 하겠냐는 것인데요. 이는 이미 MariaDB와 같은 데이타베이스를 설치하면서 끝냈기 때문에 No를 선택합니다.
다음으로는 웹서버로 무엇을 선택할것인지를 묻는데요. 여기에는 nginx는 없습니다. nginx에 설치하여면 그냥 esc키를 눌러 취소하면 됩니다.
그러면 phpMyAdmin 설치가 끝난 것인데요. 그런데 이 설치 디렉토리가 /usr/share/phpmyadmin에 설치되어있기 때문에 이를 사이트에서 쉽게 접근할 수 있도록 사이트 아래 디렉토리로 연결해 줍니다. 연결 디렉토리는 보안을 사용해 자기만 알 수 있는 이름을 사용합니다.
오늘 은결이가 아무아리움을 가야한다고 주장해서..코엑스를 다녀왔다. 우리 집은 은결이가 가장 힘이 세다.
코엑스, 아니 지금은 신세계 주도로 리모델링해서 스타필드 코엑스라고 불리우는 곳.
은결이와 엄마는 아쿠아리움으로 향했고 은우와 난 뱔마당과 SM Town을 다녀왔다. 이 중 SM Town의 풍경을 공유해 본다.
SM Town은 아시다시피 JYP, YG와 함께 우리나라 3대 기획사중의 하나이다. 최근 YG가 치고 나오고 방탄소년단을 배출한 빅히트엔터테인먼트같은 신생 업체가 두각을 나타내면서 주춤한 모습이 잠깐 보이고는 있다.
암튼 은우가 스타필드(코엑스)에 온 이유는 오직 SM Town에 가기 위해서이니 별마당을 거쳐서 SM Town으로 향했다.
종현 추모
SM Town에서 본것의 90%는 종현 추모이다. 지난해 12월 27세의 젊은 나이로 세상을 등진 종현을 추모하는 메모와 편지와 꽃다발이 SM Town 전체를 덮고 있었다.
생활에 바빠 그냥 스치고 지났는데.. 그날 은우가 슬퍼해서 잠깐 잠깐 고민에 빠진 것말고는 별로 한게 없어.. 추모 메모들을 보면서 그의 명복을 빌었다. 문득 건물 전체르 뒤덥고(?) 있는 추모물들을 보면서 종현이는 그래도 행복하겠다는 생각을 했다.
그냥 지나칠 수 없어서 건물 곳곳에 혼재하는 추모 모습을 담아 보았다.
종현 CD를 사다 – 종현 소품집 – 이야기 Op.2
SM Town을 나오면서 마지막으로 종현의 CD를 샀다. 은우에게 종현의 노래중 가장 유명한 앨범이 뭐냐고 물었는데 은우가 이 앨범을 골라 주었다
흔히 볼 수 있는 외국인
SM Town에는 SM 엔터테인먼트 소속 연예인(? 표현이 맞는지 모르겠다.)의 팬들이 모여드는 곳이라 이런 일에 열심인 소녀팬들이 정말 많았다. 그가운데 아저씨는 나외엔 딱 1명만 보았다.
이런 소녀팬 그리고 연인들외 외국인도 많이 눈에 띄었다. 특히 히잡을 쓴 아랍분들도 많았는데 조금 생경한 느낌이 들었다. 중동에도 한류가 여전히 강하다는 반증이 아닐까 싶기도 하다.
스타을 기다리는 팬들
밖으로 나오니 일단의 (주로) 소녀들이 엄청 모여 있다. 그들의 스타가 오늘 생일이라고 축하해주기 위해서 모였다고..
흔하면서도 생경한 풍경…
그 동안 회사와 집만 오가던 나로서 SM Town에서의 마주한 풍경은 생경했지만, 그 동안 뉴스를 통해서 무수히 들었고 영상으로 너무도 많이 접해서 그리 놀랍지는 않았지만 여러가지 다시 생각케하는 계기를 만들어 주었습니다.
이미 거의 한달이 지나감에도 불구하고 여전히 SM Town 건물 전체를 뒤덥고 있던 종현 추모의 흔적은 대중에게 사랑받는 것이 무엇을 의미하는지, 그리고 사후에 훨씬 더 인정을 받았던 음악성을 보면서 한길에 매진하고 평범함을 거부한 채 다른 사람들보다 더 뛰어남으로 소수든 다수든 지향점을 마드는 것의 중요성을 알려줍니다.
중동을 비롯한 여러 나라 사람들이 SM 소속 스타들을 좋아하고 그들과 관련된 상품(앨범, 기념품 등등)을 구매하는 것을 보면서 그리고 현장에서 은우랑 이야기했던 방탄소년단을 생각하면서 한류에 대해서 그리고 이 분야에 대한 케이스 스터딜ㄹ 해 보아야겠다는 생각을 했습니다.
그리고 팬의 생일을 맞아 대규모로 운집한 팬들을 보면서 이렇게 자발적으로 사람들의 마음을 움직이는 메커니즘이 그리고 어느 한 사람을 향항 이런 종류의 사랑은 어떻게 형성딜까라는 궁금증이 일면서 내가 더 이해해야할 것들이 참으로 많다는 생각을 했습니다.
구글에서 제안하는 Accelerated Mobile Pages를 적용해서 사용하고 있는데요.
1. AMP(Accelerated Mobile Page)란 무엇이냐구요?
인터넷이 빠르게 모바일로 전환되고 모바일 광고도 매우 빠르게 증가하고 있습니다. 그런데 모바일의 속도는 모바일 인터넷의 증가 속도를 따라가지 못하고 모바일에서 속도 문제가 매우 중요해졌습니다.
1.1. 구글 AMP(Accelerated Mobile Page) 개요
일반적인 문서도 속도가 느린데 여기에 구글 광고까지 실으면 더욱 느려지기 대문에 구글로서는 빠른 모바일 환경으로 빨리 전활할 필요가 있었습니다. 이런 배경하에 나온 것이 구글 AMP(Accelerated Mobile Page)입니다.
구글 AMP(Accelerated Mobile Page)는 속도를 최대한으로 올리기 위해서 불필요한 코드를 모두 제거하고, 구글 입장에서 꼭 필요하다고 생각하는 항목만 반영하도록 Accelerated Mobile Page 문법을 상당히 엄격하게 적용하고 있습니다.
JavaScript가 페이지 렌더링을 차단하는 것을 막기 위해 비동기 JavaScript만 허용한다.
CSS는 모두 인라인으로 지정해야 하며 50KB를 넘을 수 없다.
스크립트는 처럼 AMP에서 제공하는 스크립트 외에는 외부 JavaScript를 허용하지 않는다.
기본 HTML 태그 대신 , , 같은 AMP 전용 태그를 사용한다.
모든 리소스는 크기를 지정해서 리소스를 다운로드 한 후에 브라우저가 레이아웃을 다시 그리지 않도록 한다.
1.2. 심심하게 나오는 AMP 페이지 구현 오류
구글에서는 속도 개선을 위해서 Accelerated Mobile Page 문법을 상당히 엄격하게 적용하고 있다보니 조금만 정한 규정에서 어긋나도 바로 “Accelerated Mobile Page에 문제가 있다.”는 경고를 띄우고 구글 검색 시 “페이지에 AMP 구현 오류가 있습니다.”를 표시해 줍니다.
문제는 “페이지에 AMP 구현 오류가 있습니다.”라는 문구가 뜨는 포스팅이 증가하고 있다는 것이죠.
처음에는 그러려니하다가도 이를 볼때마다 신경이 쓰이긴 합니다. 다만 한가지 다행인점은 이 메세지는 오직 사이트 owner에게만 보여진다는 점입니다.
1.3. AMP(Accelerated Mobile Page)의 문제점
이 AMP(Accelerated Mobile Page)가 모바일 인터넷의 속도를 증가시키지만 별도의 구글 캐시 서버를 통해서 내용을 보여주므로 구글 중심의 정책이라 비난을 많이 받고 있습니다. Outsider님, 나는 AMP를 좋아하지 않는다. 참조
또한 블로그나 웹사이트의 정체성을 굉장히 훼손하면서 속도를 증가를 추구하고 있어 블로그들의 이해와는 반하는 결과를 낳고 있습니다.
구글 애드센스 넣기가 보다 까롭습니다. 뭐 방법은 많이 있으니 전문가들에게는 큰 문제가 아닙니다.
Social share button을 추가하기 매우 어렵습니다. AMP에 맞추어 별도 작업을 해주어야 합니다.
포스팅에서 글쓴이가 연결했던 Link 등의 정보가 구글 제공 link로 대체되는 경우가 많습니다.
사이트 디자인 등의 아이덴티티를 완전히 변화시킵니다.
그렇기때문에 AMP를 포기하고 다시 예전으로 돌아가는 경우도 증가하고 있으며, 인터넷에는 AMP 삭제 방법에 대한 문의도 늘고 있습니다.
2. 끊임없이 AMP와 사이트와 충돌이 발생하다.
이러한 구글의 정책에 맞추어 제대로 페이지를 구성하면 문제가 없습니다. 그러나 많은 자료들이 아주 예전부터 만들어쟜고 이 문서들은 AMP 정책과 맞지 않는 것들이 많습니다. 한때는 하루 몇십개씩 수정을 시도해 보았지만 날이갈수록 요구사항이 까다로워지고 새로운 프로그램 적용이나 플러그인을 설치하면 충돌이 발생하는 것 같더군요.
최근 워드프레스 최적화를 한다면서 그동안 형식적으로 적용해 작동하는지 하지않는지 제대로 않았던 서버의 각종 옵션들을 재점검했습니다. 그 결과 생각외로 작동하지 않은 옵션 명령들이 많았습니다.
제 옵션 명령들을 정상적으로 작동하도록 만들자 이제는 문제가 AMP 페이지에서 터져 나왔습니다. 대부분의 포스팅들이 모든 문제가 있어서 AMP 인덱스에서 빠졌다는 것입니다.
그 원인으로는 잘못된 CSS 스타일시트를 적용해다는 것인데요. 아무래도 구글 ngx_PageSpeed를 제대로 설정했더니 이와 충돌을 일으키는 것으로 보였습니다.
그동안 AMP 삭제에 대해서 고민을 많이 했는데 이 정도 수준이면 포기해야겠다는 생각이 들었고 본격적으로 삭제하기 시작했습니다.
도구에서 Real-Time Find and Replace 플러그인을 선택한 다음 ① Add 버튼을 눌러 ② Find 필드에는 ““입력하고 Replace에는 비워 놓습니다. ③ 그 다음 Regex를 눌러서 선택되도록 체크 표시한 후 ④ Update Setting을 누릅니다.
3.2. AMP 페이지를 인덱스하지 않토록 코드 추가
이렇게 rel=”amphtml” 마크업을 삭제하면 구글에게 더 이상 이 사이트에는 AMP 페이지나 포스트가 없다는 것을 알려 주는 것입니다. 그러면 구글은 이 관련 페이지들을 다시 인덱스하게 됩니다.
그런데 여기에는 문제가 하나 있습니다. 이제 Google은 AMP 버전 페이지를 일반 버젼의 중복 된 URL로 간주 할 수 있습니다. 이를 방지하기 위해서 제거된 AMP 페이지가 더이상 인덱스 되지 않는 방법을 추가해야 합니다.
이를 위해서 AMP for WP 플러그인을 삭제하지말고 여기에서 옵션 코드를 추가해 줍니다.
즉 AMP for WP 플러그인을 열고 SEO 섹션으로 이동한 다음 ““ 코드를 추가해 줍니다.
이제 AMP 페이지를 인덱스하지 않토록(NOINDEX)하도록 설정을 마쳤습니다.
3.3. 구글 서치 콘솔에서 사이트맵 제공
이제는 구글에 최신 사이트맵을 제공해서 우리 사이트를 최신으로 업데이트하고 인덱스에 반영해 달라고 요청해야 합니다.
먼저 최신 사이트맵을 만듭니다. 사이트맵 플러그인이 설치되어 있다면 자동으로 제출 될 수 있겠지만 그렇지않다면 수동으로 사이트맵을 만듭니다.
오늘은 브라우저 캐싱이라고 불리우는 웹 브라우저에서 캐싱을 통해서 워드프레스 속도를 높이는 방법에 대해서 살펴 보도록 하겠습니다.
1. 브라우저 캐싱(Browser Caching)이란?
사용자와 서버간 응답 속도를 높이기 위해서는 웹 페이지 구성 요소들을 압축하는 방법과 사용자 PC에 관련 내용을 저장해 놓고 재방문시 사용하는 브라우저 캐싱(Browser Caching)이 있습니다. 이 중 압축방법에 대해서는 앞에서 설명을 드렸습니다.
브라우저 캐싱(Browser Caching)은 보다 전문적이 용어로는 HTTP 캐싱이라고 불리우는데요. 가장 간단하게 설명해서 웹 페이지 구성요소(즉 이미지, CSS 파일 등)을 사용자의 PC에 저장했다가 그 페이지를 다시 방문 시 사용자 PC에 저장된 요소를 꺼내 보여줌으로써 속도를 빠르게 하고 트랙픽 절감 효과를 주는 기법입니다.
이는 사이트를 처음 방문할땐 효과가 없지만 재방문시는 속도를 빠르게 할 수 있습니다. SEO에서 중요시하는 TTFB(Time To First Byte)에는 도움은 안되지만 전체 사용에서는 효과를 볼 수 있습니다.
흔히 컴퓨터 Temp 폴더를 보면 그동안 방문했던 사이트의 이미지 등등이 모여 있는 것을 볼 수 있는데요. 이게 바로 그 사이트에서 브라우저 캐싱(Browser Caching)을 설정했기 때문에 남아 있는 것입니다.
만기일 매커니즘 : 브라우저가 웹 페이지를 재방문 시 사용자 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) 명령을 넣은 것입니다.
그러나 이런 방식을 지원하는 브라우저가 한정되어 있으므로 최근에는 거의 사용되지 않는 방법입니다. 마이크로소프트에서 제공하는 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파일 앞부분에 관련 명령을 넣습니다.
오늘 이야기는 멜트다운 이슈로 업데이트가 꼭 필요한 상황인데 보안 문제로 일부 PPA(Personal Package Archives, 개인 패키지 프로그램 저장소)에서 업데이트 안되는 상황을 해소하는 방법입니다.
다시 이러지말아야지 하면서도 서버를 만지다보면 문제를 발견하게 되고, 이 문제 해결 과정에서 나중을 위해서 기록으로 남겨야할 필요성이 들면서 다시 포스팅을 하게 되었습니다.
멜트다운 문제로 업데이트를 시도하다.
요즘 멜트다운 문제로 시끄럽습니다. 이 서버 분야에서는 특히 민감한 문제인 것 같습니다. 하여 제가 사용하는 우분투에서도 며칠전 프로그램 패치를 내놓았습니다. 그리고 제가 운영하는 Vultr에서도 며일내로 업뎅트를 한다고 공지가 나왔더군요.
아무튼 이 중요한 시기에 업데이트를 하려고 서버에 접속했는데요. 그동안 몇번 업데이트를 하려다 이런 저런 이유로 못했는데요. 이슈가 점점 커가는 듯 싶어 오늘만은 업데이트하리라는 굳은 결심을하고 서버에 진입했지만 생각지도 못했던 문제에 봉착했습니다.
업데이트를 진행하다 서버는 아래와 같은 메시지를 내놓고 중단해 버렸습니다.
@happist:~# apt-get update
Get:1 http://security.ubuntu.com/ubuntu artful-security InRelease [78.6 kB]
Hit:2 http://archive.ubuntu.com/ubuntu artful InRelease
Hit:3 http://ppa.launchpad.net/ondrej/php/ubuntu artful InRelease
Hit:4 http://nginx.org/packages/mainline/ubuntu xenial InRelease
Get:5 http://archive.ubuntu.com/ubuntu artful-updates InRelease [78.6 kB]
Ign:6 http://ppa.launchpad.net/rtcamp/nginx/ubuntu artful InRelease
Hit:7 http://ftp.kaist.ac.kr/mariadb/repo/10.2/ubuntu xenial InRelease
Get:8 http://archive.ubuntu.com/ubuntu artful-backports InRelease [72.2 kB]
Err:9 http://ppa.launchpad.net/rtcamp/nginx/ubuntu artful Release
404 Not Found
Reading package lists... Done
E: The repository 'http://ppa.launchpad.net/rtcamp/nginx/ubuntu artful Release' does not have a Release file.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
이게 무슨 문제인가를 살펴보니 rtcamp/nginx라는 PPA(Personal Package Archives를 사용하는 없데이트는 보안상 허용되지 않는다고 합니다.
아무리 생각해도 rtcamp/nginx는 무엇 때문에 설치했는지 기억이 나질 않은데요. 아마 이런 저런 시도를 하면서 rtcamp/nginx라는 PPA를 사용해 Nginx를 설치했나 봅니다.
이렇듯 서버를 운영하다 보면 알게 모르게 여러가지 PPA(Personal Package Archives, 개인 패키지 프로그램 저장소)에서 프로그램을 설치하게 됩니다. 그런데 이 PPA(Personal Package Archives)는 아무래도 신뢰성이 떨어지므로 꼭 믿을만하고 널리 알려진 PPA(개인 패키지 저장소)를 이용하라는 가이드를 많이 받고 있죠.
이런 PPA가 별 문제없이 지속적으로 작용하면 좋으련만 가끔은 보안등의 이유로 시스템에서 거부하는 경우가 생김니다. 이번이 그런 케이스인가 봅니다.
문제가 되는 PPA 삭제 방법
보안이 문제된다면 당연히 이러한 위험 요소가 있는 PPA 사용은 회피해야 겠지요. 그리고 이 PPA 자체를 서버에 남겨 놓아서도 안될것입니다.
그러면 이 PPA를 어떻게 없앨까요?
리눅스에서는 PPA 삭제는 설치와 유사한 방법으로 진행합니다.
add-apt-repository --remove ***(PPA)
이러한 방법에 따라 rtcamp/nginx라는 PPA를 삭제해 보죠.
add-apt-repository --remove rtcamp/nginx
그러면 아래와 같은 메세지를 내면서 계속 삭제를 하려면 엔터를 치고, 삭제를 멈추려면 Ctrl-c 를 치라고 합니다. 당근 엔터를 쳐야지요.
그러면 별다른 메세지없이 지워집니다.
Nginx build by rtCamp. This is mainly used and maintained for EasyEngine project - http://github.com/rtCamp/easyengine
You can use it directly as well.
More info: https://launchpad.net/~rtcamp/+archive/ubuntu/nginx
Press [ENTER] to continue or Ctrl-c to cancel removing it.
컨텐츠가 있는 곳에 검색이 있다. 쇼핑 정보가 가장 많은 아마존 검색이 활성화 되었다. 가두리지만 일정 정보를 모아 놓았던 네이버에 검색이 몰렸다. 그리고 컨텐츠가 풍부해지는 유튜브로 검색이 몰리는 것
유튜브 검색은 쇼핑을 위한 검색으로 진화 중, 유튜브 사용자 40%는 상품 구매전에 유튜브에서 검생을 일상화 함
소셜 정보 중 동영상이 구매로 이어지는 전환율이 가장 높았음. 86%는 동영상에서 영향을 받았으며, 텍스트는 겨우 44%에 불과
동영상 쇼핑 검색에서 새로운 기회들이 창출되고 있음
1. 컨텐츠 있는 곳에 검색이 있다.
요즘 유튜브의 역활이 굉장히 커졌습니다. 예전에는 네이버 검색이나 구글 검색을 당연하다고 생각했는데, 요즘 젊은 세대는 무엇을 찾을 때 유튜브 검색을 당연 시하고 있습니다. 우리 은우나 은결이도 동영상을 많이 보기 때문이지만 검색의 상당 부분을 유튜브에서 하고 있더군요.
이는 보고 싶은 컨텐츠가 있는 곳에서 검색을 하는 것으로 어쩌면 당연한 귀결일 것입니다. 미국에서 쇼핑 검색의 70%를 아마존에서 하는것처럼 말입니다. 물론 그 사람들도 구글 검색을 그 못지 않게 합니다만 아마존 검색이 더 전환율이 높기 때문에 구글로서는 가슴 아푼 일이겠지요.
▽ 컨텐츠 있는 곳에 검색이 있다는 것을 보여주는 아마존, 미국 영국 프랑스 독일 소비자들이 상품 구매전에 탐색하는 사이트
유튜브 검색이 활성화되고 젊은층에서 유튜브 검색이 더 활성화되는 이유는 유튜브에 젊은이들이 좋아하는 컨텐츠가 있기 때문입니다.
2. 왜 소비자는 유튜브에서 상품 검색을 할까?
이러한 유튜브 검색이 이제는 단순 동영상 검색을 넘어 구매로 넘어가기전의 상품 정보 검색에서도 맹위를 떨치고 있다고 합니다. 이러한 현상에 대해서 이마케터가 How Video Is Changing The Way Consumer Shop이라는 자료를 발표했는데요. 이 내용을 간략 정리해서 공유합니다.
소비자들의 상품 구매전에 유튜브 검색이 크게 증가했습니다. Think with Google에서 밝힌 데이타에 따르면 유튜브 사용자의 40%는 상품에 대해서 더 알아 보기 위해 유튜브와 같은 동영상 플랫폼을 방문했다고 조사되었습니다.
그러면 이 소비자들은 유튜브와 같은 동영상 풀랫폼에 어떤 이점이 있다고 생각할까요? 당연하게도 그들은 제품을 실제 볼수 있기 때문이라고 답합니다. 동영상에 비해서 일반 상품 판매 사이트나 블로그는 동영상 중심으 제공하는 유튜와 같은 플랫폼 만큼의 디테일한 정보를 줄 수 없습니다.
구글 Think With Google에 따르면 Target이나 Homegoods같은 곳에서 쇼핑하는 사람들을 대상으로 제작해 상품 평가 시 가상 태그를 붙여 유튜브에서 보도록 유도했던 “shop with me”와 같은 상품 소개 동영상 시청율은 지난 2년간 1,000% 증가했다고 합니다.
이러한 동영상은 동영상 시청 시간이 증가하고(평균 미국 성인은 하루 81분 디지탈 비디오를 본다고 함), 동영상 컨텐츠가 점점 풍부해지면서 구매 과정에서 동영상의 영향이 점점 커지고 있습니다. 동영상은 다른 매체에 비해서 이미지와 나래이션을 추가하여 가장 설득력이 강한 컨텐츠로 거듭나고 있으며, 동영상을 통해서 감정 이입을 쉽게 할 수 있는 잇점이 있습니다. 활자 매체에 비해서 몰입도가 높고 이성적인 경계를 쉽게 무너뜨릴 수 있어 기존 매체가 가지지 못한 강력한 영향력을 가지게 된 것입니다. 동영상을 통해서 다른 사람들이 신상품을 고르려고 고민하는 것을 볼 수 있고, 또 신상을 입고 있는 것을 보면서 그리고 신상을 입고서 멋진 시간을 보내는 것을 보여줌으로써 기존 매체가 할 수 없었던 엄청난 감정 이입을 가능케 합니다.
인플러언서 마케팅 및 소셜 미디어가 소비자 행동에 미치는 영향을 조사한 gen.video와 Geometry Global의 조사에 따르면 소셜 사용자들에게 동영상을 통한 구매 결정 영향이 가장 컸다고 밝히고 있습니다. 이 조사에 따르면 소셜 미디어 컨텐츠 중 구매에 미치는 영향은 동영상이 86%로 가장 높았고 이미지가 78% 그리고 텍스트는 44%에 불과했습니다. (중복 응답이므로 총합이 100%를 넘는다.)
이에 대한 그래프는 아래를 참조하세요.
3. 마치며
어쩌면 트렌드가 동영상으로 흘러갔다는 사실은 진부한 언명일 수 있습니다. 근래 동영상의 중요성에 대해서 엄청나게 이야기되었기 때문이고 인스타그램이나 스냅챗이나 오래전부터 (짧은) 동영상에 승부를 걸고 있고, 페이스북이나 애플이 영상 컨텐츠를 활성화하기 위해 엄청난 노력을 한다는 것은 주지의 사실이니깐요.
그러나 쇼핑의 관점에서는 아직도라는 생각이 있을 수 있는데 이 부분도 이미 많은 부분이 shift되고 있다는 것을 보여주고 있습니다.
여기서 엄청난 새로운 기회들이 만들어지고 있습니다. 그게 어떤식으로 구현될지 고민해 봐야겠습니다.
여기 아일랜드 금연 광고가 있습니다. 이 광고는 2017년 4월 아일랜드에서 제작, 방영되어 큰 호평과 소기의 금연 캠페인 성과를 거두었습니다.
아일랜드 HSE의 금연 광고 I Will Survive
아일랜드 정부 보건 서비스인 HSE가 공개한 이 광고는 글로리아 게이너(Gloria Gaynor)의 유명한 1978년 노래를 립싱크하면서 금연을 맹세하는 장면을 담고 있습니다.
이 광고는 뛰어난 작품성으로 2017년 많은 광고제에서 수상(Kinsale Shark 페스티발, Epica상 수상 등)했고 2018년 뉴욕시는 이 광고를 뉴욕에서도 온에어 하겠다고 결정했습니다.
실제 사람들이 금연를 결심하는 결정적인 진실의 순간이 있습니다. 이 광고는 글로리아 게이너(Gloria Gaynor)의 노래 “I Will Survive”의 음악과 가사를 사용했습니다. 이 노래는 금연을 결심하는 많은 사람들이 담배로부터 해방되는 기분과 건강한 상태가 되는 것을 축하하는 감정과 상태를 잘 반영하고 있습니다. – 아일랜드 HSE 관계자
실제로 2007년이후 담배를 피우는 아일랜드 사람들의 비율은 29%에서 22%로 낮아졌습니다. 이는 인구의 27%가 과거에는 담배를 피우는 사람들이었고 아일랜드 15세이의 백만명 이상이 금연을 성공적으로 이루었다는것을 말하고 있죠.
이 광고의 댓글에는 광고를 피우지 않은 사람들 이야기보다 더 많은 금연 사연들이 올라왔습니다.
Gloria Gaynor — I Will Survive Official Video HD
I Will Survive 노래 가사
I Will Survive Lyrics
At first, I was afraid, I was petrified Kept thinking, I could never live without you by my side But then I spent so many nights thinking, how you did me wrong And I grew strong and I learned how to get along
And so you’re back from outer space I just walked in to find you here with that sad look upon your face I should have changed that stupid lock I should have made you leave your key If I’d known for just one second you’d be back to bother me
Go on now, go, walk out the door, just turn around now ‘Cause you’re not welcome anymore Weren’t you the one, who tried to hurt me with goodbye? Did you think I’d crumble? Did you think I’d lay down and die?
데이타베이스가 오래되면 파편화가 생길 수 있고, 어디인지 모르게 꼬일 수도 있습니다. 그래서 데이타베이스를 최적화 시켜주는데요.
이는 컴퓨터 하드디스크 정리와 비슷합니다. 컴퓨터 하드디스크에 기록되는 정보들은 순서대로 차곡차곡 정보가 쌓이는 것이 아니라 여기 저기 분산되어 빈 공간에 데이타를 저장하게 됩니다. 그러다보면 정보를 찾는데 시간이 걸리먄서 속도가 저하되는 것처럼 데이타베이스도 여기저기에 정보가 저장되다보면 속도가 느려지게 됩니다.
이렇게 명령을 수행하다보면 “Table does not support optimize, doing recreate + analyze instead”라는 메세지를 만나게 되는데요. 이는 MariaDB에게는 이런 메세지를 보여준다고 합니다.
wp.wp_commentmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_comments
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_links
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_options
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_postmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_posts
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_term_relationships
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_term_taxonomy
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_termmeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_terms
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_usermeta
note : Table does not support optimize, doing recreate + analyze instead
status : OK
wp.wp_users
note : Table does not support optimize, doing recreate + analyze instead
status : OK
4. 주기적으로 최적화하기
그러면 데이타베이스를 최적화한다면 조금 더 성능이 좋아진다고 하는데요. 이를 정기적으로 수행할 수 있는 방법이 없을까요?
바로 리눅스에서 제공하는 cron 명령을 사용하면 가능합니다.
매일 새벽 3시에 모든 데이타베이스를 최적화하고 오류가 있으면 자동으로 복구하도록 하겠습니다.
아래와 같이 cron에 등록해주면 매일 새벽 3시 30부나다 모든 데이터베이스를 최적화, 오류가 있으면 오류복구를 실행하게 됩니다.
먼저 cron에 주기적으로 최적화 및 오류 복구 명령을 수행하기 위해서 crontab -e 명령을 사용합니다.
가상서버호스팅을 시작했다면 서버를 설치해보고 기본 세팅 정도는 할 수 있어야 할것 입니다. 저도 이 분야를 전혀 모르는 문외한 이었지만 구글링의 힘을 빌어서 거의 1년 반동안 서버를 운영해 오고 있습니다. 물론 상당히 많은 시간 투자를 해야 합니다.
서버 설치 시 엔트리급 서버를 운영한다면 아래 내용을 참고하는 게 좋을 것 같습니다. 엔트리급은 Vultr아나 Linode 기준으로 월 2.5$,또는 5$ 플랜으로 디스크 용량은 크지만 메모리가 작은 경우입니다.
메모리가 적은 엔트리급에서는 32비트 운영체제를 사용하는게 도움이 됩니다. 원래 윈도우즈에서도 32비트 운영체제는 기본 4GB만 지원할 정도로 적은 메모리에서 작동하도록 만들어져 있습니다. 그렇기에 램 512MB, 765MB, 1GB등 엔트리급 사양으로 워드프레스 사이트를 운영한다면 32비트 Ubuntu나 Centos등 운영 체제를 선택하면 조금 도움이 됩니다. 요즘 대세인 64비트 운영체제는 풍부한 메모리사용을 지원하기 위해서 개발되었고 그러다보니 기본적으로사용하는 메모리가 큽니다. 운영 체제별 최소 사양을보니 Centos/ Ubuntu 32비트는 최소 메모리로 512MB를 권장합니다. 64비트는 1GB를 권장하는데 예전 경험으로 보면 512MG나 756MB도 돌아가긴 하더라구요.
데이타베이스 설치 시 메모리를적게 사용하는 MyISAM 같은 데이타베이스를 선택할 필요가 있습니다. 요즘 InnoDB가 대세이고, 이를 적용하는 것중에 MariaDB가 가장 좋다고 많이 선택합니다, 그런데 이게 기본적으로 예전에 사용하던 것에 비해서 많은 메모리를 사용합니다. 그래서 조금 성능은 떨어지지만 MyISAM를 적용할 수 있습니다.
사이트 운용에서 빠른 메모리를 많이 확보하는것이 성능을 높일 수 있는 지름길이므로 엔트리 사양이라면 가능하면 많은 메모리를 확보할 수 있는 운영체제, 데이타베이스, 플러그인등을 선택하는 게 좋습니다.
이렇게 말씀드리지만 저는 1GB 메모리지만 이미 64비트 운영체제,MariaDB를 설치해 적용하고 있어서 이를 중심으로 설명드릴 예정입니다. 그리고 조만간 RAM을 2GB로 업그레이드할 예정입니다.
저도 Newspaper를 사용하다 진짜 가볍고 단순하면서도 디자인적으로 나쁘지 않은 테마로 변경 사용을 시도했습니다. 처음에는 가볍기 때문에 만족하면서 사용했는데요. 어느 순간 이것도 문제가 있다는 것을 알았습니다.
어느날 사이트가 갑자기 이상하게 작동하기 시작하는 것 입니다. 어떤 주소를 입력해도 똑같은 페이지로 이동해버리는 문제가 발생했는데요. 원인을 알기 위해 이런 저런 시도를했지만 워드프로세스를다시 설치하는 것외는 방법을 찾지 못했습니다. 그런데 테마를 Newspaper와 같은 최신 유료 테마로 변경하니 단박에 문제가 해결되더군요.
제가 적용했던 가벼운 테마들은 개인이 무료로 공개하는 것들이었는데요. 이들은 업데이트가 거의 없었고 특히 보안 이슈로 반드시 업데이트가 필요한 경우에도 대응을 않하거나 못하는 경우가 많은 것 같았습니다.
이런 경험을 하니 꼭 속도가 빠른 가벼운 무료 테마가 좋은 것은 아니다라는 생각이 들었습니다. 어느 정도 돈이 들더라도 꾸준히 기능 및 보안 업데이트가 빨리 빨리 이루어지는 테마를 사용하는 게 장기적으로는 이익이라는 결론을 얻었습니다. 그래서 다시 유료 테마인 Newspaper 8.5로 돌아왔습니다.
결론은 안정성있는 유료 테마중에서 꼭 필요한 기능 중심으로 커스터마이징해서 사용하는 게 좋습니다.
[업데이트] 워드프레스를 사용한지 5년 가까이 되면서 생각해보묜 Newspaper와 같은 완전한 유료보다는 위에서 언급한 Astra, GeneratePress, OceanWP와 같은 무료 버전과 유료 버전이 같이 있는 테마를 사용하는 것이 좋다는 생각을 합니다.
이러한 테마들은 무료 버젼도 유료 버전을 유지하기 위해서는 계속 업데이트 및 업그레이드를 해야 하기 때문에 상대적으로 안전합니다.
5. 웹브라우저에서 서버까지 길 빨리 찾기
앞에서 사용자가 워드프레스 컨텐츠를 보기 위해 인터넷 브라우저에서 명령을 내리면 브라우저는 컨텐츠가 있는 사이트 서버가 어디에 있는지를 찾습니다. 이를 전문 용어로 DNS Lookup이라고 하는데요. 브라우저가 사이트 서버가 있는 곳을 빠르게 찾을 수 있도록 만들어 것이 필요합니다.
그러면 DNS Lookup 시간을 어떻게 줄일 수 있을까요?
일반적으로 한국 업체에서 도메인을 구입하고 한국 서버를 사용하면 DNS Lookup 시간은 거의 걸리지 않는 것 같습니다. 네이버의 경우 30ms가 나오네요.
저는 미국 업체인 LuckyRegister 에서 도메인을 구입하고 서버도 일본에 있는 vultr을 사용해서인지 처음엔 DNS Lookup 시간이 250ms까지 나오더군요.
이 결과(솔직히 어는 항목이 효과를 보았는지 분간이 잘 안됩니다.) DNS lookup 시간은 30ms 정도로 줄었습니다. 물론 때에 따라서는 100ms가까이 가는 경우도 간혹 나오지만 30ms 정도로 안정적인 속도가 나옵니다.
[업데이트] 여기서 이야기하는 구글 페이지스피드 모듈(Google PageSpeed Module)은 구글에서 야심(?) 시작한 웹 개선 프로젝트였지만 몇년전부터 중단되었습니다. 그리고 서버에서 엄청난 자원을 사용하면서 오히려 성능이 낮아지는ㅁ 누제도 있기 때문에 거의 사용하지 않습니다.
6. 캐시 플러그인?
이 단계부터는 서버단에서 작업 효율을 높이는 방법에 대해서 살펴 보겠습니다.
가장 먼저 살펴볼 것이 cache를 잘 활용하는 것인데요. 어쩌면 가장 극적으로 성능이 개선 되는 것을 볼 수 있는 것이 바로 이 캐시(cache) 사용이 아닐까 합니다.
앞에서 설명했지만 서버는 브라우저에게서 받은 요청을 수행하려고 이 내용이 어디에 있는지를 찾고, PHP에게 사람들이 이해할 수 있는 HTML 파일로 만들도록 시키죠. 그러면 PHP는 데이타베이스에서 정보를 찾아 HTML 파일을 만드는데요. 이런 과정을 건너 뛰게 하거나 쉽게 할 수 있도록 만드는 게 캐시의 역활입니다.
이 캐시에는 여러 가지 종류가 있는데요. 제가 보기엔 3가지로 정리할 수 있습니다.
HTML 파일 전체를 cache하는 Full Page Cache
PHP Script한 결과를 보관하고 있는 PHP Script Cache
데이타베이스 관련해 Query 결과를 모아 두는 Query Cache
일반적으로 cache라고하면 캐시 플러그인(cache plug-in)을 떠올리는데요. 저는 이런 캐시 플러그인들이 충돌을 많이 일으켜서 가능하면 서버에서 제공하는 cgche 기능을 활용하는 것을 선호합니다.
6.1. Full page caching – FastCGI
Full page caching은 완성된 HTML 페이지를 디스크(RAM 용량이 많다면 RAM Disk)에 저장하고 있어서 브라우저로부터 요청 시 여기서 바로 컨텐츠를 보여주므로 실제로 속도도 빨라지고 체감 속도도 엄청 빨라 집니다.
이러한 Full page caching은 웹서버를 설치시 같이 설치되는 FastCGI의 성능이 우수하다고 알려져 있습니다.
아래는 FastCGI가 작동하는 다이어그램인데요. NGINX, PHP-FPM, MySQL 사이의 관계를 잘 보여주고 있습니다. 이 다이어그램은 ashleys라는 곳에서 배포한 것입니다.
FastCGI cache는 서버 부하를 줄여주고, 사이트 속도를 빠르게 해주는데요. cache된 페이지 중심으로 로딩 속도가 빨라지고, TTFB(Time To First Byte, 서버에 요청해 첫 데이타를 받기까지 걸리는 시간)가 절반 이하로 줄어듭니다.
NGINX 요청은 받은 PHP는 PHP script를 수행하게 되는데요. PHP Interpreter는 PHP Script를 컴파일하고 그 결과를 Shared Memory에 저장한 후 결과를 수행하게 됩니다. 나증에 똑같은 요청이 오면 Shared Memory에 Cache된 결과물을 이용하므로 속도를 증대시킬 수 있습니다.
아래는 PHP Script를 처리하는 과정에 대한 플로우 차트인데 Cache와 PHP Script 컴파일이 잔행되는 프로세스를 살펴볼 수 있습니다. 이 플로우 차트는 Basics of PHP opcode cache 에서 가져왔습니다.
이런 PHP Script 결과를 Cache해주는 프로그램에는 여러가지가 있지만 PHP에 기본 내장되는 OPcache가 가장 성능적으로 우수하다고 합니다. OPcache 사용에 대해서는 아래 포스팅을 참조하시기 바랍니다.
위에서 거론한 방식들은 서버단에서 직접 적용하는 것이라서 일방 웹호스팅에서는 적용하기 어려울 수 있습니다.
이럴 경우는 비슷한 효과를 내주는 캐시 플러그인을 설치할 수 있는데요. 여기에는 WP Super Cache, W3 Total Cache, WP Rocket 등등이 있습니다.
이러한 캐쉬 플러그인들은 각기 독특한 특징을 가지고 워드프레스 성능을 높여주고 있는데요. 각기 특징이 다르고 운영하고 있는 사이트와 잘 맞는지를 점검해서 사용해야 합니다.
기능이 많다고 좋은 성과를 내는 것도 아닙니다. W3 Total Cache는 캐쉬 플러그인중에서 가장 다양한 기능들을 적용하고 있습니다. 그렇다고 W3 Total Cache가 가장 좋은 성과를 보여 준다는 것은 아닙니다. 우수한 편이지만 가장 우수하다고 볼 수는 업죠. 그리고 복잡한 기능을 적용하다보니 충돌이 많은 편입니다.
캐쉬 플러그인에 대한 여러가지 벤치마킹한 자료들을 보면 이 테스트 결과에서 수위를 차지하는 것은 CacheEnabler, WP Rocket 또는 WP Super Cache등이 많이 거론되고 있습니다.
다운 받을 파일에서 필요 없는 부분, 예를 들어 주석이라든지, 빈 공간이라든지를 지워 용량을 가볍게 하는 방법입니다. 이를 Minify라고 부르는데요.
이렇게 minify하는 방법에는 여러가지가 있습니다.
가장 무식한 방법으로 서버 운영자가 각각 CSS 파일, Java Script 파일 등등을 줄일 수도 있습니다. 이는 것은 너무 힘들고 비효율적입니다. 그리고 수시로 업데이트되기 때문에 대응 불가능하죠. 저도 Newspaper 테마의 style.css 파일이 무려 1MB에 육박하기 때문에 필요없는 부분을 지워서 0.5MB로 만들어서 사용한적이 있습니다. 우선 속도가 얼마나 빨라졌는지 차이가 나지않고요. 업데이트될때마다 이런 작업을 매번 다는 할 수는 없어서 포기 했습니다.
다음으로는 Minify를 해주는 워드프레스 플러그인을 활용하는 방법입니다. 널리쓰이는 Autoptimize는 이런 파일들을 minify해주고 caching해 줍니다. 다만 이 방법은 다소 느리기 때문에 별로 권장하지 않는 방식입니다.
가장 속도가 빠른 것은 NGINX나 APACHE 서버를 설치 시 구글 페이지스피드 모듈(Google PageSpeed Module)을 포함해 컴파일해서 서버에서 직접 알아서 minify 하도록 하는 방식입니다. 이는 제가 사용하는 방식인데요. 뒤에서 소개하는 구글 페이지스피드 모듈(Google PageSpeed Module)을 참조하시기 바랍니다. 이 방식의 단점은 컴파일이 다소 복잡하고 조금(20분정도?) 시간이 걸립니다.
렌더링이 시작되면 다운 받는 내용중 가장 많은 비중을 차지하는 것 중의 하나가 이미지입니다.
아래는 제 사이트 메인의 컨텐츠 종류별 요청 비중과 다운받은 용량 비중을 나타낸 그래프인데요. 이미지 요청은 68개로 비중이 52.3%나 차지하지만, 실제 다운 용량 비중은 35%로 오히려 적어지고 있습니다.
이렇게 68개나 되는 많은 이미지이지만 적절하게 압축해서 다운 용량을 0.4MB로 최적화했기 때문에 비중이 줄어드는 효과를 본 것입니다.
그러면 여기서 제가 어떻게 이미지를 최적하하고 있는지 이야기 해보겠습니다.
먼저 포스팅 시 이미지는 가능하면 jpg 중심으로 사용합니다. 가장 압축율이 높기 때문입니다.
JPG라도 압축율을 70%~85%로 높여 이미지를 가볍게 만듭니다. 이반 이미지는 70% 압축율을 적용하고, 글씨들이 많이 포함된 이미지는 85% 정도로 압축을 약하게 합니다. 압축율이 높아지면 글자가 흐릿해지더군요. jpg 아축율은 80%정도가 적절하고 하는데 80% 압축하면 구글 페이비스피드로 측정해보면 압축을 더하라고 가이드하더군요.
서버단에 적용된 구글 페이지스피드 모듈(Googke PageSpeed Module)에서 각종 이미지 압축 기술을 적용토록 옵션을 두고 있고 특히 크롬등에서 적용하는 webP 포맷을 적ㅇ요토록 하고 있습니다. 이에 대해서는 아래 포스팅을 참조하세요.
외국이라면 전체 속도에 효과 있고, 트래픽이 절감되며 보안에도 유리한 방법이 바로 CDN(contents delivery network)인데요,
위키에서 CDN(contents delivery network)을 아래와 같이 정의하고 있습니다.
콘텐츠 전송 네트워크(Content delivery network 또는 content distribution network (CDN))는 콘텐츠를 효율적으로 전달하기 위해 여러 노드를 가진 네트워크에 데이터를 저장하여 제공하는 시스템을 말한다.
서버와 사용자사이 인터넷 중간에 CDN이라는 별도 cache 역활을 하는 다수의 서버에 컨텐츠를 저장해놓고 사용자는 가장 가까운 CDN 서버에서 컨텐츠를 받을 수 있도록 한 것으로 먼곳의 사용자가 빨리 접속할 수 있습니다.
그러나 이 서비스에는 두가지 문제가 있다고 알려져 있습니다.
첫째는 CDN을 걸쳐서 컨텐츠를 받기 때문에 TTFB가 느리게 나옵니다. 이 TTFB 속도에 대해서 CDN 서비스의 대표격인 클라우드 플레어에서는 TTFB가 중요하지 않다고 발표했었고 구글에서 반박하는 해프닝이 있었습니다. 이에 대해서는 hackYa님의 글 클라우드플레어 (CloudFlare)를 쓰지 말아야 하는이유를 참고하세요.
둘째는 클라우드플레어 (CloudFlare)같은 글러벌 서비스는 여러가지 정책 상 비지니스 플랜이외에는 한국 서버가 아닌 해외 심지어는 유럽 서버로 연결되어 속도가 엄청 느려 진다고 합니다. 특별히 트래픽 절약 목적이 아니라면 사용하지 말자는 이야기가 많습니다. 이에 대해서는 XETOWN 가진곰님의 글을 참고해 보세요. 제발 해외 CDN 좀 사용하지 맙시다.
이러한 이유로 저는 CDN(contents delivery network)은 사용하고 있지 않습니다. 아직 트래픽을 5%(월 1TB 트래픽 중 약 60GB 사용)밖에 사용하지 않아서 트래픽을 절약할 이유도 없구요.
8. 워드프레스 군더더기 없애기
다음으로 생각할 게 워드프레스에 불필요한 군더더기를 최소화 하는 것 입니다.
이러한 군더더기에는 무엇이 있을까요? 군더더기라고 표현하니 쓸모없는 것이라고 생각하기 쉽지만 정확히 표현해서 중요성이 떨어지는 것입니다.
8.1. 워드프레스 리비젼(Revision) 갯수 제한
워드프레스로 글을 작성하다보면 계속 내용을 업뎅트 하게 됩니다. 그러면 워드프레스는 무한적으로 수정 버젼을 기록하는데요. 이를 리비젼(Revision)이라고 부릅니다.
정말 중요한 문서가 아닌 이상 글의 히스토리를 기록할 필요가 없고 대부분 이전 버젼을 참고하므로 리비젼(Revision)이 거의 필요 없거나 최소로 남겨 놓는 게 효율적입니다.
가장 쉽게는 wp-config.php에서 아래 문구를 넣어 리비젼(Revision) 갯수를 제한 합니다.
워드프레스는 2.9버젼부터 휴지통 기능이 생겨 포스팅, 댓글, 미디어 등을 삭제하면 휴지통으로 이동해 치종 39알 경과하면 완전히 없어집니다.
자주 포스팅, 댓글, 미디어등을 지운다면 휴지통에 많은 정보들이 모여 데이타베이스 공간을 차지하고 데이타베이스가 커지면 실행 속도가 느려질 수 있습니다.
따라서 주기적으로 휴기통을 지워주든지 휴지통에서 비워주는 기간을 30일보다 앞당기는 것도 한 방법입니다.
워드프레스 wp-config.php에서 아래 문구를 넣어 휴지통에서 완전 삭제하는 기간을 단축합니다.
/** 휴지통 완전 삭제 기간을 10일로 단축하기 */
define ('EMPTY_TRASH_DAYS', 10);
Code language:PHP(php)
8.3. 트랙백과 핑백 알림을 사용하지 않기
워드프레스는 커뮤니케이션 활성화를 위해 트랙백과 핑백을 기본으로 알려주는 기능을 적용하고 있습니다.
그러나 스팸등의 이유로 이런 기능을 없애는 블로그 툴들이 늘어나고 있습니다. 네이버 블로그나 티스토리는 아예 트랙백 기능을 없앴습니다.
워드프레스에서도 스팸 위험이나 데이타베이스를 가볍게 만들기 위해 트랙백과 핑백 알림을 사용하지 않토록 설정할 수 있습니다.
워드프레스 설정 – 토론의 기본글 설정에서 “새로운 글에 다른 블로그에서 오는 링크알림(핑백이나 트랙백)을 허용”부분의 체크를 없애면 됩니다.
저는 이게 워드프레스 속도에 미치는 영향이 크지 않다고 생각하며, 스팸의 위협도 Disqus 등을 적용하면 거의 없으며 블로그의 본질이 커뮤니케이션에 있다고 생각해서 아직은 유지하고 있습니다.
8.4. 플러그인 최소화, 가벼운 플러그인 사용
워드프레스로 사이트를 운영하다보면 매력적인 기능을 제공하는 다양한 플러그인을 만나게 됩니다. 그러면 그 기능과 디자인에 혹해서 하나 둘씩 플러그인을 늘랴가게 되죠.
하지만 워드프레스는 이러한 플로그인이 늘어날수록 이런 플러그인을 모두 처리하고 컨텐츠를 보여주므로 워드프레스를 느리게 할 수 있습니다.
앞에서 계속 강조했던 최적화를 위해서 요청 명령수를 최소화하자는 원칙에서 벗어나 요청 명령수를 늘리고 속도를 저하하게 됩니다. 따라서 정말 꼭 필요한 플로그인인지 심사 숙고한 후 설치해야 합니다.
저는 플러그인을 7개 내외로 최소화하고 있습니다.
그리고 꼭 필요한 플러그인이라면 상대적으로 가벼운 플러그인이 무엇인지를 고민할 필요가 있습니다.
SNS 공유 플러그인을 검토한 예를 말씀드리면 플러그인에 따라 로딩 속도차이가 컸습니다. 당시 Monarch, AddThis, AddToAny 그리고 Sassy Social Share를 검토했는데요. 플러그인에 따라서 로딩 시간이 최대 1초까지 차이가 났습니다. 기능이나 멋진 디자인에도 불구하고 0.5초 ~1초 까지 감수할 이유는 없었습니다. 결국 가장 가벼워 보이면서도 커스터마이징이 가능한 Sassy Social Share를 적용했습니다.
이런 여러가지 최적화를 통해서 최종 속도는 어느정도 나올까? 아래는 여러 측정도구 중 가장 잘 나왔던 Webpagetest.org에서 측정한 값 입니다. 로딩 타임 1.42초, TTFN 0.47초, 렌더링 시작 시간 1.09초로 비교적 양호합니다.
10. 마치며
이상으로 간단하게 워드프레스 최적화 방안에 대해서 정리해 보았습니다.
개인적으로는 (아마 많은 원드프레스 사용자들이 공감할 것입니다. FastCGI를 제대로 적용했을 시 가장 급격하게 속도가 좋아졌습니다. 아마 이와 비슷하게 Full page cache에 집중해주는 cache enabler 등이 속도가 좋았던 이유도 마찬가지라고 생각합니다.
다음으로는 이미지 압축을 통해서 약 2.5GB의 이미지를 0.9GB로 줄였는데요. 이 때도 확실하게 다운 이미지 용량이 감소하니 도움이 되었던 것 같습니다.
![[워드프레스 최적화] 구글 AMP(Accelerated Mobile Pages) 제거로 사이트 정체성 유지하기](https://happist.com/wp-content/uploads/2018/01/구글-AMP-삭제-방법-How-To-Remove-Googlr-AMP-768x362.jpg "[워드프레스 최적화] 구글 AMP(Accelerated Mobile Pages) 제거로 사이트 정체성 유지하기")
![[워드프레스 최적화] 브라우저 캐싱(Browser Caching) 설정으로 빠른 속도와 트래픽 절감이란 두마리 토끼를 잡아 보자](https://happist.com/wp-content/uploads/2018/01/Featured_Fast-자전거-경주-paolo-candelo-203824-768x368.jpg "[워드프레스 최적화] 브라우저 캐싱(Browser Caching) 설정으로 빠른 속도와 트래픽 절감이란 두마리 토끼를 잡아 보자")
![[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck](https://happist.com/wp-content/uploads/2018/01/Featured_Fast-터널-tunnel-mathew-schwartz-397471-768x345.jpg "[워드프레스 최적화] 효율적인 MySQL 데이타베이스 최적화 및 복구 방법, mysqlcheck")
![[워드프레스 최적화] MySQLTuner 사용 워드프레스 데이타베이스 튜닝 방법](https://happist.com/wp-content/uploads/2018/01/Featured_Fast-자동차-toine-garnier-396670-768x345.jpg "[워드프레스 최적화] MySQLTuner 사용 워드프레스 데이타베이스 튜닝 방법")
