오랜만에 확인해본 FeedBurner 통계

feedburner-collapsed

Google 사용량 통계 메일 (매달 오는듯?) 보다가 FeedBurner가 아직 살아있는 것 보고 반가운 마음에 (???) 들여다본 결과.

Google Reader가 2013년 7월 1일 부로 서비스 종료한 이후로 구독자 수 / 도달률 모두 거의 붕괴한 상황이다. 내가 블로그를 덜 읽고, 글도 덜 쓰게 된 것도 대충 저것과 유사한 흐름인 것 같기도 하구나 -_-a

Python 기반의 static page 생성기로 블로그를 옮기려는 중

원래 내 의도는 최근에 읽은 책 (=”해커를 위한 디자인 레슨”) 과 게임 (=”어쌔신 크리드 2 및 그 확장팩, 3″)에 대한 리뷰를 쓰려는 거였다.
하지만 블로그 관리자 페이지 로딩이 너무 느려서 — WordPress 버전이 올라갈 수록 더 심한듯? — 좀 괴롭다.

(일반 유저가 볼) 페이지 로딩 자체는 큰 차이가 없어서 그냥 쓸 생각이 많았는데 오늘 좀 추가 많이 기운 듯 하다.

그래서 Pelican 이란 도구를 다음과 같은 이유로 시도해봤다: (이 순서대로 고려한 것은 아님)

  • OpenSource
  • History가 길다 (+5yr)
  • 현재도 개발이 진행되고 있다
  • Python 기반
  • Markdown 지원 (rst가 주 언어지만)
  • WordPress import 지원

이걸 가지고 내 블로그를 import 해보니 몇 가지 문제가 있다: (WordPress 가 정의한 xml을 rst로 변환하는 도구가 포함되어 있다)

  • 멀티바이트 인코딩된 블로그 제목이면 rst 의 #### 이 부분을 짧게 계산해서 망한다. (글자 수를 세서 그런가)
  • 일부 글에서 글자를 해석 못해서 망하고 있음
  • 글 제목(정확히는 WordPress의 slug 값)을 이용해서 .rst 를 만드는데 urlencode 당한 문자열을 쓴다 -_-

딱히 다른 대안이 없으면 importer를 고치고 어떻게 해봐야겠다;

블로그 로딩 시간 줄이기

주말 저녁에 블로그 패이지 뜨는 속도가 이상하리만치 느려서 최적화하기로 결정했다 — 심지어 구글은 페이지 랭크에 로딩 속도를 반영한다.

사용한 도구는 Chrome용 Pagespeed 확장기능. 여기서 네트워크 탭을 이용해서 오래걸리는 기능을 하나씩 제거했다.
최적화 하기 이전 측정치는  다음과 같다.


WordPress JetPack 관련
이 플러그인엔 적어도 두 가지 문제가 있다. 우선 통계 플러그인이 제 3자인 quantcast 쪽에 js파일을 큰 쿠키를 던져 요청하고, 이걸 실행한다. 위에서 quant.js, pixel;… 에 해당하는 내용. 이게 적어도 500ms는 걸리더라. 이게 이전부터 꽤 이슈였던듯. Respecting User Privacy in WordPress에 따르면 2011년 초 이전부터 있던 일이란다. 이슈화돼서 그런지 이에 대한 방책도 있다. WP DoNotTrack이란 플러그인이 이에 해당하는 DOM 삽입을 차단해준다. 이걸 쓰면 이 500ms를 줄일 수 있더라.그리고 쓰지도 않는 gravatar hovercard관련으로 로드하는 js 파일도 지연시간이 꽤 큰 편. 게다가 css까지 로드 하는 시간을 생각하면 아주 악몽이다. 저 위에선 6초 넘게 날려먹었음. (분산도 커서 더욱 거지 같기도하고). 첫 js 로드도  길고, 얘가 로드하는 파일도 다운로드가 오래 걸리고…
하지만 이게 어이 없었던건 — 난 켜지도 않은 기능이니 — 데이터베이스에 원래 있어야 할 옵션이 없어서 그렇다. 다음 항목을 wp_options 테이블에 추가하면 됨. (wp 부분은 설치 설정에 따라 다름)

mysql> insert into wp_options (option_id, option_name, option_value) values (NULL, ‘gravatar_disable_hovercards’, ‘disabled’);

이걸로 적어도 500ms ~ 3000ms 정도를 벌 수 있다.

 

블로그 테마 관련

위의 두 가지를 제외하면 다음 내용들이 적당히 튀어나온다.

1. 블로그 내용 시작 부분에 Google Transliteration관련 스크립트를 로드하더라. 이건 내 블로그엔 필요 없는 듯 하니 제거. jquery도 구글 서버에서 가져오게 수정.

2. 서버의 vhost 중 내 블로그만 mod_pagespeed 를 적용해 봤다.[1] wp supercache가 문제를 일으키길레 일단 이 플러그인은 삭제. 그리고 .htaccess에서 켰던 mod_deflate 강제하는 것도 껐다. 어차피 mod_pagespeed가 따로 로드하고 적용함. 이거 적용한 후엔 html 타입으로 가는 컨텐츠에 각 파일 별 만료 태그, css sprite, caching등이 자동 적용된다. 약간은 빨라지는듯.

