오늘은 최근에 진행한 HAPPIST.COM의 속도 개선에 대해 이야기 해보겟습니다.
워드프레스로 이전 후 메인 테마로 newspaper를 이용해왔는데 생각보다 만족스럽지 목한 속도에 고민이 많았습니다.

HAPPIST.COM을 webpagetest.org에서 테스트해버년 전체 loading속도 및 TTFB 속도에서 상당히 느린 속도가 측정되고 했었습니다.

요 며칠사이에 newspaper 테마의 속도 최적화에 대해 이런 저런 노력을 기울였고 그 성과가 있어서 이를 공유하고자 합니다.

1. 그간 간략한 History

처음 newspapr 7을 설치하고 속도 측정을 Tools.pingdom.com에서 진행했었습니다. 당시에는 webpagetest라는 곳을 몰랐고 TTFB 개념도 없었습니다.

webpagetest에서 본격적으로 측정한 자료들을 찾아보니 2017년 1월 자료들이 있네요. 확인해보면 전체 Loading Time 4~5초, TTFB는 1초이상이 나왔습니다.

▽ 웹페이지테스트(webpagetest.org)에서 2017년 1월 11일 측정 결과,
Time To First Byte Speed가 1초이상으로 측정되어 F를 받고 있다.

이 상황을 타개하기 위해서 지금까지 아무리 서버 성능 옵션을 최적화해도(서버 자체를 바로 바로 바꿀 수는 없어서 있는 서버의 세팅값을 조정해 최적화하고자 하였습니다.) 뚜렸한 속도 증가가 없었습니다.

한 때는 현재 사용중인 vuktr.com의 서버속도가 느린 것 아니냐는 의심을 품고서 막대한 손해이지만(시간 및 금전적으로) Linode로 옮겨서 테스트도 했습니다. 옮겨서 한달이상 적용해 보았습니다만 별 차이는 없었습니다.

가상서버호스팅(VPS) Vultr Tokyo vs Linode Tokyo datacenter2 비교에서 Linode와 Vultr를 비교해 놓았습니다. 여기에서 결론은 큰 차이가 없다는 것이었습니다. 수치상으로 큰 차이는 없거나 그래도 따진다면 Linode가 조금 낫다는 것이었죠.

2. 어떻게 개선할 것인가? 목표 설정

빛과 같은 속도로 반응했으면 얼마나 좋을까요?

무한정 빠르게 할 수 있으면 좋겠지만 현재 저의 실력과 상황을 고려해 아래와 같은 목표를 설정했습니다.

첫째, 전체 Loading Speed는 2초대에 뜰 수 있도록 한다.
둘째, TTFB는 0.4초대로 낮춘다.

이 정도의 속도라면 네이버와 비교해서 TTFB가 0.5초정도 높고 전체 loading 속도도 0.5초정도 뒤지는 수준으로 과히 나쁘지 않은 소준으로 보았습니다.

위와 같은 목표로 HAPPIST.COM의 속도를 개선하기 하기 위해서 서버단의 작업과 워드프레스 테마단의 작업이 이루어졌습니다.

3. 서버 세팅, mod_PageSpeed 세팅 정교화

서버 세팅은 구글에서 제공하는 mod_PageSpeed 세팅을 정교하게 하는데 주력했습니다. mod_PageSpeed가 생각보다 많은 옵션을 제공해주고 있으므로 이런 믾은 옵션들을 제대로 살릴 수 있다면 Cache 플러그 인 등 다른 프로그램을 사용하지 않아도 그 이상 속도가 날 것으로 보았습니다. 실제로 그렇게 추천하는 사람들도 있습니다만.

우선 mod_PageSpeed를 최신 버젼으로 업데이트를 했습니다.

[워드프레스 속도 개선] Nginx에 페이지스피드(mod_PageSpeed)설치 방법 두번째에서 mod_PageSpeed 설치하는 방법을 설명해 놓았습니다.

