저자: Fenng | 재인쇄할 때는 반드시 기사의 원본 출처와 저자 정보 및 저작권 표시를 하이퍼링크 형식으로 표시하십시오: http://www.dbanotes.net/web/flickr_web_tech. .html
Cal Henderson은 유명한 Flickr 웹사이트의 개발자 중 한 명입니다. Serving JavaScript Fast라는 기사에서 그는 Flickr 사이트 애플리케이션을 최적화하는 기술을 소개했습니다. 이 기사를 읽으면서 많은 이점을 얻었습니다. "남의 빵을 씹다"는 기사의 주요 내용을 요약합니다.
플리커(Flickr)는 웹 2.0의 대표적인 사이트이다. 일반 웹사이트에서 흔히 볼 수 있는 콘텐츠 최적화 외에도, 직면한 네트워크 문제는 JavaScript 및 CSS의 잦은 변경으로 인해 발생하는 배포 및 배포의 복잡성을 유연하게 처리해야 합니다.
파일 크기 전략을 설정할 때 직면하는 첫 번째 질문은 JavaScript와 CSS를 모두 하나의 파일에 넣을 것인지, 아니면 여러 파일로 분할할 것인지입니다. 네트워크 요청을 줄이는 관점에서 전자가 더 좋고 후자가 더 나쁩니다. 그러나 병렬 관점에서 볼 때 IE와 Firefox는 기본적으로 동시에 하나의 도메인에서 두 개의 리소스만 요청할 수 있습니다. 이로 인해 많은 경우 사용자에게 나쁜 경험이 발생합니다. 모든 파일은 괜찮은 페이지를 다운로드해야 합니다. 절충안을 사용합니다. 파일 수를 가능한 한 적게 유지하면서 JavaScript와 CSS를 여러 하위 파일로 분할합니다. 이로 인해 개발이 복잡해지지만 성능상의 이점은 엄청납니다.
압축 최적화 문제 사이트 콘텐츠를 압축하는 것이 상대적으로 일반적인 웹 최적화 방법이라는 점에는 의심의 여지가 없습니다. 그러나 원하는 효과를 얻는 것이 항상 가능한 것은 아닙니다. 그 이유는 mod-gzip 모듈이 서버 측 CPU 자원뿐만 아니라 클라이언트 측 CPU 자원도 소모하기 때문입니다. 또한, mod_gzip이 파일을 압축한 후 생성된 임시 파일이 디스크에 배치되므로 심각한 문제가 발생할 수도 있습니다. 디스크 IO용으로는 Httpd 2.x 이상에서 지원하는 mod_deflate 모듈이 사용됩니다. 압축 작업은 모두 메모리에서 수행됩니다. mod_deflate는 Httpd 1.x에서는 사용할 수 없지만 RAM 디스크를 생성하여 간접적으로 성능을 향상시킬 수 있습니다.
물론, mod_gzip은 미리 압축된 파일에도 유용합니다. 또한 압축을 사용할 때 이미지 파일을 압축할 필요도 없습니다(Flickr에는 많은 이미지가 있으며, 압축은 많은 이점을 얻을 수 없습니다. Flickr는 JavaScript 및 CSS만 압축합니다. mod_gzip_update_static 옵션을 구성하여 사전 압축된 파일을 자동으로 처리할 수 있습니다. 또한 Cal은 이 기능이 일부 이전 버전의 브라우저에서 문제를 일으킬 수 있다고 지적했습니다
. 압축 한 가지 주요 수단은 콘텐츠 압축입니다. JavaScript의 경우 압축 구문 및 기타 트릭을 사용하여 주석을 줄이고 공백을 병합하여 이를 수행할 수 있습니다(물론 모든 Google 스크립트는 유사한 아이디어로 읽기가 매우 어렵고 매우 압축됩니다). 이런 방식으로 처리하면 JavaScript에는 구문 분석하기 어려운 괄호가 많이 있을 수 있습니다. Flickr는 Dojo Compressor를 사용하여 구문 분석 트리를 만듭니다. Dojo Compressor는 오버헤드가 매우 낮고 최종 사용자에게 투명합니다. JavaScript 처리 방법이 도입되었으며 CSS 처리는 간단한 정규식 대체(예: 여러 공백을 공백 문자 하나로 대체)를 통해 얻을 수 있습니다. 50% 압축 비율로.
캐싱 최적화 Flickr 개발자는 캐싱 효율성을 향상시키기 위해 HTTP 1.1 사양에 정의된 Etag 및 Last-Modified 메커니즘을 최대한 활용했습니다. 즉, Cal이 로드 밸런싱 조건에서 e-Tag 트릭을 도입했다는 점은 주목할 가치가 있습니다. 파일 조정 시간과 파일 크기를 통해 Apache가 E-Tag를 얻도록 설정할 수 있습니다. 기본적으로 Apache는 파일 노드를 통해 e-Tag를 얻습니다. 물론 이것은 수정된 이후부터 영향을 미치기 때문에 완벽하지는 않습니다.
mod_rewrite의 유연한 사용 Flickr 웹사이트 애플리케이션은 매일 빌드(Daily Build)된다고 합니다. 이는 유연한 메커니즘 없이는 상상할 수 없는 일입니다. 더욱이 Flickr와 같은 사이트에서는 컨텐츠 수정을 동기화하는 것이 골치 아픈 일입니다. 그들의 무기는 mod_rewrite의 유연한 사용입니다. URL 재작성 규칙을 구성하면 다른 환경으로 쉽게 전환할 수 있습니다. 아주 간단해 보이지만, 특정 웹 기술 없이도 이 얼마나 쉽게 할 수 있겠습니까?!
이러한 주요 방법들을 적용함으로써 우리는 꿈같은 고성능 Flickr를 보았습니다.
참고: Flickr는 중국에 서버가 없기 때문에 본토 사용자의 액세스 속도는 언급할 수 없습니다. :(
--End.
이 문서 [Flickr 개발자를 위한 웹 애플리케이션 최적화 팁]은 dbanotes.net에서 가져온 것입니다.