3. 최근 댓글 보여주는 것도 잠시 생각하고 껐다. 이건 이글루스 블로그들을 따라 해본던데 좀 별로인듯.

4. 더불어 CC라이센스 플레이트에 붙어있는 아이콘 이미지 로딩이 느리길레 역시 제거함.

 

최종 결과:

이 결과 대략 800ms ~ 900ms 정도에 페이지 로딩이 되고, 최종 렌더링도 1.3초 수준에 해결.

 

  1. 사실 캡쳐한건 이 모듈 적용 후임 []

Blog 재설치

WordPress의 비쥬얼 에디터가 제대로 동작하지 않아서 WordPress 자체를 재 설치. 이 글은 비쥬얼 에디터에서 쓰고 있다.

MS Windows에서 글 쓰는 거라면 Windows Live Writer가 워낙 훌륭해서 되거나 말거나 크게 신경 안 썼는데, 요즘 Windows 부팅하는 시간이 너무 적어서 결국 불편함을 못 견디고 재설치했다.

설치는 다음과 같은 순서로 진행했다.

  1. 기존 디렉터리 백업 (blog 디렉터리를 백업 디렉터리로 변경)
  2. 새로 설치 (svn checkout 으로 통채로 blog 디렉터리에 가져다 설치)
  3. 기존 설정 파일 복사 (wp-config.php, wlwmanifest.xml, .htaccess)
  4. 기존 테마 파일 복사 (wp-content/theme 디렉터리를 백업에서 blog로 복사)
  5. 기존 플러그인 복사 (wp-content/plugins 디렉터리를 백업에서 blog로 복사)
  6. 기존 이미지 파일 복사 (wp-content/uploads 디렉터리를 백업에서 blog로 복사)

만에 하나 있을지 모를 문제 때문에 캐싱 플러그인 (wp-super-cache는 비활성화 했음)

 

혹시 깨진 링크, 깨진 이미지, 비정상 동작하는 부분이 발견되면 댓글로 알려주시면 감사하겠습니다(…).

 

 

JetPack: WordPress.com의 기능을 설치 형 블로그에서도

WordPress는 GPL v3 에 따라 배포되는 Free/Open Source SW다. 이걸 개발하고 있는 Automattic은 설치 형 블로그로 WordPress를 제공하고, 이와 별개로 WordPress.com 을 통해 무료 및 유료 서비스도 한다. 얘네 핵심 사업 모델이 이 WordPress.com 인데, 설치 형 WordPress에서도 이 사이트에서만 제공되는 기능 중 일부를 쓸 수 있다. 예를 들어 WordPress.com 의 통계 기능[1] 을 설치 형 블로그에서도 그냥 쓸 수 있게 해준다 – 다만 무료라도 WordPress.com 계정이 있긴 해야 함. 스팸 댓글 혹은 트랙백을 막는 Akismet 의 서비스도 일정 규모 이하의 사이트에서는 공짜다. 더불어, wp.me 로 짧은 URL을 만들어주는 기능도 제공한다.

최근에 WordPress.com 에서만 제공되던 기능들 중 일부가 JetPack이란 이름의 플러그 인[2] 으로 새로이 제공되는 걸로 바뀌었다. 몇 가지는 기존에 서로 다른 플러그 인으로 존재하거나, WP.com 밖에서도 쓸 수 있게 해주던 것이고, 몇 가지는 내가 생각하기에는 구현 방식의 한계로 다른 프로그램 없이는 잘 안될 거 같은 기능이다. 예를 들어[3] 서버에 LaTeX이 있어야 적당히 돌 거 같은 \LaTeX 지원이라거나…

관리자 메뉴에서 실제 페이지는 이런 식이고, 통계나 공유 기능처럼 약간의 설정이 필요한 녀석들은 추가 메뉴가 들어있음.

jetpack-page

현재 지원되는 기능은 전부 무료고, “Coming soon…” 으로 표시된 자리가 있으니 앞으로 몇 가지 기능이 더 추가될 것으로 보인다. WordPress.com에서 현재 제공 중인 서비스 방식을 생각할 때, 추후에 추가되는 플러그 인, 혹은 JetPack 자체가 기간 당 사용료를 받는 모델로 전환될 가능성도 있는 것 같다. Akismet 처럼 소규모 사용자에겐 계속 무료일 수도 있고 말이다. 뭐 이건 어디까지나 내 추측; 이 기능들 중 상당 수는 WordPress 설치 자체에서 제공할 수 있는 기능도 아니고, 설치 형 사용자들도 원할만한 기능들이 꽤 많이 있으니, 앞으로 이것도 얘네 사업 모델의 일부가 될 것 같다. WordPress.com 을 몇 가지 이유로 안 쓰는 사람들도 꽤 있고, 그 중 일부는 그래도 WordPress.com의 일부 기능(통계, LaTeX, …)을 쓰고 싶어하니까 말이다.