그리고 인터넷 검색을 토대로 mod_PageSpeed 세팅값을 아래와 같이정리, 적용했습니다.
적용 후 속도에 대해서는 나름 나쁘지 않다고 생각합니다.

   # enable pagespeed module on this server block
    pagespeed on;              

    # let's speed up PageSpeed by storing it in the super duper fast memcached
    pagespeed MemcachedThreads 1;
    pagespeed MemcachedServers "localhost:11211";

    # This setting should be enabled when using HTTPS
    # Take care when using HTTP > HTTPS redirection to avoid loops
    pagespeed MapOriginDomain http://happist.com https://happist.com;


    # show half the users an optimized site, half the regular site
    pagespeed RunExperiment on;
    pagespeed AnalyticsID UA-64766674-1;
    pagespeed ExperimentVariable 1;
    pagespeed ExperimentSpec "id=1;percent=50;level=CoreFilters;enabled=collapse_whitespace,remove_comments;";
    pagespeed ExperimentSpec "id=2;percent=50";

    pagespeed EnableFilters extend_cache;
    pagespeed JpegRecompressionQuality 70;

    # Filter settings
    pagespeed RewriteLevel CoreFilters;
    pagespeed EnableFilters collapse_whitespace,remove_comments;

    pagespeed EnableFilters prioritize_critical_css;
    pagespeed EnableFilters combine_css,combine_javascript;
    pagespeed EnableFilters collapse_whitespace;
    pagespeed EnableFilters insert_dns_prefetch;
    pagespeed EnableFilters collapse_whitespace,remove_comments;
    pagespeed EnableFilters make_google_analytics_async,make_show_ads_async;
    pagespeed EnableFilters rewrite_css,rewrite_javascript;  # enable CSS, Javascript optimization
    pagespeed EnableFilters convert_png_to_jpeg;
    pagespeed EnableFilters convert_jpeg_to_webp, convert_to_webp_lossless, convert_to_webp_animated, recompress_webp.,convert_jpeg_to_webp;
    pagespeed EnableFilters sprite_images;
    pagespeed EnableFilters rewrite_images;  # enable image optimization
    pagespeed EnableFilters resize_mobile_images;
    pagespeed EnableFilters lazyload_images;
    pagespeed EnableFilters inline_javascript;
    pagespeed EnableFilters defer_javascript;

    # needs to exist and be writable by nginx  755로 되어 있음 
    # cache 비우는 방법 Flushing PageSpeed Sever-ide Cache
    # rm -rf /var/ngx_pagespeed_cache/* or touch /var/ngx_pagespeed_cache/cache.flush
    # ngxrestart
    pagespeed FileCachePath /var/ngx_pagespeed_cache;

    pagespeed FileCacheSizeKb            1024000000;  # cache를 적용 후 다 차면 비운다
    pagespeed FileCacheInodeLimit        50000000;
    pagespeed CssFlattenMaxBytes 5120;
    pagespeed LRUCacheKbPerProcess     8192;
    pagespeed LRUCacheByteLimit        16384;


    # onfiguring SSL Certificates
    pagespeed SslCertDirectory directory;
    pagespeed SslCertFile file;

    pagespeed RewriteLevel CoreFilters;

    pagespeed FetchWithGzip on;
    # enable gzip compression
    gzip on;
    gzip_min_length  1000;
    gzip_buffers     4 4k;
    gzip_types       text/html application/x-javascript text/css application/javascript text/javascript text/plain application/json application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf application/xml font/eot font/opentype font/otf image/svg+xml image/vnd.microsoft.icon;
    # Disable for IE < 6 because there are some known problems
    gzip_disable "MSIE [1-6].(?!.*SV1)";
    gzip_static on;
    gzip_comp_level 2;
    gzip_http_version 1.0;
    gzip_proxied any;

4. newspaper 테마 최적화

한때 newspaper 7 or newspaper 8 테마는 속도상으로 문제가 있다는 생각을 했습니다. 아무리 속도 개선 작업을 해도 전혀 진척이 없었죠.
그래서 다른 테마로의 변경도 많이 검토했었습니다만 무료이면서도 당야한 기능을 갖는 테마를 찾기는 쉽지는 않았습니다.

그러다가 최적화를 위해서는 일반적으로 알려진(일반적이라는 의미는 그만큼 효과가 있는 것이라는 이야기도 됩니다) 점검 요인들을 하나씩 짚어 보았습니다.

• 불필요한 플러그인이 있는지?
• 사이드바가 꼭 필요한 것인지? 사이드바 적용도 속도에 영향을 미칩니다.
• Header 부분을 가볍게 하자, 이는 메튜님이 Head를 간단하게 해야한다는 댓글에서 힌트를 얻었습니다.
• 불필요하게 데이타베이스를 불러오는 요인들이 있는지? 다른 이야기로 Database quary를 최소화하라는 이야기
• Infinite scrolling 미적용 또는 최소 적용

4.1. 플러그인 최적화

예전부터 워드프레스가 무겁다는 지적에 플러그인 사용을 최대한 자제해 왔습니다.
그 결과 실제 사용 플러그인은 8개 정도였는데요. 이번 최적화 작업을 하면서 이 플러그인조차 최소화하였습니다.

