웹 페이지의 빠른 해석을 위한 조치 중의 하나로, 가장 기초적인 것이 웹 페이지에 사용된 그림 파일들의 용량을 최대한 줄여주는 방법이 있다. 대부분 Photoshop과 같은 그래픽 어플리케이션에 있을 법한 “save for web” 메뉴에서 저장하는 것 만으로 만족할 수도 있겠지만, PNG와 같은 자료 손실 없는 압축 형식을 채용한 파일이더라도, 여분의 압축 효율 최적화 과정을 통해 자료 손실 없이 더 작은 크기의 파일을 얻어낼 수가 있다.

추가적인 PNG 압축을 위한 공개된 GUI 어플리케이션들은 많지만, Mac 용으로 알려진 대표적인 것들은 다음과 같다:

위 어플리케이션들은 공통적으로 속도 빠르고 효율 좋기로 소문난 공개 소프트웨어인 OptiPNG를 사용하고 있는데, 불행히도 내장되어 있는 바이너리 파일이 오래된 버전이거나 혹은 Intel 용으로 제공되지 않고 있으며, 또 세세한 조작이 불가능해서 개인적으로 직접 컴파일해서 사용하는 편이 더 쉬웠다. 마침 얼마 전 0.6 버전으로 갱신되면서 압츅 효율이 더 개선되었다고 한다.

빌드 방법은 Unix 소스 코드와 함께 오는 README.txt 파일에 자세히 소개되어 있는데, 우선 압축을 풀고 터미널에서 다음과 같이 빌드/설치한다:

cd optipng-0.6/src/
$ make -f scripts/gcc.mak
.
.
$ make -f scripts/gcc.mak install

이렇게 하면, optipng 바이너리 파일이 /usr/local/bin/ 디렉토리에 위치하게 된다.

원래 command line tool인 이유로, 와일드카드(*)를 써서 디렉토리 안 여러 파일들을 한꺼번에 압축할 수가 있어서 편하고, 사용 옵션을 살펴보면, -o flag를 써서 압축 정도(-o0 ~ -o7)를 지정해 줄 수 있는데, 기본 설정 level(-o2) 만으로도 만족할 만한 결과를 보여준다. 덤으로 압축 시, -i0 옵션을 줘서 (지금은 거의 불필요한) interlaced 정보마저 석제하면 더 높은 압축 결과를 얻을 수가 있다.

dLite 로고근래에 다양해진 여러 JavaScript 라이브러리 출현으로 웹 개발 작업에서의 그 사용 빈도는 덩달아서 크게 늘어났으며, 많은 개발자들의 이런 라이브러리들에 대한 의존도 역시 자연 더 높아질 전망이다.
하지만, 이런 만능 JavaScript 라이브러리들을 쓰면서도 정작 특정 프로젝트에 필요한 기능들은 제한적일 수 밖에 없다. 결국, 이런 작업에 이런 덩치 큰 JavaScript 라이브러리의 힘을 빌리는 것은 어쩌면, 과유 불급, 과잉을 자초하는 행위일지도. 그래서, 평상시 개발에 있어서 꼭 필요한 기능들만 모아놓은 알짜배기 JavaScript 라이브러리의 필요성이 대두되었고, 이런 요구에 부응해서 태어난 놈이 이 dLite라는 놈이다.

dLite에 있는 이 알짜배기 기능들을 모두 나열해 보아도 무척이나 단출하다:

  • elm – 특정 id를 포함하고 있는 element 찾기
  • elmsByClass – 특정 class 이름을 포함하고 있는 모든 element들 찾기
  • DOMReadyDOM이 준비가 되자마자 원하는 함수를 실행
  • addClass – class 이름 추가
  • removeClass – class 이름 제거
  • addEvent – 이벤트 핸들러(handler) 추가
  • removeEvent – 이벤트 핸들러(handler) 삭제
  • stopDefault – 이벤트에 부여된 기본 동작이 진행되는 것을 막음
  • cancelBubbling – 이벤트의 버블링(bubbling) 현상을 취소시킴

