페이지스피드는 12만개 이상의 웹사이트에서 사용하고 있는 오픈소스 아파치 모듈이다. 지난 11일 구글 페이지스피드 팀의 조슈아 마렌츠와 일야 그레고릭은 블로그를 통해 "웹 페이지 관련해서 속도 문제를 갖고 있는 개발자와 웹 마스터에게 있어 웹 페이지를 더 빠르게 만드는 것은 공통된 고민거리"라며 "이것이 지난 2010년 구글이 모드 페이지스피드 프로젝트를 발표한 이유"라고 말했다.
사이트의 속도를 높이는 기술은 페이지 로드 시간을 줄이고 웹 페이지 호출시간과 대역폭 사용을 효율화하는 방식으로 구현된다. 그 결과물인 페이지스피드는 아파치 HTTP 서버 모듈의 집합 형태인데 여기에는 현재 콘텐츠나 워크로드를 수정하지 않고도 페이지는 물론 CSS와 자바 스크립트, 이미지 등 관련 에셋의 웹 성능을 높일 수 있는 모범 사례(best practice)들이 포함돼 있다.
이들 모범 사례는 다시 캐시 최적화, 브라우저 렌더링, 모바일 최적화, RTT(round-trip time) 최소화, 오버헤드 요구, 페이로드(payload) 크기 등 여섯개의 카테고리로 구분된다.
마렌츠와 그레고릭은 "우리는 오픈소스 커뮤니티와 함께 모드 페이지스피드 개발을 진행해 왔다"며 "웹 페이지 최적화를 더 좋고 똑똑하게 구현하고 다양한 웹서버를 지원하는 것에 초점을 맞췄다"라고 말했다.
모드 페이지스피드의 핵심 필터에는 사이트 디자인과 작동방식에는 영향을 주지 않으면서 콘텐츠를 최적화하는 기능이 포함돼 있다. 또한 개발자와 웹 마스터가 웹 사이트 성능 개선을 위해 사용할 수 있는 고급 필터도 지원한다. 구글 측은 "페이지스피드는 개별 웹사이트에 맞춤 적용하는 것도 가능하다"라고 설명했다.
-------------------------
Google에서 제공하는 mod_pagespeed Apache 모듈은 Apache 웹 호스터가 서버 설치 위치에 드롭하면 그 즉시 페이지 표시 속도의 현저히 증가를 달성할 수 있는 "드롭 인" 모듈로 설계되었다. 웹 사이트 속도를 높이는 방법을 잘 모르거나 성능 향상을 위해 구성을 최적화하지 않은 경우에는 이 모듈이 찾고 있는 바로 그 솔루션이 될 수 있다. 예를 들어, 바로 사용 가능한 구성 및 설치를 사용하는 Wordpress 블로그 소유자에게는 이 모듈이 엄청난 차이를 만들어 낼 수 있다.
mod_pagespeed 모듈은 한 모듈에 페이지 로드 시간을 최적화하기 위한 우수 사례를 결합하여 필요한 모든 단계를 자동으로 수행하도록 한다.
인 터넷 연결 속도와는 상관없이, 항상 웹 페이지가 빠르게 로드되기를 바랄 것이다. 웹 페이지의 컨텐츠를 전송하는 웹 서버 역시 두 가지 이유로 더 빨리 로드하려고 한다. 그 이유란, 회사 입장에서는 서버 속도가 느리면 고객을 잃게 되고, 사용자를 위해 개별 페이지 로드 속도를 높이는 회사는 다른 사용자를 위해 더 많은 페이지를 서비스할 수 있는 서버 성능상의 여력을 더 누릴 수 있기 때문이다. 개인의 입장에서야 그 회사 웹 사이트의 해당 웹 페이지를 하루에 한 번 방문할지 몰라도, 회사 입장에서는 하루 100,000명의 고객에게 같은 웹 페이지를 제공해야 할 수도 있는 것이다. 따라서 그런 회사로서는 속도가 조금만 높아져도 그 효과는 막대한 것이다. .
본 기사의 목적상, 여기서는 "속도"를 사용자의 관점에서 페이지 로드 시간으로 정의한다. www.google.com과 같이 신속하게 로드되는 웹 페이지는 빠른 것으로 간주되며, 그 페이지 로드 시간은 매우 짧다. 반대로, 오래된 Pentium II 600MHz CPU로 작동되는 서버 한 대밖에 없고 40개의 큰 이미지 파일을 담고 있는 가상의 사이트가 있다고 했을 때, 이 사이트는 느린 것으로 간주되며, 그 페이지 로드 시간은 매우 길다. 그 밖에도, 하루에 몇 안 되는 사람만 방문할 때는 속도가 빠른 웹 페이지라도 10분의 시간 범위 내에 수천 명이 사이트를 방문할 때는 형편없이 속도가 느려질 수 있다. 따라서 "속도"는 A에서 B까지 도달하는 데 걸리는 시간으로 정의된다. 여기서 A는 주소 표시줄에 뭔가를 입력한 후 "Enter" 키를 누를 때이고, B는 브라우저에서 웹 페이지 로드가 완전히 완료되는 때이다.
웹 서버의 관점에서는 (하드웨어 변경 없이) 속도를 높이는 최선의 방법은 더 적은 양의 데이터를 더 빠르게 보내는 것이다. 좀 더 자세하게 설명하자면, 시스템의 대기 시간(응답 시간)을 줄이고 전송되는 데이터의 크기(전송되는 데이터의 실제 Kb)를 줄이는 것이다. 따라서 웹 사이트 "속도를 높이기" 위해서는 웹 서버의 관점과 사용자의 관점에서 모두 서버의 대기 시간을 줄이는 동시에 전송되는 데이터의 크기를 줄일 필요가 있다.
웹 사이트의 속도를 높이기 위해 가능한 모든 전술은 캐싱 극대화, 검색 최소화, 단위 요청 오버헤드 최소화, 데이터 크기 최소화 및 브라우저 렌더링 최적화라는 5가지 카테고리로 나뉜다. 각각의 카테고리가 "극대화" 또는 "최소화"와 같은 극한적 조치를 어떻게 설명하는지에 주목하자. 예를 들어, 어떤 기능이나 설정을 "On" 또는 "Off"하는 것과 같은 간단한 해결책은 없다. 각각의 카테고리를 분석하고 어떤 역할을 하는지 설명하겠다.
브 라우저는 파일을 로컬에서 캐시하는 기능이 있으므로, 각 페이지 로드에 대해 서버에서 이런 파일을 로드하는 대신 로컬 사본을 사용한다. 이것이 블로그 페이지와 같은 동적 웹 페이지 자체에는 그다지 타당하지 않지만, 모든 이미지, CSS 파일 및 JavaScript 파일도 해당 페이지와 함께 로드되는 경우는 어떨까? 이런 파일은 변경될 일이 없으며, 설령 있다 하더라도 매우 드물다. 따라서 같은 CSS 파일을 로드하기 위해 매번 서버로 돌아갈 필요가 없으며, 특히 전체 사이트에 대해 하나의 CSS 파일만 사용하는 경우에는 더욱 그러하다. 사용자가 로드하는 모든 페이지에서 같은 CSS 파일을 사용하므로, 서버의 사본 대신 로컬에서 캐시된 사본을 사용할 수도 있다. 두 파일은 동일한 것이기 때문이다.
브라우저는 실제로는 서버로부터 캐시 명령을 받는다. 서버는 브라우저에게 해당 항목이 유효한지 여부와 그 유효 기간을 알려줄 수 있다. 서버는 이런 명령을 각각의 파일에 연 결할 수 있다. 따라서 서버 호출을 통해 브라우저에게 JS 파일, CSS 파일, JPG 파일은 캐시하고 HTML 파일이나 TXT 파일은 캐시하지 않도록 지시할 수 있다. 더 나아가, 브라우저에게 "CSS 및 JPG 파일이 1년 동안 만료되지 않는다"는 사실을 알려줄 수 있다. 브라우저는 이런 명령을 서버가 "여기 JPG 파일이 있는데, 이 파일은 1년간 바뀌지 않을 거야. 그리고 때때로 서버 상의 어떤 페이지에서든 이 파일을 참조할 때마다 로컬 사본을 사용하면 돼."라고 알려주는 것으로 해석한다.
어 떤 유형의 파일이 서버에서 브라우저로 전송되면 각 파일에 HTTP 연결을 설정하는 것과 연관된 오버헤드가 있다. 다시 말해, 각각의 파일에 대해 서버와 브라우저 사이에 통신 채널을 설정할 필요가 있다. 대부분의 일반적인 웹 사이트에서는 수십 개의 파일을 전송해야 하고, 이 오버헤드가 요구될 때마다 서버는 이를 작성하는 데 일정한 시간이 걸린다. 따라서 검색 횟수를 줄이면 서버가 검색 작성에 소요하는 시간이 단축된다.
이 목표를 달성하는 기본적인 방법은 분명하다. 즉, 웹 페이지에서 전송해야 할 파일의 수를 줄이는 것이다. 예를 들어, 한 페이지에 10개의 이미지가 있는 경우 10개의 HTTP 연결을 작성해야 할지 모른다. 그러나 모든 jQuery 플러그인을 한 파일 안에 넣거나 한 페이지에 있는 작은 이미지를 전부 하나의 큰 이미지 파일로 결합한 다음 CSS를 사용하여 표시해야 할 큰 이미지의 일부만 표시하는 것처럼, 자원을 최소 개수의 파일로 결합하면 필요한 연결 수를 줄일 수 있다.
각 웹 페이지가 로드될 때, 브라우저는 쿠키와 POST 및 GET가 호출되는 시점과 같은 정보를 포함한 특정 정보를 서버로 릴레이한다. 물론, 각 페이지 로드마다 클라이언트에서 쿠키 정보를 서버로 업로드해야 하기 때문에 시간이 걸린다. 어떤 웹 사이트는 쿠키에 어마어마한 정보를 저장하고 있고, 업로드해야 할 정보가 많을수록 시간이 더 오래 걸린다.
그 대신, 좀 더 바람직한 설계는 예컨대 사용자 ID만 저장하는 것처럼 쿠키에 가능한 한 적은 정보를 저장하고, 그 정보를 키로 사용하여 데이터베이스에 저장할 수 있었던 필수 정보를 전부 찾도록 하는 것이다. 이렇게 하면 이 정보에 대한 업로드 시간을 대폭 줄일 수 있다.
크 기가 20Kb인 이미지 파일은 200Kb인 이미지 파일보다 빠르게 전송할 수 있다. 이 카테고리에는 관련된 모든 방법이 포함된다. 예컨대, 가능하면 JPG보다는 GIF를 사용하고, JavaScript 파일을 최소화하고, 전체 이미지 대신 미리 보기 이미지를 전송하는 등의 방법이다.
이 카테고리는 쉽지 않은 방법이다. 여기에는 최적화된 CSS 선택기를 사용하는 것과 같은 방법이 포함되지만, 사이트가 이미 디자인된 상태이고 CSS 파일을 다루는 사람이 서버 성능 최적화를 담당한 사람이 아닌 경우가 종종 있다. 또한, 이 카테고리의 여러 요인은 들인 노력에 비해 그 효과가 미미한 경향이 있다.
이 론적인 설명은 이것으로 충분하므로, 이 제품을 다운로드하여 실제로 실행해보자! 결국, 이 플러그인이 약속하는 바는 사용자가 설치한 Apache에 드롭 인하는 방식으로 서비스를 제공하는 것이므로, 속도를 높이기 위한 모든 세부적인 사항에 대해 걱정할 필요가 없다.
패키지를 다운로드하고(링크는 아래의 Resources 참조), 적절한 Linux 명령을 실행하여 시스템에 설치한다.
mod_pagespeed가 Linux 시스템에 설치되더라도 아직 시스템에 설치된 Apache에 연계된 것은 아니므로, 그 작업을 해주자. 설치가 완료된 후 일을 쉽게 풀어나가려면, mod_pagespeed를 설치한 곳에서 "pagespeed.conf" 파일을 복사하여 Apache의 "conf" 디렉토리에 붙여 넣는 것이 좋다. 또한, "mod_pagespeed.so" 파일을 Apache의 "modules" 디렉토리로 복사한다. 마지막으로, 모듈에서 생성하게 될 캐시와 파일을 저장할 디렉토리를 작성한다. 이런 디렉토리를 각각 "cache"와 "files"라고 부르겠다.
그 다음, Apache에 mod_pagespeed 모듈을 사용하고 http.conf 파일을 편집하기 위해 필요한 작업을 수행하라고 지시해야 한다. 파일 맨 아래에 다음 행을 추가한다.
목록 1. Apache의 http.conf 파일 수정
Include "{your-path-to-this-file}/pagespeed.conf" |
다음으로, pagespeed.conf를 약간 수정하여 파일과 디렉토리에 대해 올바른 경로를 가리키도록 해야 한다.
목록 2. pagespeed.conf 파일 수정
# at line 1 of the fileLoadModule pagespeed_module {your-path-to-this-file}/mod_pagespeed.so# down at line 25-26 in the fileModPagespeedFileCachePath "{your-'cache'-file-path-here}"ModPagespeedGeneratedFilePrefix "{your-'files'-file-path-here}" |
마지막으로, Apache 서버를 시작한다.
몇 가지 사항을 검사하여 mod_pagespeed가 올바로 설치되었는지 확인한다. Apache가 올바로 시작되었는지 분명히 확인하고, 그렇지 않았다면 mod_pagespeed를 올바르게 설치 또는 구성하지 않았다는 뜻이다. 그 다음, mod_pagespeed가 "cache" 폴더에 올바르게 데이터를 쓰고 있는지 확인한다.
이 제 작업 중인 사이트의 웹 페이지를 방문해 본다(페이지에는 JS 및 CSS 파일과 같은 것이 포함되어 있어야 함). 페이지를 방문한 후, "cache" 폴더를 검사한다. 그곳의 파일이 축소할 수 있는 GZipped/Compressed 버전의 파일(JS 및 CSS 파일)인지 확인해야 한다. 그것이 바로 mod_pagespeed를 올바로 설치하고 구성했다는 첫 번째 지표이다.
최 종 검사는 서버에서 돌아오는 응답 헤더이다. Firebug나 Google 자체의 Page Speed와 같은 도구를 사용하여 이를 검사할 수 있으며, 응답 헤더를 찾기 위한 PHP 코드를 작성하여 검사하는 방법도 있다. Google의 도구가 응답에 태그를 지정하므로, 응답 헤더를 검사할 때는 "Modpagespeed"에 대한 참조를 찾아야 한다.
드디어 "cache" 폴더 검사에 성공했다. 응답 헤더를 통해 mod_pagespeed를 올바르게 설치하고 구성했다는 사실도 확인했다.
mod_pagespeed를 이리저리 테스트한 후 커미트하려는 경우, 위 단계에 따라 활성화할 준비가 될 때까지 pagespeed.conf 파일에서 모듈을 끌 수 있다. (Apache의 http.conf 파일에서 구성 설정을 실행 취소할 필요는 없다.) 단순히 pagespeed.conf 파일 자체에서 mod_pagespeed를 켜고 끌 수 있다. 10행에서 ModPagespeed on 매개변수를 찾아보면 된다. 이 변경 사항을 적용하려면 Apache를 바운스하거나 다시 시작해야 한다.
대부분의 웹 마스터들은 속도와 페이지 로드 시간의 중요성을 잘 알고 있지만, 이와 관련된 통계 데이터와 최대 로드 시간을 철저히 모니터링하는 Linux 전문가는 소수에 불과하다.. 대부분의 웹 마스터에게는 mod_pagespeed와 같은 간단한 도구가 제격이다. 설치하기도 쉽고 거의 아무런 구성도 필요하지 않은 반면, 사용자를 위한 페이지 로드 시간은 대폭 단축시켜 주기 때문이다.
출처 : http://www.ibm.com/developerworks/kr/library/l-apache-pagespeed/
-----------------------
1. 설치
1-1. 설치 환경.
* Linux RHEL5 64bit (glibc, gcc등의 버젼이슈가 잇음.)
* 기본적으로 Httpd-2.2 버젼 이상에서 동작한다.
- Server version: Apache/2.2.17 (Unix)
* 준비 : mod-pagespeed-beta_current_i386.rpm
(http://code.google.com/intl/ko/speed/page-speed/download.html 에서 download 가능)
1-2. 설치
* Apache 설치 configure
- ./configure --prefix=/usr/local/apache --enable-deflate=shared --enable-rewrite=shared --enable-expires=shared --enable-headers=shared --enable-so --with-mpm=prefork;make;make install
* mod_pagespeed 설치
- cd /usr/local
- mkdir mod_pagespeed
- cd mod_pagespeed
- wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-beta_current_i386.rpm
- rpm2cpio mod-pagespeed-beta_current_i386.rpm | cpio -idmv
- cp /usr/local/mod_pagespeed/usr/lib/httpd/modules/mod_pagespeed.so /usr/local/apache/modules/
- cp /usr/local/mod_pagespeed/etc/httpd/conf.d/pagespeed.conf /usr/local/apache/conf/
- chmod 755 /usr/local/apache/modules/mod_pagespeed.so
- mkdir /usr/local/apache/mod_pagespeed/cache
- mkdir /usr/local/apache/mod_pagespeed/files
1-3. apache httpd.conf 설정
* apache httpd.conf 설정
- mod_headers.so 모듈을 load 해주고 (LoadModule headers_module modules/mod_headers.so)
- pagespeed.conf 를 Include 시킨다. (Include conf/pagespeed.conf)
* pagespeed.conf 설정
(테스트버젼 - 현재 apache 정상동작 및 일부 테스트까지만 진행한 관계로 사용중인 conf만 첨부합니다.)
- pagespeed.conf
| LoadModule pagespeed_module modules/mod_pagespeed.so <IfModule !mod_deflate.c> LoadModule deflate_module modules/mod_deflate.so </IfModule> <IfModule pagespeed_module> # Turn on mod_pagespeed. To completely disable mod_pagespeed, you # can set this to "off". ModPagespeed on # Direct Apache to send all HTML output to the mod_pagespeed # output handler. AddOutputFilterByType MOD_PAGESPEED_OUTPUT_FILTER text/html text/css text/plane application/javascript SetOutputFilter MOD_PAGESPEED_OUTPUT_FILTER # ModPagespeedUrlPrefix is deprecated. mod_pagespeed still depends # on its being set, but does not use its value. This directive # will be removed in a future release. ModPagespeedUrlPrefix "http://www.babo.net" # The ModPagespeedFileCachePath and # ModPagespeedGeneratedFilePrefix directories must exist and be # writable by the apache user (as specified by the User # directive). ModPagespeedFileCachePath "/usr/local/apache/mod_pagespeed/cache/" ModPagespeedGeneratedFilePrefix "/usr/local/apache/mod_pagespeed/files/" # Override the mod_pagespeed 'rewrite level'. The default level # "CoreFilters" uses a set of rewrite filters that are generally # safe for most web pages. Most sites should not need to change # this value and can instead fine-tune the configuration using the # ModPagespeedDisableFilters and ModPagespeedEnableFilters # directives, below. Valid values for ModPagespeedRewriteLevel are # PassThrough and CoreFilters. # # ModPagespeedRewriteLevel CoreFilters # Explicitly disables specific filters. This is useful in # conjuction with ModPagespeedRewriteLevel. For instance, if one # of the filters in the CoreFilters needs to be disabled for a # site, that filter can be added to # ModPagespeedDisableFilters. This directive contains a # comma-separated list of filter names, and can be repeated. # # ModPagespeedDisableFilters rewrite_javascript # Explicitly enables specific filters. This is useful in # conjuction with ModPagespeedRewriteLevel. For instance, filters # not included in the CoreFilters may be enabled using this # directive. This directive contains a comma-separated list of # filter names, and can be repeated. # ModPagespeedEnableFilters collapse_whitespace,elide_attributes,extend_cache,combine_css,combine_heads,move_css_to_head,inline_css,inline_javascript,remove_comments,rewrite_css,rewrite_images,rewrite_javascript # ModPagespeedDomain # authorizes rewriting of JS, CSS, and Image files found in this # domain. By default only resources with the same origin as the # HTML file are rewritten. For example: # ModPagespeedDomain http://www.babo.net # # This will allow resources found on http://cdn.myhost.com to be # rewritten in addition to those in the same domain as the HTML. # # Wildcards (* and ?) are allowed in the domain specification. Be # careful when using them as if you rewrite domains that do not # send you traffic, then the site receiving the traffic will not # know how to serve the rewritten content. # When Apache is set up as a browser proxy, mod_pagespeed can record # web-sites as they are requested, so that an image of the web is built # up in the directory of a users choosing. # SLURP_DIR_COMMAND # SLURP_READ_ONLY_COMMAND # Enables server-side instrumentation and statistics. If this rewriter is # enabled, then each rewritten HTML page will have instrumentation javacript # added that sends latency beacons to /mod_pagespeed_beacon. These # statistics can be accessed at /mod_pagespeed_statistics. You must also # enable the mod_pagespeed_statistics and mod_pagespeed_beacon handlers # below. # ModPagespeedEnableFilters add_instrumentation # This handles the client-side instrumentation callbacks which are injected # by the add_instrumentation filter. # You can use a different location by adding the ModPagespeedBeaconUrl # directive; see the documentation on add_instrumentation. # # <Location /mod_pagespeed_beacon> # SetHandler mod_pagespeed_beacon # </Location> # This page lets you view statistics about the mod_pagespeed module. <Location /mod_pagespeed_statistics> Order allow,deny # You may insert other "Allow from" lines to add hosts you want to # allow to look at generated statistics. Another possibility is # to comment out the "Order" and "Allow" options from the config # file, to allow any client that can reach your server to examine # statistics. This might be appropriate in an experimental setup or # if the Apache server is protected by a reverse proxy that will # filter URLs in some fashion. Allow from 127.0.0.1 SetHandler mod_pagespeed_statistics </Location> </IfModule> <Directory /usr/local/apache/htdocs> <IfModule headers_module> # To enable to show that mod_pagespeed to rewrites web pages, we must # turn off Etags for HTML files and eliminate caching altogether. # mod_pagespeed should rewrite HTML files each time they are served. # The first time mod_pagespeed sees an HTML file, it may not optimize # it fully. It will optimize better after the second view. Caching # defeats this behavior. <FilesMatch "\.(html|htm)$"> Header unset Etag Header set Cache-control "max-age=0, no-cache, no-store" </FilesMatch> # Images, styles, and javascript are all cache-extended for # a year by rewriting URLs to include a content hash. mod_pagespeed # can only do this if the resources are cacheable in the first place. # The origin caching policy, set here to 10 minutes, dictates how # frequently mod_pagespeed must re-read the content files and recompute # the content-hash. As long as the content doesn't actually change, # the content-hash will remain the same, and the resources stored # in browser caches will stay relevant. <FilesMatch "\.(jpg|jpeg|gif|png|js|css|php)$"> Header unset Etag Header set Cache-control "public, max-age=300000000" </FilesMatch> </IfModule> </Directory> |
2. 결론
현재 css, js 등의 최적화부분까지 진행하였으며, 추가적으로 테스트하여 서비스에 적용 해 볼만한 부분이 있는지 확인할 예정입니다.
3. 참고자료
http://code.google.com/intl/ko/speed/page-speed/docs/using_mod.html
출처 :: http://blog.daum.net/cacarot00/4
apache가 worker 모드인지 prefork 모드로 동작하는지 확인
