YSlow는 Yahoo! 내부 개발 도구로 사용되어 오던 Firebug의 확장 플러그인으로, 런던에서 열렸던 @midia 2007 Conference의 “High Performance Web Sites”라는 주제의 강연에서 그 존재가 처음 알려졌었는데, 드디어 일반에게 공개되었다.

웹 페이지 최적화 등급은 모두 13가지의 웹 페이지 최적화 규칙을 기반으로 매겨지는데, 이 규칙들은 일반 웹 애플리케이션의 최적화를 위한 알짜배기 정보로도 참고될 수 있다.

YSlow를 설치하면 크게 네 가지의 View를 제공하는데, 아래는 이곳의 최적화 등급을 나타낸 Performance View 모습이다.

그림에는 각 최적화 규칙에 대한 현재 웹 페이지의 평가 등급을 한눈에 알 수 있게 보여준다.
여기서 주의할 것은, 2번 규칙인 Use a CDN(Content Delivery Network)에 관해서 제대로 된 등급을 매기려면, CDN으로 등록되어 있는 hostname을 자신이 사용하는 것으로 바꾸어 주어야 하는데 방법은 YSlow FAQ에 설명되어 있다.
등급 결과를 보면 B라는 흐뭇한(?) 점수를 받았지만, 두 군데에서 낙제점을 받았는데 Configure ETags 항목에서 낙제점이 찍힌 것은 이곳이 단일 서버에서 돌아가는 곳으로 cluster servers와는 상관이 없다는 것을 생각해 보면 무시해도 될 듯하다. 결국 비교적 많은 HTTP 요청 횟수가 문제지만 이것도 두 번째 방문부터 차기 cache로 흡수될 것을 생각하면 당장의 불안 요인은 아닌 듯. 이것은 “Stats” View에서도 확인할 수가 있는데, Full Cache일 때는 서버로 단 두 개의 HTTP 요청만 소모된다.

덤으로, Tools 항목에는 JavaScript 코드의 오류 방지를 위한 정리 도구인 JSLint가 내장되어 있고, 웹 페이지에 포함된 모든 js, css 파일을 뽑아서 보여주는 도구 그리고 마지막으로 Performance View의 결과 내용을 나중 검토를 위해 종이로 인쇄할 수 있는 형식으로 정리해서 보여주는 “Printable View” 도구가 자리 잡고 있다.

참고로 아래는 웹 페이지 최적화와 관련해서 이곳에서 사용하는 Gzip 압축과 Expires HTTP headers 부분의 Apache 환경 설정 사항이다.

# 
# Compress some document types using mod_deflate module 
# 
<Location />
  AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xhtml+xml
  AddOutputFilterByType DEFLATE text/css application/javascript text/javascript
  AddOutputFilterByType DEFLATE application/x-httpd-php application/x-httpd-fastphp application/x-httpd-eruby
  AddOutputFilterByType DEFLATE application/xml application/rss+xml application/atom+xml image/svg+xml
 
  # Netscape 4.x has some problems... 
  BrowserMatch ^Mozilla/4 gzip-only-text/html
 
  # Netscape 4.06-4.08 have some more problems 
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
 
  # MSIE masquerades as Netscape, but it is fine 
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
 
  # NOTE: Due to a bug in mod_setenvif up to Apache 2.0.48 
  # the above regex won't work. You can use the following 
  # workaround to get the desired effect: 
  #BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html 
 
  # Don't compress images, compressed files, movies, audio files 
  SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.(?:exe|t?gz|zip|bz2|sit|rar)$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.pdf$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.avi$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.mov$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.mp3$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.mp4$ no-gzip dont-vary
  SetEnvIfNoCase Request_URI \.rm$ no-gzip dont-vary
 
  # Make sure proxies don't deliver the wrong content 
  Header append Vary User-Agent env=!dont-vary
 
  # n = 1..9 with 9 being the highest compression level. Standard is 6. 
  # DeflateCompressionLevel n 
</Location>
 
# 
# Expires HTTP headers 
# 
<IfModule expires_module>
  ExpiresActive on
  ExpiresDefault "access plus 2 weeks"
  ExpiresByType image/gif "access plus 1 month"
  ExpiresByType image/jpeg "access plus 1 month"
  ExpiresByType image/png "access plus 1 month"
  ExpiresByType image/x-icon "access plus 1 month"
  <FilesMatch "\.(php|php4)$">
      ExpiresByType text/html "now"
  </FilesMatch>
</IfModule>

당분간 등급 놀이에 빠져있겠군. 😉

Safari 3에 포함되어 있는 Web Inspector가 새로운 모습으로 또 한 번 탈바꿈 하였다.

바뀐 내용을 보면,