• BJ Lazy Load는 서버단에서 적용한 mod-_PageSpeed의 Image Lazy load 기능 및 defer_javascript 기능으로 커버 가능하다고 보아 비적용했습니다.

• Facebook Instant Articles & Google AMP Pages by PageFrog는 AMP 플러그인이 이미 적용되어 있으므로 더 편리하게 작업하는 추가 기능의 필요성은 상대적으로 적다고 판단하여 비적용했습니다.

• MailChimp for WordPress는 메일링에 대해서 다시 고민하기 위해서 우선 비적용하기로 했습니다.

• tagDiv Social Counter도 보기에는 좋지만 효율성을 극대화하기 위해 끄기로 했습니다.

그러다보니 최종적으로 4개의 플러그인만 적용하게 되네요.

▽ Newspaper 8에 적용중인 플러그인 리스트

4.2. 사이드바의 필요성

사이드바는 사이트를 안정감 있게 만들어 주고 동일한 화면안에 더 많은 정보를 제공할 수 있으므로 선호되는 화면 구성입니다.

그렇지만 이 2단구성 3단 구성이 많지는 않지만 속도에 영향을 미친다고 합니다.
그리고 1단 구성이 집중도 등등에서 더 효율적이라는 이야기도 많아서 1단으로 가기로 했습니다.

물론 많은 정보의 전달이 필요한 곳에서는 2단 구성을 유지하고 했습니다. 예를 들어 카테고리, 서치 결과 등등에서는 2단을 유지한 것이죠.

4.3. Header를 가볍게 하자.

메투님이 head를 가볍게 해애한다고 조언을 주셔서 어떻게 head를 가볍게 할것이냐를 고민했는데 요즘 많은 테마에서 유행처럼 적용하고 있는 메가 메뉴가 문제가 있다는 생각이 들었습니다.

메가 메뉴란 메뉴에 마우스를 올리면 메뉴 아래 최신 포스팅 내용이 이미지로 보여주는 것인데요. 메뉴마다 어떤 최신 포스팅이 있는지 바로 알 수 있어서 좋기는 합니다. 그리고 디자인적으로 보기 좋고 세련되어 보이는 효과가 있습니다.

문제는 이게 속도를 많이 저하시킨다는 판단입니다.
세번째 항목의 quary를 최소화하는 항목에서도 설명하겠지만 이 메가 메뉴는 첫화면을 띄우면서 그 관련 이미지도 동시에 loading시키므로 속도를 저하시키고 많은 이미지를 불러와 트래픽을 증가시킵니다.

Newspaper에서 메가메뉴 비적용으로도 많은 효과가 있다.
아래는 메가 메뉴 적용 예,
Newspaper제작사 사이트에서 캡춰 함

4.4. 불필요한 Quary를 최소화하자.

아래는 newspaper를 webpaespeed.org에서 테스트해본 것인데요. adsense 등을 적용하지않는 상태에서 83개의 request를 하고 있습니다.
여기에 adsense를 적용하고 몇가지 기능을 넣으면 120~130개의 quary를 던지게 되는 것이죠.

여기에는 이미지만 65개 정도를 불러오고 있습니다. 너무 과하다는 생각이 들어서 이미지를 최소한만 불러올 수 있도록 메뉴를 최소화했습니다.

Newspaper의 contents별 반응 시간 waterfall 그래프,
이미지만 65개가까이 loading 시킨다.

첫째, 메뉴를 최소화하고,
둘째, 무엇보다 앞에서 설명한 메가메뉴를 비적용하고,
셋째, 사이드 메뉴를 포기하고 1단 적용했습니다.

이렇게하니 이미지 loading이 13개 정도로 줄였습니다.

Newspaper 8 최적화 후Newspaper의 contents별 반응 시간 waterfall 그래프,
이미지는 13개만 loading 시킨다.

5. 결과

이러한 최적화 결과 아래의 성적을 거두었습니다. 항상 이정도 속도를 보여줄지는 모르겠습니다. 측정시간이 상대적으로 유리한 시간이었으니 평소에는 이보다도 조근 더 늦을 것 같습니다.

전체 Loading Speed는 2.7초,
TTFB는 0.4초 달성

역시 디자인을 이쁜게 한다는 것은 거의 대부분의 경우 속도등등을 희생해야 한다는 결론이네요. 메가 메뉴가 대표적인 사항인듯하고 full display도 용량이 커지기 때문에 속도 저하에 영향을 줄 것 같긴 합니다만 우선은 적용해 보았습니다.

완전히 만족스럽지는 않지만 우선 여기까지 온것으로도 감사하게 생각하며 추후 더 지식이 쌓으면 더 빠른 속도라는 새로운 도전을 해 보려고 합니다.