오늘은 "고성능 웹사이트"를 간단히 살펴보았습니다. 이 책의 중국어판은 "고성능 웹사이트 구축 가이드"입니다.
이 책에는 개별 문제를 깊이 탐구하는 고급 장인 "Even Faster Web Sites"도 포함되어 있으며, 중국어 번역은 "고성능 웹 사이트 구축을 위한 고급 가이드"입니다.
작가님이 위의 두반링크에 소개하셨으니 여기서는 복사하지 않겠습니다.
이 책은 웹사이트 성능을 향상하기 위한 14가지 원칙을 제공하며, 각 원칙은 예제가 포함된 독립된 장입니다. 이러한 원칙의 대부분은 매우 실용적이며 사이트 설계자 및 프런트엔드 엔지니어에게 적합합니다. 이는 프론트 엔드 엔지니어에게 더 큰 의미를 갖습니다.
이번에는 원작을 봤습니다. 웹 개발에 대한 실무 경험이 부족하여 급하게 읽다가 누락된 부분이나 부적절한 표현이 있을 수 있으니 네티즌 여러분께서 편하게 지적해 주셨으면 좋겠습니다.
원칙 1 HTTP 요청 수를 줄입니다.
요청을 구성하고 응답을 기다리는 데 시간이 걸리므로 요청이 적을수록 좋습니다. 요청을 줄이는 일반적인 아이디어는 리소스를 병합하고 페이지를 표시하는 데 필요한 파일 수를 줄이는 것입니다.
1. 이미지 맵
<img> 태그의 usemap 속성을 설정하고 <map> 태그를 사용하면 이미지를 여러 영역으로 나누고 다른 링크를 가리킬 수 있습니다. 여러 이미지를 사용하여 별도로 링크를 구성하는 것에 비해 요청 수가 줄어듭니다.
2. CSS SPRite(CSS 텍스처 통합/텍스처 스티칭/텍스처 포지셔닝)
이는 요소의 배경 위치 스타일을 설정하여 수행됩니다. 일반적으로 인터페이스 아이콘에 사용됩니다. 일반적인 것은 TinyMCE 편집기 위의 작은 버튼을 참조할 수 있습니다. 여러 개의 작은 이미지는 본질적으로 서로 다른 오프셋을 사용하여 통합된 큰 이미지에서 잘라냅니다. 이러한 방식으로 로딩 인터페이스의 많은 버튼은 실제로 한 번만 요청하면(큰 이미지를 한 번 요청) HTTP 요청 수가 줄어듭니다.
3. 인라인 이미지
<img>의 src에는 외부 이미지 파일의 URL을 명시하지 말고, 이미지 정보를 직접 넣어주세요. 예를 들어, src="data:image/gif;base64,R0lGODlhDAAMAL..."은 일부 특수한 경우에 유용합니다(예: 작은 이미지가 현재 페이지에서만 사용됨).
원칙 2: 다중 회선 CDN 활용
모든 사용자가 신속하게 액세스할 수 있도록 사이트에 여러 회선(예: 국내 통신, 차이나 유니콤, 차이나 모바일) 및 여러 지리적 위치(북쪽, 남쪽, 서쪽)에 대한 액세스를 제공합니다.
원칙 3: HTTP 캐시 사용
자주 업데이트되지 않는 리소스(예: 정적 이미지)에는 더 긴 만료 헤더 정보를 추가합니다. 이러한 리소스는 일단 캐시되면 나중에 오랫동안 다시 전송되지 않습니다.
원칙 4: Gzip 압축 사용
Gzip을 사용하여 HTTP 메시지를 압축하면 크기와 전송 시간이 줄어듭니다.
원칙 5: 페이지 전면에 스타일 시트를 배치하세요.
페이지 렌더링이 더 일찍 시작될 수 있도록 스타일 시트를 먼저 로드하여 사용자에게 페이지가 더 빠르게 로드되는 느낌을 줍니다.
원칙 6: 페이지 끝에 스크립트를 배치하세요
이유는 5와 같습니다. 페이지 표시가 먼저 처리되고, 페이지 렌더링이 먼저 완료되고, 스크립트 로직이 나중에 실행되므로 사용자에게는 페이지가 더 빨리 로드되는 느낌을 줍니다.
원칙 7 CSS 표현식 사용을 피하세요
지나치게 복잡한 JavaScript 스크립트 논리, DOM 검색 및 선택 작업은 페이지 처리 효율성을 저하시킵니다.
원칙 8 Javascript와 CSS를 외부 리소스로 사용
이는 원칙 1의 병합 아이디어에 반대되는 것처럼 보이지만 그렇지 않습니다. 각 페이지가 공개 JavaScript 리소스(예: jQuery 또는 ExtJS와 같은 JavaScript 라이브러리)를 도입한다는 점을 고려하면 한 페이지만의 성능으로 판단하면 인라인 (예: HTML에 JavaScript 삽입) 페이지는 아웃바운드(<script> 태그를 사용하여 도입됨) 페이지보다 (HTTP 요청 수가 적기 때문에) 더 빠르게 로드됩니다. 그러나 많은 페이지에서 이 공용 JavaScript 리소스를 도입하면 인라인 방식으로 인해 반복 전송이 발생합니다. (이 리소스는 각 페이지에 포함되어 있으므로 페이지를 열 때마다 리소스의 이 부분을 전송해야 하므로 네트워크 전송 낭비가 발생합니다.) 자원). 이 문제는 이 리소스를 독립적으로 만들고 외부에서 참조함으로써 해결될 수 있습니다.
JavaScript와 CSS는 상대적으로 안정적이므로 해당 리소스에 대해 더 긴 만료 날짜를 설정할 수 있습니다(원칙 3 참조).
원칙 9 DNS 조회 줄이기
저자의 조언은 다음과 같습니다.
1. 연결 유지를 위해 Keep-Alive를 사용하세요
연결이 끊어지면 다음에 연결될 때 DNS 조회를 수행해야 합니다. 해당 도메인 이름-IP 매핑이 캐시되어 있어도 조회에 시간이 걸립니다.
2. 도메인 이름 줄이기
새 도메인 이름을 요청할 때마다 DNS를 통해 다른 도메인 이름을 조회해야 하며 DNS 캐시가 작동하지 않습니다. 따라서 통합 도메인 이름으로 사이트를 구성하고 하위 도메인 이름을 너무 많이 사용하지 않도록 최선을 다해야 합니다.
원칙 10 JavaScript를 축소하세요
JS 압축 도구를 사용하여 JavaScript를 압축하면 매우 효과적입니다. 차이점을 확인하려면 jQuery의 두 가지 배포판을 살펴보세요.
http://code.jquery.com/jquery-1.6.2.js 읽기 버전 jQuery 코드, 230KB
http://code.jquery.com/jquery-1.6.2.min.js jQuery 코드 압축 버전(실제 배포용), 89.4KB
원칙 11 리디렉션을 피하십시오
리디렉션은 보고 싶은 페이지에 실제로 액세스하기 전에 추가 HTTP 요청 라운드가 추가됨을 의미합니다(클라이언트가 HTTP 요청 시작 → HTTP 서버가 리디렉션 응답 반환 → 클라이언트가 새 URL에 대한 요청 시작 → HTTP 서버가 콘텐츠를 반환하는데, 밑줄 친 부분은 추가 요청임) 시간이 더 많이 소모됩니다(이로 인해 사람들은 응답 속도가 느려진다는 느낌도 받습니다). 따라서 필요한 경우가 아니면 리디렉션을 사용하지 마세요. 몇 가지 "필요한" 상황:
1. 잘못된 URL을 피하세요
이전 사이트가 이전된 후 이전 URL이 무효화되는 것을 방지하기 위해 이전 URL에 대한 요청은 일반적으로 새 시스템의 해당 주소로 리디렉션됩니다.
2. URL 미화
읽을 수 있는 URL과 실제 리소스 URL 사이를 변환합니다. 예를 들어 Google 툴바의 경우 사용자는 인간의 의미 주소인 http://toolbar.google.com을 기억하지만 http://www는 기억하기 어렵습니다. .com/tools/Firefox/toolbar/FT3/intl/en/index.html은 실제 리소스 주소입니다. 따라서 전자를 유지하고 전자에 대한 요청을 후자로 리디렉션해야 합니다.
원칙 12 중복된 스크립트를 제거하세요
페이지에 동일한 스크립트를 반복적으로 포함하지 마세요. 예를 들어 스크립트 B와 C는 모두 A에 의존하므로 B와 C를 사용하는 페이지에서 A에 대한 참조가 반복될 수 있습니다. 해결책은 간단한 사이트에 대한 종속성을 수동으로 확인하고 복잡한 사이트에 대한 반복적인 도입을 제거하는 것입니다. 자체 종속성 관리/버전 제어 메커니즘을 구축해야 합니다.
원칙 13 ETag를 주의해서 다루세요.
ETag는 Last-Modified 외에 또 다른 HTTP 캐시 방법입니다. 해싱을 통해 리소스가 수정되었는지 확인합니다. 그러나 ETag에는 다음과 같은 몇 가지 문제가 있습니다.
1. 불일치: 서로 다른 웹 서버(Apache, IIS 등)는 서로 다른 ETag 형식을 정의합니다.
2. ETag 계산이 불안정합니다(너무 많은 요소를 고려하여). 예:
1) 동일한 리소스는 서로 다른 서버에서 계산된 서로 다른 ETag를 가지며 대규모 웹 애플리케이션은 일반적으로 둘 이상의 서버에서 제공됩니다. 이로 인해 서버 A에 있는 클라이언트의 캐시된 리소스는 여전히 유효하지만 다음에 B를 요청할 때 발생합니다. ETag가 다르면 유효하지 않은 것으로 간주되어 동일한 리소스가 반복적으로 전송됩니다.
2) 리소스는 변경되지 않은 상태로 유지되지만 구성 파일 변경과 같은 다른 요인의 변경으로 인해 ETag가 변경됩니다. 직접적인 결과는 시스템 업데이트 후 클라이언트 캐시 오류가 대규모로 발생하여 전송량이 크게 증가하고 사이트 성능이 저하된다는 것입니다.
저자의 제안은 애플리케이션의 특성에 따라 기존 ETag 계산 방법을 개선하거나 단순히 ETag를 사용하지 않고 가장 간단한 Last-Modified를 사용하는 것입니다.
원칙 14 Ajax로 HTTP 캐시 활용
Ajax는 비동기 요청입니다. 비동기 요청은 현재 작업을 차단하지 않으며 요청이 완료되면 즉시 결과를 볼 수 있습니다. 그러나 비동기식은 즉시 완료될 수 있다는 의미도 아니며, 완료하는 데 무한한 시간이 걸릴 수 있고 허용될 수 있다는 의미도 아닙니다. 따라서 Ajax 요청의 성능에도 주의를 기울여야 합니다. 비교적 안정적인 리소스에 액세스하는 Ajax 요청이 많으므로 Ajax 요청에 대해 HTTP 캐시 메커니즘을 잘 활용하는 것을 잊지 마세요. 자세한 내용은 원칙 3과 13을 참조하세요.
저자 : 양멍동
기사 출처 : Yang Mengdong 블로그. 전재시 출처 링크를 표기해주세요.