그리고 이런 기능이 WordPress.com이 다른 WordPress hosting 서비스에 대한 edge가 될 듯…

  1. 흔히 볼 수 있는 페이지 별 방문 수, 일별 통계, 참조 페이지 목록, 검색어 등등 []
  2. Mozilla에서 제공하는 PlugIn SDK의 이름이랑 겹친다; 이미 Mozilla 소프트웨어 재단이랑 얘기가 되어서, 이름을 쓰는데 큰 문제(?)는 없다고 한다… []
  3. 원격 서버를 통해 가능은 하지만 []

rein’s world 2010 통계

2010녀 한 해는 블로깅이 좀 많이 소홀했다. (작년에 이어…)
올해에도 내가 만든 WordPress 연간 통계 플러그 인 우려먹기.

여하튼 그래도 정리하는 의미에서 통계 내기.

글은 총 79개 썼다. 전반적으로 글 수가 Orz

Annual Post Statistics

댓 글도 적었고(…),

Annual Comment Statistics

 

작년과 비교해도 전반적으로 좀 활동이 뜸했다.

Comparison

Comparison

 

글은 예전처럼(…) 프로그래밍과 잡담 위주. 올해는 GCC 새 릴리즈와 VisualStudio 2010에서 C++0x를 지원하기 시작해서 이쪽 포스팅을 좀 한 듯도..

Blog 이사 아닌 이사

도메인 주소 구입 + 블로그 디렉토리 이전으로 몇 가지 삽질을 했다. 아래는 이틀 간의 삽질 기록.

1. 2009년 12월 27일을 끝으로 만료된 rein.kr 도메인을 구입했다 – 물론 만료 후 한 달이 지나야 다른 사람이 등록할 수 있기에 어제 구입. 구매할 때 상당히 많은 개인정보를 요구하는건 유감이지만 — .kr 도메인이 아니고서야 한국 내에서 살 이유가 없으니 – 어쨌든 도메인 주소가 대폭 짧아졌다.

여기까지 해서 http://rein.upnl.org/wordpresshttps://rein.kr/wordpress/ 로 이전.

2. 도메인 주소가 짧아지고나니, wordpress 라는 블로그 디렉토리 이름이 묘하게 길어보이기 시작(…).

집에 돌아와서 mod_rewrite 를 열어 수정을 했다. 뭐가 문제였는지는 모르겠지만, top-level 주소는 제대로 redirection[1] 되던데, 나머지 주소들 – 그러니까 WordPress 에서 사용하는 archives/post-name tags/tagname 같은 대부분의 주소들 – 은 제대로 redirection 이 안되서 어젯밤은 GG 치고 자러 갔다.

3. 오전에 병원가려고 준비하다가 mod_rewrite 대신에 mod_alias 를 쓰면 되겠다 싶어서 간단히 proof-of-concpets 코드만 짜고 병원 행.

오후에 잠시 난 짬을 써서 주소를 옮겼다.

설정은 다음 코드를 이용.

<IfModule mod_alias.c>
Redirect 301 /wordpress /blog
</IfModule>

이걸로  https://rein.kr/wordpresshttps://rein.kr/blog 로 전환. 하지만 rein.upnl.org/blog 로 직접 접근해오는 경우는 웹 브라우져 주소창에는 여전히 이전 주소로 찍힌다.

4. 301 redirect 될 주소에 도메인 주소까지 명시적으로 줘봤다. 잘 된다!

이제 rein.upnl.org/wordpress 로 접속해와도 rein.kr/blog 로 간다

<IfModule mod_alias.c>
Redirect 301 /wordpress https://rein.kr/blog
</IfModule>

이제 블로그 내부 데이터에 박혀있는 – 그러니까 각 글들의 링크, 사진 주소 등등 – 데이터를 rein.kr 기반으로 옮기면 끝.

여기까지가 현재 상태.

남은 문제:

  • Google 검색 정보 옮기기: WebMaster 툴에서 내가 upnl.org 는 소유하고 있는게 아니라고 거부한다
  • upnl.org 를 내껄로 위장(?)하기?
  • 구글 커스텀 검색이 rein.upnl.org 기반 페이지로 가려고 시도함. 어디서 바꾸지?[2]

과연 언제다 해결?

2010-01-31 13:42 – 블로그 각 글에서 rein.upnl.org 사용되는 것 rein.kr 로 이동. 이제 메타데이터 테이블 고쳐야?

  1. HTTP 301 응답; permanently moved 이용 []
  2. 물론 저기로 가봐야 다시 돌아오게 아파치 설정을 고쳐서 별 문제는 안생김 []

Blog 도메인 이전 및 기타 등등

rein.upnl.org –> rein.kr 이전 + /wordpress/ –> /blog/ 이전이 진행 중.

일부 디렉토리가 접근이 안된다거나, 특정 그림/사진이 안보인다거나, 링크가 잠시(?) 접근이 안된다거나 할 수 있는 상황.

주말까지 간헐적으로 문제가(혹은 폭발적으로?) 생길 예정..

<IfModule mod_alias.c>
    Redirect 301 /wordpress /blog
</IfModule>

로 일단 수정. 과연 이걸로 끝?