• 완전히 새로 디자인한 인터페이스, 더는 투명한 패널이 아님.
• Safari 뿐만이 아니고, WebView를 사용하는 제 3의 어플리케이션들에서도 사용 가능.
• 탐색 페이지 별 도킹(docking) 지원.
• 페이지에 포함된 모든 리소스들을 종류별로 분류해서 보여줌.
• 글자 기반의 모든 리소스들을 검색할 수 있는 통합 검색.
• 실시간 JavaScript 실행으로 나타나는 오류 및 경고를 보여주는 콘솔 창.
• HTTP 요청과 응답 headers를 포함해서 리소스의 시간대 별 로드 시간을 보여주는 Network 창.
• Network 창 속 리소스 크기와 로드 시간을 요약해서 보여주는 그래프.
• HTML 소스의 문법 구별 색깔 표시 기능(syntax highlighting).
• inline JavaScript과 HTML의 오류 보고 기능.

과연, Web Inspector는 Safari의 Firebug가 되고 싶은 것인가?
이 모든 기능이 Windows에도 그대로 적용된다니 웹 개발자들에게는 또 하나의 좋은 도구로 자리잡겠군. 당장 Mac과 Windows 용 nightly builds에서 사용 가능하다.
설치 유혹이 너무나 크군. 😈

Firefox용 만능 웹 개발자 도구인 Firebug가 베타 딱지를 띠고 1.0으로 발표되었다.

마침 Firebug 1.0의 발표에 맞춰 개발자인 Joe Hewitt씨가 Yahoo!에서 했던 소개 동영상도 공개되면서 몇 가지 새로운 기능들을 맛볼 수가 있다.

베타 때부터 사용해왔지만, 화살표 키가 가지고 있는 마력은 앞으로 자주 애용하겠는걸!
실시간 분석과 조치가 가져다 주는 즐거움은 코드를 견고하게 해준다. 8)

Yahoo! User InterfaceBlog의 글에도 나와 있듯이, 웹 브라우져에서 특정 웹 페이지를 읽어드리는데 가장 많은 시간이 소요되는 부분은 html 문서를 생성해서 전달하는 과정보다도 그림 파일들이나 스크립트, 스타일쉬트들과 같은 기타 부분들을 읽어드리는 데에서 대부분의 시간이 소요되는 것으로 알려져 있다.
그렇다면, HTTP의 요청 횟수를 적당한 수준으로 줄일 수 있다면, 여기서 얻어지는 성능의 향상은 서버 튜닝이나 DB 최적화에 의해 얻어지는 성능의 향상보다 훨씬 손쉽게 더 큰 이득을 볼 수도 있다는 얘기가 된다.

하지만, HTTP의 요청 휫수를 줄이고자 무턱대고 멋드러진 웹 유저 인터페이스를 포기할 수도 없는 노릇.
그래서, 불필요한 HTTP 요청들을 즐이면서도 효과적이고 멋진 유저 인터페이스 환경을 제공하기 위한 노력으로서, 관련 자바스크립트나 CSS 파일들을 압축해서 한 데 묶고 캐쉬 기술을 사용하거나 메뉴의 Rollover 이미지들을 하나로 묶는(Pixy rollover) 등의 기법들이 사용되기도 한다.
물론, 여기서 더 나아가 사용자들이 취할 수 있는 조치로, 웹 페이지의 로딩 속도를 단축하기 위해 특정 웹 브라우져의 HTTP의 Pipelining 기능을 커놓는 작업도 할 수 있겠지만, 아직 모든 브라우져들이 이 기능을 지원하지도 않고, 또한 대부분의 서버들은 아직 pipeline된 요청들에 대해 편차가 심한 반응들을 보여주는 것으로 알려지고 있다.

따라서, 적당한 HTTP 요청 횟수를 판단하는 것은 웹 사이트별 사용 환경과 요구 사향에 따라 차이를 보일 수 밖에 없으며, 결국은 개발자 경험에 의한 판단이 중요하다고 말할 수 있다. 여기서 판단의 기초 자료로 사용될 수 있는 도구로 마침 BETA 딱지를 붙이고 새로 갱신되면서 추가된 Firebug의 Network Monitoring 기능을 빼놓을 수 없다.

위에 보이는 창에서처럼 FireBug의 Net 항목을 선택하면, 현재 접속한 웹 페이지를 읽어드리는데 소요된 HTTP 요청들의 횟수와 크기, 시간을 파일별로 한 눈에 살펴볼 수가 있다. 여기서 얻은 자료는 유별나게 웹 페이지 로딩 속도를 지체하게 만드는 불필요한 병목 요인을 끄집어내서, 추가 최적화 작업이 필요한지를 판단하는 중요한 단서가 될 수 있을 것이다.

결국, 웹 개발자들에게 FireBug는 찰떡궁합이라는 얘긴가?

FireBug는 Firefox에 기생하면서 벌레들을 잡어먹는, 그래서 의외로 깔끔을 떠는 벌레의 이름이다.
이렇게 보기에도 속 시원하게 구석구석 살펴서 벌레들을 잡아주는 놈을 왜 진작 안키우고 있었단 말이냐? 😈

추가: FireBug 개발과 배포가 중단되어 대체 자바스크립트 디버깅 도구 소개 페이지로 대신합니다: FireBug 대체 디버깅 도구 모음