WJ
웹 사이트 최적화 방법 본문
1. HTTP 요청 줄이기
브라우저가 웹페이지를 그리는 첫번째 과정으로 주소창에 URL을 입력하고 엔터키를 누르면 서버는 요청을 받고 웹 페이지를 구성하고 있는 HTML, CSS, JavaScript, 이미지 등의 구성 요소들을 보내며 응답합니다. 이러한 구성 요소들을 사용자의 컴퓨터로 가져오는 데는 네트워크 비용이 발생되고, 이 비용이 곧 응답 시간으로 이어집니다. 그러므로 구성요소의 개수를 줄이는 것이 가장 기본적이면서도 중요한 부분중에 하나 입니다.
아래 그림은 쉐보레 메인 페이지와 스파크 세이프티 페이지를 분석한 결과 입니다. 왼쪽은 캐시가 없는 상태일때의 분석 결과이고, 오른쪽은 캐시가 있는 상태일 때 분석한 결과 입니다. 각각의 페이지 마다 구성요소들의 수만큼 HTTP 요청 횟수도 달라지며 이에따라 응답 시간도 차이가 나게 됩니다. 이러한 구성요소들을 어떻게 줄이고 최소화 할 수 있는지에 대한 방법들을 살펴보겠습니다.
- 쉐보레 메인 페이지
- 쉐보레 스파크 세이프티 페이지
2. CSS 스프라이트(sprite)
1번 항목의 그림에서도 볼 수 있듯이 웹페이지를 구현하면서 많은 이미지들이 사용됩니다. 마크업만으로는 표현에 한계가 있기 때문입니다. 대신 이미지를 많이 사용하면 할수록 HTTP 요청 또한 많아 지게 됩니다. 이미지를 많이 사용하면서도 HTTP 요청을 최소화 하기 위한 방법으로 CSS 스프라이트(sprite) 기법이 있습니다.
CSS 스프라이트(sprite) 기법은 여러개의 이미지를 하나로 모아 이미지 파일의 갯수를 줄이는 방법 입니다. 여러 이미지를 다운 받아야 했던 것을 한개만 다운 받게 되니 요청횟수도 줄고 응답 시간도 줄어들게 됩니다. 또 여러 이미지를 하나로 모으면 이미지 사이즈가 더 커질 것이라 생각 할 수 있는데 오히려 개별 이미지의 사이즈를 합한 것보다 이미지를 하나로 합친 파일의 용량이 더 작아 용량을 줄이는 효과도 얻을 수 있습니다.
3. CDN(Content Delivery Network)의 사용
사용자 응답시간의 대부분이 구성요소를 다운로드 받는데 사용 됩니다. CDN 은 사용자에게 보다 효율적으로 컨텐츠를 제공하기 위해 여러 지역에 걸쳐 분산된 웹서버의 집합체로 사용자가 요청을 했을 때 고객의 네트워크에서 가장 가까운 서버를 측정하여 선택하기 때문에 가장 빠른 응답시간의 서버가 선택됩니다.
일부 대형 인터넷 업체들은 자체 CDN 서비스를 소유 하고 있다고 하지만 CDN 서비스를 전문적으로 제공하는 업체를 이용하는 것이 비용적으로 더 효율적이라고 합니다.
CDN 서비스는 비용이 발생하지만 웹사이트의 속도를 급격히 향상시킬 수 있는 쉬운 방법중에 하나 입니다.
4. 캐시 만료일 설정
캐시 만료일을 설정하는 이유는 웹페이지의 구성 요소인 HTML, CSS, JavaScript, 이미지 등의 파일등을 사용자 컴퓨터의 캐시에 저장해두고 재사용하기 위해서 입니다.
1번 항목에 있는 그림을 보면 저장된 캐시가 없을 때 63개의 구성요소를 다운로드 하고, 저장된 캐시가 있을 경우 24개의 구성요소 만을 다운로드 하는 모습을 보았습니다.
이처럼 사용자의 컴퓨터에 캐시 파일이 저장되어 있을 경우 사용자가 캐시 파일을 지우기 전까지 저장된 파일을 불러와 구성 요소를 다운 받지 않고 응답 시간을 줄이게 됩니다.
아래 그림을 보면 제 컴퓨터에 저장되어 있는 캐시 파일들 입니다. 만료 날짜가 설정된 파일도 있고 그렇지 않은 파일들도 있는 모습을 보실 수 있습니다.
모든 구성 요소에 만료 날짜를 설정하는 것이 아니라 만료 날짜 동안 수정되지 않아도 문제가 되지 않을 요소들에게 적용해야 합니다. 만약 만료 날짜 전에 파일을 수정해야 한다면 파일이름을 변경하거나 캐시 데이터를 재 다운로드 받아 수정해야 합니다. 만약 이렇게 하지 않는다면 계속 같은 파일로 인식해 기존의 사용자 컴퓨터에 있는 파일을 로딩해 사용하게 되어 새로운 정보가 웹페이지에 나타나지 않습니다.
5. Gzip
압축을 통해서 파일 크기를 줄여 응답 시간을 줄일 수 있습니다. 브라우저에서 사용되는 encoding 종류는 Accept-Encoding 이라는 Request Header의 attribute를 통해서 서버쪽에 알려지며 서버쪽에서는 이 Accept-Encoding 의 값을 보고 브라우저에서 decoding이 가능한 압축 파일을 보내게 됩니다.
Gzip은 파일의 압축에 사용되는 응용 소프트웨어 이며 대부분의 브라우저에서 지원되고 있기 때문에 가장 대중적이며 효과적인 압축 방법입니다. Gzip 으로 파일을 압축해 전송하게 되면 평균 70% 정도 파일 크기가 작아지는 효과를 볼 수 있습니다. 모바일 환경과 같이 네트워크 환경이 불안한 상황에서는 더욱 효과적인 기술 입니다.
10번 항목의 JavaScript and CSS Minify 와 같이 사용하면 훨씬 더 많은 용량을 줄일 수 있습니다.
6. 상단에 스타일시트를 넣기
문서의 HEAD에 스타일시트를 입력하면 순차적으로 페이지를 로딩하도록 만들어 주어 페이지 로딩 속도를 향상 시킬 수 있습니다. 브라우저는 점진적으로 페이지를 그리는데 렌더 트리를 생성할 때 스타일시트가 반드시 필요합니다. 그리고 파이어폭스나 인터넷 익스플로러는 스타일시트 파일을 모두 다운로드할 때까지 화면을 렌더링 하지 않고 기다립니다. 그래서 스타일시트 파일은 페이지의 제일 위쪽에 위치하는 것을 권장 합니다.
7. 하단에 스크립트를 넣기
스크립트를 하단에 놓아야 하는 가장 큰 이유는 파일을 다운로드해서 실행하기 전까지 브라우저가 DOM 파싱도 중지하고 아무것도 렌더링하지 않기 때문입니다. 이로 인해 이미 서버 통신을 완료하고 필요한 구성 요소를 모두 브라우저에 가져왔음에도 자바스크립트를 수행하느라 렌더링이 멈추게 됩니다. 이때 사용자에게는 마치 화면이 멈춘 것처럼 보여 체감 속도가 느려지게 됩니다.
8. JavaScript and CSS 파일을 외부로 분리하기
JavaScript 와 CSS 파일을 문서내에 배치하는것 보다 외부로 분리하여 link, script 태그로 불러 오는 방식을 사용하는 방법으로 응답시간을 줄일 수 있습니다. 브라우저에 의해 캐시에 저장된 JavaScript 와 CSS 파일은 재사용 되어 사용되기 때문입니다.
9. JavaScript and CSS 통합하기
외부로 분리한 파일들을 최대한 통합하여 파일 갯수를 줄이는 것 또한 중요합니다. 아무리 작은 파일이라도 사용자의 컴퓨터로 가져오기 위해서는 요청을 해야하고 요청이 많아지면 응답 시간 또한 늘어나게 되기 때문입니다.
10. JavaScript and CSS Minify(축소)
JavaScript 와 CSS 작성 시 불필요한 선언을 하지 않는 것 역시 파일의 용량을 줄이고, 렌더링 속도를 빠르게 할 수 있는 방법 중 하나입니다. JavaScript 와 CSS 에서 불필요한 white space를 제거하여 용량을 줄이고 필요한 정보만 한줄에 보내기 때문에 traffic 사이즈가 상당히 줄어들게 됩니다.
JavaScript 축소하는 툴로 JSMin 과 YUI Compressor가 있습니다. YUI Compressor 는 CSS 축소도 가능 합니다.
CSS 축소하는툴로는 CSS Optimizer, Page Speed, YUI Compressor 등과 같은 툴로 축소 할 수 있습니다.
툴을 사용하여 축소를 하는것도 나쁜 방법은 아니지만 직접 코드를 줄여가며 좀 더 자연스럽고 깔끔하게 코드를 작성하는 방법을 확인해 보는 것도 좋은 방법이라고 생각합니다.
CSS
#Minify{
display: block;
float: left;
width: 300px;
height: 300px;
}
#Minify{display:block;float:left;width:300px;height:300px;}
11. DNS 조회 줄이기
DNS (Domain Name System)는 전화 번호부가 사람들의 이름을 전화 번호로 매핑하는 것처럼 호스트 이름을 IP 주소에 매핑합니다. 브라우저에 www.yahoo.com을 입력하면 브라우저에서 접속 한 DNS 확인자가 해당 서버의 IP 주소를 반환합니다. DNS에는 비용이 발생합니다. 일반적으로 DNS가 주어진 호스트 이름의 IP 주소를 조회하는데 20 - 120ms 가 걸립니다. 브라우저는 DNS 조회가 완료 될때까지 이 호스트 이름에서 아무것도 다운로드 할 수 없습니다.
DNS 조회는 성능향상을 위해 임시저장(cache) 됩니다. 이 캐시는 사용자의 ISP 또는 LAN (Local Area Network)이 관리하는 특수 캐시 서버에서 발생할 수 있지만 개별 사용자의 컴퓨터에서 발생하는 캐시도 있습니다. DNS 정보는 운영 체제의 DNS 캐시 (Microsoft Windows의 "DNS 클라이언트 서비스")에 남아 있습니다. 대부분의 브라우저에는 운영 체제의 캐시와 별도로 고유한 캐시가 있습니다. 브라우저가 자체 캐시에 DNS 레코드를 보관하는 한 운영 체제가 레코드 요청을 방해하지 않습니다.
Internet Explorer는 기본적으로 DnsCacheTimeout레지스트리 설정에 지정된대로 DNS 조회를 30분 동안 캐시합니다. Firefox는 network.dnsCacheExpiration구성 설정에 의해 제어되는 DNS 조회를 1분 동안 캐시합니다. (Fasterfox가 이것을 1시간으로 변경합니다.)
클라이언트의 DNS 캐시가 비어 있으면 (브라우저와 운영 체제 모두에 대해) DNS 조회 수는 웹 페이지의 고유한 호스트 이름 수와 같습니다. 여기에는 페이지의 URL, 이미지, 스크립트 파일, 스타일시트, 플래시 객체 등에 사용된 호스트 이름이 포함됩니다. 고유한 호스트 이름의 수를 줄이면 DNS 조회 횟수가 줄어 듭니다.
고유한 호스트 이름의 수를 줄이면 페이지에서 발생하는 병렬 다운로드의 양이 줄어 듭니다. DNS 조회를 피하면 응답 시간이 단축되지만 병렬 다운로드를 줄이면 응답 시간이 늘어날 수 있습니다. 따라서 이 components를 적어도 2개(hostnames이 4개를 넘으면 안됨)로 분리시킬 것을 권장합니다. 이것은 DNS 조회를 줄이는 것과 높은 수준의 parallel downloads를 허용하는 것 사이에 적당한 절충안을 만들어줄 것입니다.
12. 중복 Script 제거하기
한페이지에서 동일한 자바스크립트 파일을 두번 포함시키는 것은 성능에 큰 영향을 미칩니다. 이러한 경우가 생각보다 특별한 경우가 아니라고 합니다. 두 가지 중요 요소(스크립트 크기와 개수)는 단일 웹페이지에서 스크립트 복제 가능성을 증가 시킵니다. 그런 일이 생기면, 복제 스크립트는 불필요한 HTTP 요청과 자바스크립트 실행의 생성으로 인해 성능에 영향을 줍니다.
13. 리다이렉트 피하기
리다이렉트는 사용자를 한 URL에서 다른 URL로 다시 보내는 것을 말합니다. HTML 문서 모두 요청하기도 하며, 페이지 안에서 구성요소를 요청할 때도 사용됩니다. 이 밖에도 리다이렉트를 사용하는 이유는 다양하지만 리다이렉트는 페이지를 더 느리게 만듭니다.
리다이렉트가 완료되고 HTML 문서가 다운로드 될때까지 브라우저 화면에 아무것도 보이지 않습니다. 리다이렉트를 HTML 문서 자체의 다운로드를 지연시키기 때문에 가장 안 좋다고 할 수 있습니다.
14. ETag 헤더를 설정하기
ETag(Entity Tags) 란? 브라우저 캐시에 있는 컴포넌트가 원본 서버에 있는 컴포넌트와 일치하는지 여부를 확인하기 위해 웹서버와 브라우저가 사용하는 매커니즘 입니다.
ETag는 유일하게 컴포넌트의 특정 버전을 식별하는 문자열입니다.
13. 초기 렌더링 시 Ajax 요청 최소화하기
동적인 웹사이트에서 화면을 그리는 단계는 일반적으로 다음과 같습니다.
1. 사용자가 페이지를 요청합니다.
2. 서버에서 보낸 마크업을 다운로드해 렌더링을 시작합니다. 이때 마크업은 화면을 구성하는 레이아웃만 있고 실제로 보여 줄 데이터는 나중에 Ajax 요청을 통해 받은 그리게 됩니다.
3. 자바스크립트 다운로드와 렌더링이 끝난 후 onload 이벤트가 발생합니다.
4. onload 이벤트가 발생한 다음에야 Ajax 통신을 실행하고 데이터를 화면에 그립니다.
5. 화면을 완성합니다.
이 과정에는 두 가지 문제점이 있습니다. 원래 Ajax 통신을 사용하지 않는 방법으로 페이지를 개발했다면 3번 단계에서 사용자는 화면을 보게 됩니다. 그런데 5번 단계까지 가서야 사용자는 최종화면을 볼 수 있습니다. 또 다른 문제는 렌더링이 반복된다는 것입니다. 1 ~ 3번 단계까지 전체 화면을 한 번 그리고 4 ~ 5번 단계에서 화면을 한 번 더 그립니다.
초기 응답 속도가 중요한 경우 Ajax 통신을 하지 않고 JSON 형태로 필요한 데이터를 받아 그려주는 방식으로 변경한다면 통신 비용만 덜었지 여전히 앞에서 발생한 문제가 그대로 나타나게 됩니다. 초기 렌더링 시에 마크업 전체를 서버에서 보내는 방식으로 개발하면 체감 속도를 높일 수 있습니다. 다시 말하면, 1 ~ 3단계에서 전체 화면과 데이터가 있는 화면을 모두 그리는 것입니다. 그리고 사용자의 행동이 있을 때 Ajax 요청을 실행해서 데이터를 받은 다음 화면을 그리게 하는 것으로 개선이 가능합니다.
초기 렌더링 시에 Ajax 통신으로 받은 데이터를 화면에 그리는 방법은 화면을 두 번 그리게 되어 체감 속도를 매우 느리게 합니다. 체감 속도를 높이려면 되도록 초기 렌더링시에는 Ajax 요청을 최소화 합니다.
14. 쿠키 사이즈 줄이기
HTTP 쿠키들은 인증 및 개인화와 같은 다양한 이유로 사용이 됩니다. 쿠키들에 대한 정보는 웹 서버와 브라우저 사이의 HTTP headers에서 교환 됩니다. 쿠키들의 크기를 가능한 작게 유지하는 것은 사용자의 응답시간에 미치는 영향을 최소화 하기 때문에 중요합니다.
15. 구성요소들에 대해 cookie - free 도메인을 사용하기
브라우저가 정적 이미지에 대한 요청을 하고 쿠키들을 함께 보낼 때, 쿠키들은 서버에서 아무런 영향을 주지 않습니다. 그래서 이 쿠키들은 별다른 이유 없이 네트워크 트래픽만을 생성합니다. 정적 구성요소들이 cookie - free 요청들과 함께 요구 되고 있는지 반드시 확인해야 합니다. 서브도메인을 생성하고 거기에 모든 정적 구성요소들을 호스트 합니다. 만약 도메인이 www.example.org 이라면, static.example.org에 정적 구성요소들을 호스팅 할 수 있습니다. 그러나 www.example.org 와 반대로 만약 최상위 도메인 example.org에 이미 쿠키들을 설정했다면, static.example.org로의 모든 요청은 쿠키들을 포함할 것입니다. 이 경우, 완전히 새로운 도메인을 구입할 수 있고, 거기에 정적 구성요소들을 호스트 할 수 있습니다. 또한 이 도메인은 cookie - free 상태로 유지될 수 있습니다. Yahoo는 yimg.com을 사용, YouTube는 ytimg.com을 사용하고 Amazon은
images - amazon.com 등을 사용합니다. cookie - free 도메인에서 적정 구성요소들을 호스팅 하는 것의 또 다른 이점은 일부 proxies가 쿠키들과 함께 요청된 구성요소들을 캐시하는 것을 거부할 수도 있다는 것입니다. 같은 맥락으로, 홈페이지에 example.org 또는 www.example.org의 사용을 망설이고 있는 중이라면, 쿠키에 미치는 영향을 고려해봐야 합니다. www를 생략하는 경우는 *.example.org의 쿠키들을 작성하는 것 밖에 할 수 없지만, 성능을 위해 www 서브도메인을 사용하고 그 서브도메인에 대한 쿠키들을 작성하는 것이 최선의 방법입니다.
16. iframe의 개수를 최소화 하기
iframe을 사용할때는 아래와 같은 장점과 단점들이 있지만 많은 iframe 은 많은 이미지, 스크립트를 사용하는 경우와 같이 성능을 떨어뜨리기 때문에 iframe 또한 개수를 최소화 하여 사용하는 것이 좋습니다.
<iframe> 의 장점
- 광고나 뱃지와 같은 로딩이 느린 third-party-content
- Security sandbox
- 스크립트 병렬 다운로드
<iframe> 의 단점
- 비어있어도 값이 비쌈
- page onload 를 차단함
- Non-semantic (비의미론적인 마크업)
17. DOM 요소의 수를 줄여라
복잡한 페이지는 더 많은 바이트를 다운로드 하는 것을 의미하고, 또한 자바스크립트에서 느린 DOM 접근을 의미합니다. 예를 들어, 만약 event handler를 추가하려는 페이지에 500 또는 5000 개의 DOM 요소를 통해 루프를 돌려서 처리한다면 큰 차이가 생깁니다. DOM 요소의 높은 숫자는 컨텐츠를 반드시 제거하지 않고 페이지의 마크업과 함께 개선되야만 하는 무언가가 있다는 것을 말합니다. 당신은 레이아웃을 위해 중첩된 테이블을 사용하고, 단지 레이아웃 문제를 해결하기 위해 더 많은 DIV를 삽입하고 있는지 생각해 봐야 합니다. 좋은 마크업을 하기 위해서도 불필요한 요소들을 제거하여 마크업 하는 것을 중요합니다.
18. DOM 접근을 최소화 하기
자바스크립트의 DOM 객체는 자바스크립트의 주요 성능 저하 요인 중 하나 입니다. 따라서 자바스크립트의 성능을 최적화하기 위해서는 DOM 객체 접근을 최소화하도록 코드를 작성해야 합니다.
19. 이벤트 핸들러 설정하기
페이지 안에서 너무 자주 실행되는 DOM tree의 서로 다른 요소들에 붙여진 많은 이벤트 핸들러 때문에 반응 속도가 느려지게 됩니다. 만약 한개의 div 안에 10개의 버튼을 사용한다면 각 버튼마다 이벤트 핸들러를 설정하지 않고 버튼들을 감싸고 있는 div 에 이벤트 핸들러를 사용하는 것이 더 효과적입니다.
20. NO 404s 없애기
404 Not Found 는 HTTP 요청을 하고 페이지가 없다는 응답을 받게 되는 불필요한 요청으로 사용자경험을 느리게 만듭니다.
21. CSS의 filter 사용 자제하기
filter는 IE 7 미만 버전에서 PNG의 반투명한 색채의 문제점을 해결하는 것을 목표로 만들어 졌습니다. 하지만 filter 의 문제점은 이미지가 다운로드 되고 있는 동안 렌더링을 차단하고 브라우저를 멈추게 만듭니다. 이것은 메모리 소모를 증가 시키고 이미지마다가 아닌 요소마다 적용되므로 더 문제가 되기 때문에 filter 의 사용을 하지 않는 것이 최적화를 위해 좋습니다.
22. CSS의 Expression 사용 자제하기
CSS expression은 동적으로 CSS 속성을 설정하는 위험하지만 강력한 방법입니다. Internet Explorer 5로 시작되는 버전은 지원되지만, Internet Explorer 8로 시작되는 버전에서는 사용하지 않을 것을 권장합니다. 예로 배경색상은 CSS expression을 사용하여 매시간 다른 설정이 가능합니다.
backgroud-color : expression( (new Date()).getHour()%2? '#B8D4FF' : '#F08A00');
위와 같은, 표현방법은 자바스크립트 방식을 사용합니다. CSS 속성은 자바스크립트 방식을 처리한 결과값으로 설정됩니다. 표현방법은 다른 브라우저에 의해 무시되므로, 여러 브라우저를 통해 일관된 표현 생성을 필요로 하는 Internet Explorer의 속성을 설정하는 것은 유용합니다.
Expression의 문제는 CSS가 대부분 사람들이 생각한 것보다 더 자주 사용된다는 것입니다. 페이지를 읽어오거나 크기를 재설정 또는 스크롤 하거나 심지어 사용자가 마우스로 페이지를 이동할 때에도 사용됩니다. CSS expression의 카운터를 추가하면 CSS expression이 사용되는 빈도를 파악할 수 있습니다.
CSS expression의 사용횟수를 감소시키는 방법 중 하나는 뚜렷한 값으로 스타일 속성을 설정할 수 있는 expression을 한번 사용하는 것입니다. 만약 스타일 속성을 페이지 전반에 걸쳐 동적으로 설정해야 한다면, CSS expression 대신에 event handlers를 사용하는 것이 대안이 될 수 있습니다. 반드시 CSS expression을 사용해야 한다면, 수천 번 이상 사용될 수 있으며 페이지 성능에 영향을 줄 수도 있다는 사실을 기억해야 합니다.
23. HTML 에서 이미지 크기를 줄이기 않기
HTML 안에서 <img width="300" height="300" src="example.png" alt="example"> 와 같이 이미지 사이즈를 변경할 수 있습니다. HTML 내에서 사이즈를 수정하지 않고 원하는 사이즈로 컷팅된 이미지를 넣어 사용하는 것이 최적화에 좋습니다.
24. favicon.ico 파일은 작고 캐시가 가능하게 제작하기
파비콘은 서버의 루트(root)에 머무는 이미지입니다. 브라우저는 같은 서버에 있기 때문에 쿠키들은 요청 시마다 발송됩니다. 또한 이 이미지는 다운로드 순서를 방해합니다.
favicon.ico 이 가진 단점을 보완하기 위해서는
- 가능한 1k 이하로 작게 제작
- 변경설정 후에는 이름변경이 불가능하므로 원하는 시점의 Expires header를 설정해 줍니다.
25. 이미지 최적화 하기
이미지의 개수를 줄이는 스프라이트 기법을 통해 개수를 줄여주는 것도 중요하지만 모든 이미지에 다 적용할수는 없기 때문에 각각의 이미지들을 최적화 해주는 것이 중요합니다. 이미지 최적화를 통해 이미지의 용량이 줄어들고, 사용자의 대역폭에 여유가 생기고, 더 빨리 다운로드하여 화면에 렌더링 할 수 있게 해줍니다.
이미지를 최적화 하기 전 꼭 이미지를 사용해야 하는지에 대한 여부부터 생각해 봐야 합니다. 이미지를 대신하여 CSS 와 웹 글꼴들을 활용하여 대체할수 있다면 대체하여 구현하는 것이 최고의 최적화 방법입니다.
- 벡터 형식 선호 : 벡터 이미지는 해상도 및 배율에 독립적이므로, 여러 기기 및 고해상도 환경에 가장 적합합니다.
- SVG 자산 최소화 및 압축 : 대부분의 그리그 애플리케이션에서 생성하는 XML 마크업에는 불필요한 메타데이터가 들어 있는 경우가 많습니다. 이러한 메타데이터는 제거할 수 있습니다. 서버가 SVG 자산에 대해 GZIP 압축을 적용하도록 구성 되었는지 확인합니다.
- 최적의 래스터 이미지 형식 선택 : 기능적인 요구사항을 확인하고 각각의 특정 자산에 맞는 형식을 선택합니다.
- 래스터 형식에 최적화된 품질 설정 실험 : '품질' 설정을 낮추는 것을 두려워하지 마세요. 결과가 매우 좋은 경우가 많으며 바이트 절감 효과는 상당합니다.
- 불필요한 이미지 메타데이터 제거 : 많은 래스터 이미지에는 위치정보, 카메라 정보 등 자산과 관련하여 불필요한 메타 데이터가 들어 있습니다. 적합한 도구를 사용하여 이러한 메타 데이터를 삭제해 줍니다.
- 배율이 조정된 이미지 제공 : 서버의 이미지 크기를 조정하고 '표시' 크기를 이미지의 '실제' 크기와 최대한 가깝게 합니다. 특히, 큰 이미지의 경우 크기가 조정될 때 가장 큰 오버헤드가 발생하므로 주의 해야 합니다.
- 자동화 : 자동화된 도구 및 인프라에 투자하여 모든 이미지 자산이 항상 최적화 되도록 합니다.
구글 개발자 페이지 입니다. 각 단계별로 더 자세한 설명을 보실 수 있습니다.
26. 25k 이하의 구성요소들을 유지해라
아이폰에서는 25k 보다 큰 구성요소를 캐시하지 않는 이유 때문입니다. gzip으로는 충분하지 않을 수도 있기 때문에 축소하는것은 중요합니다.
좀 더 자세한 정보는 Wayne Shea and Tenni Theurer 의 "Performance Research, Part 5: iPhone Cacheability - Making it Stick" 을 통해 보실 수 있습니다.
27. 다중문서에 구성요소들을 묶어라
이메일의 첨부파일과 같이 다중문서에 구성요소들을 묶는 것은 한 개의 HTTP 요청에 여러 개의 구성요소들을 불러오는 데 도움이 됩니다. 사용자가 이 기술을 사용할 때, 사용자 에이젼트가 이러한 기능르 지원하는 먼저 확인해 봐야 합니다.
28. 초기 buffer를 flush 하기
사용자들이 페이지를 요청할 때, backend 서버와 HTML 페이지를 함께 연동하는 것은 200 ~ 500ms 사이의 시간이 걸릴 수 있습니다. 브라우저는 도착하는 데이터를 기다리는 동안 작동하지 않습니다. PHP는 flush() 기능을 가지고 있습니다. 그것은 일부 준비된 HTML 응답을 브라우저로 전송하는 것을 승인함으로써, 브라우저는 backend 가 HTML 페이지의 나머지와 함께 연동되는 동안 컴포넌트를 불러올 수 있습니다. head 에 대한 HTML이 보통 더 쉽게 생성되기 때문에 head 바로 다음에 flushing을 사용하는 것이 적합합니다. 그것은 backend 가 동작하는 동안, 브라우저가 병렬로 연동하기 위해 필요한 CSS 및 JavaScript 파일들을 포함하는 것을 허락합니다.
ex)
...<!-- css, js -->
</head>
<? php flush(); ?>
<body>
...<!-- content -->
29. Post-load Components
페이지를 자세히 살펴보게 되면 "처음에 페이지를 읽어오기 위해 절대적으로 요구되는 것"이 무언인지에 의문을 가집니다. 컨텐츠와 컴포넌트의 나머지는 기다릴 수 있습니다. JavaScript 는 onload event 전후의 분할을 위한 이상적인 후보입니다. 예를 들어, 만약 드래그 앤 드롭(drag and drop)과 애니메이션을 실행하는 JavaScript 코드와 라이브러리를 갖고 있다면, 초기 렌더링 후에 페이지의 dragging 요소(elements)가 오기 때문에 그것들을 기다릴 수 있습니다. Post-loading에 대한 후보를 찾기 위한 또 다른 장소는 fold 아래의 숨겨진 컨텐츠(사용자의 동작 이후에 나타나는 컨텐츠)와 이미지들을 포함합니다.
YUI Image Loader를 이용하면 fold 아래의 이미지들을 지연시킬 수 있고, YUI GET 유틸리티는 즉시 JS와 CSS를 포함하는 가장 쉬운 방법입니다. Firebug의 Net Panel이 실행되는 Yahoo의 홈페이지는 좋은 예가 됩니다. 성능목표는 다른 웹 개발 모범사례(best practices) 와 비슷할 때 가장 이상적입니다. 이런 경우, 점진적 강화의 아이디어는
자바스크립트를 지원받을 때 사용자경험(UX)를 향상시킬 수 있지만, 페이지가 자바스크립트 없이도 작동하는지 반드시 확인 해야 한다는 것을 명시해야 합니다. 그래서 페이지가 정상적으로 작동하는지 확인한 후에, 약간의 post-loaded script(드래그 앤 드롭 및 애니메이션과 같은 부가프로그램을 제공하는)로 향상시킬 수 있습니다.
30. Preload Components
Preload는 post-load의 반대개념처럼 보일지 모르지만, 실제로는 다른 목적을 가지고 있습니다. 컴포넌트를 preloading 함으로써 브라우저가 정지상태(idle)인 시간의 이점을 활용할 수 있고, 미래에 필요한 컴포넌트(이미지, css, script와 같은)를 요청할 수 있습니다. 이 방법은 사용자가 다음 페이지를 방문할 때, 대부분의 컴포넌트를 캐시에 이미 가질 수 있고, 페이지는 사용자에게 훨씬 빨리 로드(load)될 것입니다.
31. 도메인에서 구성요소들을 분할하라
컴포넌트를 분할하는 것은 병렬 다운로드를 극대화 할 수 있습니다. DNS 조회의 페널티 때문에 2-4개 이상의 도메인을 사용하고 있지는 않은지 확인 해 봐야 합니다.
예를 들어, www.example.org 에서 HTML과 동적 컨텐츠를 호스트할 수 있고, static 1.example.org 와 static 2.example.org 사이의 정적 구성 요소를 분할 할 수 있습니다.
더 자세한 내용은 Tenni Theurer와 Patty Chi의 "Maximizing Parallel Downloads in the Carpool Lane"을 통해 보실 수 있습니다.
32. @import 보다 <link>를 선택하라
위에서 점진적 렌더링을 위해서 CSS가 페이지의 상단에 와야 한다는 내용을 확인 했었습니다. IE에서 @import는 태그를 페이지의 하단에 사용하는 것과 같으므로 최적의 사용방법이 아닙니다.
33. 빈 이미지 src 없애기
1. HTML
<img src="">
2. JavaScript
var img = new Image();
img.src = "";
위 두가지 양식은 동일한 효과를 불러 일으킵니다. 브라우저마다 서버에 다른 요청을 하게 됩니다.
- IE 는 페이지가 위치한 디렉토리를 요청합니다.
- Safari 와 Chrome 은 그것들의 실제 페이지를 요청합니다.
- Firefox 3 와 이전 버전들은 Safari, Chrome 과 같은 동작을 수행하지만, 버전 3.5에서는 이 문제를 ([bug 444931]) 다루며 더 이상 요청을 보내지 않습니다.
- Opera는 빈 이미지가 src가 발생할 때, 아무것도 수행하지 않습니다.
이 규칙은 Yahoo의 자바스크립트 전문가, Nicolas C. Zakas에 의해 창안되었습니다. 자세한 내용을 보려면 그의 기사 "Empty image src can destroy your site"을 통해 보실 수 있습니다.
웹 성능 최적화 측정 도구
YSlow
YSlow는 웹 성능 최적화 측정 도구로 웹 페이지가 얼마나 최적화 법칙을 만족하고 있는지 측정하는 도구 입니다.
많은 브라우저에 확장 프로그램으로 제공하고 있고 http://yslow.org/ 에서 다운로드 받을 수 있습니다.
YSlow는 현재 야후에서 발표한 35개의 법칙 중 프로그램으로 측정할 수 있는 23개 법칙을 분석해 자체 기준에 따라 A~F 등급으로 분류해 줍니다.
등급 및 점수는 참고 사항이기 때문에 기준을 모두 따라야 하는 것은 아니며 보고서 내용을 참고하여 상황에 맞게 최적화 하면 될 것 입니다.
참조
http://12bme.tistory.com/128?category=682905
https://b.luavis.kr/server/is-css3-transform-is-better-choice
http://d2.naver.com/helloworld/303083
// 성능 향상을 위한 iframe 사용법
http://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS5589088797&cate_cd=
// 모바일 웹 성능 체크리스트
http://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS8620093257&cate_cd=
// 웹사이트 이미지 최적화
http://www.hanbit.co.kr/media/channel/view.html?cms_code=CMS6023644359&cate_cd=
// 야후의 성능개선팀이 만든 웹 사이트 성능 최적화 법칙 입니다.
https://developer.yahoo.com/performance/rules.html
// 야후에서 내논 최적화 법칙을 한글로 번역한 사이트 입니다.
https://www.xpressengine.com/tip/22330022