그야말로, 평상시 자주 쓰이는 알짜배기 함수들만 모아 놓았다.
특히나 모든 dLite 함수들은 global scope에서 정의되어 있기 때문에, objectName.methodName 형식으로 부를 필요없이 함수 이름을 그대로 사용할 수 있다. 물론, 같은 이름의 함수가 이미 존재할 경우에는 원래의 함수가 대신 사용되고, dLite.함수_이름 형태로 dLite에 있는 함수를 끄집어 사용할 수도 있다.

원 개발자의 기존 JavaScript 라이브러리인 DOMAssistant도 상당히 가볍고 좋았는데, 이놈은 그 보다 더 가벼운 DOMAssistant light 정도로 생각된다.

쉽게 빠지기 쉬운 여러 JavaScript 라이브러리들에 대한 깊은 의존도에서 벗어나서 DOM Scripting 기본에 충실하려는 사용자들에게 상당한 매력이 있을 듯.

EmulateIE7 tells IE8 to display standards DOCTYPEs in IE7 Standards mode, and Quirks DOCTYPEs in Quirks mode. We believe this will be the preferred IE7 compatibility mode for most cases. Support for IE=EmulateIE7 is available now as part of the IE June Security Update for IE8 Beta 1.

IEBLog : Introducing IE=EmulateIE7

<meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" />

요넘은 게으른 개발자들이 미쳐 모든 문서를 표준에 맞게 고치지 못한 경우, Quirks DOCTYPE을 가지고 있는 문서가 깨져 보이지 않도록 Quirks mode로 해석해서 보여준단다. 어쩔 수 없이 과거의 어두운 그림자를 더 길게 드리우게 되었다.

내가 진정 원하는 meta tag은,

<meta http-equiv="X-UA-Compatible" content="IE=자폭 모드 돌입 18초 전, 당장 새로운 브라우저를 까십시오!" />

오랜만에 WebKit Nightly Build를 받아보니 눈에 보이는 많은 변화가 있었다. 우선, WebKit을 내려받으면 항상 같이 붙어 오던 JavaScript debugger인 Drosera가 눈에 보이질 않는다. 확인해 보니, 최근에 WebKit에 내장된 Web Inspector에 흡수되었단다. 설치하고 Web Inspector를 열어보면, 겉모습에서 눈에 띄는 변화들이 보인다.

WebKit의 Web Inspector 메뉴먼저, 다섯 가지(Elements, Resources, Scripts, Profile, Databases)의 항목별 구분 아이콘들로, 훨씬 보기 편하게 작업 환경이 정리된 느낌. 이제 JavaScript debugger는 Scripts 항목에서 실행시킬 수 있고, 또 Console 창 어디에서나 쉽게 접근할 수 있으며, 코드 자동 완성 기능까지 지원해 준다.

Resources 항목을 살펴보면, 예전의 Stylesheets, Images, Scripts 항목들을 통합해서 여러 분류 조건에 따라 한꺼번에 정리된 목록으로 보여주면서 전체적인 분석이 훨씬 용이해졌고, 덤으로 각 리소스 별 Request/Response Headers 정보도 확인할 수 있다.
WebKit의 Web Inspector에 있는 Resources 항목의 창 그림
또, Profiles 항목의 추가로 JavaScript의 실행 속도를 측정/진단하는데 용이하게 쓰일 수 있을 것이다.

WebKit에서는 이렇게 눈에 보이는 변화 말고도, SquirrelFish라는 새로운 JavaScript interpreter를 채용하였는데, 이전 WebKit interpreter보다 1.6 배 더 빠른 JavaScript 실행 속도를 보여준단다. (실제 물고기의 생김새는 아이콘처럼 귀엽지는 않고, 그저 눈만 닮았다. 😯 )
이는 차기 Safari에서도 적용될 예정인데, 아마도 이번 WWDC 2008에서 발표된 Apple의 새로운 MobileMe 서비스에서 사용된 상당히 복잡한 Web 어플리케이션과 같이, JavaScript 의존성이 높은 어플리케이션의 경우 부드러운 사용성 측면에서 앞으로 상당히 중요한 요소가 될 듯 싶다.

아무튼, Web Inspector와 더불어서, Firefox의 Firebug 그리고 Opera의 Dragonfly 등, 개발자들의 마음을 얻기 위한 활발한 웹 개발 도구들의 경쟁에는 박수를 쳐주고 싶다. 😮