├── .idea ├── modules.xml ├── performance-optimization.iml ├── vcs.xml └── workspace.xml ├── LICENSE ├── README.md ├── advanced ├── Lighthouse-6가지-평가지표.md ├── README.md ├── TCP,IP-프로토콜.md └── 왜-웹-성능이-중요한지(구글-검색).md ├── basic ├── 10장-웹-최적화-실습하기 │ └── README.md ├── 1장-웹-성능이란-무엇인가 │ ├── README.md │ ├── rita.md │ ├── tanney.md │ └── yujo.md ├── 2장-웹-최적화 │ ├── README.md │ ├── rita.md │ ├── tanney.md │ └── yujo.md ├── 3장-웹-사이트-성능을-개선하는-기본적인-방법 │ ├── README.md │ ├── rita.md │ ├── tanney.md │ ├── tococ.md │ └── yujo.md ├── 4장-이미지-최적화 │ ├── README.md │ ├── rita.md │ └── tococ.md ├── 5장-웹에서-가속을-이끌어-내는-방법 │ ├── README.md │ ├── rita.md │ ├── tanney.md │ └── tococ.md ├── 6장-캐시-최적화 │ ├── README.md │ ├── tococ.md │ └── yujo11.md ├── 7장-CDN │ └── README.md ├── 8장-웹-프로토콜-최적화 │ └── README.md ├── 9장-웹-최적화-트렌드 │ └── README.md └── README.md ├── practice ├── 2.5-네비게이션-타이밍 │ └── rita.md └── README.md └── 목차.md /.idea/modules.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | -------------------------------------------------------------------------------- /.idea/performance-optimization.iml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | -------------------------------------------------------------------------------- /.idea/vcs.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | -------------------------------------------------------------------------------- /.idea/workspace.xml: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 10 | 11 | 12 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 1640173257656 25 | 30 | 31 | 32 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2021 Frontend-Divers 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | ## 🔎 스터디 소개 2 | 3 | ### 📑 Introduction 4 | 5 | **웹에 날개를 달아주는 성능 최적화 기법**을 함께 읽으며 공부하는 스터디입니다. 6 | 7 | - https://webfrontend.org/ 8 | 9 | ### 📌 When, Where 10 | 11 | - **매주 수요일 22시~23시** Discord 12 | - 2021.12.08 ~ 2022.3.16 13 | 14 | ### 🥅 Goal 15 | 16 | - 네트워크 지식을 학습한다. 17 | - 웹 성능 최적화 기법을 학습한다. 18 | 19 | ## 📝 진행방법 20 | 21 | 1. 매주 화요일까지 정해진 챕터를 읽고 내용을 정리해서 PR을 보낸다. 22 | - 실습 코드가 존재하는 챕터의 경우 실습을 진행한 내용을 정리해서 PR을 보낸다. 23 | 2. 매주 수요일까지 번갈아가면서 해당 챕터에 대한 추가적인 내용을 정리해서 PR을 보낸다. 24 | - 윤호, 상민 | 태은, 진주 25 | 26 | ## 중간점검 27 | 2022.2.9 중간점검 및 회고 결과에 따라 더 이상 내용을 정리하지 않습니다. 챕터를 읽어오고, 각자 질문을 정해옵니다. 28 | 29 | ## 🚀 PR 컨벤션 30 | 31 | 1. 공통 32 | - 본인의 PR에 본인을 assign 한다. 33 | - 본인의 PR에 적합한 label을 등록한다. 34 | - 리뷰어에 본인을 제외한 나머지 스터디 원들을 등록한다. 35 | 2. PRACTICE, BASIC 36 | - [PRACTICE or BASIC] [해당 챕터 이름] - [닉네임] 37 | - 예시) [PRACTICE] 1장 웹 성능이란 무엇인가 - 태은 38 | 3. ADVANCED 39 | - [ADVANCED] [제목] - [닉네임] 40 | - ex) [ADVANCED] Lighthouse의 6가지 평가 지표 - 윤호 41 | -------------------------------------------------------------------------------- /advanced/Lighthouse-6가지-평가지표.md: -------------------------------------------------------------------------------- 1 | ### 1. FCP(First Contentful Paint) - 15% 2 | 3 | - FCP는 사용자가 페이지를 탐색 한 후 브라우저가 DOM 콘텐츠의 첫 번째 부분을 렌더링하는 데 걸리는 시간을 측정합니다. 페이지의 이미지, 흰색이 아닌 `` 요소 및 SVG는 DOM 콘텐츠로 간주됩니다. iframe 내부의 내용은 포함되지 않는다. 4 | ![](https://s3.us-west-2.amazonaws.com/secure.notion-static.com/569069b6-b433-4deb-93f6-a080c066220e/Untitled.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAT73L2G45O3KS52Y5/20210822/us-west-2/s3/aws4_request&X-Amz-Date=20210822T053938Z&X-Amz-Expires=86400&X-Amz-Signature=4c14764633cf7e09b371fe58904ee19ff0fa3660920c00aadd813fe68f598a7c&X-Amz-SignedHeaders=host&response-content-disposition=filename%20="Untitled.png") 5 | - https://web.dev/first-contentful-paint/ 6 | 7 | ### 2. Speed Index - 15% 8 | 9 | - Speed Index는 페이지로드 중 콘텐츠가 시각적으로 표시되는 속도를 측정한다. 10 | - Lighthouse는 먼저 브라우저에서로드되는 페이지의 비디오를 캡처하고 프레임 간의 시각적 진행을 계산합니다. Lighthouse는 Speedline Node.js 모듈 을 사용하여 Speed Index 점수를 생성한다. 11 | 12 | ![](https://s3.us-west-2.amazonaws.com/secure.notion-static.com/0c403c7d-2b94-417f-8244-87c34c4190bd/Untitled.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAT73L2G45O3KS52Y5/20210822/us-west-2/s3/aws4_request&X-Amz-Date=20210822T054235Z&X-Amz-Expires=86400&X-Amz-Signature=a3d7097f65c4628a231946e48ef3f9f29c6565ec5eeeb229492884668b5a8be0&X-Amz-SignedHeaders=host&response-content-disposition=filename%20="Untitled.png") 13 | 14 | - https://web.dev/speed-index 15 | 16 | ### 3. LCP(Largest Contentful Paint) - 25% 17 | 18 | - LCP는 페이지가 처음 로드 되기 시작한 시점을 기준으로 뷰포트 내에 표시되는 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간을 측정한다. 19 | - https://web.dev/lcp/ 20 | 21 | ### 4. TTI(Time to Interactive) - 15% 22 | 23 | - TTI는 페이지가 완전히 상호 작용하는 데 걸리는 시간을 측정한다. 24 | - 페이지는 다음과 같은 경우 완전한 대화 형으로 간주됩니다. 25 | - https://web.dev/interactive/ 26 | 27 | ### 5. TBT(Total Blocking Time) - 25% 28 | 29 | - TBT는 페이지가 마우스 클릭, 화면 탭 또는 키보드 누름과 같은 사용자 입력에 응답하지 못하도록 차단 된 총 시간을 측정한다. 30 | - 합계는 First Contentful Paint와 Time to Interactive 사이의 모든 긴 작업의 차단 부분을 추가하여 계산된다. 31 | - 50ms 이상 실행되는 모든 작업은 긴 작업으로 간주 된다. 50ms 이후의 시간이 차단 부분이다. 32 | - 예를 들어 Lighthouse가 70ms의 긴 작업을 감지하면 차단 부분은 20ms가 된다. 33 | - https://web.dev/lighthouse-total-blocking-time/ 34 | 35 | ### 6. CLS(Cumulative Layout Shift) - 5% 36 | 37 | - CLS는 페이지의 전체 수명 동안 발생하는 모든 예기치 않은 레이아웃 이동에 대한 모든 개별 레이아웃 이동 점수의 합계를 측정한다. 38 | - 레이아웃 이동은 표시되는 요소가 렌더링 된 프레임에서 다음 프레임으로 위치를 변경할 때마다 발생한다. 39 | 40 | - https://web.dev/cls/ 41 | -------------------------------------------------------------------------------- /advanced/README.md: -------------------------------------------------------------------------------- 1 | # Advanced 2 | 3 | 주마다 해당 챕터에 대해 심화된 내용을 찾아 정리합니다. (매주 2명) 4 | 5 | ## 📝 링크 모음 6 | 7 | - [Lighthouse의 6가지 평가지표](https://github.com/Frontend-Divers/performance-optimization/blob/main/advanced/Lighthouse-6%EA%B0%80%EC%A7%80-%ED%8F%89%EA%B0%80%EC%A7%80%ED%91%9C.md) 8 | - [웹 성능이 중요한 이유(feat. 구글 검색)](https://github.com/Frontend-Divers/performance-optimization/blob/main/advanced/%EC%99%9C-%EC%9B%B9-%EC%84%B1%EB%8A%A5%EC%9D%B4-%EC%A4%91%EC%9A%94%ED%95%9C%EC%A7%80(%EA%B5%AC%EA%B8%80-%EA%B2%80%EC%83%89).md) 9 | -------------------------------------------------------------------------------- /advanced/TCP,IP-프로토콜.md: -------------------------------------------------------------------------------- 1 | # TCP/IP 프로토콜 2 | 3 | - TCP/IP 프로토콜은 일반적으로 TCP와 IP를 사용해 통신하는 방식을 의미하며 응용 계층부터 하드웨어까지의 계층을 모두 내포한다. 4 | - 응용 계층(HTTP 등)에서 전달하고자하는 데이터를 TCP나 UDP 중 하나로 전송한다. 5 | - 이때 해당하는 프로토콜은 데이터를 패킷 단위로 나누어 인터넷 네트워크 계층에 전달한다. 6 | - 인터넷 네트워크 계층에서는 전달 받은 패킷을 IP 패킷에 포함시켜 네트워크 인터페이스 계층에 전달한다. 7 | - 네트워크 인터페이스 계층에서는 받은 데이터를 하드웨어를 통해 전달한다. 8 | 9 |
10 | 11 | ## IP (Internet Protocol) 12 | 13 | - IP는 출발지의 IP주소, 목적지의 IP 주소 등 정보를 주고 받는 데 사용하는 정보를 패킷에 담아 통신하도록 하는 프로토콜이다. 14 | - IP는 신뢰성과 연결성을 보장하지 않는다. 15 | - 전송 과정에서 패킷이 손상되거나, 순서가 뒤 바뀌는 등의 상황에 대한 대처가 어렵다는 단점이 있다. 16 | 17 |
18 | 19 | ## TCP (Transmission Control Protocol) 20 | 21 | - TCP는 IP의 상위 계층으로 IP의 비신뢰성, 비연결성을 보완하는 프로토콜이다. 22 | - 3-way hanshake를 통해 논리적 연결을 보장한다. 23 | - 송신측에서 SYN(접속 요청) 메시지를 보낸다. 24 | - 수신측에서는 ACK(요청 수락) 메시지를 보냄과 동시에 수신측에 대한 SYN 메시지를 보낸다. 25 | - 송신측에서 다시 ACK 메시지를 보냄으로써 논리적 연결을 달성한다. 26 | - check sum 방식을 통해 데이터 손상 여부 확인한다. 27 | - 순서 번호를 부여해 순서를 보장한다. 28 | - 확인 응답 번호를 통해 실제 수신 여부를 확인하고 다음 순서를 지시한다. 29 | - 정해진 시간이 지나거나 중복 ack가 도착하면 재전송을 시도한다. 30 | - IP 주소에 PORT 정보를 더해 다수의 연결을 동시에 처리할 수 있도록 함 31 | 32 |
33 | 34 | ## UDP (User Datagram Protocol) 35 | 36 | - IP와 거의 유사하나 PORT와 체크섬 정도만 추가된 프로토콜이다. 37 | - 따라서 연결이나 데이터 전송, 순서 등을 보장하지 않는다. 38 | - 애플리케이션에서 추가 작업을 할 수 있다.(고 한다.) 39 | - 프로세스 자체가 가볍고 추가 작업에 여지가 있다는 장점이 있다. 40 | - HTTP/3 사양에서는 UDP를 사용한다.(고 한다.) 41 | 42 |
43 | 44 | ## 참고 45 | - [모든 개발자를 위한 HTTP 웹 기본 지식, 김영한(강의)](https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/dashboard) 46 | - [TCP/IP프로토콜, ibm](https://www.ibm.com/docs/ko/aix/7.1?topic=protocol-tcpip-protocols) 47 | - [TCP, 정보통신기술용어해설](http://www.ktword.co.kr/test/view/view.php?m_temp1=347) -------------------------------------------------------------------------------- /advanced/왜-웹-성능이-중요한지(구글-검색).md: -------------------------------------------------------------------------------- 1 | # 웹 성능이 중요한 이유 (구글 SEO 관련) 2 | 3 | **Chapter 1.2에서 언급한 `웹 성능이 중요한 이유`에 대해서 보충하는 문서입니다.** 4 | 5 |
6 | 7 | `웹 성능 최적화 기법`책에서는 온라인 쇼핑몰을 예로 들면서 `웹 성능이 좋으면 좋을 수록 고객들이 상품을 더 잘 구매한다`라는 사실을 인용하면서 웹 성능이 중요한 이유에 대한 예제를 보여주고 있습니다. 8 | 9 | 웹 성능이 중요한 또 다른 예시를 찾아보던 와중에 구글의 SEO 측정과 웹 성능의 관계에 대해서 알게 되었고 , 구글이 `웹 성능에 따라 사용자들이 검색될 수 있는 정도를 다르게 한다`는 내용을 소개하려고 합니다. 10 | 11 |
12 | 13 | ### 실제로, 구글에서는 웹 성능을 하나의 지표로 놓고 SEO를 측정하고 있습니다. 14 | 15 | > SEO란? 16 | > 17 | > SEO는 **search engine optimization**의 약자로, 한국말로는 검색 엔진 최적화를 뜻합니다. 웹 페이지 검색엔진(구글, 네이버, 야후등)이 자료를 수집하고 순위를 매기는 방식에 맞게 웹 페이지를 구성해서 검색 결과의 상위에 나올 수 있게 하는 것이 SEO의 목적입니다. 18 | 19 |
20 | 21 | 구글의 개발 문서에 있는 글을 번역해보면, 사용자가 특정한 단어를 검색하면 나오는 수많은 웹사이트들중에 어떤 웹사이트를 보여줄 지 판단하는 기준은 먼저, 해당 웹사이트가 `적절한 지 (relevant)`를 판단하고, 비슷하게 적절하다면 `더 높은 성능`을 가지고 있는 사이트를 사용자들에게 보여준다고 합니다. 22 | 23 |
24 | 25 | 아래 이미지는, 구글이 SEO가 잘 되어 있는 페이지인지 판단하는 지표 중 하나인 `Page experience signals`에 대한 발췌 이미지입니다. 26 | 27 | ![page exprience signals](https://user-images.githubusercontent.com/61097373/145543559-8e226623-8448-4afa-bdca-47617d00c47e.png) 28 | 29 | 이미지에서 알 수 있듯이, 구글이 사이트가 SEO가 잘 되어있는 지를 판단하기 위해서 `웹 성능을 지표로 사용하고 있다는 것`을 알 수 있었습니다. 30 | 31 |
32 | 33 | ### 인용 & 출처 34 | 35 | --- 36 | 37 | 참고한 자료들에서 글들을 발췌했습니다. 참고하면 좋을 것 같습니다. 38 | 39 | ## Speed is now a landing page factor for Google Search and Ads 40 | 41 | Both efforts recommend that site owners and developers pay attention to [user-centric performance metrics](https://developers.google.com/web/fundamentals/performance/user-centric-performance-metrics) and use tools such as [Lighthouse](https://developers.google.com/web/tools/lighthouse) and [PageSpeed Insights](https://developers.google.com/speed/pagespeed/insights), and real-world field data to diagnose and improve user experiences. 42 | 43 | ## Speed is now used as a ranking factor for mobile searches 44 | 45 | Users want to find answers to their questions quickly and [data](https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/) shows that people really care about how quickly their pages load. 46 | 47 | https://developers.google.com/web/updates/2018/07/search-ads-speed 48 | 49 | ## Understanding page experience in Google Search results 50 | 51 | Page experience is a set of signals that measure how users perceive the experience of interacting with a web page beyond its pure information value. 52 | 53 | ## Understand how page experience affects ranking 54 | 55 | in cases where there are many pages that may be similar in relevance, page experience can be much more important for visibility in Search. 56 | 57 | https://moz.com/learn/seo/page-speed 58 | 59 | https://developers.google.com/search/docs/advanced/experience/page-experience 60 | -------------------------------------------------------------------------------- /basic/10장-웹-최적화-실습하기/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 10 웹 최적화 실습하기 2 | 3 | 10.1 WebPageTest로 웹 성능 진단하기 4 | 5 | 10.1.1 WebPageTest 고급 기능 활용하기 6 | 7 | 10.1.2 WebPageTest의 최적화 진단 요소 8 | 9 | 10.1.3 WebPageTest API 활용하기 10 | 11 | 10.2 구글의 웹 최적화 기술 적용하기 12 | 13 | 10.2.1 Lighthouse 웹 사이트 측정 도구 14 | 15 | 10.2.2 PageSpeed 웹 성능 최적화 모듈 16 | 17 | 10.3 웹 사이트에 프로토콜 최적화 적용하기 18 | 19 | 10.3.1 프로토콜 최적화를 위한 조건 20 | 21 | 10.3.2 Let's Encrypt 인증서 발급 및 설치하기 22 | 23 | 10.3.3 Apache 웹 서버에 HTTP/2 적용하기 24 | 25 | 10.3.4 Nginx 웹 서버에 HTTP/2 적용하기 26 | 27 | 10.3.5 QUICHE 라이브러리를 사용한 HTTP/3 적용 28 | 29 | 10.4 다양한 조건에서 웹 성능 비교하기 30 | 31 | 10.4.1 Golang에서 제공하는 이미지 타일 서비스 32 | 33 | 10.4.2 WebPageTest를 사용한 웹 성능 비교 34 | 35 | 10.4.3 웹 성능 개선 결과 확인 36 | -------------------------------------------------------------------------------- /basic/1장-웹-성능이란-무엇인가/README.md: -------------------------------------------------------------------------------- 1 | # 1장 웹 성능이란 무엇인가 2 | 3 | ## 1.1 웹 4 | 5 | ### 1.1.1 웹의 역사 6 | 7 | ### 1.1.2 웹의 대표적인 요소 8 | 9 | ## 1.2 웹 성능이 중요한 이유 10 | 11 | ## 1.3 웹 성능 측정 방법 12 | 13 | ### 1.3.1 크롬 브라우저의 개발자 도구 14 | 15 | ### 1.3.2 WebPageTest 서비스 16 | 17 | ### 1.3.3 구글 PageSpeed 18 | 19 | ## 1.4 웹 성능을 만드는 지표 20 | 21 | ### 1.4.1 사용자 환경 - 프런트엔드 22 | 23 | ### 1.4.2 공급자 환경 - 백엔드 24 | 25 | ### 1.4.1 전달 환경 - 네트워크 26 | 27 | ## 1.5 웹 성능과 런트엔드 28 | 29 | ### 1.5.1 브라우저 렌더링 30 | 31 | ## 1.6 웹 성능 예산 32 | 33 | ### 1.6.1 정량 기반 지표 34 | 35 | ### 1.6.2 시간 기반 지표 36 | 37 | ### 1.6.3 규칙 기반 지표 38 | 39 | ### 1.6.4 성능 예산 활용 40 | 41 | -------------------------------------------------------------------------------- /basic/1장-웹-성능이란-무엇인가/rita.md: -------------------------------------------------------------------------------- 1 | ## 요약 2 | 3 | Why? 웹 로딩 속도가 느리면 서비스 사용자의 이탈률이 높아진다. 웹 성능이 비즈니스 성패를 좌우한다. 4 | 5 | How? 웹 성능 측정 방법과 웹 성능 예산 방법을 사용. 6 | 7 | What? 웹 성능 목표를 만드는 지표(ex. YSlow)와 웹 성능 예산 지표(정량,시간,규칙)를 통해 8 | 9 | 10 | 11 | 앞으로 이 책을 통해, 프런트엔드에서 웹 성능을 최적화하는 기법을 배운다. 12 | 13 | 14 | > 이 책에서 다루는 웹 최적화 기법도 프런트엔드에 많은 내용을 할당합니다. 24p 15 | 16 | ``` 17 | 이유 : 프런트엔드가 페이지 로딩 시간 중 대부분을 차지함 18 | - 사용자 관점에서 원하는 콘텐츠를 전달받았는지가 웹 성능의 기준이기 때문. 19 | - 웹 서버가 콘텐츠를 생산하는 시간 < 사용자와 상호작용하여 원하는 콘텐츠를 렌더링하는 시간 20 | ``` 21 | 22 | 23 | 24 | # 1. 웹 성능이란 무엇인가 25 | 26 | ## 1.1 웹 27 | 28 | 웹 == 인터넷일까? 29 | 30 | 동일하게 인식되기도 하지만, 웹은 인터넷이 제공하는 서비스 중 하나. 31 | 32 | - 인터넷 서비스의 종류 : 이메일, 메신저, 텔넷(원격연결), FTP 등 33 | 34 | ### 1.1.1 웹의 역사 35 | 36 | - 웹 등장 이전 : TCP/IP나 UDP를 이용한 클라이언트-서버간 네트워크 통신 또는 소켓 네트워크 기술을 사용하여 데이터를 교환함 37 | 38 | - 웹의 등장 : 페이지를 기반으로 다양한 정보를 문서읽듯 제공. 브라우저를 일종의 데이터베이스로 사용하여 필요한 정보를 조회/전달할 방법을 고안함. 39 | 40 | ``` 41 | 웹을 한 마디로 정의하면 42 | " 하이퍼 텍스트를 바탕으로 관련있는 문서끼리 연결할 문서의 집합체 " 43 | ``` 44 | 45 | - 하이퍼텍스트 : 텍스트를 뛰어넘는 다양한 콘텐츠를 아우르는 형식. 46 | 47 | --- 48 | 49 | - 서버의 역할 = 웹 서버 50 | 51 | TCP/IP 기술에서 고전적인 서버의 역할을 함. 문서 형식의 콘텐츠 정보를 전달 52 | 53 | - 클라이언트의 역할 = 브라우저 54 | 55 | 전달받은 페이지를 사용자가 볼 수 있는 화면에 출력하는 방식으로 서비스를 제공 56 | 57 | - 사용자 : 하이퍼링크를 통해 다른 페이지로 이동하거나 사용자의 정보를 입력해서 보낼 수 있음. 58 | 59 | --- 60 | 61 | - 최근 웹 동향 : 멀티미디어 기술이 더욱 발전, 보편화되면서 음성과 영상 콘텐츠뿐 아니라 VR, AR을 생산, 전달, 소비할 때도 사용 62 | 63 | 64 | 65 | ### 1.1.2 웹의 대표적인 요소 66 | 67 | 1. URL(Uniform Resource Locator) 68 | 69 | 2. 네트워크 프로토콜 70 | 71 | 주로 HTTP를 사용한다. 헤더에는 클라이언트와 서버 사이에 필요한 정보를 담고, 바디(페이로드)에는 HTML이나 이미지 같은 실제 데이터를 받음 72 | 73 | 3. HTML 74 | 75 | 웹 페이지에 실제로 나타낼 데이터를 정의하고 페이지 문서의 제목, 단락, 목록과 같은 구조를 표현하는 역할 76 | 77 | 그 외 Javascript, CSS 78 | 79 | ## 1.2 웹 성능이 중요한 이유 80 | 81 | - #### **웹 로딩 속도가 느리면 서비스 사용자의 이탈률이 높아진다.** 82 | 83 | 예시 : 웹사이트를 통해 수입을 만들어내는 온라인 쇼핑몰. 84 | 85 | 실제 사례 : 월 마트 웹사이트의 로딩 시간과 구매율의 상관관계 86 | 87 | 웹사이트와 매출이 직접적인 연관이 없는 서비스라고 해도, 기업의 이미지와 직결됨. 88 | 89 | - 용어 설명 : 웹 성능이란, 콘텐츠가 신속하게 전달되어 사용자가 원하는 서비스를 빠르게 전달받을 수 있도록 하는 시스템을 의미.(웹 사이트의 기능이나 내용을 의미하는 것이 아님.) 90 | 91 | - 웹 성능(Web performance)은 웹 로딩 시간(Web loading time) 92 | 93 | 브라우저 주소창에 도메인 주소를 입력하여 해당 사이트로 접속하고 웹 페이지가 로딩 되어 내용을 볼 수 있을 때까지 걸린 시간. 94 | 95 | - 3초의 법칙 : 3초 안에 웹 사이트에 접속한 사용자의 관심을 끌어야한다. (구글의 조사자료에 따르면 페이지가 3초 안에 로딩되지 않으면 53% 의 사용자가 떠난다.) 96 | 1. 웹사이트의 로딩이 빨라야한다. (웹 성능과 연관된 부분) 97 | 2. 웹사이트의 머리말이 주목받을 수 있어야한다. 98 | 3. 웹 페이지의 글이 눈에 띄어야한다. 99 | 4. 웹 페이지 내 사용자 행동이 필요한 부분은 명확이 전달해야한다. 100 | - 한국처럼 인터넷 전송속도가 빠른 나라에선 웹 성능 최적화(WPO, Web Performance Optimization)가 큰 관심을 받지 못했다. 그러나 **글로벌 서비스를 지향하며 많은 국가를 대상으로 프로젝트를 진행하는 경우 상대적으로 느린 인터넷 환경에 대비해야하기에**, WPO가 중요하다. 101 | 102 | 103 | 104 | ## 1.3 웹 성능 측정 방법 105 | 106 | 1. 웹 성능에 **영향을 주는 요소를 파악**해야한다. (사용자 환경, 공급자 환경, 전달 환경 등) 107 | - 사용자 입장 : 거주지역, 네트워크 장비(4G, 5G, Wi-fi 등), 브라우저 등 108 | - 공급자 입장 : DNS 네임 서버 응답 속도, 웹 서버 응답 속도, 웹 사이트의 백엔드 처리 속도, **프런트엔드 최적화 여부** 109 | - 전달 환경 : 웹 서버가 위치한 데이터 센터가 자체 전용선을 보유했는지, 유선망과 모바일망에 각각의 서버를 배포했는지 110 | 2. 이를 측정할 수 있는 **적절한 도구를 선택**해야한다. 111 | 112 | ### 1.3.1 크롬 브라우저의 개발자 도구 113 | 114 | 크롬 브라우저에서 F12로 실행 115 | 116 | Network 탭에서 **전체 HTTP 요청 수와 응답수**, 전달받은 콘텐츠 파일들의 크기, **DOMContentLoaded** 시간, **Load시간**, **로딩 완료 시간(Finish)**을 확인할 수 있음 117 | 118 | Waterfall차트는 어떤 콘텐츠 파일이 로딩 시간을 얼마나 소모했는지 시각적으로 나타낸다. 119 | 120 | ### 1.3.2 WebPageTest 서비스 121 | 122 | WPT는 세계 여러 위치에서 웹 사이트 로딩 속도를 테스트할 수 있는 무료 서비스. 123 | 124 | 실제 유선망이나 모바일 망의 네트워크, 다양한 기기, 브라우저를 세계 곳곳에 설치하여 실제 사용자 환경에서 테스트할 수 있게 함. 125 | 126 | 웹 성능에 영향을 주는 6개 항목이 잘 지켜지고 있는지 A~F점수로 알려줌. 127 | 128 | 1. First Byte Time : 웹 서버에서 받은 콘텐츠의 첫 번째 바이트가 얼마 만에 도착했는가? 129 | 2. Keep-Alive Enabled : TCP 연결을 재사용하기 위한 Keep-Alive가 설정되어 있었는가? 130 | 3. Compress Tranfer : 스크립트 파일이 Content-Encoding으로 압축되어 있었는가? 131 | 4. Compress Image : 이미지를 압축해 최적화했는가? 132 | 5. Cache Static content : 정적 파일에 브라우저 캐시가 설정되어 있었는가? 133 | 6. Effective use of CDN : CDN을 효과적으로 적용했는가? 134 | 135 | ### 1.3.3 구글 PageSpeed 136 | 137 | 웹 사이트 성능 개선을 돕기 위해 구글에서 개발한 서비스. 138 | 139 | - 모듈 **Mod_pagespeed** : Apache나 Nginx 웹 서버에 추가할수 있는 오픈소스 모듈. 140 | 141 | 웹 서버에 연동하여 CSS, JavaScript, HTML, 이미지 등의 성능 최적화를 수행함. 142 | 143 | 장점 : 원본 콘텐츠를 별도로 가공하여 저장할 필요없이 최적화된 모듈을 웹상에서 클라이언트에게 실시간으로 제공함. 설치 이후 자동으로 최적화 실행 144 | 145 | - 모듈 **PSI**(PageSpeed Insights) : 웹 사이트의 성능 최적화 요소를 평가하는 서비스를 제공. 146 | 147 | 1.3.2의 WebPageTest처럼 별도의 테스트지역이나 세세한 옵션을 선택할 순 없으나 PC와 모바일 환경의 웹 성능 테스트 결과를 심플하게 제공함. 148 | 149 | - **FCP**(First Contentful Paint) : 웹 페이지가 사용자에게 시각적 응답을 보인 시간 150 | - **DCL**(DOM Content Loaded) : 브라우저가 HTML 문서를 로딩 및 해석하는 시간을 측정한 값 151 | - FCP와 DCL메트릭스로 특정 웹 페이지의 성능을 알림. 두 메트릭스로 측정된 데이터들의 중간값으로 빠른 영역, 중간 영역, 느린 영역이 전체 콘텐츠 대비 몇 %인지 비교가능. 152 | 153 | ## 1.4 웹 성능을 만드는 지표 154 | 155 | 스티브 사우더스 (ITC, 2008) 156 | 157 | 사우더스는 14가지 웹 성능 최적화 기법을 백엔드, 프런트엔드, 네트워크 기술로 나누었다. 158 | 159 | 이후 야후는 이 항목들을 바탕으로 YSlow 서비스를 개발하여, 각 웹 성능 최적화 항목이 얼마나 잘 지켜지고 있는지 온라인에서 확인할 수 있도록 했다. (http://yslow.org/) 160 | 161 | ## Web Performance Best Practices and Rules 162 | 163 | 1. [Minimize HTTP Requests](http://developer.yahoo.com/performance/rules.html#num_http) 164 | 2. [Use a Content Delivery Network](http://developer.yahoo.com/performance/rules.html#cdn) 165 | 3. [Avoid empty src or href](http://developer.yahoo.com/performance/rules.html#emptysrc) 166 | 4. [Add an Expires or a Cache-Control Header](http://developer.yahoo.com/performance/rules.html#expires) 167 | 5. [Gzip Components](http://developer.yahoo.com/performance/rules.html#gzip) 168 | 6. [Put StyleSheets at the Top](http://developer.yahoo.com/performance/rules.html#css_top) 169 | 7. [Put Scripts at the Bottom](http://developer.yahoo.com/performance/rules.html#js_bottom) 170 | 8. [Avoid CSS Expressions](http://developer.yahoo.com/performance/rules.html#css_expressions) 171 | 9. [Make JavaScript and CSS External](http://developer.yahoo.com/performance/rules.html#external) 172 | 10. [Reduce DNS Lookups](http://developer.yahoo.com/performance/rules.html#dns_lookups) 173 | 11. [Minify JavaScript and CSS](http://developer.yahoo.com/performance/rules.html#minify) 174 | 12. [Avoid Redirects](http://developer.yahoo.com/performance/rules.html#redirects) 175 | 13. [Remove Duplicate Scripts](http://developer.yahoo.com/performance/rules.html#js_dupes) 176 | 14. [Configure ETags](http://developer.yahoo.com/performance/rules.html#etags) 177 | 15. [Make AJAX Cacheable](http://developer.yahoo.com/performance/rules.html#cacheajax) 178 | 16. [Use GET for AJAX Requests](http://developer.yahoo.com/performance/rules.html#ajax_get) 179 | 17. [Reduce the Number of DOM Elements](http://developer.yahoo.com/performance/rules.html#min_dom) 180 | 18. [No 404s](http://developer.yahoo.com/performance/rules.html#no404) 181 | 19. [Reduce Cookie Size](http://developer.yahoo.com/performance/rules.html#cookie_size) 182 | 20. [Use Cookie-Free Domains for Components](http://developer.yahoo.com/performance/rules.html#cookie_free) 183 | 21. [Avoid Filters](http://developer.yahoo.com/performance/rules.html#no_filters) 184 | 22. [Do Not Scale Images in HTML](http://developer.yahoo.com/performance/rules.html#no_scale) 185 | 23. [Make favicon.ico Small and Cacheable](http://developer.yahoo.com/performance/rules.html#favicon) 186 | 187 | ### 1.4.1 사용자 환경 - 프런트엔드 188 | 189 | 목적 : 빠르고 보기 쉽게 콘텐츠를 전달 190 | 191 | 역할 : 감각적인 디자인으로 더 많은 사용자들이 웹 사이트로 유입될 수 있도록 끌어들임, 콘텐츠를 보기 편하게 전달 192 | 193 | ### 1.4.2 공급자 환경 - 백엔드 194 | 195 | 백엔드는 사용자에게 보이는 프런트엔드 콘텐츠를 실제 생산하고 저장하여 네트워크를 통해 전달. 196 | 197 | 백엔드의 성능을 빠르게 알 수 있는 방법 : 구글 애널리틱스의 웹 성능과 속도 관련 서비스인 Speed 기능을 사용 198 | 199 | ### 1.4.1 전달 환경 - 네트워크 200 | 201 | 네트워크는 장소와 시간에 따라 속도가 변하기에 성능 측정이 어렵다. 202 | 203 | 네트워크 성능을 제약하는 두 가지 요소 : 대역폭(bandwidth), 지연시간(latency) 204 | 205 | - 대역폭 : 일정 시간에 처리할 수 있는 트래픽 양. 사용자가 갑작스레 증가하면 이에 영향을 받아 웹 콘텐츠의 전달 속도를 느리게 만들 수도 있다. 206 | - 지연시간 : 기술적 이유로 사용자에게 콘텐츠를 전달하지 못하고 지연되는 시간을 의미함. 인터넷상 다양한 환경에 영향을 받음 207 | 208 | 네트워크는 각 국가의 인터넷 서비스 사업자(ISP)가 제공하는 서비스를 사용한다. ISP 품질에 따라 대역폭과 지연 시간도 달라질 수 있다. 회사마다 유/무선망을 이용하는 사용자와 트래픽 증가에 따라 네트워크 장비 시스템 증설 투자 여부를 결정한다. 그러므로 보통 분기나 연도별로 평균값을 구하여 네트워크의 성능을 판단한다. 209 | 210 | ## 1.5 웹 성능과 프런트엔드 211 | 212 | 소프트웨어 공학에서의 백엔드(데이터 접근 영역), 프런트엔드(소프트웨어의 표시영역), 213 | 214 | 웹에서의 백엔드(사용자에게 제공하는 데이터를 생성,저장,전달), 프런트엔드(그 데이터를 요청하고 받아서 표현) 215 | 216 | - 프런트엔드가 페이지 로딩 시간 중 대부분을 차지함 217 | - 이유 : 사용자 관점에서 원하는 콘텐츠를 전달받았는지가 웹 성능의 기준이기 때문. 218 | - 웹 서버가 콘텐츠를 생산하는 시간 < 사용자와 상호작용하여 원하는 콘텐츠를 렌더링하는 시간 219 | 220 | ### 1.5.1 브라우저 렌더링 221 | 222 | 방법1 : 브라우저 렌더링 시 성능 지표를 PageSpeed로 살펴본다. 223 | 224 | 방법2 : 크롬 개발자 도구-Lighthouse 기능을 사용한다. 225 | 226 | 227 | 228 | ## 1.6 웹 성능 예산 229 | 230 | 웹 성능이 비즈니스 성패를 좌우하는 경우가 많다. 전자상거래와 같은 산업에서는 웹 성능 목표를 명확한 지표로 만들고 관리하는 것이 중요하다. 웹 성능을 계량할 수 있도록 수치화하여 기업의 목표로 삼을 때 '**웹 성능 예산**' 방법을 많이 사용한다. 231 | 232 | - **성능 예산**이란 : 웹 성능에 영향을 미치는 다양한 요소를 제어하는 한곗값을 의미. 웹 페이지의 파일 크기, 페이지 로딩시간, 페이지에 포함된 이미지 파일 수 등 다양한 값이 존재함. 233 | 234 | ### 1.6.1 정량 기반 지표 235 | 236 | - 정량 기반 지표 : 이미지, 스크립트, 폰트 등 웹 페이지 제작에 필요한 요소들에 대한 한곗값 237 | 238 | - 정량 기반 지표의 대표적 예시 239 | - 이미지 파일의 최대 크기 240 | - 최대 웹 폰트 파일 개수 241 | - 자바스크립트 파일 크기 합 242 | - 타사 스크립트 개수 합 243 | 244 | ### 1.6.2 시간 기반 지표 245 | 246 | 시간 기반 지표(timing based metrics)는 milestone timing이라고도 함. 247 | 248 | 정량 기반 지표의 단점을 보완하는 성능 예산이다. 249 | 250 | DOMContentLoaded, Load와 같이 브라우저에서 실제로 발생하는 다양한 웹 성능 이벤트 값을 측정하여 사용주가 느끼는 웹 성능에 대한 목표치를 설정하는 방식 251 | 252 | - 시간 기반 지표의 대표적 예시 253 | - **FCP**(First Contentful Paint) : 텍스트 또는 이미지와 같이 DOM의 첫 번째 비트를 표시하는 시점 254 | - **TTI**(Time to Interactive) : 페이지가 사용자 입력에 안정적으로 응답하는 데 걸리는 시간 255 | 256 | ### 1.6.3 규칙 기반 지표 257 | 258 | - 규칙 기반 지표의 대표적 예시 259 | - **WebPageTest**의 성능 점수 260 | - 구글 **Lighthouse**의 성능 점수 261 | - PageSpeed, WebPageTest, 구글의 Lighthouse 등이 제공하는 웹 성능 점수는 공신력있는 표준 점수이기 때문에 규칙 기반 지표에서 자주 사용됨. 262 | - 또는 사내에 자체적인 웹 성능 지표에 대한 테스트케이스를 만들고, 자동화 테스트 시스템을 통해 웹 사이트의 성능을 지표화하는 방식을 이용하기도 한다. 263 | - 정량 기반 지표와 시간 기반 지표를 개선할수록 규칙 기반 지표 점수는 높아진다. 264 | 265 | ### 1.6.4 성능 예산 활용 266 | 267 | 웹 기획자들이 사이트에 적합한 성능 예산이 어느정도 되는지 초기에 가늠하긴 어렵다. 따라서 일반적으로 **경쟁사 사이트나 비슷한 산업군의 대표적인 웹 사이트를 참고**함 268 | 269 | 가장 쉬운 접근 방법은 **아주 직관적이고 단순하게 성능 예산 목표치를 설정**하고 웹 사이트 설계와 개발을 시작하는 것이다. 270 | 271 | 웹 사이트는 업데이트가 잦기 때문에, 최근에는 **형상 관리 및 새로운 버전을 빌드한 후 배포 이전에 최종 성능 예산을 측정하고 관리하는 방법**도 사용한다. 구글 Lighthouse의 측정값을 빌드의 CI 단계의 테스트 케이스로 사용하는 것이 대표적인 예이다. 272 | 273 | -------------------------------------------------------------------------------- /basic/1장-웹-성능이란-무엇인가/tanney.md: -------------------------------------------------------------------------------- 1 | # 1장 웹 성능이란 무엇인가? 2 | 3 | ## 1.1 웹 4 | 5 |
6 | 7 | ### 웹 8 | 인터넷 상에서 하이퍼텍스트를 바탕으로 관련있는 문서끼리 연결한 집합체 9 | > 하이퍼텍스트
10 | > `참조`를 통해 한 문서에서 다른 문서로 접근할 수 있는 텍스트 11 | > 하이퍼텍스트 문서에는 단순 텍스트 뿐만 아니라 다양한 컨텐츠 형식을 담을 수 있다. 12 | 13 |
14 | 15 | ### 웹의 구성 요소 16 | 1. URL(Uniform Resource Location) 17 | - 웹 자원이 인터넷상 어느 위치(Location)에 존재하는지 알려주는 방법 18 | - 자원의 식별자(Identifier)인 URI의 한 종류 19 | - URL은 프로토콜, 도메인, 자원의 경로 등으로 이루어진다. 20 | 2. 네트워크 프로토콜 21 | - 주로 HTTP(HTTPS)를 사용 22 | - HTTP는 정보를 주고 받는 header와 실제 데이터를 주고 받는 payload(or body)로 이루어져 있다. 23 | 3. HTML(HyperText Mark-up Language) 24 | - tag를 사용해 다양한 컨텐츠를 브라우저에 보여주는 언어 25 | - 페이지 문서의 단락 등 구조를 표현하기도 한다. 26 | - 일반적으로 서버는 HTML문서를 브라우저에게 전달한다. 27 | 28 |
29 | 30 | ## 1.2 웹 성능이 중요한 이유 31 | 32 |
33 | 34 | - 웹 성능은 사용자에게 웹 컨텐츠나 서비스를 얼마나 빠르게 전달하는지에 대한 성능을 의미한다. 35 | - 웹 로딩 시간과 관련이 깊다. 36 | - 웹 로딩 시간은 실제 사용자들의 이탈률, 서비스 이용률 등에 영향을 준다. 37 | - 직접적으로 매출에 영형을 주지는 않아도 '느린 사이트'라는 인식은 좋지 못한 선입견을 갖게한다. 38 | - 일반적으로 3초 안에 로딩이 완료되는 것을 목표로 한다. 39 | - 글로벌 서비스의 경우 느린 네트워크 환경을 고려한 웹 성능 최적화를 고민해야한다. 40 | 41 |
42 | 43 | ## 1.3 웹 성능 측정 방법 44 | 45 |
46 | 47 | - 웹 성능을 측정하려면 성능에 영향을 주는 요소(사용자 환경, 공급자 환경, 전달 환경 등)를 파악하고 성능을 측정할 수 있는 도구를 선택해야한다. 48 | 49 |
50 | 51 | ### 성능에 영향을 주는 요소 52 | 1. 사용자 환경 53 | - 사용자의 거주 지역, 네트워크 환경, 브라우저 등 54 | 2. 공급자 환경 55 | - DNS 응답 속도, 웹 서버 응답 속도, 백엔드 처리 속도, 프론트엔드 최적화 여부 등 56 | 3. 전달 환경 57 | - 물리적인 네트워크 인프라 등 58 | 59 |
60 | 61 | ### 웹 성능 측정 도구 62 | 63 | 1. 크롬 브라우저 개발자 도구 64 | - 네트워크 탭에서 DOMContentLoaded시간, Load 시간 등과 각 리소스의 waterfall 등을 확인할 수 있다. 65 | 2. WebPageTest 서비스 66 | - 세계 여러 위치에서 로딩 속도를 테스트할 수 있는 서비스이다. 67 | - 실제 유선망, 모바일 망의 네트워크, 다양한 기기, 브라우저를 곳곳에 설치하여 실제 사용자 환경에서의 테스트를 제공한다. 68 | 3. 구글 PageSpeed 69 | - PSI(PageSpeed Insights) 모듈을 통해 성능 최적화 요소를 평가할 수 있다. 70 | - 여러 모듈을 통해 성능 최적화 자체를 수행할 수도 있다. 71 | 72 |
73 | 74 | ## 1.4 웹 성능 지표 75 | 76 |
77 | 78 | - 책 `웹 사이트 최적화 기법`의 저자 스티브 사우더스는 여러 성능 최적화 기법을 프론트엔드, 백엔드, 네트워크 기술로 구분하여 작성했다. 79 | ![웹최적화기법-스티브사우더스](https://user-images.githubusercontent.com/57767891/145177535-f4f05a39-14b5-4de4-a5a6-02d1e36835ec.jpeg) 80 | - 웹 성능 측정도구인 [YSlow](http://yslow.org/)에서는 위 항목을 바탕으로 웹 성능 지표를 정했다. 81 | 82 |
83 | 84 | ### 사용자 환경(프론트엔드)에서의 성능 85 | - 프론트엔드에서의 성능은 빠르고 보기 쉽게 컨텐츠를 전달하는지와 관련이 깊다. 86 | - 자세한 내용은 뒤에서 다루도록한다. 87 | - 1.3장에서는 프론트엔드를 공급자 환경으로 분류했던 것 같은데... 88 | 89 |
90 | 91 | ### 공급자 환경(백엔드)에서의 성능 92 | - 실제로 컨텐츠를 생산하고 저장하며 전달하는 일들에 대한 성능 93 | - 여러 언어로 구현되는 백엔드 서비스 자체 성능 뿐만 아니라 데이터베이스, 라우터, 네트워크 스위치 성능도 포함한다. 94 | 95 |
96 | 97 | ### 전달환경(네트워크) 98 | - 일반적으로 전달환경의 성능은 대역폭과 지연시간에 영향을 받는다. 99 | - ISP(Internet Service Provider)가 제공하는 품질에 의존한다. 100 | 101 |
102 | 103 | ## 1.5 웹 성능과 프론트엔드 104 | - 프론트엔드는 데이터를 표현하고 사용자가 입력한 데이터를 백엔드에 전달하기도 한다. 105 | - 프론트엔드의 성능은 사용자의 브라우저에서 측정한다. 106 | 107 |
108 | 109 | ### 브라우저 렌더링 시 성능 지표 110 | - FCP(First Contentful Paint): 첫 번째 텍스트 또는 이미시가 표시되는 데 걸린 시간 111 | - SI(Speed Index): 페이지 컨텐츠가 얼마나 빨리 표시되는지 ([참고](https://developer.mozilla.org/en-US/docs/Glossary/Speed_index)) 112 | - LCP(Largest Contentful Paint): 가장 큰 텍스트 또는 이미지가 표시된 시간 113 | - TTI(Time to Interactive): 사용자와 페이지가 상호작용할 수 있게 된 시간 114 | - TBT(Total Blocking Time): FCP와 TTI사이 모든 시간의 합 115 | - CLS(Cumulative Layout Shift): 표시영역 안에 보이는 요소들이 얼마나 이동하는지에 대한 정보 116 | 117 |
118 | 119 | ## 1.6 웹 성능 예산 120 | - 성능 예산이란 성능에 영향을 미치는 다양한 요소를 제어하는 한곗값을 의미한다. 121 | 122 |
123 | 124 | ### 정량 기반 지표 125 | - 이미지, 스크립트, 폰트 등 웹 페이지 제작에 필요한 요소들에 대한 한곗값이다. 126 | - 예를 들어 다음과 같은 요소를 포함한다. 127 | - 이미지 파일의 최대 크기 128 | - 최대 웹 폰트 파일 수 129 | - 자바스크립트 파일 크기 합 130 | - 타사 스크립트 수 131 | 132 |
133 | 134 | ### 시간 기반 지표 135 | - 단순히 정량 지표가 모든 성능을 좌우하지는 않는다. 같은 크기, 같은 수의 리소스라도 호출 시점에 따라 성능이 달라지기도한다. 136 | - 이를 보완하는 예산이 시간 기반 지표이다. 137 | - 시간 기반 지표는 실제 브라우저에서 발생하는 웹 성능 이벤트들(FCP, TTI 등)의 한곗값을 의미한다. 138 | 139 |
140 | 141 | ### 규칙 기반 지표 142 | - Lighthouse, WebPageTest 등의 성능 점수를 이용하는 방법 143 | - 점수를 통해 유사 사이트와 비교할 수도 있고, 어느 부분을 개선 포인트로 삼아야하는지도 발견할 수 있다. 144 | - 사내에서 자체적으로 웹 성능 지표에 대한 테스트 케이스를 만들고 자동화를 통해 성능을 지표화 하는 방식을 이용하기도 한다. -------------------------------------------------------------------------------- /basic/1장-웹-성능이란-무엇인가/yujo.md: -------------------------------------------------------------------------------- 1 | # 1. 웹 성능이란 무엇인가? 2 | 3 | ## 1.1 웹 4 | 5 | 웹은 인터넷의 대표적인 서비스 6 | 7 | ### 1.1.1 웹의 역사 8 | 9 | - 물리학자들 간 공동으로 연구를 진행하고 그 결과를 빠르게 공유하기 위해 팀 버너스 리 등이 개발 10 | - 기존에 이미 TCP/IP, UDP를 이용한 클라이언트-서버 간 네트워크 통신 또는 소켓 네트워크 기술이 존재했다. 그러나 웹 사이트라는 페이지를 기반으로 문자 뿐만 아니라 다양한 정보를 문서 읽듯 제공하고, 이를 읽을 수 있는 전용 프로그램인 브라우저를 일종의 데이터베이스로 사용해 필요한 정보를 조회하고 전달할 수 있는 방법 고안 11 | 12 | ### 1.1.2 웹의 대표적인 요소 13 | 14 | 1. URL 15 | - 웹 자원이 인터넷상 어느 위치에 존재하고 있는지 알려주는 방법 16 | 2. 네트워크 프로토콜 17 | - URL을 통해 알게 된 웹의 자원 위치에 접근하는 방식 18 | 3. HTML 19 | - 해당하는 콘텐츠를 사용자에게 쉽게 나타내기 위한 방법 20 | - 태그(tag)라는 명령어로 웹의 목적에 맞는 여러 기능 수행 21 | 22 | ## 1.2 웹 성능이 중요한 이유 23 | 24 | - 웹 성능이라는 용어는 웹 사이트의 기능이나 내용을 의미하는 것이 아니라, 콘텐츠가 신속하게 전달되어 사용자가 원하는 서비스를 빠르게 전달받을 수 있도록 하는 시스템들의 성능을 의미한다. 25 | - 웹 성능은 브라우저 주소창에 도메인 주소를 입력하여 해당 사이트에 접속하고 웹 페이지가 로딩되어 내용을 볼 수 있을 때까지 걸린 시간, 즉 웹 로딩 시간을 말한다. 26 | - 월마트 닷컴에서 연구한 결과 로딩 시간을 1초 줄이면 구매율이 약 2% 증가한다는 사실을 밝혔다. 또한 로딩이 2초 내에 완료 됐을 때 사용자의 구매가 가장 많았다. 27 | - 구글의 조사 자료에 따르면 페이지가 3초 안에 로딩되지 않으면 53%의 사용자가 떠나고 로딩 시간이 길어질수록 사용자 이탈률 역시 늘어난다고 한다. 28 | 29 | ## 1.3 웹 성능 측정 방법 30 | 31 | ### 1.3.1 크롬 브라우저 개발자도구 32 | 33 | ### 1.3.2 WebPageTest 서비스 34 | 35 | - https://www.webpagetest.org/ 36 | 37 | ### 1.3.3 구글 PageSpeed 38 | 39 | - https://pagespeed.web.dev/ 40 | 41 | 42 | 43 | ## 1.4 웹 성능을 만드는 지표 44 | 45 | - 스티브 사우더스의 14가지 웹 성능 최적화 기법 46 | 47 | | 최적화 | 내용 | 48 | | ---------- | ------------------------------------------------------------ | 49 | | 백엔드 | 1. Expiers 헤더를 추가한다.
2. gzip으로 압축한다.
3. 페이지 재전송을 피한다.
4. ETag를 설정한다.
5. 캐시를 지원하는 AJAX를 만든다. | 50 | | 프론트엔드 | 1. HTTP 요청을 줄인다.
2. 스타일 시트는 상단에 넣는다.
3. 스크립트는 하단에 넣는다.
4. CSS표현식은 피한다.
5. 자바스크립트와 CSS는 외부 파일에 넣는다.
6. 자바스크립트는 작게 한다.
7. 중복 스크립트는 제거한다. | 51 | | 네트워크 | 1. CDN을 사용한다.
2. DNS 조회를 줄인다. | 52 | 53 | ## 1.5 웹 성능과 프런트엔드 54 | 55 | - 프론트엔드가 페이지 로딩 시간 중 대부분을 차지하는 이유는 웹 서버가 아닌 '사용자 관점에서 원하는 콘텐츠를 전달받았는지'가 웹 성능의 기준. 56 | 57 | ## 1.6 웹 성능 예산 58 | 59 | ### 1.6.1 정량 기반 지표 60 | 61 | - 이미지 파일의 최대 크기 62 | - 최대 웹 폰트 파일 개수 63 | - 자바스크립트 파일 크기 합 64 | - 타사 스크립트 개수 합 65 | 66 | ### 1.6.2 시간 기반 지표 67 | 68 | - FCP(First Contentful Paint) 69 | - TTI(Time to Interactive) 70 | 71 | ### 1.6.3 규칙 기반 지표 72 | 73 | - WebPageTest의 성능 점수 74 | - 구글 Lighthouse의 성능 점수 75 | -------------------------------------------------------------------------------- /basic/2장-웹-최적화/README.md: -------------------------------------------------------------------------------- 1 | # 2장 웹 최적화 2 | ## 2.1 웹 최적화란 3 | ### 2.1.1 프런트엔드 최적화 4 | ### 2.1.2 백엔드 최적화 5 | ### 2.1.3 프로토콜 최적화 6 | ## 2.2 TCP/IP 프로토콜 7 | ### 2.2.1 TCP 혼잡 제어 8 | ## 2.3 HTTP 프로토콜 9 | ### 2.3.1 HTTP 최적화 기술 10 | ### 2.3.2 HTTP 지속적 연결 11 | ### 2.3.3 HTTP 파이프라이닝 12 | ## 2.4 DNS 13 | ### 2.4.1 DNS의 작동 원리 14 | ### 2.4.2 사용 중인 다양한 도메인 확인 방법 15 | ### 2.4.3 웹 성능을 최적화하는 도메인 운용 방법 16 | ## 2.5 브라우저 17 | ### 2.5.1 브라우저의 역사와 특징 18 | ### 2.5.2 내비게이션 타이밍 API 19 | ### 2.5.3 내비게이션 타이밍 속성 20 | ### 2.5.4 내비게이션 타이밍 속성값 구하기 21 | -------------------------------------------------------------------------------- /basic/2장-웹-최적화/rita.md: -------------------------------------------------------------------------------- 1 | # 2장 웹 최적화 2 | 3 | 웹사이트에 검색 엔진 최적화(Search Engine Optimization, SEO)를 실행한다. 4 | 5 | SEO가 적용된 웹 사이트는 다른 사이트에 비해 상단 노출 회수가 높다 -> 많은 방문자를 이끌어낸다. 6 | 7 | ## 2.1 웹 최적화란 8 | 9 | 최고의 성능을 만드는 최적화 조건을 갖추는 것. 세가지가 있다. 10 | 11 | ### 2.1.1 프런트엔드 최적화 12 | 13 | - 웹 UI/UX와 관련된 최적화 14 | 15 | HTML, JavaScrip, CSS, Image fil, 타사 파일 자체의 모음들이 콘텐츠를 만들어낼 때 최적화를 진행함. 16 | 17 | FE 최적화가 잘 된 사이트는 브라우저에서 콘텐츠를 다운로드, 로딩, 렌더링할 때 속도가 빠르다. 18 | 19 | - FE 최적화 기술은 사용자 환경에 따라 달라진다. 20 | 21 | 사용자의 기기, 네트워크 속도와 품질, 브라우저 등 상대적임. 22 | 23 | 따라서 어떤 경우에 성능이 저하되는지 파악하고 조치를 취해야함. 24 | 25 | - FE 최적화 기술의 예 26 | 27 | - 스크립트를 병합(merge)하여 브라우저의 호출 개수를 줄임 28 | - 스크립트 크기를 최소화해 바이트(byte) 자체를 줄임 29 | - 스크립트를 gzip 등으로 압축하여 전달 30 | - WebP 등으로 브라우저 이미지 형식을 최적화 31 | 32 | - 이미지 손실, 무손실 압축 33 | - Cache-Control 응답 헤더를 통해 브라우저 캐시를 충실히 사용 34 | - 도메인 수를 줄여 DNS 조회를 최소화 35 | - DNS 정보 미리 읽어 오기 36 | - CSS를 HTML 상단에, 자바스크립트를 HTML의 하단에 위치시키기 37 | - 페이지 미리 읽어 오기(page prefetching) 38 | - 타사 스크립트가 웹 성능을 방해하지 않도록 조정 39 | 40 | ### 2.1.2 백엔드 최적화 41 | 42 | - 웹 UI를 로직에 맞게 만듬 43 | - 백엔드 : 웹 서버, 웹 애플리케이션 서버, 데이터베이스, 로드 밸런싱, DNS 서버 등 44 | - BE 최적화의 목표 : 이 시스템들을 튜닝해 정상 출력을 만드는 것 45 | - BE 최적화는 FE에 비해 가시적 효과가 크지 않지만 웹사이트의 빠른 로딩보다 네트워크를 정상적으로 사용하고 콘텐츠를 전달하기 위해 반드시 필요한 요소 46 | - BE 최적화의 예 47 | - DNS 응답이 빨라지도록 서버 증설 48 | - DNS 응답을 빠르게 할 수 있도록 DNS 정보를 최대한 캐싱 49 | - 웹 서버가 있는 데이터 센터의 네트워크 출력(throughput)/대역폭(bandwidth) 증설 50 | - 웹 서버, 웹 애플리케이션 서버의 CPU/RAM 증설 51 | - 프록시 서버를 설정하여 웹 콘텐츠를 캐싱 52 | - CDN(Content Delivery Network)을 사용해 인터넷상에 콘텐츠 캐싱 53 | - 데이터베이스 정규화로 디스크 I/O 최적화 54 | - 데이터베이스 캐싱으로 응답을 빠르게 55 | - 로드 밸런싱을 통해 가장 성능이 좋은 웹 서버로 요청을 연결 56 | - 웹 애플리케이션 로직을 가볍고 빠르게 개발 57 | 58 | ### 2.1.3 프로토콜 최적화 59 | 60 | 웹 콘텐츠를 전달하는 HTTP/HTTPS 프로토콜 자체의 효과를 극대화하면 웹 서버가 클라이언트에게 콘텐츠를 최대 속도와 최저 지연 시간으로 전달할 수 있다. 61 | 62 | 프로토콜 최적화 : 웹 콘텐츠를 더 빠르게 요청하고 응답하도록 프로토콜을 업그레이드하는 과정이다. 63 | 64 | ## 2.2 TCP/IP 프로토콜 65 | 66 | 웹은 TCP/IP 프로토콜의 일종인 HTTP를 사용해 콘텐츠를 전달한다. 67 | 68 | - **TCP/IP 프로토콜** : OSI 7계층 중 4번째 전송계층에 속함 69 | 70 | 전송 계층 : 네트워크상에서 송신자와 수신자 사이에 데이터 전송을 보장하는 역할 71 | 72 | - **HTTP** : 7번째 응용계층에 속함 73 | 74 | 응용 계층 : 메일, FTP, 인터넷 등 실제 네트워크상에서 SW와 사용자의 상호 연동을 담당함 75 | 76 | - 전송과 응용 계층은 독립적인 것이 아니라 상위 계층인 응용 계층이 하위 계층인 전송 계층을 바탕으로 운용되는 구조 77 | 78 | - TCP 네트워크를 사용하는 네트워크에 있어 대표적인 성능 지표 : 대역폭, 지연 시간 79 | 80 | - **대역폭** : 특정 시간동안 얼마나 많은 네트워크 트래픽을 보낼 수 있는지. 시간당 전송량 81 | 82 | 예) 크기가 큰 이미지 파일을 다운로드하려면 완료시간은 클라이언트와 서버 사이 대역폭에 영향을 받음 83 | 84 | - 지연 시간 : 클라이언트와 서버간 콘텐츠를 전달하는 물리적인 시간 85 | 86 | 클라이언트와 서버 사이 요청, 전달, 응답까지 걸리는 시간. 87 | 88 | 예) 브라우저가 콘텐츠를 해석하고 화면에 렌더링하는 단계는 클라이언트 측에서만 실행되므로 지연 시간에 포함되지 않음. 89 | 90 | - RTT(Round Trip Time) : 서버와 클라이언트 두 호스트를 모두 왕복하는 데 걸리는 지연 시간 91 | 92 | 게임, 화상 채팅 등의 품질에 영향을 줌. 93 | 94 | 예) 스트리밍 서비스 회사는 지연시간이 길고 짧음에 따라 전달받는 영상 파일의 품질을 조절하여 버퍼링을 줄일 수 있는 가변 스트리밍 방식(adaptive streaming)을 사용함 95 | 96 | ### 2.2.1 TCP 혼잡 제어 97 | 98 | 성능 저하 요소를 해결하는 TCP의 기술을 알아보자. 99 | 100 | #### 문제 101 | 102 | - **TCP 혼잡제어**(congestion control)는 TCP 네트워크의 통신량을 조절하여 TCP 네트워크가 혼잡해지지 않도록 하는 방식 103 | 104 | - **TCP 혼잡 붕괴**(congestion collapse)는 TCP 네트워크의 통신량이 실제 처리량보다 많아서 문제가 발생하는 것 105 | 106 | 인터넷에 연결된 호스트들이 최대한 많은 정보를 전송하려고 많은 네트워크 패킷을 보내기 때문에 발생함 107 | 108 | #### 해결 109 | 110 | - **TCP 혼잡 제어 기술** 111 | 112 | 패킷을 보내는 쪽에서 네트워크에서 수용할 수 있는 양을 파악, 그만큼의 패킷만 보내는 약속으로 해결 113 | 114 | 받는 쪽은 패킷이 정상적으로 송신되었음을 알리는 ACK 패킷을 보냄 115 | 116 | ACK 패킷을 받은 호스트는 지속적으로 패킷을 보낼 수 있음 117 | 118 | 처음부터 네트워크가 얼만큼의 패킷을 수용할 수 있는지 정확히 파악하는 것은 어렵고, 그 값도 시간에 따라 변함. 따라서 호스트가 네트워크의 상태를 파악하고 전송 속도를 조절하는 것 또한 혼잡 제어 기능 중 하나. 119 | 120 | - 혼잡 제어의 대표 기술 121 | 122 | - **느린 시작**(slow start) : TCP 연결이 시작되면 전송 가능한 버퍼의 양인 혼잡 윈도우(Congestion Window, CWND)의 초기값을 작게 설정하여 전송. 패킷이 정상도착할 때마다 더 많은 패킷을 보냄. 패킷 유실이 발생하기 전까지 반복. 123 | 124 | 즉, 초기에 적은 패킷을 보내면서 곱셈 방식으로 전송 패킷의 크기를 빠르게 늘림 125 | 126 | - **빠른 재전송**(fast retransmit) : 먼저 도착해야하는 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 수신자가 일단 ACK패킷을 보냄 127 | 128 | - **흐름 제어**(flow control) : TCP 송신자가 데이터를 너무 빠르게 혹은 너무 많이 전송하여 수신자의 버퍼가 오버플로되는 현상을 방지 129 | 130 | ## 2.3 HTTP 프로토콜 131 | 132 | HyperText Transfer Protocol 133 | 134 | 텍스트 이상 콘텐츠들을 웹에서 전달하기 위해 만들어진 프로토콜. 135 | 136 | 웹은 HTTP 프로토콜을 통해 전달되므로 HTTP 성능을 개선하면 웹 성능도 향상된다. 137 | 138 | ### 2.3.1 HTTP 최적화 기술 139 | 140 | ~ HTTP/0.9 버전까지는 클라이언트와 서버의 인터넷 통신 정상화, 가용성, 신뢰성 등에 초점을 두었음 141 | 142 | HTTP/1.0버전부터는 클라이언트와 서버 사이 요청과 응답을 빠르게 할 수 있는 연구가 진행됨. 143 | 144 | 웹이 멀티호스트 환경으로 변하면서, HTTP/1.1버전부터 **멀티호스팅 기능**과 클라이언트와 서버 사이에서 TCP/IP 연결을 재사용하는 기능을 추가하였다. **연결 재사용, 파이프라이닝 기법** 등. 145 | 146 | ### 2.3.2 HTTP 지속적 연결 147 | 148 | - 초기 버전 : 통신을 통해 여러 오브젝트를 요청하고 응답하려면 3-way handshake 방식으로 TCP연결을 함 149 | 150 | 3-way handshake 방식 : 클라이언트와 서버 사이 SYN, SYN-ACK, ACK의 3번의 요청과 응답으로 이루어짐 151 | 152 | 장점 : 송신자와 수신자 사이 신뢰성, 안전한 통신을 추구하는 TCP 알고리즘 153 | 154 | 문제점 : 동시에 많은 웹 콘텐츠를 전달해야하는 HTTP 통신에서 번거로움이 발생 155 | 156 | - 지속적 연결 기술의 등장 157 | 158 | 클라이언트와 서버가 TCP상에서 한 번 연결되면 둘 사이의 연결이 완전히 끊어지기 전까지 맺어진 연결을 지속적으로 재사용하는 기술 159 | 160 | HTTP request header에 Connection 헤더, keep-alive 속성으로 지속적인 연결을 요청 161 | 162 | HTTP/1.0 RFC의 규약이 됨 163 | 164 | HTTP/1.1 버전에서는 Connection 헤더를 사용하지 않아도 모든 요청과 응답이 HTTP 지속적 연결을 기본으로 지원함. HTTP 응답이 완료되거나 TCP 연결을 끊어야할 때만 Connection 헤더를 사용함. 165 | 166 | - 멀티플렉싱 기술의 등장 167 | 168 | HTTP/2 버전은 단일 TCP 연결을 통해 클라이언트와 서버 사이 응답 지연없이 스트림형태로 다수의 HTTP 요청과 응답을 주고받을 수 있음 169 | 170 | ### 2.3.3 HTTP 파이프라이닝 171 | 172 | - 배경 : HTTP 선입 선출의 단점을 극복하자 173 | 174 | HTTP 요청과 응답이 여럿일때, 하나의 응답이 지연되면 나머지 요청과 응답 모두 지연되었음. 175 | 176 | - HTTP 파이프라이닝 : 먼저 보낸 요청의 응답이 없어도 다음 요청을 병렬적으로 수신자 측에 전송하는 기술 177 | 178 | 중간에 응답 지연이 발생하더라도 클라이언트는 먼저 서버 측의 응답을 받을 수 있어 빠른 웹 로딩이 구현되는 구조 179 | 180 | ## 2.4 DNS 181 | 182 | DNS : 인터넷 호스트명을 클라이언트와 서버가 이해할 수 있는 IP 주소로 변환해주는 시스템 183 | 184 | DNS 질의와 응답 성능이 나쁘면 웹 사이트 로딩에 영향을 주기 때문에 운영하는 웹 사이트 호스트명의 DNS 질의를 파악하고 개선해야한다. 185 | 186 | ### 2.4.1 DNS의 작동 원리 187 | 188 | 도메인을 IP 주소로 질의하여 값을 받아오는 과정에는 도메인 구조 계층에 따라 각각의 DNS 서버들이 관여함 189 | 190 | 반복적 질의 (iterative query) : 계층형으로 나누어진 역할에 따라 순차적인 DNS 질의를 반복하여 값을 받아오는 프로세스 과정 191 | 192 | ### 2.4.2 사용 중인 다양한 도메인 확인 방법 193 | 194 | - 크롬 개발자 도구-Source 항목 195 | 196 | 하나의 웹 페이지에서 어떤 도메인들이 사용되고 있는지 파악할 수 있음. 197 | 198 | 해당 페이지에서 사용중인 모든 도메인 호스트명 리스트와 그 도메인에서 어떤 콘텐츠를 가져왔는지 확인가능함. 199 | 200 | ### 2.4.3 웹 성능을 최적화하는 도메인 운용 방법 201 | 202 | - 많은 도메인 호스트명을 사용하면 DNS 질의가 늘어나 응답시간이길어지고 웹 성능에 영향을 줌 203 | 204 | 직접 개발한 내부 서비스에 도메인 분할을 하고 싶다면 상위 도메인을 동일하게 해 DNS 질의를 최대한 적게 만드는 것을 권장 205 | 206 | - 공통된 상위 도메인을 사용하는 서비스들은 도메인 질의를 담당하는 네임 서버에 캐싱된 정보를 재사용할 수 있어 DNS 질의 시간을 단축시킴 207 | 208 | 동일한 상위 도메인을 사용하면 HTTPS 사용을 위한 SSL 인증서를 와일드카드 형식으로 하나만 생성해도 모든 도메인에 사용가능 209 | 210 | - HTML의 DNS 프리페치(prefetch) 기능을 사용하면 웹 페이지에 사용된 도메인들의 DNS를 조회하는 시간이 개선됨 211 | 212 | DNS 프리페치 : 하나의 웹 페이지에 다수의 도메인 호스트명이 섞여 있을 때 웹 문서 페이지를 여는 시점에 멀티스레드 방식으로 미리 DNS를 조회해 빠르게 IP주소를 불러오는 기술 213 | 214 | ``` 215 | 216 | 217 | ``` 218 | 219 | link 태그의 지시자 구문에 'dns-prefetch'라는 명령어를 사용해 페이지 상단에서 미리 DNS를 조회하면 브라우저는 웹 콘텐츠를 다운로드함과 동시에 DNS를 조회하여 성능이 개선된다. 220 | 221 | ## 2.5 브라우저 222 | 223 | HTTP,DNS를 사용해 사용자가 원하는 HTML,이미지,오디오,동영상 등의 웹 콘텐츠를 전달하는 소프트웨어. 224 | 225 | ### 2.5.1 브라우저의 역사와 특징 226 | 227 | 브라우저는 1990년 초반 웹이 만들어진 시대에 함께 개발되었다. 228 | 229 | - 넷스케이프, MS의 인터넷 익스플로러와 브라우저 전쟁 230 | 231 | - HTML5와 CSS3.0의 등장 232 | 233 | ### 2.5.2 내비게이션 타이밍 API 234 | 235 | 웹 사이트의 성능을 측정하는 데 사용할 수 있는 데이터를 제공함. 종단간 대기 시간 정보를 제공함. 236 | 237 | 이전까지는 브라우저의 자바스크립트 기능을 이용해 웹 페이지가 열리는 시간과 로딩이 완료되는 시간 차이를 계산함으로써 웹 로딩 시간을 구할 수 있었음. -------------------------------------------------------------------------------- /basic/2장-웹-최적화/tanney.md: -------------------------------------------------------------------------------- 1 | # 2 웹 최적화 2 | 3 | ## 2.1 웹 최적화란 4 | 5 |
6 | 7 | - 최고의 웹 성능을 구현하기 위해 최고의 조건을 만드는 다양한 노력 8 | - 웹 최적화는 프론트엔드 최적화, 백엔드 최적화, 프로토콜 최적화 세 가지로 나뉜다. 9 | 10 |
11 | 12 | ### 프론트엔드 최적화 13 | 14 |
15 | 16 | - 프론트엔드 최적화는 리소스의 로딩, 렌더링과 관련이 있다. 17 | - 사용자의 기기, 네트워크 품질, 브라우저 등에 따라 상대적으로 적용해야 한다. 18 | - 프론트엔드 최적화에는 대표적으로 다음과 같은 방법이 있다. 19 | - 스크립트를 병합하여 네트워크 호출 수를 줄인다. 20 | - 스크립트, 이미지 등 리소스의 크기를 줄인다. 21 | - 캐싱을 활용한다. 22 | - DNS 조회를 최소화한다. 23 | - 페이지 prefetching 24 | 25 |
26 | 27 | ### 백엔드 최적화 28 | 29 |
30 | 31 | - 웹 서버, 데이터 베이스, 로드 밸런싱, DNS 서버 등에 대한 최적화 32 | - 백엔드 최적화에는 대표적으로 다음과 같은 방법이 있다. 33 | - 서버 증설 34 | - 캐싱 35 | - 데이터베이스 정규화 36 | - 로드밸런싱 37 | 38 |
39 | 40 | ### 프로토콜 최적화 41 | 42 |
43 | 44 | - HTTP/HTTPS 프로토콜의 자체 효과를 극대화하면 리소스를 최대 속도, 최저 지연 시간으로 전달할 수 있다. 45 | - 이를 위해 프로토콜을 업그레이드 하는 과정이 프로토콜 최적화이다. 46 | 47 |
48 | 49 | ## 2.2 TCP/IP 프로토콜 50 | 51 |
52 | 53 | - 웹에서 사용하는 프로토콜인 HTTP는 TCP/IP 프로토콜의 일종이다. 54 | - TCP 네트워크를 사용하는 대표적인 성능 지표는 대역폭과 지연 시간이다. 55 | - 대역폭은 단위 시간동안 보낼 수 있는 트래픽의 양을 의미한다. 56 | - 지연시간은 리소스를 전달하는 물리적인 시간을 의미한다. 57 | - 요청이 두 호스트를 왕복하는 데 걸리는 시간을 RTT(Round Trip Time)이라고 한다. 58 | 59 |
60 | 61 | ### TCP 혼잡 제어 62 | 63 |
64 | 65 | - TCP 혼잡제어는 통신량을 조절해 TCP 네크워크가 혼잡해지지 않도록 하는 방식을 의미한다. 66 | - TCP 네트워크의 통신량이 실제 처리량보다 많으면 TCP 혼잡 붕괴 현상이 나타난다. 67 | - TCP 혼잡 제어 기술은 패킷 송신측이 네트워크에서 수용할 수 있는 양을 파악하는 방식으로 혼잡을 해결한다. 68 | - 시시각각 편하는 네트워크 상태를 파악하는 혼잡제어 기술에는 다음이 있다. 69 | 1. 느린 시작 70 | - TCP 연결이 시작되면 혼잡 윈도우(전송 가능한 버퍼의 양)의 초깃값을 작게 설정하여 전송한다. 71 | - 패킷이 정상적으로 도착할 때마다 곱셈방식으로 더 많은 패킷의 양을 늘린다. 72 | - 패킷 유실이 발생하기 전까지 이를 반복한다. 73 | - 이를 통해 혼잡 윈도우의 크기를 파악하면 그 이상의 패킷을 보내지 않는다. 74 | 2. 빠른 재전송 75 | - 순서상 먼저 도착해야하는 패킷이 도착하지 않으면 순서대로 잘 도착한 마짐가 패킷의 다음 순번을 ACK 패킷에 실어 보낸다. 76 | - 이러한 중복 ACK를 3번 받으면 재전송이 이루어진다. 77 | - 기본적으로 TCP 통신의 송신측은 설정된 타임아웃까지 ACK를 받지 못하면 혼잡이 발생한 것으로 파악한다. 78 | - 빠른 재정송은 타임아웃이 되지 않았어도 패킷을 재전송해 빠른 전송률을 유지하는 방법이다. 79 | 3. 흐름 제어 80 | - 송신자가 데이터를 너무 빠르게 혹은 너무 많이 전송해 수신자의 버퍼가 오버플로우 되는 현상을 방지하는 기술이다. 81 | - 수신 속도를 송신 속도와 일치시키는 기술이다. 82 | - stop and wait, sliding window 등의 방법이 사용된다. 83 | 84 |
85 | 86 | ## 2.3 HTTP 프로토콜 87 | 88 |
89 | 90 | - HTTP/1.1 버전부터 TCP/IP 연결 재사용과 파이프라인 기법이 적용되었다. 91 | 92 |
93 | 94 | ### HTTP 지속적 연결 95 | 96 |
97 | 98 | - TCP의 3-way handshake 방식의 연결로 안정성을 추구할 수 있지만 많은 요청을 주고 받아야하는 경우에는 로딩 시간에 영향을 줄 수 있다. 99 | - '지속적 연결'은 TCP 연결을 재사용하는 기술이다. 100 | - HTTP Connection헤더에 'keep-alive' 속성을 추가해 지속적 요청을 서버에 요청할 수 있다.(HTTP/1.0) 101 | - HTTP/1.1 에서는 Connection헤더를 사용하지 않아도 기본적으로 지속적 연결을 지원한다. 102 | - 따라서 TCP 연결을 끊어야할 때만 Connection헤더를 사용한다. (Connection: close) 103 | - 서버와 TCP 연결을 유지하는 클라이언트를 무한정 늘릴 수는 없다. 104 | - 따라서 메인페이지와 같이 많은 사용자가 접속하는 페이지에서는 지속적 연결 여부를 고려해봐야한다. 105 | - 멀티플렉싱 기술이 적용된 HTTP/2에서는 지속적 연결을 고민할 필요가 없다고 한다.(자세한 내용은 추후..) 106 | 107 |
108 | 109 | ### HTTP 파이프라이닝 110 | 111 |
112 | 113 | - 먼저 보낸 요청에 대해 응답이 없어도 다음 요청을 병렬적으로 전달하는 기술이다. 114 | 115 |
116 | 117 | ## 2.4 DNS 118 | 119 |
120 | 121 | - DNS의 질의, 응답 성능이 사이트 로딩 성능에 영향을 준다. 122 | 123 |
124 | 125 | ### DNS 작동원리 126 | 127 |
128 | www.tanney.com을 질의한다고 가정하자 129 |
130 | 131 | 1. 로컬 DNS 서버로 질의 132 | - 로컬 DNS는 사용자가 수동으로 설정한 DNS의 IP 혹은 ISP의 인근 서버이다. 133 | - 브라우저는 가장 먼저 로컬 DNS에 질의한다. 134 | - 만약 캐싱된 IP 주소가 있고 캐싱 주기가 남아있다면 이를 반환한다. 135 | 2. 루트 DNS 서버로 질의 136 | - 로컬에 캐싱된 정보가 없거나 캐싱 주기가 지났다면 로컬 DNS는 루트 DNS에 질의를 한다. 137 | - 루트 DNS는 .com 도메인 서버의 IP를 알려준다. 138 | 3. .com DNS 서버로 질의 139 | - 로컬 DNS는 .com DNS에 질의한다. 140 | - .com DNS는 tanney.com DNS의 IP를 알려준다. 141 | 4. tanney.com DNS 서버로 질의 142 | - 로컬 DNS는 tanney.com DNS에 질의한다. 143 | - www.tanney.com의 IP를 알려준다. 144 | 145 |
146 | 147 | - 이와 같이 IP주소를 질의하는 과정은 도메인 구조 계층에 따라 각각의 DNS 서버에 질의하는 '반복적 질의'의 과정을 따른다. 148 | - DNS 전문 업체의 서비스를 받거나 분산된 DNS 서버를 직접 운영하는 방식으로 성능을 향상시킬 수 있다. 149 | - 타사의 서비스를 이용할 경우 해당 도메인 서버 성능에 영향을 받는다. 150 | - DNS 질의를 할 도메인 수 자체를 줄이는 것도 방법이다. 151 | 152 |
153 | 154 | ### DNS 최적화 155 | 156 |
157 | 158 | - 자체 서비스들의 경우 상위 도메인을 동일하게 해 DNS 질의를 최대한 적게 만드는 것이 좋다. 159 | - HTML의 DNS prefetch 기능을 사용할 수도 있다. 160 | 161 |
162 | 163 | ## 2.5 브라우저 164 | 165 |
166 | 167 | ### 네비게이션 타이밍 API 168 | 169 |
170 | 171 | - 웹 사이트의 성능을 측정하는 데 사용하는 데이터를 제공한다. 172 | - window.performance 객체를 통해 사용할 수 있다. -------------------------------------------------------------------------------- /basic/2장-웹-최적화/yujo.md: -------------------------------------------------------------------------------- 1 | # 2장 웹 최적화 2 | 3 | ## 2.1 웹 최적화란 4 | 5 | - 웹 최적화란 최고의 웹 성능을 구현하기 위해 최고의 조건을 만드는 다양한 노력을 의미 6 | 7 | ### 2.1.1 프런트엔드 최적화 8 | 9 | - 스크립트 병합으로 브라우저 호출 개수 줄임 10 | - 스크립트 크기를 최소화 함 11 | - 스크립트를 gizp 등으로 압축하여 전달 12 | - WebP 등으로 이미지 최적화 13 | - 이미지 손실, 무손실 압축 14 | - Cache-Control 헤더를 통해 브라우저 캐시 충실히 사용 15 | - 도메인 수를 줄여 DNS 요청 최소화 16 | - DNS 정보 미리 읽어 오기 17 | - CSS를 HTML 상단에, JS를 HTML 하단에 위치 18 | - 페이지 미리 읽어오기 (page prefetching) 19 | 20 | ### 2.1.2 백엔드 최적화 21 | 22 | - DNS 응답을 빠르게 하기 위한 서버 증설 23 | - DNS 응답을 빠르게 하기 위한 DNS 캐싱 24 | - 네트워크 출력/대역폭 증설 25 | - CDN 사용 26 | - DB 정규화 27 | - 로드 밸런싱 28 | 29 | ## 2.2 TCP/IP 프로토콜 30 | 31 | ### 2.2.1 TCP 혼잡 제어 32 | 33 | - TCP 혼잡 제어는 TCP 네트워크의 통신량을 조절하여 TCP 네트워크가 혼잡해지지 않도록 하는 방식을 의미. 34 | - TCP 네트워크의 통신량이 실제 처리량보다 많아서 문제가 발생하는 것을 TCP 혼잡 붕괴라고 한다. 35 | - TCP 혼잡 제어 기술은 패킷을 보내는 쪼에서 네트워크에서 수용할 수 있는 양을 파악하고 그만큼의 패킷만 보내는 약속으로 TCP 혼잡을 해결합니다. 36 | 37 | **느린 시작** 38 | 39 | - 느린 시작은 TCP연결이 시작되면 버퍼의 양인 혼잡 윈도우의 초기값을 작게 설정하여 전송. 40 | - 최초 패킷을 1개만 보내고 패킷의 정상 수신 응답인 ACK를 받으면 처음 보낸 패킷의 2배인 2개 패킷을 전송. 41 | - 즉, 패킷이 정상적으로 도착할 때마다 더 많은 패킷을 보내고, 패킷 유실이 발생하기 전까지 반복하는 방식 42 | 43 | **빠른 재전송** 44 | 45 | - 1먼저 도착해야 하는 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 수신자가 일단 ACK 패킷을 보내는 방식. 46 | - 중간에 패킷이 하나 손실되면 송신자는 중복된 ACK 패킷을 통해 이를 감지하고 정상적으로 전송되지 않은 패킷을 재전송. 47 | 48 | **흐름 제어** 49 | 50 | - 흐름 제어는 TCP 송신자가 데이터를 너무 빠르게 혹은 너무 많이 전송하여 수신자의 버퍼가 overflow 되는걸 방지하는 기술. 51 | - 송신자가 데이터를 전송하는 속도를 애플리케이션 프로세스를 읽는 속도와 유사한 수준으로 만들어 트래픽 수신 속도를 송신 속도와 일치시키는 기술. 52 | 53 | ## 2.3 HTTP 프로토콜 54 | 55 | ### 2.3.1 HTTP 최적화 기술 56 | 57 | - HTTP/0.9 -클라이언트와 서버의 인터넷 통신 정상화, 가용성, 신뢰성 등 기능에 초점 58 | - HTTP/1.0 - 클라이언트와 서버 사이 요청과 응답을 빠르게 할 수 있는 연구 진행 59 | - HTTP/1.1 - 멀티호스트 기능과 클라이언트 서버 사이에서 TCP/IP 연결을 재사용하는 기능을 추가한 것이 두드러진 업데이트 내용 60 | 61 | - HTTP/1.1 버전부터 적용된 연결 재사용, 파이프라이닝 기법이 연결 기반의 HTTP 최적화 기술 62 | 63 | ### 2.3.2 HTTP 지속적 연결 64 | 65 | - HTTP/1.1에서는 클라이언트와 서버의 HTTP 지속적 연결을 기본으로 지원, 필요 없는 경우에만 close 요청을 통해 지속적 연결 사용하지 않음 66 | - HTTP/2 에서는 단일 TCP 연결을 통해 클라이언트와 서버 사이 응답 지연 없이 스트림 형태로 다수의 HTTP 요청과 응답으 ㄹ주고받을 수 있는 멀티플렉싱 기술의 토대를 만듦. 67 | - 따라서, HTTP/2를 사용한다면 지속적 연결을 고민할 필요가 없음. 68 | 69 | ### 2.3.3 HTTP 파이프라이닝 70 | 71 | - 먼저 보낸 요청의 응답이 없어도 다음 요청을 병렬적으로 수신자 측에 전송하는 기술. 72 | - 따라서 중간에서 응답 지연이 발생하더라도 클라이언트는 먼저 서버 측의 응답을 받을 수 있어 전체적으로 빠른 웹 로딩 구현. 73 | 74 | ## 2.4 DNS 75 | 76 | ### 2.4.1 DNS의 작동 원리 77 | 78 | - 브라우저 주소 창에 example.com을 입력했을 때 79 | 80 | 1. 로컬 DNS 서버로 질의 81 | 82 | 2. 루트 DNS 서버로 질의 83 | 84 | 3. .com DNS 서버로 질의 85 | 4. exmaple.com DNS 서버로 질의 86 | 87 | -------------------------------------------------------------------------------- /basic/3장-웹-사이트-성능을-개선하는-기본적인-방법/README.md: -------------------------------------------------------------------------------- 1 | # 3장 웹 사이트 성능을 개선하는 기본적인 방법 2 | ## 3.1 HTTP 요청 수 줄이기 3 | ### 3.1.1 스크립트 파일 병합 4 | ### 3.1.2 인라인 이미지 5 | ### 3.1.3 CSS 스프라이트 6 | ## 3.2 콘텐츠 파일 크기 줄이기 7 | ### 3.2.1 스크립트 파일 압축 전달 8 | ### 3.2.2 스크립트 파일 최소화 9 | ### 3.2.3 이미지 파일 압축 10 | ### 3.2.4 브라우저가 선호하는 이미지 포맷 사용 11 | ### 3.2.5 큰 파일은 작게 나누어 전송 12 | ## 3.3 캐시 최적화 하기 13 | ### 3.3.1 인터넷 캐시 사용 14 | ### 3.3.2 브라우저 캐시 사용 15 | ## 3.4 CDN 사용하기 16 | -------------------------------------------------------------------------------- /basic/3장-웹-사이트-성능을-개선하는-기본적인-방법/rita.md: -------------------------------------------------------------------------------- 1 | # 3장 웹 사이트 성능을 개선하는 기본적인 방법 2 | 3 | ## 3.1 HTTP 요청 수 줄이기 4 | 5 | - 웹 클라이언트가 특정 웹 페이지에 접속시 서버와 통신하는 방법을 알아야한다. 6 | 7 | 브라우저는 DNS시스템으로 특정 도메인의 접속 IP를 알아내 접속 8 | 9 | HTML파일을 응답 받음 10 | 11 | HTML내 CSS,JavaScript,이미지 등 콘텐츠를 차례로 호출 12 | 13 | 브라우저가 HTML을 모두 해석하여 콘첸트를 전부 받아오기까지 호출이 계속 진행됨. 14 | 15 | 만약 HTML을 받아온 도메인과 콘텐츠 주소가 다르면 DNS 조회부터 다시 시작. 이렇게 조회된 웹 서버 IP를 통해, 브라우저와 웹 서버 간 TCP/IP연결을 맺은 후 실제 콘텐츠를 다운로드함. 16 | 17 | - **웹 페이지를 단순하게 제작**하는 것이 HTTP 요청수를 줄이는 가장 쉬운 방법이다. 18 | 19 | 그러나 웹을 통해 기업을 홍보하거나 제품을 판매하는 경우(유저을 끌어들이는) 20 | 21 | 웹 성능을 위해 콘텐츠를 줄이는 게 현실적으로 적절하진 않다. 22 | 23 | **즉, 콘텐츠는 동일하게 유지하되 HTTP 요청 수를 줄이는 방법을 찾아야한다.** 24 | 25 | 아래에서 살펴보자 26 | 27 | ### 3.1.1 스크립트 파일 병합 28 | 29 | 모듈화 : 최소 기능 단위별로 SW 모듈을 나누어 개발 30 | 31 | JavaScript나 CSS파일을 기능별로 분리하여 각각의 파일로 저장하고 호출하는 방식을 사용함 32 | 33 | 그러나 분할정복 모듈화는 HTTP 요청수를 증가시킴 -> 웹 성능에 부정적 영향 34 | 35 | 36 | 37 | 따라서, 기능 단위로 모듈화된 여러 파일들을 하나로 합치고 이 하나의 파일을 브라우저가 실행하는 것이 38 | 39 | 여러 파일을 각각 호출하는 것과 동일한 결과를 만들 수 있다면 40 | 41 | **파일 병합으로 HTTP 요청수를 줄일 수 있다.** 42 | 43 | 44 | 45 | 책 속의 예시 이미지를 참고하면, 병합 이전 6개의 CSS파일 로딩은 0.6초 -> 이후 0.45초로 감소 46 | 47 | 48 | 49 | ### 3.1.2 인라인 이미지 50 | 51 | HTML 파일의 CSS 안에 해시 정보를 통해 웹 페이지 배경 이미지 파일을 삽입한다. 52 | 53 | 이 방식은 HTML파일의 바이트 크기가 소폭 증가. 54 | 55 | 그러나 이미지 파일을 따로 호출하여 해당 크기만큼 파일을 받아오는 전통적인 방식과 비교하면 **전체 로딩 시간이 감소** = 인라인 이미지 라고 부름 56 | 57 | 58 | 59 | 이 방식은, 웹 페이지 안에 이미지를 포함하는 경우 별도의 이미지 파일이 존재하지 않기에 인터넷이나 브라우저에 캐시할 수 없다. HTML이 캐시되어야 동시에 캐시할 수 있음. 그러므로 전반적인 성능 개선 여부를 확인한 후 선택 사용해야함. 60 | 61 | 62 | 63 | - 파일 병합 : HTTP 요청 수를 줄이는 것은 물론, 인터넷상 프록시나 브라우저에 캐시될 확률을 좀 더 높인다. 64 | 65 | 원본 파일이 존재하는 웹 서버에서 아무리 빠른 속도로 응답이 온다고 해도, 사용자의 위치의 캐시 서버나 사용자의 기기에 캐시된 콘텐츠를 사용하는게 성능면에서 훨씬 빠르다. 66 | 67 | ### 3.1.3 CSS 스프라이트 68 | 69 | CSS 스프라이트란, 여러개의 이미지를 하나의 이미지 파일로 결합해 필요한 이미지가 위치하는 픽셀 좌표 정보를 사용하는 방식이다. 아이콘, 버튼 등 작은이미지에 유용 70 | 71 | 예시) background 이미지에 url로 사용 72 | 73 | ``` 74 | .sprite_face { 75 | background: url(‘imgs/sprites_image.png’); 76 | background-position: 0 -64px; 77 | width: 50px; 78 | height: 50px; 79 | float:left; 80 | transition: all .2s ease-in-out; 81 | } 82 | ``` 83 | 84 | 85 | 86 | ## 3.2 콘텐츠 파일 크기 줄이기 87 | 88 | 다운로드 시간을 줄이자 89 | 90 | ### 3.2.1 스크립트 파일 압축 전달 91 | 92 | 메일을 보낼때 zip파일로 압축해서 전송하는 것처럼, 93 | 94 | 각 웹 서버가 지원하는 방식으로 스크립트 형태 콘텐츠를 압축해 클라이언트에게 더 작은 크기로 내려주고, 95 | 96 | 이를 다운로드한 클라이언트가 압축을 해제하여 원래 콘텐츠를 사용한다면 다운로드 속도가 더 빨라짐 97 | 98 | 압축 방식을 선택해야함. 만약 클라이언트가 지원하지 않는 압축 방식을 사용해 파일을 내려주면 클라이언트는 이를 해제할 수 없기 때문. 99 | 100 | 101 | 102 | HTTP 프로토콜은 Accept-Encoding, Content-Encoding 헤더를 사용하여 이러한 압축 방식의 정보교환을 지원함. 103 | 104 | 105 | 106 | 브라우저가 서버에 콘텐츠를 요청하면서, 자신이 지원하는 압축 알고리즘을 HTTP request header에 나열해서 알려줌 (= 어떤 방식으로 압축해제할 수 있는지 고지함) 107 | 108 | 그러면 서버는, 그 중 자신이 지원하는 알고리즘을 택일하여 HTTP response header로 알려줌. 109 | 110 | 111 | 112 | 이 때 사용하는 것이 request header의 경우 Accept-Encoding이다 113 | 114 | response header는 Content-Encoding 115 | 116 | 117 | 118 | ``` 119 | 예시 120 | // 클라이언트의 요청 헤더 브라우저는 gzip, deflate, sdch 압축 방식을 지원함 121 | Accept-Encoding: gzip, deflate, sdch 122 | //웹 서버의 응답 헤더 클라이언트가 지원하는 압축 방식 중 gzip을 사용할 것을 명시함 123 | Content-Encoding: gzip 124 | ``` 125 | 126 | - gzip : UNIX 운영체제에서 일반적으로 사용하는 LZ77 파일 압축 라이브러리를 사용합니다. 32비트 CRC로 정상 압축 여부를 검사합니다. 127 | 128 | - deflate : zlib라는 파일 압축 라이브러리를 사용합니다. RFC 1951에 정의된 압축 방식입니다 129 | - sdch(Shared Dictionary Compression over HTTP) : 구글이 개발한 HTTP 상의 압축 방식이며 주 130 | 로 크롬 브라우저에서 사용합니다. 131 | 132 | ### 3.2.2 스크립트 파일 최소화 133 | 134 | 스크립트 파일에서, 실제 로직에 아무런 영향을 주지 않는 주석, 개행문자 등을 제거하여 전반적인 파일 크기를 줄이는 방식이다. 135 | 136 | Minify 사이트 137 | 138 | 139 | 140 | 개발 서버와 운영 서버를 분리하는 방법을 많이 사용한다. 141 | 142 | 143 | 144 | ### 3.2.3 이미지 파일 압축 145 | 146 | 이미지 파일은 파일정보를 메타데이터에 포함해 저장함 147 | 148 | tiny png 서비스 - 손실 압축 방식으로 이미지 파일 압축 149 | 150 | 151 | 152 | ### 3.2.4 브라우저가 선호하는 이미지 포맷 사용 153 | 154 | 자사 브라우저가 동일 품질의 이미지 크기를 더욱 줄일 수 있는 이미지 포맷을 개발 155 | 156 | =WebP(Google)와 JPEG XR(MS) 157 | 158 | 159 | 160 | 161 | 162 | ### 3.2.5 큰 파일은 작게 나누어 전송 163 | 164 | 대용량 파일 전송의 예 165 | 166 | 고화질 이미지, 매우 긴 문서, 게임 패치 파일 등 167 | 168 | 파일의 일부분을 순서대로 다운로드하는 **부분 요청 응답 방식**을 사용 169 | 170 | 171 | 172 | 웹 서버에 특정 부분 파일 전달을 지원하는 기능이 있을 때만 사용가능 173 | 174 | request header를 통해 확인 175 | 176 | Accectp-Ranges, Content-Length, Content-Range 등 177 | 178 | ## 3.3 캐시 최적화 하기 179 | 180 | 캐시 : 자주 사용되는 콘텐츠나 특정 데이터 등을 임의의 저장소에 복제해두고 재사용하는 방식을 의미 181 | 182 | 원래 데이터 위치에 접근하는 시간보다 짧음. 시스템의 리소스를 절약가능 183 | 184 | 185 | 186 | 인터넷 캐시 : 캐시 영역에 미리 데이터를 복사해두는 push 방식 / 실제 요청이 있을 때만 캐시에 저장하는 pull 방식 187 | 188 | 189 | 190 | ### 3.3.1 인터넷 캐시 사용 191 | 192 | 인터넷상에서 자주 요청되는 콘텐츠를 캐시하는 것은 **속도와 인프라 보호** 차원에서 중요하다. 프록시 서버가 담당함. 193 | 194 | 서버 대신 클라이언트의 자원 요청에 응답해준다. 195 | 196 | 콘텐츠 소비자와 제공자 사이의 인터넷 구간이 멀 때 구간의 중간 정도에 HW or SW 방식으로 프록시를 설치해 사용함 197 | 198 | 서버와 클라이언트 사이에서 통신을 대신하는 기능 자체를 프록시, 199 | 200 | 중계 기능을 수행하는 서버를 프록시 서버라고 함. 사용자가 많은 지역에 여러곳을 선택하여 설치함 201 | 202 | 1. 사용자 부근의 프록시 서버의 응답속도가 원래 서버의 응답속도보다 빠름 203 | 2. 원본 서버로 몰릴 수 있는 인터넷 트래픽을 프록시 서버로 분산해 원본 서버의 자원을 절약함 204 | 205 | 206 | 207 | ### 3.3.2 브라우저 캐시 사용 208 | 209 | 프록시 = 클라이언트와 서버 중간에 위치한 인터넷상의 캐시 210 | 211 | 브라우저 캐시 = 클라이언트 위치의 캐시 212 | 213 | 214 | 215 | ![image](https://user-images.githubusercontent.com/48556400/147093935-adf1e4e3-823f-45b6-95cb-69da9aaad97b.png) 216 | 217 | 얼마나 긴 시간동안 캐시해도 되는지 정책이 결정되면 218 | 219 | 웹서버는 Cache-Control request header를 통해 설정 내용을 클라이언트에 전달함 220 | 221 | ## 3.4 CDN 사용하기 222 | 223 | CDN : 인터넷상에서 생산,소비되는 웹 콘텐츠를 사용자에게 빠르게 전달하기 위해 **캐시 서버** 혹은 **에지 서버**라 불리는 **대용량 인터넷 캐시 영역**에 콘텐츠를 저장해 사용하는 네트워크 방식 224 | 225 | 여러 노드를 가진 네트워크에 콘텐츠를 저장하여 제공하는 프록시의 일종 226 | 227 | 원본 서버라 불리는 콘텐츠 서버와 사용자 사이에서 중재자 역할을 함 228 | 229 | 230 | 231 | 232 | 233 | -------------------------------------------------------------------------------- /basic/3장-웹-사이트-성능을-개선하는-기본적인-방법/tanney.md: -------------------------------------------------------------------------------- 1 | # 3장 웹 사이트 성능을 개선하는 기본적인 방법 2 | 3 |
4 | 5 | ## 3.1 HTTP 요청 수 줄이기 6 | 7 |
8 | 9 | - 스크립트, CSS, 이미지, 폰트 등 요청하는 컨텐츠의 수가 많을수록 필연적으로 로딩 완료 시점이 뒤로 미뤄진다. 10 | - 특히 각 컨텐츠의 도메인이 다르면 DNS 조회 수도 늘어난다. 11 | - 따라서 좋은 웹 성능을 위해선 HTTP 요청 수를 줄여야 한다. 12 | - 단순하게는 컨텐츠의 수를 줄이는 것이 가장 좋지만 그럴 수 없는 상황이 분명히 존재한다. 13 | - 따라서 페이지에 나타나는 컨텐츠는 동일하게 유지하고 HTTP 요청 수를 줄이는 방법을 찾아야한다. 14 | 15 |
16 | 17 | ### 3.1.1 스크립트 파일 병합 18 | 19 |
20 | 21 | - 기능별로 모듈화해 여러 파일을 두면 자연스레 HTTP 요청 수가 증가한다. 22 | - 모듈화된 여러 파일을 하나로 합쳐(번들) 하나의 요청만으로 불러오게 한다면 웹 성능에 도움이 될 수 있다. 23 | - 번들 과정에서 하나의 파일의 크기가 너무 커진다면 오히려 성능에 악영향을 주므로 적절한 크기를 유지하는 것이 중요하다. 24 | 25 |
26 | 27 | ### 3.1.2 인라인 이미지 28 | 29 |
30 | 31 | - Data URI를 사용해 이미지를 HTML 문서에 임베드하는 방식 32 | - HTML 파일의 용량이 증가하나 HTTP 요청을 보내지 않는다는 장점이 있다. 33 | - HTML 문서에 임베드 되어 있기 때문에 이미지만 따로 캐싱할 수 없다. 34 | 35 |
36 | 37 | ### 3.1.3 CSS 스프라이트 38 | 39 |
40 | 41 | - 여러 이미지(주로 아이콘)를 하나의 이미지 파일로 결함하고 필요한 이미지의 위치 좌표(background-position)를 사용하는 방식이다. 42 | - 하나의 HTTP 요청만으로 여러 이미지를 사용할 수 있다는 장점이 있다. 43 | 44 |
45 | 46 | ## 3.2 콘텐츠 파일 크기 줄이기 47 | 48 |
49 | 50 | - 요청의 수를 줄이는 것도 중요하지만 전송하는 컨텐츠의 크기를 줄이는 것도 성능에 영향을 준다. 51 | - 그러나 무작정 크기를 줄이는 것은 컨텐츠 자체를 훼손 할 수 있다. 52 | - 따라서 컨텐츠를 유지하면서 크기를 줄이는 방법을 고민해야한다. 53 | 54 |
55 | 56 | ### 3.2.1 스크립트 파일 압축 전달 57 | 58 |
59 | 60 | - HTML, CSS, JS, XML, JSON 등은 모두 스크립트 형태의 텍스트 파일이다. 61 | - 웹 서버가 지원하는 방식으로 해당 스크립트들을 압축해서 클라이언트에 제공할 수 있다. 62 | - 이때, 서버는 클라이언트에서 지원하는 형식으로 압축을 해야한다. 63 | - 이를 위해 HTTP 프로토콜에서는 Accept-Encoding, Content-Encoding 헤더를 사용해 압축 방식에 대한 정보를 공유한다. 64 | - 클라이언트는 컨텐츠를 요청할 때 자신이 지원하는 압축 알고리즘을 요청 헤더 Accept-Encoding에 나열해 알려준다. 65 | - 서버는 이 중 자신이 지원하는 방식을 선택해 컨텐츠를 압축하여 제공한다. 66 | - 이때, 서버는 응답 헤더 Content-Encoding에 압축 알고리즘을 담는다. 67 | - 클라이언트는 서버가 헤더로 전달한 방식을 보고 압축된 파일을 해제한다. 68 | 69 |
70 | 71 | ### 3.2.2 스크립트 파일 최소화 72 | 73 |
74 | 75 | - 스크립트 파일에 포함된 주석, 공백, 개행 문자 등 실제 로직에 영향을 주지 않는 부분을 제거해 전반적인 파일의 크기를 줄일 수 있다. 76 | - 위 방식으로 최소화 된 스크립트를 디버깅하기 쉽지 않으므로 개발 환경에서는 최소화를 하지 않거나 source map을 사용한다. 77 | 78 |
79 | 80 | ### 3.2.3 이미지 파일 압축 81 | 82 |
83 | 84 | - 이미지 파일에 대한 정보를 담고 있는 메타데이터를 제거해 크기를 줄일 수 있다. 85 | - 손실 압축 방식으로 이미지의 크기를 줄일 수 있다. 86 | - 이미지 압축에 대한 자세한 내용은 4장에서 다룬다. 87 | 88 |
89 | 90 | ### 3.2.4 브라우저가 선호하는 이미지 포맷 사용 91 | 92 |
93 | 94 | - 이미지 포맷에는 일반적으로 무손실 이미지 형식인 png, gif, 손실 이미지 형식인 jpeg 등 다양한 형식이 있다. 95 | - 브라우저 개발팀에 의해 더욱 압축 효율이 좋은 포맷이 개발되기도 한다. 96 | - WebP와 JPEG XR이 대표적이다. 97 | - WebP는 구글에서 개발된 손실 압축 방식의 이미지 포맷이다. 98 | - WebP는 동일 품질의 JPEG 보다 10% ~ 80% 정도 작게 압축할 수 있다. 99 | - JPEG XR은 MS에 의해 개발된 이미지 포맷으로 손실 압축과 비손실 압축을 모두 지원한다. 100 | - JPEG XR은 동일 품질 JPEG의 약 30% 정도 크기로 압축할 수 있다. 101 | - 각 형식을 개발사의 브라우저를 우선적으로 지원한다. 102 | 103 |
104 | 105 | ### 3.2.5 큰 파일은 작게 나누어 전송 106 | 107 |
108 | 109 | - 동영상이나 패치 파일 등 크기가 매우 큰 컨텐츠의 경우 파일의 일부분을 순서대로 다운로드하는 부분 요청 응답 방식을 사용할 수 있다. 110 | - 또한 크기를 가늠할 수 없는 컨텐츠 전송에도 유용하다. 111 | - 이 방식은 웹서버가 지원할 때만 사용할 수 있다. 112 | - 지원 여부는 응답 헤더를 통해 확인할 수 있다. 113 | - 응답헤더에 "Accept-Ranges: bytes"가 포함되어 있으면 부분 지원 기능을 수락한다는 의미이다. 114 | - 부분 지원이 가능한 컨텐츠에 경우 Range 헤더를 통해 특정 부분만 요청할 수 있다. 115 | - 이 경우 서버는 206 Partial Content로 응답한다. 116 | - 이때, 응답 헤더에 Content-Range 가 포함되면 전체 영역중 어느 부분을 전송했는지 명시한다. 117 | - "Range: bytes=0-50, 100-150" 과 같이 쉼표로 구분해 여러 범위를 동시에 요청할 수도 있다. 118 | 119 |
120 | 121 | ## 3.3 캐시 최적화 하기 122 | 123 |
124 | 125 | - 컴퓨터 자원의 활용을 위해 캐시가 사용되듯 인터넷 상에서도 캐시를 사용한다. 126 | - ISP가 제공하는 Proxy를 통해 캐시를 하면 로딩 속도를 개선할 수 있을 뿐만 아니라 네트워크 대역폭도 아낄 수 있다. 127 | - Proxy는 인터넷 구간에서 서버 대신 클리이언트 자우너 요청에 응답해주는 기능을 의미한다. 128 | - 서버와 클라이언트 사이에서 통신을 대신하는 기능 자체를 proxy, 이 중계 기능을 수행하는 서버를 Proxy server라고 한다. 129 | - 인터넷 캐시는 PUSH 방식과 PULL 방식으로 구분할 수 있다. 130 | - PUSH 131 | - 캐시 영역에 미리 데이터를 복사해 두는 방식이다. 132 | - 특정 시간, 특정 지역에 사용자 요청이 과하게 몰릴 것을 대비할 수 있다. 133 | - PULL 134 | - 실제 요청이 있을 때만 캐시에 저장하는 방식이다. 135 | - 브라우저에서도 캐시를 할 수 있다. 136 | - 특정 웹 사이트에서 받아온 컨텐츠들 중 브라우저가 저장할 수 있는 컨텐트 들은 클라이언트 측에 저장해 불필요한 요청 자체를 줄일 수 있다. 137 | - 서버는 Cache-Control 헤더를 통해 브라우저 캐시 여부와 어떤 방식으로 캐시를 할 것인지 명시한다. 138 | 139 |
140 | 141 | ## 3.4 CDN 사용하기 142 | 143 |
144 | 145 | - CDN은 에지 서버(or 캐시 서버)라 불리는 대용량 인터넷 캐시 영역에 컨텐츠를 저장해 사용하는 네트워크 방식이다. 146 | - 여러 엔드 포인트를 사용하는 일종의 proxy이다. 147 | - CDN의 장점 148 | - 원거리 origin에서 컨텐트를 전달 받을 때 생길 수 있는 네트워크 지연, 패킷 손실 등의 현상을 줄일 수 있다. 149 | - 사용자는 가까운 에지에서 컨텐츠를 제공받으므로 로딩시간을 단축할 수 있다. 150 | - 원본서버의 부하를 줄일 수 있다. 151 | - 에지 서버와 에지 서버 간 ICP(Internet Cache Protocol)를 사용한 서버 전파를 할 수 있어 캐시 컨텐츠의 재사용률이 높다. 152 | 153 |
154 | -------------------------------------------------------------------------------- /basic/3장-웹-사이트-성능을-개선하는-기본적인-방법/tococ.md: -------------------------------------------------------------------------------- 1 | # 3장 웹 사이트 성능을 개선하는 기본적인 방법 2 | ## 3.1 HTTP 요청 수 줄이기 3 | - 웹 페이지에서 요청하는 콘텐츠의 수가 많을수록 로딩 완료 시간은 길어지고, 이미지 같은 콘텐츠가 적은 페이지는 매우 빠르게 로딩이 완료된다. 4 | - 따라서, 웹 성능을 더 빠르게 하기 위해서 HTTP의 요청 수를 줄여야한다. 5 | - 웹 페이지를 단순하게 제작하는 것이 HTTP 프로토콜 요청 수를 줄이는 가장 쉬운방법이다. 6 | - 하지만, 웹 사이트를 통해 기업을 홍보하거나 상품 판매를 위해 많은 사용자를 끌어들여야 하는 실제 상황을 고려하면, 웹 성능을 위해 나타낼 콘텐츠를 줄이는 것이 현실적으로 적절한 방법은 아니다. 7 | 8 |
9 | 10 | ### 3.1.1 스크립트 파일 병합 11 | 12 | - 모듈화는 HTTP 요청 수를 증가시키므로 웹 성능에 부정적인 영향을 미친다. 13 | 14 | > 모듈화 - 소프트웨어 개발의 손쉬운 분업화 및 편리한 유지 보수를 위해 최소 기능 단위별로 소프트웨어 모듈을 나누어 개발하는 것을 제안하는데 이를 모듈화라고 한다. 15 | 16 | - 따라서, 기능 단위로 모듈화된 여러 파일들을 하나로 합치고 이 하나의 파일을 브라우저가 실행하는 것이 여러 파일들을 각각 호출하는 것과 동일한 결과를 만들 수 있다면, 파일 병합으로 HTTP 요청수를 줄일 수 있습니다. 17 | - 하지만, 합쳐진 파일의 크기가 너무 크다면 해당 파일을 다운로드해 브라우저 화면에 나타내는 로딩 과정이 너무 길어질 수 있으므로 적절한 크기를 유지해야한다. 18 | 19 |
20 | 21 | ### 3.1.2 인라인 이미지 22 | 23 | - HTML 파일의 CSS안에 해시 정보를 통해 웹 페이지 배경 이미지 파일을 삽입을 하는 방식을 사용하면 HTML 파일의 바이트 크기가 소폭 커지게 된다. 24 | - 하지만, 이미지 파일을 따로 호출하여 해당 크기만큼 파일을 받아오는 전통적인 방식과 비교하면 전체 로딩시간이 단축된다. 25 | 26 |
27 | 28 | ### 3.1.3 CSS 스프라이트 29 | 30 | - 여러 개의 이미지를 하나의 이미지 파일로 결합해 필요한 이미지가 위치하는 픽셀 좌표 정보를 사용하는 방식이다. 31 | 32 |
33 | 34 | ## 3.2 콘텐츠 파일 크기 줄이기 35 | 36 | - 웹 사이트의 파일 수를 줄이더라도 파일 자체의 크기가 크다면 이 또한 웹 성능에 부정적인 영향을 준다. 37 | - 파일이 크면 인터넷 전송 시간이 길어지기 때문이다. 38 | - 아래의 방법들은, 파일 내용은 변하지 않고 크기를 줄일 수 있는 기능들이다. 39 | 40 |
41 | 42 | ### 3.2.1 스크립트 파일 압축 전달 43 | 44 | - 각 웹 서버가 지원하는 방식으로 스크립트 형태 콘텐츠(JS,CSS XML, JSON등)를 압축해 클라이언트에게 더 작은 크기로 내려주고, 이를 다운로드한 클라이언트가 압축을 해제하여 원래 콘텐츠를 사용한다면 인터넷 다운로드 속도가 좀 더 빨라질 수 있다. 45 | - 다만 파일을 압축하여 내려주기 전에 웹 서버와 클라이언트는 서로가 지원하는 다양한 압축 방식 중 어떤 것을 사용할지 하나를 골라 정해야한다. 46 | - 압축 방식의 정보 교환은 HTTP 프로토콜에서 `Accept-Encoding`과 `Content-Encoding` 헤더를 사용하여 이루어진다. 47 | 48 |
49 | 50 | ### 3.2.2 스크립트 파일 최소화 51 | 52 | - HTML, 자바스크립트, CSS같이 코딩된 스크립트 파일에 포함된 주석문, 공백, 개행 문자등 실제 로직에 아무런 영향을 주지 않는 부분을 제거하여 전반적인 파일 크기를 줄이는 방식이다. 53 | 54 |
55 | 56 | ### 3.2.3 이미지 파일 압축 57 | 58 | - 이미지 파일은 웹 사이트에서 가장 많은 용량을 차지하는 콘텐츠이다. 59 | - 이미지 파일은 해당 파일 정보를 메타 데이터에 포함해 저장한다. (어떤 카메라로 촬영했는지, 해상도가 무엇인지등) 60 | - 메타 데이터는 사람의 눈에 실제 이미로써 보이지 않으므로 불필요한 부분을 제거하면 크기를 상당히 줄일 수 있다. 61 | 62 |
63 | 64 | ### 3.2.4 브라우저가 선호하는 이미지 포맷 사용 65 | 66 | - 웹상의 이미지는 JPG, GIF, PNG등 다양한 포맷을 사용한다. 67 | - 크롬이나 인터넷 익스플로러 개발팀은 자사 브라우저가 동일 품질의 이미지 크기를 더욱 줄일 수 있는 이미지 포맷을 개발했다. 68 | - WebP, JPEG XR 69 | - WebP는 손실 압축 방식을 사용하는 이미지 형식 70 | - JPEG 이미지 형식을 대체하기 위해 처음부터 웹 사이트 트래픽 감소, 로딩 속도 단축을 목적으로 개발됨 71 | - 사진 이미지의 압축 효과가 높고화질 저하를 최소화하면서도 파일 크기를 작게 만든다. 72 | - 동일 품질의 JPEG보다 평균 50% 정도 파일 크기가 작아진다. 73 | 74 |
75 | 76 | ### 3.2.5 큰 파일은 작게 나누어 전송 77 | 78 | - 인터넷 속도가 느린 곳이라면 크기가 큰 동영상을 재생할 때 버퍼링이 발생한다. 79 | - 모든 파일을 다운로드하는 방식은 버퍼링을 유발하며 실제 보지 않는 부분까지 다운로드함으로써 인터넷 자원 낭비가 발생한다. 80 | - 위 경우를 대비해, 큰 파일의 일부분을 순서대로 다운로드하는 부분 요청 응답 방식을 사용할 수 있다. 81 | - 부분 요청 응답 방식은 웹 서버에 특정 부분 파일 전달을 지원하는 기능이 있을 때만 가능하다. 82 | 83 |
84 | 85 | ## 3.3 캐시 최적화 하기 86 | - 캐시는 자주 사용되는 콘텐츠나 특정 데이터 등을 임의의 저장소에 복제해두고 재사용하는 방식을 의미한다. 87 | - 인터넷상에서 캐시는 ISP 회사가 지역에 분포된 특정 시스템에 사용자와 원격 시스템 사이에서 주고받은 데이터를 캐시하고 다음 사용자에게 제공하는 방식으로 널리 사용된다. 88 | - 콘텐츠를 캐시하는 이 시스템을 `프록시 서버`라고 부른다. 89 | - 해당 서버 덕분에 ISP 회사들은 네트워크 대역폭을 아낄 수 있다. 90 | - 또한, 소비자들은 좀 더 빠르게 콘텐츠 응답을 받을 수 있어 만족도가 증가한다. 91 | - 인터넷에서 빠른 자원 전달을 위한 인터넷 캐시가 발달하자 해당 콘텐츠를 소모하는 브라우저도 콘텐츠를 캐시하기 시작했다. 92 | - 즉, 자주 바뀌지 않는 이미지나 자바스크립트, CSS파일 등을 인터넷 프록시 서버뿐만 아니라 사용자의 브라우저에도 캐시해놓습니다. 93 | 94 |
95 | 96 | ### 3.3.1 인터넷 캐시 사용 97 | 98 | - 인터넷상에서 자주 요청되는 콘텐츠를 캐시하는 것은 속도와 인프라 보호 차원에서 중요하다. 99 | - 이를 주로 담당하는 시스템은 프록시 서버이다. 100 | - 프록시 서버는 클라이언트가 처음 요청한 콘텐츠를 원본 서버에 대신 요청하여 클라이언트에게 전달해주고 이를 스스로 저장한다. 101 | - 이후 다른 클라이언트가 동일한 콘텐츠를 요청했을 때 원본 서버에 접속할 필요 없이 자체 저장한 콘텐츠를 제공한다. 102 | - 이 방법은 두 가지 장점을 가지고 있다. 103 | - 사용자 부근의 프록시 서버의 응답 속도가 원래 서버의 응답 속도보다 빠르다. 104 | - 원본 서버로 몰릴수 있는 인터넷 트래픽을 프록시 서버로 분산해 원본 서버의 자원을 절약한다. 105 | 106 |
107 | 108 | ### 3.3.2 브라우저 캐시 사용 109 | 110 | - 브라우저 캐시는 클라이언트 위치의 캐시이다. 111 | - 특정 웹 사이트에 접속하여 받아온 웹 콘텐츠들 중 브라우저가 저장할 수 있는 콘텐츠들을 클라이언트 측에 저장해 인터넷상의 요청을 아예 하지 않겠다는 개념이다. 112 | - 특정 콘텐츠가 브라우저 캐시를 사용할지 아닐지는 일반적으로 웹 서버에서 먼저 결정해야한다. 113 | - 웹 서버는 Catche-Control 응답 헤더를 통해 브라우저 캐시 관련 설정 내용을 클라이언트에게 전달한다. 114 | 115 |
116 | 117 | ## 3.4 CDN 사용하기 118 | 119 | - CDN(Content Delivery Network)은 인터넷상에서 생산 소비되는 웹 콘텐츠를 사용자에게 빠르게 전달하기 우해 캐시 서버혹은 에지 서버라 불리는 대용량 인터넷 캐시 영역에 콘텐츠를 저장해 사용하는 네트워크 방식이다. 120 | 121 | - 오늘날 인터넷 환경에서 광범위하게 사용되어 전 세계 인터넷 트래픽 성능을 개선해준다. 122 | 123 | - CDN은 촘촘히 분산된 서버로 이루어져있고 사용자의 웹 콘텐츠 요청에 직접 응답한다. 124 | 125 | - CDN은 주로 실제 인터넷 사용자가 가입한 ISP의 데이터 센터 내에 캐시 서버를 두고 이를 직접 사용자와 연결해 데이터를 전송한다. 126 | 127 | - 아래와 같은 장점들이 존재한다. 128 | - 네트워크 지연과 패킷 손실 현상을 줄일 수 있다. 129 | - 사용자는 가까운 에지 서버에 캐시된 콘텐츠를 전달받으므로 전송에 필요한 RTT(Round Trip Time)가 줄어들어 빠르게 콘텐츠를 받을 수 있다. 130 | - 원본 서버의 부하를 줄일 수 있다 131 | - etc. 132 | 133 | 134 | -------------------------------------------------------------------------------- /basic/3장-웹-사이트-성능을-개선하는-기본적인-방법/yujo.md: -------------------------------------------------------------------------------- 1 | ​ 2 | 3 | # 3. 웹 사이트 성능을 개선하는 기본적인 방법 4 | 5 | ## 3.1 HTTP 요청 수 줄이기 6 | 7 | - 웹 페이지에서 요청하는 컨텐츠 수가 많을수록 로딩 완료 시간은 길어진다. 8 | - 그러므로 웹 성능을 빠르게 하기 위해서 HTTP의 요청 수를 줄여야 한다. 9 | 10 | ### 3.1.1 스크립트 파일 병합 11 | 12 | - 스크립트 파일을 하나로 합쳐서 호출하는 것으로 로딩 속도를 개선할 수 있다. 13 | 14 | ### 3.1.2 인라인 이미지 15 | 16 | ### 3.1.3 CSS 스프라이트 17 | 18 | - CSS 스프라이트는 여러 개의 이미지를 하나의 이미지 파일로 결합해 필요한 이미지가 위치하는 픽셀 좌표 정보를 사용하는 방식. 19 | - 주로 아이콘이나 버튼 등 작은 이미지를 사용할 떄 유용하며 HTML에 필요한 이미지 영역을 이미지 맵 좌표로 표시. 20 | 21 | ## 3.2 콘텐츠 파일 크기 줄이기 22 | 23 | ### 3.2.1 스크립트 파일 압축 전달 24 | 25 | - gzip 등으로 스크립트 파일을 압축해서 전달 26 | 27 | ### 3.2.2 스크립트 파일 최소화 28 | 29 | ### 3.2.3 이미지 파일 압축 30 | 31 | ### 3.2.4 브라우저가 선호하는 이미지 포맷 사용 32 | 33 | - webp 등 34 | 35 | ### 3.2.5 큰 파일을 작게 나누어 전송 36 | 37 | ## 3.3 캐시 최적화하기 38 | 39 | ### 3.3.1 인터넷 캐시 사용 40 | 41 | - 프록시 서버를 사용하여 먼 곳에 있는 원본 서버의 콘텐츠를 캐시를 사용하여 저장하고, 클라이언트가 요청했을 때 서버 대신 응답. 42 | - 장점 43 | 1. 가까운 곳에서의 요청을 보다 빠르게 처리할 수 있다. 44 | 2. 원본 서버의 트래픽을 프록시 서버로 분산한다. 45 | 46 | ### 3.3.2 브라우저 캐시 사용 47 | 48 | - Cache-Control 응답 헤더를 통해 얼마나 긴 시간 동안 캐시해도 되는지클라이언트에 전달. 49 | 50 | ## 3.4 CDN 사용 51 | 52 | - 장점 53 | 1. 원거리에 있는 콘텐츠를 전달받는 과정에서 발생할 수 있는 네트워크 지연과 패킷 손실 현상을 줄일 수 있다. 54 | 2. 전송에 필요한 RTT가 줄어들어 빠르게 콘텐츠를 받을 수 있다. 55 | 3. CDN의 엣지 서버에서 콘텐츠를 전송하므로 원본 서버의 부하를 줄일 수 있다. 56 | 4. 캐시 컨텐츠의 재사용률이 매우 높다. 57 | 5. CDN 사업자를 사용함으로써 시스템과 인적 관리 비용 절감. 58 | -------------------------------------------------------------------------------- /basic/4장-이미지-최적화/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 04 이미지 최적화 2 | 3 | 4.1 이미지의 중요성 4 | 5 | 4.2 디지털 이미지의 종류와 특성 6 | 7 | 4.2.1 래스터 이미지 vs 벡터 이미지 8 | 9 | 4.2.2 무손실 이미지 형식 vs 손실 이미지 형식 10 | 11 | 4.3 이미지 변환 기법 12 | 13 | 4.3.1 무손실 압축 14 | 15 | 4.3.2 손실 압축 16 | 17 | 4.4 반응형 웹에서의 이미지 배치 전략 18 | 19 | 4.4.1 반응형 웹의 문제점 20 | 21 | 4.4.2 원인은 이미지 22 | 23 | 4.4.3 반응형 이미지 24 | 25 | 4.4.4 반응형 이미지 구현 방법 26 | 27 | 4.5 적응형 이미지 전략 28 | 29 | 4.5.1 적응형 이미지 아키텍처 30 | 31 | 4.5.2 기기 정보에 따라 서버 로직 수행 32 | 33 | 4.5.3 브라우저별 이미지 전달 34 | 35 | 4.5.4 캐시 고려 사항 36 | -------------------------------------------------------------------------------- /basic/4장-이미지-최적화/rita.md: -------------------------------------------------------------------------------- 1 | # Chapter 04 이미지 최적화 2 | 3 | ## 4.1 이미지의 중요성 4 | 5 | 웹 사이트에서 사용된 이미지 크기와 개수의 변화를 나타낸 그래프 6 | 7 | 개수와 크기의 증가 8 | 9 | 10 | 11 | ![image](https://user-images.githubusercontent.com/48556400/147633692-a7c75fee-5788-4c14-98d5-8fd727da7fee.png) 12 | 13 | [이미지 출처 원본링크](https://httparchive.org/reports/state-of-images?start=earliest&end=latest&view=list) 14 | 15 | - 화소밀도: 물리 스크린 공간 안에 얼마나 많은 픽셀이 압축되어있는가 16 | - 픽셀과 포인트 차이점 17 | - 40px이미지는 말 그대로 40px의 이미지 하나를 의미 18 | - 40포인트 이미지는 1x에서는 40px, 2x에서는 80px... 19 | - Hero이미지, 또는 대문 이미지의 중요성 20 | - 비즈니스 부서에선 구매자의 눈길을 끌기 위해 크고 선명한, 화려한 이미지를 요구 21 | - 디자이너가 만든 고품질 이미지를 그대로 사용하면 웹 성능 문제가 발생 22 | 23 | ## 4.2 디지털 이미지의 종류와 특성 24 | 25 | - 이미지를 잘 사용하기 위한 노력 26 | - 이미지의 종류와 특성을 파악해야한다. 27 | - 사용될 기기 타입과 용도에 맞춰 적절한 이미지를 선택해야한다. 28 | 29 | - 모바일 이미지가 데크스톱용 이미지보다 무거운 이유 30 | - 모바일 이미지에 PNG 타입을 사용 31 | - PNG는 알파 채널이라는 이미지 변환 기법을 사용함 32 | - 알파채널의 장점 : 핵심 이미지 레이어를 제외한 배경 이미지를 제거하여, 전체 이미지를 투명하게 만들어 사용할 수 있음 33 | - 알파채널의 단점 : 같은 품질의 JPEG 대비 파일 사이즈가 커짐 34 | - 페이지 로딩 시간이 1초 느려질 경우 상품을 구매하는 사용자의 비율이 약 7% 감소할 수 있다. 35 | 36 | ### 4.2.1 래스터 이미지 vs 벡터 이미지 37 | 38 | - 분류 기준 : 디지털 화면에 이미지들을 어떻게 표현하는가 39 | 40 | - 레스터 이미지 : 우리가 사용하는 대부분의 이미지 유형 41 | 42 | - 작은 사각형 모양의 픽셀에 표현하고자 하는 색상 정보를 입력해 이를 컴퓨터로 표현 43 | - 각각의 픽셀이 모여 하나의 큰 이미지를 완성 44 | - 단점 : 사이즈가 크거나 품질이 더 좋은 이미지를 만들려면 그만큼의 정보를 담은 픽셀들을 추가해야 컴퓨터가 이를 정상적으로 표현할 수 있음. 확장성 떨어짐. 45 | 46 | - 벡터 이미지 : 그리고자 하는 대상의 수학적인 정보를 제공 47 | 48 | - 그림이 위치할 좌표, 형상, 크기, 색상 등의 정보를 제공하여 컴퓨터가 그림을 그리듯 화면에 표현 49 | - 대표적으로 SVG 파일이 W3C 표준 포맷으로 가장 많이 사용됨 50 | - 화면 스케일에 상관없이 정보가 유지되기 때문에 항상 선명한 이미지를 표현할 수 있음 51 | - 단점 : 그림이 복잡해지면 이를 표현하기 위한 정보가 기하급수적으로 늘어나 수학적인 정보로 표현한느데 제약이 생김 52 | 53 | 54 | 55 | - SVG 파일 56 | 57 | - 텍스트 기반 콘텐츠 58 | - gzip이나 brotli 같은 텍스트 압축 기법으로 간단히 최적화 가능 59 | - zopfli 압축 기법으로 swvz 파일을 만들어 사용 60 | 61 | ### 4.2.2 무손실 이미지 형식 vs 손실 이미지 형식 62 | 63 | - 무손실 이미지 64 | - 원본 이미지의 정보 손실을 허용하지 않음 65 | - 예 ) GIF, PNG 66 | 67 | - 손실 이미지 68 | - 필요에 따라 이동할 수 있는 형태를 만들기 위해 정보 손실을 어느 정도 허용 69 | - 예 ) JPEG, WebP, JPEG XR, JPEG 2000 등 브라우저에 특화된 이미지 70 | 71 | - GIF 72 | - 이동식 이미지 형식 73 | - 가용색상 256컬러 74 | - 트루컬러타입인 GIF로 변형가능하지만 파일 사이즈가 매우 커져서 비효율적 75 | - 화려한 색상이나 복잡한 이미지보다 기업로고 등 단순한 이미지 표현에 적합 76 | - PNG 77 | - 배경 : GIF 단점과 특허문제 해결을 위해 개발됨 78 | - 24비트 색상(2^24개) 사용으로 GIF보다 고품질 이미지 표현 79 | - 알파 채널이라 불리는 투명 기능 80 | - JPEG 81 | - Joint Photographic Experts Group 82 | - 표준 형식 83 | - 배경 : RAW 형싱 파일은 용량이 크기에 네트워크 전송/웹 게시에 어려움. 이를 극복하기 위해 개발됨 84 | - 사람의 눈이 인식할 수 있는 색상만 남기고 나머지를 제거 85 | - 고해상도 이미지를 크게 압축한 파일로 저장가능 86 | - 품질 값을 사용자가 결정가능. 87 | - 품질값 범위 : 0-100(100으로 결정해도 약간의 품질 손실이 발생) 88 | - 어떤 경우에 사용? 89 | - 동일한 이미지를 여러번 편집해야하는 경우 - 비트맵, PNG 등 무손실 이미지 파일을 사용 90 | - 편집을 완료시점에 JPEG로 저장 91 | - JPEG 2000 92 | - 배경 : JPEG의 단점을 보완하기 위해 개발됨 93 | - WebP 94 | - 구글에서 개발하고 배포한 이미지 형식 95 | - JPEG보다 개선된 공격적 압축 방식 96 | - 무손실 압축, 애니메이션 기능, 투명 기능을 모두 지원 97 | - JPEG XR 98 | - 마이크로소프트사에서 개발 99 | - JPEG에 비해 R/G/B에 해당하는 색상 채널당 더 많은 수의 채색을 허용해서 표현할 수 있는 색상 범위를 확장 100 | - 무손실 압축, 투명 기능, 점진적 데이터 전송 기능 지원 101 | 102 | ## 4.3 이미지 변환 기법 103 | 104 | - 목표 : 선택한 이미지가 웹에 최적화되도록 변환하는 방법을 알아보자 105 | - 이미지 파일 크기 줄이기 106 | - 웹 상에서 빠르게 전송하는 법 107 | - (원시 파일을 다양한 이미지 형식으로 변환하는 방법에 대해선 이 책의 범위를 벗어남 -> advanced) 108 | 109 | ### 4.3.1 무손실 압축 110 | 111 | 무손실 압축을 하려면 각 이미지 유형을 다르게 해야한다. 112 | 113 | 대체로 스크립트를 통해 압축을 자동화할 수 있다. 114 | 115 | 무료로 배포되는 라이브러리의 명령어를 이용하여 자동화하는 방법을 소개한다. 116 | 117 | - GIF : ImageMagicK, Giflossy, Gifsicle, gif2webp converter 118 | - PNG 119 | - PNG임을 알리는 첫 8바이트의 서명(구분자)를 제외하고 청크(chunk) 형태로 이미지 정보를 저장함 120 | - 이미지 정보를 저장하는 것이 핵심 청크 121 | - 히스토그램 관련 데이터, 정보성 청크 등 사용자 청크를 추가할 수 있음 122 | - 웹 렌더링에 필요하지 않은 청크는 삭제할 수 있음 123 | - 라이브러리 : Pngcrush, Pngquant, OptiPNG&Zopfli, PngOptiizer 124 | - JPEG 125 | - 이미지 정보 외에도 많은 메타 데이터가 포함되어있음 126 | - 메타데이터 예 : 주석 및 공백, 편집 애플리케이션 정보, 사진 위치 정보, 날짜 등 127 | - 웹에 게시할 땐 메타데이터가 필요없으므로 삭제하면 파일 크기를 줄일 수 있다. 128 | - 라이브러리 : MozJPEG, libJpeg, Guetzli 129 | 130 | ### 4.3.2 손실 압축 131 | 132 | 특정 이미지 정보를 누락, 즉 손실시켜 파일 크기를 줄이는 방법이 있다. 133 | 134 | 웹상에 게시할 때 성능과 화질 사이의 득실을 따져봐야한다. 135 | 136 | 손실 압축 기법을 잘 사용하면 사용자의 시각적 경험은 훼손하지 않으면서 로딩 속도를 눈에 띄게 향상시킬 수 있다. 137 | 138 | 사람이 품질 저하를 거의 눈치채지 못하면서 파일 크기를 가장 크게 줄일 수 있는 품질은 100~75% 139 | 140 | 작동 원리 : 기존 이미지 형식을 디코딩한 후 알고리즘에 따라 원하는 화질로 저하시켜 다시 원래 이미지 형식으로 인코딩해야한다. 이러한 일련의 작업을 ImageMagick이 지원 141 | 142 | 최적의 품질 지수를 찾기 위한 대표적인 알고리즘 : 평균 제곱 오차, 최대 신호 대 잡음비, 구조적 유사도 143 | 144 | ## 4.4 반응형 웹에서의 이미지 배치 전략 145 | 146 | 목표 : 반응형 웹의 문제점과 클라이언트 사이드인 웹 브라우저에서 이를 해결하는 방법을 알아보자 147 | 148 | 149 | 150 | 과거) 151 | 152 | 엠닷사이트 : 기존 데스크톱용 도메인의 www부분을 m으로 바꾸어 사용 153 | 154 | 단점 155 | 156 | - 기기 크기가 다양해짐 ->엠닷 사이트 하나만으로 모든 기기의 사용자들을 대응할 수 없어짐 157 | - 유지 보수의 문제점 : 모바일 버전 사이트를 동시에 개발하고 관리해야함 158 | - 모바일 사용자의 사용성 문제 : 유지보수가 어려워짐에 따라 몇 가지 중요한 기능들이 누락되거나, UI/UX가 달라져 불편을 겪게됨 159 | 160 | 161 | 162 | 반응형 웹의 등장 163 | 164 | - 동일한 웹사이트가 각 기기 화면에 최적화된 구조로 변경되어 제공됨 165 | - 기기별 웹사이트를 구축하지 않아도 되기 때문에 유지보수의 필요성이 줄어듬 166 | - SEO 측면의 이점 167 | 168 | ### 4.4.1 반응형 웹의 문제점 169 | 170 | 초기, 성능 측면에서 효과적이지 않음 171 | 172 | 모바일 환경은 데스크톱 환경에 비해 열악하여 페이지 로딩 시간이 들여짐. LTE 환경에서 케이블에 비해 절반 정도의 데이터를 처리하고 2배 정도 시간 지연이 발생함. 173 | 174 | 데스크톱에 비해 모바일 기기의 GPU, 메모리 등의 사양이 좋지 않아 모바일 환경에서 페이지 로딩 시간이 더욱 길어짐. 175 | 176 | ### 4.4.2 원인은 이미지 177 | 178 | 사용자의 웹 환경에 따라 변하지 않는 이미지. 179 | 180 | 반응형 웹의 기본 기술 : 미디어 쿼리, 가변 그리드, 유동형 이미지 181 | 182 | 183 | 184 | 사용자의 기기 화면이 작아졌는데도 필요 이상의 웹 리소스들을 과하게 내려받는 현상을 세가지로 구분 185 | 186 | - 내려받아 줄이기 187 | - 내려받아 숨기기 188 | - 화면 바깥 부분 189 | 190 | ### 4.4.3 반응형 이미지 191 | 192 | 반응형 웹의 문제점 : 모바일 환경에서 필요하지 않은 리소스들을 과도하게 다운로드함 193 | 194 | 해결 : 사용자의 환경에 따라 적합한 이미지를 전송한다. 195 | 196 | 유동형 이미지 처럼 브라우저에서 다운로드한 후 처리하는 방법과는 다름. 197 | 198 | 사용자가 특정 환경에서 특정 이미지를 요청하면 그 환경에 맞도록 이미 변경된 이미지가 전송되는 것 199 | 200 | 과도한 이미지 다운로드 문제를 방지할 수 있다. 201 | 202 | 반응형 이미지 커뮤니티 그룹(RICG) 203 | 204 | ### 4.4.4 반응형 이미지 구현 방법 205 | 206 | 1. 프런트엔드 측면 207 | 208 | 미디어 쿼리를 사용해 클라이언트 환경을 파악한 후 그 환경에 맞는 이미지 파일을 호출하도록 웹을 구현 209 | 210 | img 태그의 srcset 속성이나 picture 태그를 사용하여 표준 방식으로 쉽게 구현가능 211 | 212 | 단점 : 과도한 사용시 프런트엔드 코드가 무거워져 성능에 영향을 줄 수 있음 213 | 214 | 2. 백엔드 측면 215 | 216 | 서버에서 클라이언트 환경에 맞는 이미지를 선택하여 전송하는 방법 217 | 218 | Clinent Hints를 이용해 정확한 클라이언트 환경을 서버에 전달 219 | 220 | 221 | 222 | #### 프런트엔드 측면 223 | 224 | - srcset과 size속성 225 | 226 | - picture 태그 227 | - Art direction 228 | - Client Hints 229 | - 이미지 지연 로딩 230 | - 모바일 우선 접근 231 | 232 | -------------------------------------------------------------------------------- /basic/4장-이미지-최적화/tococ.md: -------------------------------------------------------------------------------- 1 | # Chapter 04 이미지 최적화 2 | 3 | ## 4.1 이미지의 중요성 4 | 5 | - 직관을 중요시하는 우리나라 사용자 특성을 고려하여 많은 웹 사이트에서는 화려하고 선명한 이미지를 사용해 홈페이지를 꾸미는데 노력하고 있다. 6 | - 인터넷 초창기에는 1K 이상 크기의 이미지를 홈페이지에 올리는 것을 상상하기 어려웠지만 현재는 초고속 인터넷 시대에 접어들어 이미지의 크기가 점점 더 커지고 있는 추세이다. 7 | - 통계 자료를 살펴보면, 이미지 개수는 48개에서 56개로 17%증가했지만 이미지 크기는 419KB에서 1,854KB로 무려 340%나 증가한 것을 알 수 있다. 8 | 9 |
10 | 11 | **화소 밀도** 12 | 13 | - 화소 밀도란 물리 스크린 공간 안에 얼마나 많은 픽셀이 압축되어 있는가를 의미한다. 14 | - 화소 밀도는 1x, 2x와 같은 기기 픽셀 비율로 표현하고 이것은 단위 길이 안에 존재하는 픽셀의 개수를 상대적으로 나타내는 단위이다. 15 | - 같은 1인치 안에 픽셀 수가 많으면 많을수록 화소 밀도가 높으며, 화소 밀도가 높을수록 더 선명한 화면을 표현할 수 있다. 16 | - 40픽셀 이미지는 말 그대로 40픽셀의 너비를 가진 이미지 하나를 의미한다. 그러나 40포인트 이미지는 1x에서는 40픽셀, 2x에서는 80픽셀, 3x에서는 120픽셀의 너비를 가진 이미지를 뜻한다. 17 | - 따라서, 웹 디자이너가 하나의 이미지를 사용할 때 디스플레이를 고려해 여러 크기의 이미지들을 모두 준비해야한다. 18 | 19 |
20 | 21 | - 이러한 이미지의 특성은 웹 사이트의 성능에서 가장 중요한 역할을 한다. 22 | - 예를 들어, 비즈니스 부서에서는 구매자의 눈길을 끌기 위해 크고 선명하고 화려한 이미지들을 사용하도록 요구하는 반면 디자이너가 만든 고품질 이미지를 그대로 사용하면 웹 성능 문제로 고객 불만이 발생할 수 있기 때문이다. 23 | 24 |
25 | 26 | ## 4.2 디지털 이미지의 종류와 특성 27 | 28 | - 이미지를 잘 사용하려면 우선 이미지의 종류와 특성을 잘 파악해야한다. 즉, 사용될 기기 타입과 용도에 맞춰 적절한 이미지를 선택해야한다. 29 | - 예를 들어, 모바일 이미지에 PNG 타입을 사용하고 있지만 투명 기능이 필요하지 않다면 JEPG 타입으로 변환해 사용하는 것이 더 작은 크기의 이미지를 사용할 수 있는 방법이다. 30 | 31 | - KissMetric의 연구 결과에 따르면 페이지 로딩 시간이 1초 느려질 경우 상품을 구매하는 사용자의 비율이 약 7% 감소할 수 있다고 언급되는 것처럼 이미지 형식의 종류와 특징을 잘 파악하고 사용 목적 및 기기에 맞는 이미지를 선택하는 것이 웹 성능 향상뿐만 아니라 비즈니스에 도움이 되는 것을 알 수 있다. 32 | 33 |
34 | 35 | ### 4.2.1 래스터 이미지 vs 벡터 이미지 36 | 37 | - 디지털 이미지는 일반적으로 디지털 화면에 이미지들을 어떻게 표현하는지에 따라 레스터 이미지와 벡터 이미지로 분류된다. 38 | 39 | 40 | 41 | **레스터 이미지** 42 | 43 | - 레스터 이미지는 우리가 사용하는 대부분의 이미지 유형이다. 44 | - 작은 사각형 모양의 픽셀에 표현하고자 하는 색상 정보를 입력해 이를 컴퓨터로 표현하는 방식이다. 45 | - 또한 각각의 픽셀들이 모여 하나의 큰 이미지를 완성하기 때문에 사이즈가 크거나 품질이 더 좋은 이미지를 만들기 위해서는 그만큼의 정보를 담은 픽셀들을 추가해야만 컴퓨터가 이를 정상적으로 표현할 수 있다. 46 | 47 |
48 | 49 | **벡터 이미지** 50 | 51 | - 벡터 이미지는 그리고자 하는 대상의 수학적인 정보를 제공한다. 52 | - 벡터이미지는 메타 정보를 담고 있으므로 화면이 커지거나 작아진다고 해서 이 정보가 달라지지 않기 때문에 화면 스케일에 상관없이 항상 선명한 이미지를 표현할 수 있다. 53 | - 단, 그림이 복잡해지면 이를 표현하기 위한 정보가 기하급수적으로 늘어나며 이를 수학적인 정보로 표현하는 데에도 많은 제약이 있다. 54 | - SVG 파일은 텍스트 기반 콘텐츠이므로 gzip이나 brotli 같은 텍스트 압축 기법으로 간단히 최적화할 수 있다. 55 | 56 |
57 | 58 | ### 4.2.2 무손실 이미지 형식 vs 손실 이미지 형식 59 | 60 | - 이미지 형식을 구분하는 또 다른 기준은 이미지 정보의 손실을 허용하는 지 여부이다. 61 | - 원본 이미지의 정보 손실을 원하지 않으면 무손실 이미지라고 하고 필요에 따라 이동할 수 있는 형태를 만들기 위해 정보 손실을 어느 정도 허용하면 손실이미지라고 한다. 62 | - GIF, PNG는 무손실 이미지의 대표적 형식이다. 63 | 64 |
65 | 66 | **GIF** 67 | 68 | - GIF는 인터넷이 활성화된 이래 가장 처음으로 등장한 이동식 이밎 형식으로써 현재까지도 널리 사용되고 있다. 69 | - 사용할 수 있는 색이 256로 매우 제한적이다. 70 | - 화려한 색상의 복잡한 이미지보다 기업의 로고 같은 다소 단순한 형태의 이미지 표현에 적합하다. 71 | 72 |
73 | 74 | **PNG** 75 | 76 | - PNG는 256색만 사용할 수 있는 GIF의 단점과 특허 문제를 해결하기 위해 개발되었다. 77 | - 24비트 색상을 사용하므로 GIF보다 고품질 이미지를 표현할 수 있다. 78 | - 컬러 팔레트 PNG와 트루 컬러 PNG로 나눌 수 있는데 대부분 웹 사이트에서 사용되는 PNG는 알파 채널이 추가된 트루 컬러 PNG이다. 79 | 80 |
81 | 82 | **JPEG** 83 | 84 | - JPEG는 사진을 저장하는 사실상의 표준 형식이다. 85 | - JPEG는 사람의 눈이 인식할 수 있는 색상만 남기고 나머지를 제거하는 방식의 기술을 사용하여 이미지를 표시하는 데 필요한 정보를 줄인다. 그렇기 때문에 고해상도 이미지를 크게 압축한 파일로 저장할 수 있다. 86 | - JPEG는 사용자가 그 품질 값을 결정할 수 있다. 87 | - PNG 파일보다 크기가 훨씬 작지만 투명 기능이나 애니메이션 기능을 지원하지 않는다. 88 | 89 |
90 | 91 | **JPEG 2000** 92 | 93 | - JPEG 2000은 JPEG의 단점을 보완하려고 새롭게 개발한 이미지 형식이다. 94 | - JPEG의 압축 방식과 달리 새로운 방식을 사용하여 이미지 압축률을 높였다. 95 | - 무손실 압축 및 투명 기능, 애니메이션 기능을 지원하고 16, 24, 32비트 등 다양한 색상을 지원한다. 96 | - 그러나 다양한 기능이 포함된 만큼 다른 형식들에 비해 더 많은 프로세싱 자원이 필요하다. 97 | - 대부분의 브라우저에서 지원하지 않는다. 98 | 99 |
100 | 101 | **WebP** 102 | 103 | - WebP는 구글에서 개발하고 배포한 이미지 형식이다. 104 | - JPEG보다 개선된 공격적 압축 방식을 사용하여 파일 크기를 25% ~ 35% 정도 작게 만들 수 있다. 105 | - 무손실 압축, 애니메이션 기능을 지원한다. 106 | - WebP는 다른 이미지 형식들에 비해 압축률이 높지만 이미지 품질을 많이 낮추면 화질에 약간의 손실이 발생한다. 107 | 108 |
109 | 110 | **JPEG XR** 111 | 112 | - JPEG XR은 마이크로소프트사에서 개발한 이미지 형식이다. 113 | - JPEG에 비해 R/G/B에 해당하는 색상 채널당 더 많은 수의 채색을 허용해서 표현할 수 있는 색상 범위를 확장했다. 114 | - 무손실 압축 및 투명 기능을 지원한다. 115 | - 점진적 데이터 전송 기능도 지원한다. 116 | - 향상된 압축 기법으로 파일 크기를 크게 감소시킬 수 있다. 117 | - 단, 인터넷 익스플로러와 에지에서만 지원한다. 118 | 119 |
120 | 121 | ## 4.3 이미지 변환 기법 122 | 123 | - 이미지를 변환하는 주된 이유는 이미지 파일의 크기를 줄이기 위함이다. 124 | 125 |
126 | 127 | ### 4.3.1 무손실 압축 128 | 129 | - 무손실 압축을 하려면 각 이미지 유형을 다르게 처리해야한다. 130 | - 스크립트를 통해 압축을 자동화할 수 있다는 장점이 있다. 131 | 132 |
133 | 134 | **GIF** 135 | 136 | - 애니메이션이 포함되어 있지 않다면 압축률이 더 높은 PNG8이나 각 브라우저에 특화된 이미지 형식으로 변경하는 것을 권한다. 137 | - ImageMagicK, Giflossy, Gifsicle, gif2webp converter, ImageMagicK를 활용하여 GIF와 관련된 작업을 진행할 수 있다. 138 | 139 |
140 | 141 | **PNG** 142 | 143 | - PNG임을 알리는 구분자인 첫 8바이트의 서명을 제외하고 청크 형태로 이미지 정보를 저장한다. 144 | - 이미지 정보를 저장하는 것은 핵심 청크이다. 145 | - 정보성 청크 등 사용자 정의 청크를 추가할 수도 있지만 이러한 청크들은 대부분 웹 렌더링에 필요하지 않으므로 삭제할 수 있다. 146 | 147 | - PngCrush, Pngquant라는 도구를 활용하여 PNG와 관련된 작업을 진행할 수 있다. 148 | 149 |
150 | 151 | **JPEG** 152 | 153 | - JPEG 파일 안에는 이미지 정보 외에도 많은 메타 데이터가 포함되어 있다. 154 | - 주석 및 공백 155 | - 어도비 포토샾 같은 편집 애플리케이션 정보 156 | - 카메라 제조사 및 모델, 사진 촬영 날짜등 157 | - 위의 정보들은 이미지를 표시할 때 아무 도움이 되지 않기 때문에 제거해도 이미지 품질 손실 없이 파일 크기를 줄일 수 있다. 158 | 159 | - MozJPEG, libJpeg, Guetzli라는 도구를 활용하여 JPEG와 관련된 작업을 진행할 수 있다. 160 | 161 |
162 | 163 | ### 4.3.2 손실 압축 164 | 165 | - 손실 압축은 특정 이미지 정보를 누락, 즉 손실시켜 파일 크기를 줄이는 방법이다. 166 | - 예를 들어, 사람의 시각은 명암 차이에 민감하지만 채색 차이에 크게 민감하지 않는다. 따라서 이미지 색이 비슷한 부분을 하나의 색으로 통일해 그만큼의 정보를 손실시켜도 사용자는 눈치채지 못한다. 167 | - 손실 압축은 원하는 만큼의 화질을 얻지 못하는 위험이 있으므로 고화질의 사진을 저장해 감사하고 싶다면 손실 압축을 피해야한다. 168 | - 손실 압축 기법을 잘 활용하면 사용자의 시각적 경험은 훼손하지 않으면서도 로딩 속도를 눈에 띄게 향상시킬 수 있다. 169 | - 손실 압축을 하려면 기존 이미지 형식을 디코딩한 후 알고리즘에 따라 원하는 화질로 저하시켜 다시 원래 이미지 형식으로 인코딩해야 한다. 170 | 171 |
172 | 173 | **적절한 손실 압축 품질 지수** 174 | 175 | - 사용자의 경험을 해치지 않고 파일 크기를 크게 줄일 수 있는 손실 압축 품질 수준은 각 이미지 특성에 따라 최적의 품질 수준이 달라진다. 176 | - 손실 압축을 위한 최적의 품질 지수를 찾기 위해서는 원본 이미지와 손실 압축 이미지의 시각적 차이를 정량 계산할 수 있는 방법이 필요하다. 177 | 178 | - 평균 제곱 오차, 최대 신호 대 잡음 비, 구조적 유사도를 활용해서 두 이미지 간 차이를 정량적으로 수치화해 표현하려는 연구가 계속 진행되고 있다. 179 | 180 |
181 | 182 | **시각적 인지 능력을 고려한 자동 최적화 도구** 183 | 184 | - 여러 알고리즘을 사용해 사람이 인지하지 못할 정도의 이미지 최적화를 수행하는 것은 쉽지 않다. 185 | - 또한, 웹 사이트 내 모든 이미지 파일에 적용하려면 일련의 작업을 자동화해야한다. 186 | - Akami 같은 CDN 서비스 제공 업체에서는 이미지 트래픽 관련 자동 최적화 기능을 제공한다. 187 | - 개별 사용자의 화면 크기, DPI등의 정보를 고려하여 각각 적절한 수준으로 손실 압축을 수행하고 사용 브라우저에 적합한 이미지 형태로 변환해 전송한다. 188 | 189 |
190 | 191 | **브라우저 특화 이미지로 변환** 192 | 193 | - 모든 사용자의 웹 경험을 향상시키려면 하나의 이미지를 만들더라도 다양한 브라우저 특화 이미지 형태로 변환시켜 제공해야한다. 194 | - WebP와 JPEG2000 같은 도구는 위와 같은 수고를 덜어주는 형태별 이미지 변환 도구이다. 195 | 196 |
197 | 198 | ## 4.4 반응형 웹에서의 이미지 배치 전략 199 | 200 | - 반응형 웹이란 TV, PC, 태블릿, 스마트폰 등 각종 기기가 제공하는 화면 크기에 맞추어 최적화된 웹 페이지를 제공하는 것을 말한다. 201 | - 반응형 웹을 사용하면 동일한 웹 사이트가 각 기기 화면에 최적화된 구조로 변경되어 제공된다. 202 | - 반응형 웹을 사용하면 기기별로 웹 사이트를 구축하지 않아도 되므로 유지 보수의 필요성도 없어지고 모바일 사용자의 사용성도 개선되는 장점이 있다. 203 | 204 |
205 | 206 | ### 4.4.1 반응형 웹의 문제점 207 | 208 | - 하지만, 성능 측면에서 효과적이지 못하다는 단점이 존재한다. (웹 페이지의 무게는 반응적이기 못했기 때문) 209 | - 모바일 환경은 데스크톰 환경에 비해 열악하여 페이지 로딩 시간이 느려진다. 210 | - 또한, 데스크톱에 비해 모바일 기기의 GPU, 메모리 등의 사양이 좋지 않아 모바일 환경에서 페이지 로딩 시간은 더 길어질 것이다. 211 | - 결국 모바일 사용자를 위해 도입된 반응형 웹이 오히려 성능 저하로 인해 사용자 경험의 질을 저하시키는 모순이 발생한다. 212 | 213 |
214 | 215 | ### 4.4.2 원인은 이미지 216 | 217 | - 화면의 크기나 사용하는 기기가 바뀌어도 웹 사이트의 무게가 변하지 않는 다는 것이 반응형 웹의 문제였는데, 이 문제의 원인은 바로 사용자의 웹 환경에 따라 변하지 않는 이미지의 크기다. 218 | - 개발자들은 테스크톱이나 모바일 환경에서 모두 이미지를 제대로 보여줘야하기 때문에 데스크톱에 맞춘 이미지를 준비하는 게 대부분이다. 이러한 상황에서 사용자의 기기 화면이 작아졌다고 해서 웹 사이트의 무게가 달라지지 않는다. 219 | - 화면이 작아졌는데도 필요 이상의 웹 리소스들을 과하게 내려받는 현상은 아래 세 가지 유형으로 구분될 수 있다. 220 | - 내려받아 줄이기 221 | - 내려받아 숨기기 222 | - 화면 바깥 부분 223 | 224 |
225 | **내려받아 줄이기** 226 | 227 | - 화면의 이미지 크기가 작아진다고 해서 실제 이미지가 작아지지 않기 때문에 브라우저가 큰 이미지를 다운로드해 작게 축소하는 처리가 진행된다. 228 | - 이때 가로 x 세로 값이 명시되지 않기 때문에 실시간으로 이 값을 계산하는 추가 과정이 필요하다. 229 | - 결국 모바일 환경에서는 과도하게 큰 이미지를 다운로드하려고 네트워크를 낭비하게 되는 문제가 발생한다. 230 | 231 |
232 | 233 | **내려받아 숨기기** 234 | 235 | - 모바일 화면에 비해 데스크톱 화면의 크기는 훨씬 크기때문에 데스크톱 하면에는 비즈니스를 위해 더 많은 정보를 나타내는 것이 유리하다. 236 | - 바꿔 말하면 데스크톱 화면에는 모바일 화면에서는 불필요한 리소스들이 존재한다는 의미이다. 237 | 238 | - 모바일에는 필요없는 정보들을 숨기기 위해 CSS를 활용해서 숨기기 처리를 해주는 경우가 있다. 하지만, 브라우저는 CSS에 의해 숨겨진 이미지들도 모두 다운로드해 필요 이상으로 네트워크 자원을 소모하면서 로딩 시간을 지연시킨다. 239 | 240 |
241 | 242 | **화면 바깥 부분** 243 | 244 | - 화면 바깥 부분의 이미지들은 화면에 보이지 않지만 내려받아 숨기기처럼 모두 다운로드된다. 245 | - 만약 화면 바깥쪽 이미지들을 다운로드하기 위해 너무 오랜 시간이 허비된다면 전체 페이지의 로딩 시간이 늦어지고, 화면 안쪽 부분의 로딩 시간에도 영향을 준다. 246 | 247 |
248 | 249 | ### 4.4.3 반응형 이미지 250 | 251 | - 이러한 이미지 관련된 문제들을 해결하기 위해서는 사용자의 환경에 따라 그 환경에 적합한 이미지를 전송하면 된다. 252 | - 사용자가 특정 환경에서 특정 이미지를 요청하면 그 환경에 맞도록 이미 변경된 이미지가 전송되는 것이 반응형 이미지다. 253 | - 이를 통해, 앞에서 살펴본 과도한 이미지 다운로드 문제를 방지할 수 있다. 254 | 255 |
256 | 257 | ### 4.4.4 반응형 이미지 구현 방법 258 | 259 | - 반응형 이미지 구현은 프런트엔드와 백엔드 측면에서 구현될 수 있다. 260 | - 프론트엔드 측면에서의 구현은 미디어 쿼리를 사용해 클라이언트 환경을 파악한 후 그 환경에 맞는 이미지 파일을 호출하도록 웹 페이지를 구현하는 방법이다. 261 | 262 |
263 | 264 | **srcset과 size 속성** 265 | 266 | - srcset은 HTML의 img 태그 속성으로 사용자의 다양한 환경에 따라 다른 이미지 URL을 지정할 수 있도록한다. 267 | - srcset은 브라우저에 가장 적절한 이미지를 선택하도록 힌트를 주는 역할을 한다. 268 | - srcset은 내려받아 줄이기 문제를 어느 정도 해결해 주지만 이를 완벽하게 지원하진 않는다. 269 | 270 |
271 | 272 | **picture 태그** 273 | 274 | - picture 태그는 앞서 설명한 img srcset의 단점을 모두 보완한다. 또한 내부적으로 source 태그를 사용해 다양한 이미지 URL을 설정하게 한다. 275 | - 이때, 미디어 쿼리를 사용해 각 URL의 로딩 조건을 구체적으로 정의할 수 있다. 276 | - srcset과는 다르게 정의된 조건에 맞는 이미지만 사용하도록 브라우저를 강제할 수 있으면 조건에 맞지 않는 이미지는 다운로드하지 않는다. 277 | - 따라서 내려받아 숨기기와 내려받아 줄이기 문제를 모두 해결하는 가장 효과적인 방법이다. 278 | - 하지만, 모든 브라우저가 이 태그를 지원하지 않는다는 단점이 있다. 279 | 280 |
281 | 282 | **Art direction** 283 | 284 | - srcset과 picture를 사용해도 해결되지 않는 문제인 반응형 이미지가 사용자 환경에 따라 자동으로 변하지 않는 문제를 해결하기 위한 방법이 Art direction이다. 285 | - Art direction은 같은 이미지를 크기만 다르게 하는 것이 아니라 이미지의 특징이나 가치가 기기 특성에 따라 표현되도록 정교한 작업을 진행하는 것이다. 286 | 287 | - Art direction을 적용하려면 개발 및 운영에 많은 시간과 비용이 요구된다는 단점이 있다. 288 | 289 |
290 | 291 | **Client Hints** 292 | 293 | - picture 태그, srcset 속성과는 전혀 다른 접근법을 제공한다. 294 | - 웹 페이지를 호스팅하는 서버에서 사용자 환경을 고려해 응답할 내용을 최적화한 후 브라우저에 전달하는 방안이 도입되고 있는데 이때 사용자 환경을 서버에 표준 방식으로 전달하기 위해 Client Hints를 사용하도록 논의되고 있다. 295 | 296 |
297 | 298 | **이미지 지연 로딩** 299 | 300 | - 나타내지 않을 이미지를 처음부터 다운로드하는 것은 웹 성능을 저하시킨다. 301 | - 해당 문제를 해결하기 위해서 자바스크립트를 사용한 지연 로딩 방법이 존재한다. 302 | - 사용자들에게 노출될 수 있는 상태일때만 해당 이미지를 다운로드하는 방법이라고 이해하면 된다. 303 | 304 |
305 | **모바일 우선 접근** 306 | 307 | - 모바일 우선이란 모바일 기기에 적합한 페이지부터 개발하는 방법이다. 308 | - 모바일 사용자가 데스크톱 사용자를 넘어섰고 앞으로도 더 증가할 추세라면 모바일 우선 접근법을 사용하는 것도 모바일 페이지 성능을 개선하는 방법이 될 수 있다. 309 | 310 |
311 | 312 | ## 4.5 적응형 이미지 전략 313 | 314 | - 앞에서는 반응형 웹의 문제점과 클라이언트 사이드인 웹 브라우저에서 이를 해결하는 방법을 설명했다. 315 | - 하지만 해당 방법을 사용하게 되면 어떠한 상황에서는 하나의 이미지를 다운로드하기 위한 코드가 늘어나고 이미지가 많아질수록 웹 페이지의 크기가 커지는 문제가 발생할 수 있다. 316 | - 이를 해결하고자 서버 측 반응형 웹 접근 방법이 등장하게 되었다. 317 | 318 |
319 | 320 | ### 4.5.1 적응형 이미지 아키텍처 321 | 322 | - 적응형 이미지 아키텍처는 다음 두 부분에서 기존 웹 아키텍처와 다르다. 323 | - 요청 클라이언트 정보를 감지 324 | - 클라이언트 맞춤형 데이터를 로딩하는 서버 로직 추가 325 | - 적응형 이미지 아키텍처에서 가장 근본적이고 중요한 부분은 클라이언트의 정보를 어떻게 감지하느냐이다. 326 | - 서버 측 반응형 웹에서는 HTTP 요청 정보 외에 클라이언트의 정보를 알 길이 없기 때문이다. 327 | - HTTP 요청의 User-Agent 헤더를 통해 클라이언트의 정보를 알 수 있다. 328 | 329 |
330 | 331 | ### 4.5.2 기기 정보에 따라 서버 로직 수행 332 | 333 | - 클라이언트의 정보를 통해 기기와 관련된 정보들을 수집했다면 클라이언트 환경에 맞는 이미지 파일을 링크에 연결한다. 334 | 335 |
336 | 337 | ### 4.5.3 브라우저별 이미지 전달 338 | 339 | - 브라우저별 이미지는 HTTP 요청의 Accept 헤더를 참고해 결정할 수 있다. 340 | 341 |
342 | 343 | ### 4.5.4 캐시 고려 사항 344 | 345 | - 서버 측 반응형 웹이나 이에 따른 적응형 이미지를 구성할 때 성능을 고려해 이미지를 캐시하는 경우가 많다. 346 | - 적응형 이미지는 동일한 URL을 사용해도 사용자 기기에 따라 서로 다른 이미지가 응답될 수 있으므로 이에 따른 캐시 충돌 현상에 주의해야한다. 347 | - 캐시 충돌 현상은 하나의 URL에 여러 개의 다른 콘텐츠가 응답할 수 있을 때 먼저 응답하는 콘텐츠만 캐시되는 현상이다. 348 | - 이러한 현상을 피하려면 서버에서 응답할 때 Vary 헤더를 활용해서 특정 헤더에 따라 콘텐츠가 달라질 것이라고 캐시 서버에 알려줘야한다. 349 | -------------------------------------------------------------------------------- /basic/5장-웹에서-가속을-이끌어-내는-방법/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 05 웹에서 가속을 이끌어 내는 방법 2 | 3 | 5.1 웹 브라우저 현황 알아보기 4 | 5 | 5.2 웹 브라우저 동작 이해하기 6 | 7 | 5.2.1 브라우저 아키텍처 8 | 9 | 5.2.2 중요 렌더링 경로 10 | 11 | 5.3 브라우저 렌더링 최적화하기 12 | 13 | 5.3.1 DOM 최적화하기 14 | 15 | 5.3.2 자바스크립트와 CSS 배치하기 16 | 17 | 5.3.3 자바스크립트 최적화하기 18 | 19 | 5.3.4 CSS 최적화하기 20 | 21 | 5.3.5 이미지 로딩 최적화하기 22 | 23 | 5.4 도메인 분할 기법 이용하기 24 | 25 | 5.4.1 도메인 분할 기법과 HTTP/2 26 | 27 | 5.5 사용자 경험 개선하기 28 | 29 | 5.5.1 사용자 경험 지표 바로 알기 30 | 31 | 5.5.2 사용자 요청에 빠르게 반응하기 32 | 33 | 5.5.3 사용자 시선 붙잡기 34 | 35 | 5.5.4 사용자 상호 작용 방해하지 않기 36 | -------------------------------------------------------------------------------- /basic/5장-웹에서-가속을-이끌어-내는-방법/rita.md: -------------------------------------------------------------------------------- 1 | # Chapter 05 웹에서 가속을 이끌어 내는 방법 2 | 3 | ## 5.1 웹 브라우저 현황 알아보기 4 | 5 | 프런트엔드 최적화의 핵심 : 브라우저가 페이지를 화면에 렌더링하는 방식을 이해하고 이를 최적화하는 것 6 | 7 | ## 5.2 웹 브라우저 동작 이해하기 8 | 9 | 1. 브라우저는 도메인 서버와 통신하여 접속하려는 호스트의 IP를 찾는다 10 | 2. 해당 아이피를 가진 서버와 통신을 시도해 TCP 연결을 맺는다 11 | 3. HTTPS에선 암호화된 연결을 생성하려는 협의 단계가 더 추가된다 12 | 4. 이후 연결이 맺어지면 브라우저는 서버로부터 필요한 리소스들을 다운로드해 이를 화면에 표현한다 13 | 14 | 15 | 16 | - 브라우저 리소스 다운로드 과정 17 | 18 | 방문페이지(landing page)의 HTML을 서버에 요청해 다운로드한다. 19 | 20 | HTML의 구문을 분석(parsing)하며 HTML 태그에 참조된 CSS, JavaScript, Image, font등 하위 리소스들을 차례로 다운로드함 21 | 22 | ### 5.2.1 브라우저 아키텍처 23 | 24 | 1. 유저 인터페이스 25 | 26 | 2. 브라우저 엔진 27 | 28 | 3. 렌더링 엔진 29 | 30 | 4. 네트워킹 31 | 32 | 5. UI 백엔드 33 | 34 | 6. 자바스크립트 해석기 35 | 36 | 7. 데이터 저장소 37 | 38 | ![브라우저 레퍼런스 아키텍처](https://user-images.githubusercontent.com/48556400/148060008-2d37d58e-62b6-4793-a700-ded9b48f2f45.jpg) 39 | 40 | ### 5.2.2 중요 렌더링 경로 41 | 42 | 렌더링 엔진이 웹 페이지를 구문 분석해 화면에 표현하는 일련의 작업은 단일 스레드에 의해 수행됨 43 | 44 | ![0_A24XmmK2IUz0wvkg](https://user-images.githubusercontent.com/48556400/148215881-043d3233-e76c-473c-8b3f-72ea6cfe47d9.png) 45 | 46 | 1. 브라우저는 HTML을 가장 처음 구문 분석하며 DOM 트리를 만듬 47 | 2. CSS를 구문 분석하여 CSSOM 트리를 만듬 48 | 3. 두 개의 트리 모델을 결합해 최종적으로 렌더 트리를 만듬 49 | 4. 렌더 트리가 생성되면 브라우저는 이를 기반으로 페이지 구조를 결정하고 화면에 표현 50 | 51 | ## 5.3 브라우저 렌더링 최적화하기 52 | 53 | ### 5.3.1 DOM 최적화하기 54 | 55 | - HTML의 구문 오류를 최소화하는 것이 가장 기본적이고 간단한 방법 56 | 57 | HTML을 DOM으로 전환하는 과정은 구문 분석이 관대하다는 점에서 XML과 다름 58 | 59 | HTML은 구문 체크에 관대하므로 작성 시 문법 오류가 발생해도 브러우저에는 정상적으로 표현되는 경우가 많음 60 | 61 | 웹 페이지 내에 오류가 많을수록 브라우저는 예외처리를 위해 더 많은 메모리와 CPU 파워를 소모함 62 | 63 | - 과도하게 HTML 태그를 중첩하는 행위를 피할 것 64 | 65 | 자바스크립트에 의해 스타일이 변경될 때 각 태그의 레이아웃을 다시 계산하고 재구성하는데 더 많은 리소스와 시간이 소요됨 66 | 67 | 일반적으로 중첩된 태그가 15단계를 넘지 않도록 권장 68 | 69 | - DOM을 분석해 최적화 방안을 알려주는 무료 도구 DOM Monster 70 | 71 | ### 5.3.2 자바스크립트와 CSS 배치하기 72 | 73 | - CSS와 자바스크립트의 렌더링 방해를 피하려면 CSS를 최대한 소스 위쪽에 배치하여 CSSOM이 빨리 생성되도록 한다 74 | 75 | ### 5.3.3 자바스크립트 최적화하기 76 | 77 | - 자바스크립트가 전체 페이지 로딩 시간에 영향을 주는 것을 막기 위해, 자바스크립트 수행이 렌더링 스레드를 방해하지 않도록 별도 스레드로 자바스크립트를 수행시켜야함 78 | 79 | - 렌더링 작업이 어느 정도 끝난 이후 스크립트를 수행해야함 80 | 81 | - async와 defer 속성을 사용하기 82 | 83 | async : HTML 구문 분석과 동시에 자바스크립트를 다운로드하고 수행. 지연 수행시 스크립트간 선후 관계를 따지지 않음 84 | 85 | defer : 구문 분석 중에 별도의 스레드로 자바스크립트를 다운로드하고 구문 분석이 끝난 이후에 수행. 스크립트가 호출된 순서에 따라 차례로 수행 86 | 87 | 참고 : [모던 자바스크립트 Deep Dive 38장 브라우저의 렌더링 과정](https://github.com/Frontend-Divers/modern-javascript-deep-dive/tree/master/38%EC%9E%A5-%EB%B8%8C%EB%9D%BC%EC%9A%B0%EC%A0%80%EC%9D%98-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B3%BC%EC%A0%95#async-%EC%96%B4%ED%8A%B8%EB%A6%AC%EB%B7%B0%ED%8A%B8) 88 | 89 | - 주의 : 모든 자바스크립트가 비동기나 지연 처리의 대상이 될 수 없다 90 | 91 | - 브라우저가 페이지 로딩을 명시적으로 끝낸 후 나머지 스크립트를 수행하는 것이 확실한 방법 92 | 93 | ### 5.3.4 CSS 최적화하기 94 | 95 | 브라우저는 CSS가 구문 분석되고 CSSOM이 만들어지기까지 렌더링을 멈추므로 CSS는 렌더링 순위가 가장 높으면서 동시에 렌더링을 가장 방해하는 리소스 96 | 97 | CSS는 필요한 정보만 빠르게 다운로드하고 실행해야 브라우저 렌더링을 가속시킬 수 있다. 98 | 99 | - 미디어 쿼리 활용 100 | 101 | ### 5.3.5 이미지 로딩 최적화하기 102 | 103 | - display none 속성을 사용해, 이미지가 숨겨질 것을 미리 알도록 함 104 | 105 | 그러나 DOM과 CSSOM이 별도 분석되고 생성되기에 브라우저는 이를 미리 알지 못하고 DOM 트리에 나타난 객체들을 모두 다운로드함 106 | 107 | - 화면 렌더링에 필요하지 않은 이미지를 다운로드 하지 않으려면 108 | 109 | 1. 웹사이트의 주요 이미지가 아니라면 CSS의 background-image 속성을 사용 110 | 2. 자바스크립트를 이용한 지연 로딩 방식을 적용 111 | 3. Progressive JPG 사용 112 | 113 | - 주의 : 이미지 지연 로딩이 브라우저 로딩 속도 개선에 효과적일 수 있으나 사용자 경험 개선에 항상 도움이 되진 않음. 모든 이미지에 지연 로딩을 적용하면 브라우저의 프리로더가 이미지를 다운로드할 수 없기에 오히려 성능을 저해함. 114 | 115 | 즉, 지연 로딩은 첫화면에 등장하지 않거나 숨겨진 이미지들을 다운로드하는데에만 사용 116 | 117 | ## 5.4 도메인 분할 기법 이용하기 118 | 119 | 여러 도메인을 소유한 경우 웹 콘텐츠를 병렬적으로 동시에 다운로드할 수 있도록 120 | 121 | HTTP/1.1 프로토콜 하에서 동일 도메인에 순차적 다운로드 방식을 사용 122 | 123 | ### 5.4.1 도메인 분할 기법과 HTTP/2 124 | 125 | ## 5.5 사용자 경험 개선하기 126 | 127 | ### 5.5.1 사용자 경험 지표 바로 알기 128 | 129 | ### 5.5.2 사용자 요청에 빠르게 반응하기 130 | 131 | ### 5.5.3 사용자 시선 붙잡기 132 | 133 | ### 5.5.4 사용자 상호 작용 방해하지 않기 -------------------------------------------------------------------------------- /basic/5장-웹에서-가속을-이끌어-내는-방법/tanney.md: -------------------------------------------------------------------------------- 1 | # Chapter 05 웹에서 가속을 이끌어 내는 방법 2 | 3 | ## 5.1 웹 브라우저 현황 알아보기 4 | 5 |
6 | 7 | - 데스크탑, 모바일을 막론하고 크롬의 점유율이 과반수 8 | - 그럼에도 한국에서는 MS의 브라우저(IE, Edge)의 점유율이 꽤 높은 것이 사실이다. 9 | - 이미지 형식, 폰트 등 점유율이 높은 브라우저에 맞게 준비할 필요가 있다. 10 | 11 |
12 | 13 | ## 5.2 웹 브라우저 동작 이해하기 14 | 15 |
16 | 17 | - 사용자가 주소 입력창에 웹 사이트 주소를 입력했을 때, 브라우저의 동작은 다음과 같다. 18 | - 도메인 서버와 통신하여 호스트의 IP를 찾는다. 19 | - 해당 IP를 가진 서버와 TCP 연결을 맺는다. 20 | - HTTPS에서는 암호화된 연결을 생성하려는 협의 단계가 추가된다. 21 | - 연결이 맺어지면 서버로부터 필요한 리소스들을 다운로드한다. 22 | - 서버에서 가져온 리소스를 통해 화면을 구성한다. 23 | - 브라우저의 리소스 다운로드 과정 24 | - 방문하는 페이지의 HTML 문서를 서버에 요청해 다운로드한다. 25 | - HTML 문서를 분석하면서 HTML 태그에 참조된 CSS, JS, 이미지, 폰트 등의 하위 리소스들을 차례로 다운로드한다. 26 | 27 |
28 | 29 | ### 5.2.1 브라우저 아키텍처 30 | 31 |
32 | 33 | 브라우저의 구성요소는 크게 7개의 컴포넌트로 나뉜다. 34 | 35 |
36 | 37 | 1. 유저 인터페이스 38 | - 사용자가 브라우저를 통해 상호 작용하도록 돕는다. 39 | - 주소 입력창, 북마크, 앞뒤 버튼 등이 이에 해당한다. 40 | - 브라우저별로 차별화된 기능을 제공하기도 한다. 41 | 2. 브라우저 엔진 42 | - 유저 인터페이스와 렌더링 엔진 사이에서 렌더링 상태를 조회하고 렌더링 작업을 제어하기 위한 인터페이스를 제공 43 | 3. 렌더링 엔진 44 | - HTML이나 CSS를 분석해 실제 웹컨텐츠를 브라우저 창에 그리는 역할 45 | - Webkit(사파리), Gecko(파이어폭스), Blink(크롬), Trident(IE) 등의 렌더링 엔진이 있다. 46 | 4. 네트워킹 47 | - HTTP 요청을 보내고 응답을 받는 역할 48 | - DNS 조회, TCP 연결 생성등을 수행 49 | - 브라우저 별로 6-10개 스레드로 동시에 네트워킹을 수행할 수 있다. 50 | 5. UI 백엔드 51 | - 콤보박스, 드롭박스 등 기본적인 UI 컴포넌트를 제공 52 | 6. 자바스크립트 해석기 53 | - V8, Spider Monkey 등의 엔진을 통해 자바스크립트를 분석하고 해석한다. 54 | 7. 데이터 저장소 55 | - 쿠키, 웹 스토리지, 인덱스 DB 등을 이용해 데이터를 저장 56 | 57 |
58 | 59 | ### 5.2.2 중요 렌더링 경로 60 | 61 |
62 | 63 | - 렌더링 엔진이 화면을 그리는 작업은 선후 관계가 비교적 명확하므로 단일 스레드에 의해 수행된다. 64 | - 브라우저의 중요 렌더링 경로는 다음과 같다. 65 | ![critical-rendering-path](https://user-images.githubusercontent.com/57767891/148157676-9c817cb4-97e6-48e9-8630-9633dab0eba1.png) 66 | 67 |
68 | 69 | #### 1. DOM트리 생성 70 | - HTML의 태그를 하나하나 해석해 DOM이라는 객체 모델로 변환한다. 71 | - DOM은 객체지향 프로그래밍 언어들로 HTML이나 XML 형태의 마크업 문서를 조작하기 위해 규정한 인터페이스이다. 72 | - DOM은 객체의 속성과 메서드, 이벤트 등을 정의한다. 73 | - 브라우저의 분석기는 HTML문서를 위에서부터 순차적으로 분석해 부모노드와 자식노드의 관계를 파악해 DOM트리를 생성한다. 74 | 75 |
76 | 77 | #### 2. CSSOM트리 생성 78 | - CSSOM은 DOM과 비슷하게 CSS를 처리하기 위한 트리 구조의 인터페이스이다. 79 | - HTML 문서를 분석하다 CSS를 참조하는 링크를 만나면 CSS리소스를 다운로드하고 이를 분석한다. 80 | - 이때 CSS분석은 다른 스레드에서 동작하기 때문에 HTML 분석 과정이 방해 받지는 않는다. 81 | 82 |
83 | 84 | #### 3. 렌더트리 생성 85 | - DOM트리와 CSSOM트리를 병합해 렌더 트리를 생성한다. 86 | - 렌더링을 위한 최종 정보를 가진 렌더 객체들을 생성해 이들의 상하관계를 트리로 구성한다. 87 | - 하나의 렌더 객체는 하나의 박스모델을 나타낸다. 88 | - body 태그는 루트 노드로 대체 된다. 89 | - 렌더트리는 실제 화면에 그려질 노드들을 표현하기 때문에 `display:none` 스타일을 가지고 있는 노드는 제외 된다. 90 | 91 |
92 | 93 | #### 4. 레이아웃 94 | - 레이아웃은 렌드 트리 노드들의 위치 정보가 계산되는 단계이다. 95 | - 각 렌더 객체에 해당하는 박스모델의 크기와 위치를 계산한다. 96 | - 이러한 계산은 루트노드부터 시작된다. 루트 노드의 너비는 뷰포트의 크기로 지정된다. 97 | - 너비는 부모 => 자식 순으로 높이는 자식 => 부모 순으로 계산한다. 98 | - 부모의 높이가 특정 값으로 지정되어 있고 자식의 높이가 비율인 경우는? 99 | 100 |
101 | 102 | #### 5. 페인트 103 | - 페인트는 렌더 트리의 정보를 바탕으로 각 픽셀을 채우는 과정 104 | - 레이어 단위로 이루어진다. 105 | 106 |
107 | 108 | #### 5. 컴포지트 109 | - 여러 레이어를 쌓임 맥락에 맞게 합치는 작업 110 | 111 |
112 | 113 | ## 5.3 브라우저 렌더링 최적화하기 114 | 115 | ### 5.3.1 DOM 최적화하기 116 | 117 |
118 | 119 | - HTML 구문 오류 120 | - HTML 구문 분석 과정은 비교적 관대하다. 태그를 닫지 않거나 테이블을 중첩하는 등의 구문 오류가 있어도 대부분 화면을 정상적으로 표현한다. 121 | - 구문 오류에도 화면을 정상적으로 표현하기 위해 브라우저는 각 상황에 대한 예외 처리를 제공한다. 122 | - 즉, 오류가 많을수로 브라우저는 예외 처리를 위해 많은 메모리와 CPU 파워를 소모한다. 123 | - 따라서 HTML 구문 오류를 최소화하는 것이 웹 성능을 향상시키는 방법이 될 수 있다. 124 | 125 | - 과도한 태그 중첩 126 | - HTML 문서 구조가 복잡하게 작성되어 있으면 자바스크립트를 통해 스타일을 변경할 때 각 태그의 레이아웃을 다시 계산하고 재구성하는 데 더 많은 리소스와 시간을 소모한다. 127 | - 일반적으로 중첩 태그가 15단계를 넘지 않도록 작성하는 것을 권장한다. 128 | 129 | - DOM Monster 130 | - [DOM Monster](http://mir.aculo.us/dom-monster)를 통해 DOM 최적화를 위한 사항들을 확인 할 수 있다. 131 | 132 |
133 | 134 | ### 5.3.2 자바스크립트와 CSS 배치하기 135 | 136 |
137 | 138 | - HTML을 해석하는 중 자바스크립트를 만나면 해당 스크립트를 다운로드하고 수행이 완료될 때까지 DOM 생성 작업을 중단한다. 139 | - 자바스크립트에 의한 DOM 변경이 완료될 때까지 기다린다. 140 | - 자바스크립트에서 스타일 요소를 변경하려 할 경우 CSSOM 생성이 완료될 때까지 수행을 멈추고 기다린다. 141 | - 따라서 CSS는 최대한 소스 위쪽에 배치해 CSSOM이 가능한 빨리 생성되도록 해야한다. 142 | - 자바스크립트는 가능한 DOM과 CSSOM이 모두 생성된 이후 수행되도록 한다. 143 | 144 |
145 | 146 | ### 5.3.3 자바스크립트 최적화하기 147 | 148 |
149 | 150 | - 자바스크립트는 렌더링 방해 요소 중 하나이다. 151 | - 자바스크립트가 렌더링에 주는 영향을 막기위해 자바스크립트 별도의 스레드로 수행할 필요가 있다. 152 | - script태그의 async 속성과 defer 속성으로 이를 해결할 수 있다. 153 | - async 154 | - 별도의 스레드로 자바스크립트를 다운로드하고 실행한다. 155 | - 지연 수행 시 스크립트 간 선후 관계를 따지지 않는다. 156 | - defer 157 | - 별도의 스레드로 자바스크립트를 다운로드하고 HTML 분석이 끝난 이후 실행한다. 158 | - 스크립트가 호출된 순서에 따라 차례로 수행된다. 159 | 160 |
161 | 162 | ### 5.3.4 CSS 최적화하기 163 | 164 |
165 | 166 | - CSS는 렌더링 우선 순위가 가장 높으면서 렌더링을 가장 방해하는 요소이다. 167 | - CSS의 내용은 점점 무거워 지지만 기기에 따라 화면으로 볼 수 있는 내용은 제한적이다. 168 | - 숨겨져있는 부분이나 다른 기기를 위한 CSS까지 모두 한 파일로 받아오는 것은 렌더링을 지연시킨다. 169 | - 필요한 CSS 정보만 빠르게 다운로드하고 실행해야 브라우저 렌더링을 가속시킬 수 있다. 170 | - 필요한 페이지에 필요한 CSS 파일만 포함해야한다. 171 | - 첫 화면에 사용될 CSS 파일과 숨겨진 화면에 사용될 CSS파일을 분리해 후자의 CSS는 지연 수행시켜야한다. 172 | - 미디어 쿼리를 통해 조건에 맞는 CSS만 다운로드하도록 할 수 있다. 173 | ```html 174 | 175 | 176 | 177 | ``` 178 | - 숨겨진 화면에 적용될 CSS는 onLoad 이벤트 발생 이후 적용하도록 처리한다. 179 | ```html 180 | <--! critical css --> 181 | 182 | 183 | <--! non-critical css --> 184 | 185 | 186 | ``` 187 | 188 | ```js 189 | const lazyLoadCSS = () => { 190 | const styles = document.querySelectorAll("link"); 191 | 192 | styles.forEach(style => { 193 | const ref = style.getAttribute("defer-ref"); 194 | 195 | if (ref) { 196 | style.href = ref; 197 | } 198 | }); 199 | }; 200 | 201 | window.addEventListener("load", lazyLoadCSS); 202 | ``` 203 | 204 |
205 | 206 | ### 5.3.5 이미지 로딩 최적화하기 207 | 208 |
209 | 210 | - img태그 사용시 `display: none`속성에 의해 실제 렌더 트리에 추가되지 않더라고 이미지는 다운로드 하게 된다. 211 | - DOM트리와 CSSOM트리는 따로 생성되기 때문에! 212 | - 이러한 이미지의 다운로드를 막을 수 있다면 렌더링을 더욱 가속화할수 있다. 213 | - 이미지가 주요 이미지가 아니라면 background-image를 통해 처리할 수 있다. 214 | - CSS 분석시 display 속성을 알 수 있기 때문 215 | - 자바스크립트를 통한 지연로딩을 할 수 있다.(4장) 216 | - 지연로딩의 경우 사용자 경험에는 도움이 되지 않을 수 있다. 217 | - preloading이 불가하기 때문 218 | - Progressive JPG를 활용할 수 있다. 219 | - Progressive JPG는 초기에 저품질이미지를 다운 받고 점차 품질을 회복할 수 있게 분할 전송한다. 220 | 221 |
222 | 223 | ## 5.4 도메인 분할 기법 이용하기 224 | 225 |
226 | 227 | - 하나의 TCP 연결에서는 리소스들을 순차적으로 다운로드 해야한다. 228 | - 보통 브라우저는 동일 도메인 당 6~13개의 TCP 연결을 동시 생성할 수 있도록 허용한다. 229 | - 여러 도메인을 사용해 더 많은 리소스를 병렬적으로 다운로드 받을 수 있다면 더욱 성능을 끌어올릴 수 있다. 230 | - 예를 들어 www.beuccol.com라는 사이트에서 다음과 같이 추가 도메인을 디자인 할 수 있다. 231 | - img.beuccol.com 232 | - script.beuccol.com 233 | - api.beuccol.com 234 | - 그러나 너무 많은 도메인은 오히려 성능을 해친다. 235 | - 동시 다운로드 수가 많을 수록 브라우저는 더 많은 CPU리소스를 사용하기 때문 236 | - 각 도메인에 대한 DNS 조회도 고려해야한다. 237 | - 따라서 여러 상황을 고려해 도메인 수를 정해야한다. 238 | - 도메인의 수가 정해지면 그 수에 맞게 리소스를 균등 분할해야한다. 239 | - 특정 도메인에서만 많은 리소스를 담당하면 다른 도메인들은 오히려 TCP연결을 위한 리소스만 낭비하는 꼴이 된다. 240 | - 리소스의 성격에 따라 도메인을 나눌 수도 있지만 동적으로 도메인을 나눌 수도 있다. 241 | - 정확한 리소스 분배를 위해 리소스 성격보다는 배포 시점에 동적으로 도메인을 나누는 것이 권장된다. 242 | - 이때 특정 리소스가 항상 같은 도메인에 배정되어야 캐시 적중률이 높아진다. 243 | - 해시를 통해 특정 리소스를 같은 도메인에 배정할 수 있다. 244 | 245 |
246 | 247 | ### 5.4.1 도메인 분할 기법과 HTTP/2 248 | 249 |
250 | 251 | - HTTP/2에서는 멀티플렉싱 기술로 인해 도메인 분할 기법을 사용할 이유가 사라졌다. 252 | - 오히려 이 기법이 HTTP/2의 헤더 압축 전송, 우선순위 전송, 서버푸시 기능 등을 방해한다고 한다. 253 | - 최근 브라우저들은 HTTP/2의 기능을 저해하지 않으면서 다중 도메인을 사용할 수 있는 방법을 제공한다. 254 | - TCP 연결을 병합하는 방식 255 | - 브라우저가 첫 번째 도메인과 맺은 TCP 연결을 나머지 도메인에 재사용하는 방식 256 | - 이때 각 도메인이 동일한 IP 주소를 반환해야한다. 257 | - 그리고 동일한 인증서를 사용해야한다. 258 | 259 |
260 | 261 | ## 5.5 사용자 경험 개선하기 262 | 263 | ### 5.5.1 사용자 경험 지표 바로 알기 264 | 265 |
266 | 267 | - 페이지 로딩 시점이 시각적으로 로딩을 완료한 시점은 아니다. 268 | - 웹사이트의 성능 지표가 브라우저 이벤트(load) 중심 지표에서 사용자 중심 지표로 변화하고 있다. 269 | - 사용자 중심 지표 270 | - WebPageTest의 Speed Index 271 | - 시간에 따른 웹사이트의 시각적 진행상태를 수치화한 지표 272 | - 값이 작을 수록 시각적 진행 상태가 빠르다는 것을 의미한다. 273 | - 페이지 로드 시점까지 시각적으로 완성되지 못한 부분의 면적을 계산한다. 274 | - FCP, LCP, TTI 등 275 | 276 |
277 | 278 | ### 5.5.2 사용자 요청에 빠르게 반응하기 279 | 280 |
281 | 282 | - 사람은 응답속도가 100ms 늦어질 때 이를 인지하고 1초가 지나면 지연으로 인식한다. 283 | - 즉, 사용자의 행동에 대해 적어도 1초 안에 반응해야 자연스럽게 그 다음 반응을 기대한다. 284 | - TTFB의 경우 300~500ms가 이상적이다. 285 | - 이를 위해 HTML 문서의 크기를 최대한 줄이고 캐시될 수 있도록 해야한다. 286 | - HTML이 다운로드되면 리소스들을 빠르게 로딩시켜 1초 이내 렌더링을 시작해야 사용자가 지연을 느끼지 않는다. 287 | - CSS, 자바스크립트의 크기를 줄인다.(minimize) 288 | - 개발자 도구 => Customize and control DevTools => More tools => Coverage 모듈을 통해 페이지에서 실제 사용되는 코드를 알 수 있다. 289 | - 이를 통해 코드를 분리하는 것을 권장한다. 290 | - HTTP/2에 경우 요청 수와 관계없이 전체 리소스 크기를 줄여야 다운로드 속도가 향상된다. 291 | - critical resource와 non-critical resource를 구분하자. 292 | - 기본적으로 above the fold에 대한하는 컨텐츠를 렌더링하기 위한 파일들이 critical resource에 해당한다. 293 | - preload 사용 294 | - HTTP/2 서버 푸시 활용 295 | - 서버 푸시는 클라이언트가 요청하지 않은 리소스를 서버에서 제공해주는 방식을 의미한다. 296 | - 클라이언트가 HTML 문서를 요청한 경우 HTML에 포함되어 있는 리소스도 같이 보내줄 수 있다. 297 | - 최초 HTML이 다운로드 되는 시점에 이루어지기 때문에 preload보다 더 빠르게 critical resource를 다운받을 수 있다. 298 | - non-critical resource에 경우 defer나 async 속성을 통해 지연 로드한다. 299 | - CSS에 경우에도 JS를 사용해 지연 로딩한다. 300 |
301 | 302 | ### 5.5.3 사용자 시선 붙잡기 303 | 304 |
305 | 306 | - 브라우저가 빠르게 화면 렌더링을 시작해도 2초 안에 의미 있는 컨텐츠가 표현되지 않으면 사용자가 사이트를 이탈할 가능성이 높다. 307 | - 사용자가 이탈하지 않도록 시선을 붙잡으려면 Hero 이미지가 가능한 빠르게 화면에 로딩되어야 한다. 308 | - Hero 이미지를 지연로딩에 포함시키지 않아야한다. 309 | - Hero 이미지 사용시 preload속성을 사용한다. 310 | - Hero가 background-image로 지정되어 있으면 늦게 로딩 될 수 있다. 311 | - img 태그나 picture태그로 지정된 이미지는 HTML 분석 시 다운로드 되지만 CSS background에 경우 CSS 분석 후 DOM에 적용될 때 다운로드 되기 때문 312 | - background로 지정되어 있으면 프리로더에도 적용되지 않는다. 313 | - 메인 텍스트에 사용되는 폰트 또한 prelaod를 적용한다. 314 | - 폰트에 경우 경량화된 서브셋 폰트를 사용해 크기를 줄일 수 있다. 315 | - 폰트 로딩 방식에는 두가지가 있다. 316 | - 웹폰트를 완전히 다운로드한 후 텍스트를 나타내는 FOIT(Flash Of Invisible Text) 방식 317 | - 시스템 폰트를 먼저 사용 후 웹 폰트가 다운로드 되면 대체 하는 FOUT(Flash Of Unstyled Test) 방식 318 | - 크롬에서는 3초까지는 FOIT, 이후에는 FOUT방식을 사용한다. 319 | - FOUT을 강제하려면 font-face 룰에서 font-display 속성을 swap으로 바꾼다. 320 | 321 |
322 | 323 | ### 5.5.4 사용자 상호 작용 방해하지 않기 324 | 325 |
326 | 327 | - 화면이 시각적으로 완성되어도 버튼 클릭, 스크롤 등 상호 작용이 원할하지 않으면 사용자들은 불편함을 느낀다. 328 | - TTI나 FID(First Input Delay) 같은 지표를 사용해 이를 평가할 수 있다. 329 | - TTI는 CPU 유휴 시간과 네트워크 사용량 등 클라이언트의 물리적 지표에 의해 결정된다. 330 | - 따라서 다운로드하는 리소스의 양, 수행 스크립트를 줄이는 것이 중요하다. 331 | -------------------------------------------------------------------------------- /basic/5장-웹에서-가속을-이끌어-내는-방법/tococ.md: -------------------------------------------------------------------------------- 1 | # Chapter 05 웹에서 가속을 이끌어 내는 방법 2 | 3 | ## 5.1 웹 브라우저 현황 알아보기 4 | 5 | - 웹 페이지를 경량화하고 요청 수를 줄여도 HTML을 화면에 그리는 것은 결국 웹 브라우저이다. 따라서 브라우저가 페이지를 화면에 렌더링하는 방식을 이해하고 이를 최적화하는 것이 프론트엔드 최적화의 핵심이다. 6 | 7 | - 웹에는 다양한 브라우저가 존재하고 그 중에서도 크롬 브라우저가 현재 전 세계에서 가장 많이 사용되고 있다. 8 | 9 | - 여러 가지의 브라우저가 존재하고 있고 각각의 브라우저는 각자의 특징을 가지고 작동하지만 웹페이지를 전송하고 렌더링하는 방식에는 큰 차이가 없이 표준 방식으로 작성된 html을 해석하고 이에 맞도록 객체를 생성하며 화면 크기에 맞추어 원하는 그림을 그릴 수 있다. 10 | 11 |
12 | 13 | ## 5.2 웹 브라우저 동작 이해하기 14 | 15 | - 사용자가 입력창에 접속하고자 하는 웹 사이트 주소를 입력함으로써 브라우저의 동작이 시작된다. 16 | 17 | - 브라우저는 가장 먼저 도메인 서버와 통신하여 접속하려는 호스트의 IP를 찾는다. 18 | 19 | - 해당 아이피를 가진 서버와 통신을 시도해 TCP 연결을 맺는다. 20 | 21 | - HTTPS에선 암호화된 연결을 생성하려는 협의 단계가 더 추가된다. 22 | 23 | - 연결이 맺어지면 브라우저는 서버로부터 필요한 리소스들을 다운로드해 이를 화면에 표현한다. 24 | 25 |
26 | 27 | - 브라우저가 리소스를 다운로드할 때는 먼저 방문 페이지의 HTML을 서버에 요청해 다운로드한다. 그리고 HTML의 구문을 분석하면서 HTML 태그에 참조된 CSS, 자바스크립트, 이미지, 폰트 등의 하위 리소스들을 차례로 다운로드한다. 28 | 29 | - 브라우저는 리소스들을 다운로드하며 동시에 개발자가 원하는 대로 화면에 페이지를 그리는 작업을 수행한다. 이렇게 화면을 그리는 일련의 절차를 렌더링 경로라고 한다. 30 | 31 |
32 | 33 | ### 5.2.1 브라우저 아키텍처 34 | 35 | - 아래는 브라우저의 구성 요소들이다. 36 | 37 | - 유저 인터 페이스 38 | 39 | - 사용자가 브라우저를 통해 상호 작용할 수 있도록 돕는다. 40 | 41 | - 브라우저 엔진 42 | 43 | - 유저 인터페이스와 렌더링 엔진 사이에서 렌더링 상태를 조회하고 렌더링 작업을 제어하기 위한 인터페이스를 제공한다. 44 | 45 | - 렌더링 엔진 46 | 47 | - HTML을 분석하여 그대로 표현하거나 CSS를 분석해 웹 페이지를 멋지게 꾸미기도 하는 등 실제 웹 콘텐츠를 원하는 대로 브라우저 창에 그리는 역할을 한다. 48 | 49 | - 네트워킹 50 | 51 | - 네트워크를 통해 HTTP 요청을 보내고 응답받는 역할을 한다. 52 | 53 | - UI 백엔드 54 | 55 | - 콤보박스, 드롭박스 등 기본적인 UI 컴포넌트들을 제공한다. 56 | 57 | - 자바스크립트 해석기 58 | 59 | - V8, Spider Monkey 등의 엔진을 사용하여 자바스크립트를 분석하고 해석한다. 60 | 61 | - 데이터 저장소 62 | 63 | - 데이터 지속성을 유지하기 위한 컴포넌트이다. 64 | 65 | - 가장 흔하겡는 쿠키 값을 로컬 디스크에 저장한다. 66 | 67 | - 사용자 요청을 처리하고 웹 사이트를 표현하기 위해 위의 모든 컴포넌트들이 유기적으로 동작한다. 실제로 HTML을 처리해 화면에 렌더링하는 컴포넌트는 `렌더링 엔진`이다. 68 | 69 |
70 | 71 | ### 5.2.2 중요 렌더링 경로 72 | 73 | - 렌더링 엔진이 웹 페이지를 구문 분석해 화면에 표현하는 일련의 작업은 선후 관계가 비교적 명확하므로 단일 스레드에 의해 수행된다. 74 | 75 | - ex) HTML이 해석되지 않으면 CSS와 자바스크립트가 수행될 수 없고, 객체 모델이 만들어지지 않으면 브라우저가 화면을 구성할 수 없으며, 화면 구성을 하지 못하면 결국 페이지를 그릴 수 없다. 따라서, 일련의 작업을 브라우저가 어떤 순서로 처리하는지 이해하는 것은 웹 최적화뿐만 아니라 웹 개발에 있어서도 매우 중요하다. 76 | 77 | - 아래의 과정을 통해서 렌더링이 된다. 78 | 79 | - **DOM 트리 생성** 80 | 81 | - 브라우저는 가장 먼저 다운로드한 HTML의 구문을 분석해 태그를 하나하나 해석하여 DOM이라는 객체 모델로 변환한다. 82 | 83 | > DOM은 객체 지향적 프로그램 언어들로 HTML이나 XML 형태의 마크업 문서들을 손쉽게 프로그래밍하기 위해 표준으로 규정한 프로그램 인터페이스이다. 84 | 85 | - DOM은 다른 프로그래밍 인터페이스와 마찬가지로 객체 속성과 메소드 그리고 이벤트 등을 정의한다. 86 | 87 | - 브라우저 구문 분석기는 위에서부터 순차적으로 HTML을 분석하며 부모 노드와 자식 노드와의 관계를 파악해 DOM 트리를 생성한다. 88 | 89 |
90 | 91 | - **CSSOM 트리 생성** 92 | 93 | - CSSOM은 DOM과 비슷하게 CSS를 처리하기 위한 트리 구조의 프로그래밍 인터페이스이다. 브라우저가 HTML을 구문 분석하며 CSS를 참조하는 링크를 만나면 해당 CSS 리소스를 다운로드하고 구문 분석기가 CSS를 분석하기 시작한다. 94 | 95 | - HTML과 다르게 CSS는 구문 분석에는 엄격한 구문 검사가 적용된다. 그렇다보니 사용하는 구문 분석기와 동작 스레드도 다르다. 따라서 HTML 구문 분석 과정이 CSS 분석에 의해 방해받지 않는다. 96 | 97 |
98 | 99 | - **렌더 트리 생성** 100 | 101 | - DOM 트리와 CSSOM 트리 구문 분석이 완료되면 브라우저는 두 개의 트리를 병합해 렌더 트리를 생성한다. DOM과 CSSOM을 기반으로 렌더링을 위한 최종 정보를 가진 렌더 객체들을 생성해 이들의 상하 관계를 트리 모양으로 구성한 것이 렌더 트리이다. 102 | 103 |
104 | 105 | - **레이아웃** 106 | 107 | - 레이아웃은 렌더 트리 노드들의 위치 정보가 계산되는 단계이다. 렌더 객체는 사각형 영억을 표시하므로 브라우저 창의 맨 왼쪽 위에서 시작하여 아래, 오른쪽으로 이동하며 각 사각형 영역의 너비와 높이를 계산한다. 108 | 109 | - 렌더 트리의 루트 노드부터 계산이 시작되는데 루트 노드의 너비는 뷰포트의 크기로 지정된다. 110 | 111 |
112 | 113 | - **페인트** 114 | 115 | - 페인트는 렌더 트리 정보를 바탕으로 브라우저 창에 표현하는 단계이다. 116 | 117 | - 이미 렌더링을 위한 정보가 모두 준비되어있으므로 GPU를 이용해 그리기만 하면 된다. 118 | 119 | - 자바스크립트는 DOM과 CSSOM을 동적으로 변경할 수 있으며 이 경우 렌더 트리가 변경되고 레이아웃, 페인트 단계가 다시 수행된다. 120 | 121 |
122 | 123 | ## 5.3 브라우저 렌더링 최적화하기 124 | 125 | ### 5.3.1 DOM 최적화하기 126 | 127 | - HTML은 구문 체크에 관대하므로 작성 시 잘못된 습관이나 실수에 의해 문법 오류가 발생해도 브라우저에는 정상적으로 표현되는 경우가 많다. 128 | 129 | - 이렇게 다양한 오류를 포용하기 위해 브라우저는 잘 알려진 수많은 오류 사항에 대한 예외 처리 방안을 구현한다. 130 | 131 | - ex) 제한된 숫자 이상 중첩된 태그가 많거나 태그를 열고 닫지 않거나 테이블 안에 테이블이 겹치는 등의 오류가 발생하면 내부 알고리즘에 의해 중첩된 태그를 제거하고, 적절한 위치에서 태그를 닫고, 겹친 테이블을 분리하는 일련의 작업을 수행한다. 따라서, 웹 페이지 내에 오류가 많을수록 브라우저는 예외 처리를 위해 더 많은 메모리와 CPU 파워를 소모한다. 132 | 133 | - **HTML의 구문 오류를 최소화하고 간소화하는 것이 웹 사이트 성능을 향상시키는 기본적이고도 간단한 방법이다.** 134 | 135 | - 과도하게 HTML 태그를 중첩 사용하는 행위도 피해야한다. 136 | 137 | - 태그가 중첩되어 HTML 문서 구조가 복잡하게 작성되어 있으면 자바스크립트에 의해 스타일이 변경될 때 각 태그의 레이아웃을 다시 계산하고 재구성하는 데 더 많은 리소스와 시간이 소요된다. 138 | 139 |
140 | 141 | ### 5.3.2 자바스크립트와 CSS 배치하기 142 | 143 | - HTML 구문 분석기가 순차적으로 HTML을 해석하는 중 자바스크립트를 만나면 이를 다운로드하고 수행이 완료될 때까지 DOM 생성 작업을 중단한다. 자바스크립트에 의한 변경이 완료되기를 기다리는 것이다. 144 | 145 | - 하지만 그 시점에 특정 CSS에 대한 구문 분석 처리 및 CSSOm 생성 작업이 진행 중이라면 자바스크립트가 변경하려는 스타일 시트가 아직 생성되지 않았을 수 있다. 그러므로 해당 자바스크립트는 CSSOM 생성이 완료될 때까지 수행을 중지하고 대기한다. 146 | 147 | - 이러한 CSS와 자바스크립트의 렌더링 방해를 피하려면 CSS를 최대한 소스 위쪽에 배치하여 CSSOM이 가능한 빨리 생성되도록 한다. 그리고 자바스크립트는 최대한 HTML 아래쪽에 배치하여 DOM과 CSSOM이 모두 생성된 이후에 수행될 수 있도록 하는 것이 가장 효과적이다. 148 | 149 |
150 | 151 | ### 5.3.3 자바스크립트 최적화하기 152 | 153 | - 자바스크립트를 HTML 아래쪽에 배치하는 것만으로도 렌더링의 방해 요소가 많이 사라지지만 이는 충분하지 않다. 154 | 155 | - 자바스크립트가 전체 페이지 로딩 시간에 영향을 주는 것을 막으려면 자바스크립트 수행이 렌더링 스레드를 방해하지 않도록 별도 스레드로 자바스크립트를 수행시켜줘야한다. 156 | 157 | - 자바스크립트에서 제공하는 관련 속성을 활용할 수 있다. (**async, defer**) 158 | 159 | - async 속성은 HTML 구문 분석과 동시에 자바스크립트를 다운로드하고 수행되도록 한다. 160 | 161 | - defer 속성은 구문 분석 중에 별도의 스레드로 자바스크립트를 다운로드하고 구문 분석이 끝난 이후에 수행되도록 한다. 162 | 163 |
164 | 165 | ### 5.3.4 CSS 최적화하기 166 | 167 | - 브라우저는 CSS가 구문 분석되고 CSSOM이 만들어지기까지 렌더링을 멈추므로 CSS는 렌더링 순위가 가장 높으면서 동시에 렌더링을 가장 방해하는 리소스이다. 168 | 169 | - CSS는 필요한 정보만 빠르게 다운로드하고 실행해야 브라우저 렌더링을 가속시킬 수 있다. 170 | 171 | - 이를 위해 첫 번째로 CSS를 적절히 분리하여 필요한 페이지에 필요한 CSS 파일만 포함해야한다. 172 | 173 | - 두 번째로는 첫 화면에 사용될 CSS 파일과 숨겨진 화면에 사용될 CSS 파일을 분리해 후자의 CSS는 지연수행 시켜야한다. 174 | 175 | - 필요한 CSS만 다운로드하려면 미디어 쿼리를 활용할 수 있다. 이때 미디어 쿼리의 조건과 함께 해당하는 CSS 파일을 링크시키면 조건에 맞지 않는 파일은 다운로드하지 않는다. 176 | 177 |
178 | 179 | ### 5.3.5 이미지 로딩 최적화하기 180 | 181 | - 웹 최적화에 있어 이미지 압축은 필수일 정도로 이미지 로딩 최적화는 다른 방법들에 비해 효율적이다. 182 | 183 | - CSS에 의해 이미지가 숨겨질 것을 미리 알고 있다면 브라우저가 그 이미지를 다운로드하지 않음으로써 페이지 로딩을 더 가속화할 수 있다. 하지만 DOM과 CSSOm이 별도 분석되고 생성되기 때문에 브라우저는 이를 미리 알지 못하고 DOM 트리에 나타난 객체들을 모두 다운로드한다. 184 | 185 | - **그렇다면 화면 레더링에 필요하지 않은 이미지를 다운로드하지 않으려면 어떻게 해야할까?** 186 | 187 | - 첫 번째로 만약 그 이미지가 웹 사이트의 주요 이미지가 아니라면 CSS의 background-image 속성을 사용해 원하지 않는 다운로드를 피할 수 있다. 브라우저가 CSS를 분석할 때 숨겨질 이미지는 미리 알고 다운로드하지 않기 때문이다. 188 | 189 | - 두 번째로 자바스크립트를 이용한 지연 로딩 방식을 적용해 불필요한 다운로드를 피한다. 190 | 191 | - 하지만, 이미지 지연 로딩이 브라우저 로딩 속도 개선에 효과적일 수 있으나 사용자 경험 개선에 항상 도움이 되지는 않는다. 모든 이미지에 지연로딩을 적용하면 브라우저의 프리로더가 이미지를 다운로드할 수 없으므로 오히려 성능을 저해하는 요소가 된다. 192 | 193 | - 따라서, 지연 로딩은 첫 화면에 등장하지 않거나 숨겨진 이미지들을 다운로드하는데만 사용하면 좋겠다. 194 | 195 | - 세 번째로 Progreesive JPG를 활용할 수 있다. Progressive JPG는 고품질 이미지를 한 번에 전송하지 않고 분할 전송하는 방식으로 브라우저에서는 초기에 저품질 이미지가 보이지만 점차 원래 품질을 회복한다. 196 | 197 |
198 | 199 | ## 5.4 도메인 분할 기법 이용하기 200 | 201 | - 도메인 분할 기법은 여러 도메인을 소유한 경우 웹 콘텐츠를 병렬적으로 동시에 다운로드할 수 있도록 하는 방법이다. 202 | 203 | - 브라우저는 HTTP/1.1 프로토콜 하에서 동일 도메인에 순차적인 다운로드 방식을 사용한다. 204 | 205 | - 도메인 분할은 달리 보면 HTTP/1.1 프로토콜 하에서 브라우저의 제약을 피하는 방식이다. 브라우저는 동일 호스트명의 동시 연결 개수를 제한하고 있는데, 한 도메인다 6~13개의 TCP 연결들을 동시 생성해 여러 리소스를 한 번에 다운로드할 수 있도록 허용한다. 206 | 207 | - 도메인 분할 기법을 이용하면 사이트 전체의 쿠키 사이즈를 축소할 수 있는 장점도 있다. 208 | 209 | - 도메인을 여러 개로 분할하는 방법은 기술적으로 어렵지 않지만 도메인을 몇 개로 운용하는 것이 최적인지 결정하는 데는 좀 더 면밀한 계획과 테스트가 필요하다. 하나의 웹 페이지에 포함된 리소스 개수가 얼마나 많은가에 따라 추가할 서브 도메인의 숫자를 결정해야한다. 210 | 211 | - 너무 많은 도메인을 추가하면 오히려 브라우저의 성능을 저하시킬 수 있으므로 주의해야한다. 212 | 213 | - 동시 다운로드 숫자가 많아질수록 브라우저는 더 많은 CPU 리소스를 사용하고 CPU 리소스가 한계에 도달하면 오히려 다운로드 속도를 느리게 만들기 때문이다. 214 | 215 | - 또한 브라우저는 각 도메인에 대한 DNS 조회를 수행하고 TCP 연결을 생성하며 생성된 도메인에 대한 연결을 유지해야 하므로 이는 결국 페이지 로딩 속도를 현저히 떨어뜨린다. 216 | 217 | - 사용할 도메인의 개수가 정해지면 그 수에 맞도록 리소스들을 균등 분할하는 것이 좋다. 218 | 219 |
220 | 221 | ### 5.4.1 도메인 분할 기법과 HTTP/2 222 | 223 | - 도메인 분할 기법이 고안된 이유는 HTTP/1.1의 가장 큰 문제점으로 지적되어 온 Head Of Line Breaking 현상 때문이다. HTTP/1.1에서 클라이언트와 서버 간의 연결은 마치 하나의 차선만 있는 도로와 같다. 224 | 225 | - 클라이언트는 하나의 요청을 서버에 보내고 그에 대한 정상적 응답을 받은 후에야 다음 요청을 서버에 보낼 수 있다. 이 문제점은 HTTP/2의 멀티 플렉싱 기술로 해결되어 도메인 분할 기법을 사용할 이유도 자연스럽게 사라졌다. 226 | 227 | - 최근 사용되는 브라우저들은 HTTP/2의 기능을 저해하지 않으면서 다중 도메인을 사용할 수 있는 방안을 제공한다. 바로 TCP 연결을 병합하는 방식이다. 228 | 229 | - 연결 병합은 브라우저가 첫 번째 도메인과 맺은 TCP 연결을 나머지 도메인에 재사용하는 방식으로 이 기술이 적용되기 위해서는 몇 가지 고려해야할 사항이 있다. 230 | 231 | - 브라우저가 DNS를 확인할 때 각 도메인은 모두 동일한 IP 주소를 반환해야한다. 232 | 233 | - 동일한 인증서를 사용해야한다. 234 | 235 |
236 | 237 | ## 5.5 사용자 경험 개선하기 238 | 239 | - 브라우저의 성능 지표만 향상시킨다고 해서 실제 사용자가 느끼는 성능이 향상되는 것은 아니다. 이를 위한 다른 방식의 측정 방법 및 개선 방안이 필요하다. 240 | 241 |
242 | 243 | ### 5.5.1 사용자 경험 지표 바로 알기 244 | 245 | - 웹 사이트 성능을 잘 관리하려면 어떤 지표를 사용할지가 중요하다. 246 | 247 | - 최근에는 웹 사이트의 성능 지표가 브라우저 이벤트 중심 지표에서 사용자 중심 지표로 변화하고 있다. 248 | 249 | - **사용자 중심의 지표에는 어떤 것이 있을까?** 250 | 251 | - WebPageTest의 Speed Index 지표가 사용되었다. Speed Index는 시간에 따른 웹 사이트의 시작 전 진행 상태를 수치화한 지표로, 값이 작을수록 시각적 진행 상태가 빠르다는 것을 의미한다. 252 | 253 | - 이 외에도 구글 크롬 팀을 주축으로 다양한 사용자 중심 성능 지표가 개발되고 있다. 254 | 255 | - 화면에 눈에 띄는 콘텐츠가 처음 표현되는 시점인 첫 번째 콘텐츠가 있는 페인트 (First Contentful Paint) 256 | 257 | - 히어로 이미지와 같은 주요 콘텐츠가 로딩되는 시점인 가장 큰 콘텐츠가 있는 페인트 (Largest Contentful Paint) 258 | 259 | - 사용자와 상호 작용이 어느 정도 가능해지는 시점인 상호 작용 시간 (Time to Interactive) 260 | 261 | - etc. 262 | 263 |
264 | 265 | ### 5.5.2 사용자 요청에 빠르게 반응하기 266 | 267 | - 웹 사이트 방문자에게 첫 응답속도는 마치 사람의 첫인상처럼 중요하다. 268 | 269 | - 사용자 요청에 빠르게 반응하려면 기본적으로 서버의 응답이 빨라야한다. 270 | 271 | - 브라우저가 서버에서 응답한 첫 번째 바이트를 수신하는 시간을 Time To First Byte라고 하는데 일반적으로 300~500ms가 이상적이라고 할 수 있다. 이를 위해서는 HTML 내의 주석이나 공백 등 불필요한 코드들을 모두 제거하여 전송되는 바이트 크기를 줄여야 한다. 또한 HTML 페이지를 캐시하여 서버 처리 시간을 최소화하는 것을 권한다. 272 | 273 | - HTML이 브라우저에 일단 다운로드되면 렌더링에 필요한 리소스들을 빠르게 로딩시켜 1초 이내에 브라우저가 화면 렌더링을 시작해야 사용자가 지연을 느끼지 않는다. 274 | 275 | - 브라우저가 렌더링을 빠르게 시작하게 하려면 아래와 같은 최적화 기법들이 있다. 276 | 277 | - CSS와 자바스크립트 파일들의 크기를 줄인다. 278 | 279 | - 크기를 줄이려면 공백과 주석을 제거하는 방법이 있다. 280 | 281 | - 근본적으로는 렌더링할 페이지에 필요한 부분만 남기고 필요하지 않은 부분은 제거하는 방법이 더 확실하다. 282 | 283 | - CSS와 자바스크립트들을 중요 리소스와 그렇지 않은 리소스로 분류한다. 284 | 285 | - 기본적으로, 화면 안쪽의 웹 콘텐츠를 렌더링하기 위한 파일들이 중요 리소스에 속한다. 286 | 287 | - 중요 리소스들은 가능한 빠르게 로딩시킨다. 288 | 289 | - 중요하지 않은 리소스들은 나중에 로딩 시킨다. 290 | 291 |
292 | 293 | ### 5.5.3 사용자 시선 붙잡기 294 | 295 | - 브라우저가 화면 렌더링을 시작했더라도 2초 안에 의미 있는 콘텐츠가 표현되지 않으면 사용자가 사이트를 이탈할 가능성이 높아진다. 296 | 297 | - 사용자가 이탈하지 않도록 시선을 붙잡으려면 Hero 이미지가 가능한 빠르게 화면에 로딩되어야한다. 298 | 299 | - Hero 이미지가 늦게 로딩이 된다면 그 이유는 페이지 로딩 시간을 개선하기 위해 모든 이미지들을 일괄적으로 지연 로딩 시켰기 때문일 것이다. 300 | 301 | - 지연 로딩이 적용된 이미지들은 브라우저의 프리로터 스레드 대상에 포함되지 않기 때문에 Hero 이미지 또한 렌더링이 늦게 된다. 302 | 303 | - 이를 방지 하기 위해서 Hero 이미지를 제외한 이미지들만 지연 로딩을 시켜주면 된다. 304 | 305 | - Hero 이미지가 늦게 로딩이 되는 또 다른 이유는 CSS의 background-image 속성으로 지정되었을 경우일 것이다. 306 | 307 | - HTML의 img 태그로 지정된 이미지들은 HTML 구문 분석과 함께 다운로드 되지만 CSS background-image 속성으로 지정된 이미지들은 CSS가 분석되고 DOM에 적용될 때 다운로드 되고 프리로더에도 적용되지 않는다. 그러므로 다른 이미지들보다 훨씬 늦게 다운로드된다. 308 | 309 | - Hero 이미지를 빠르게 로딩하는 것과 더불어 이미지와 함께 메인 텍스트 역시 의미 있는 콘텐츠로 구성하면 좋을 것이다. 310 | 311 | - 일반적으로 브라우저에서 텍스트는 폰트를 먼저 다운로드해야 비로소 표현되므로 핵심 메시지를 사용자에게 빠르게 나타내려면 폰트를 빨리 다운로드해야 한다. 312 | 313 |
314 | 315 | ### 5.5.4 사용자 상호 작용 방해하지 않기 316 | 317 | - 브라우저가 페이지를 시각적으로 완성했다 하더라도 버튼 클릭, 스크롤 등의 상호 작용이 원활하지 않으면 사용자들의 불만이 증가하고 급기야 타 사이트로 이탈할 수 있다. 318 | 319 | - 따라서 사용자의 상호 작용을 측정하는 Time to Interactive나 First Input Delay 같은 지표가 웹 사이트 평판을 가늠하는 훌륭한 지표가 될 수 있다. 320 | -------------------------------------------------------------------------------- /basic/6장-캐시-최적화/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 06 캐시 최적화 2 | 3 | 6.1 캐시 4 | 5 | 6.2 웹 캐시 동작 원리 6 | 7 | 6.2.1 HTTP 8 | 9 | 6.2.2 HTTP의 캐시 제어 방식 10 | 11 | 6.2.3 캐시 유효성 체크 12 | 13 | 6.2.4 캐시 콘텐츠 갱신 14 | 15 | 6.3 캐시 최적화 방안 16 | 17 | 6.3.1 캐시 가능한 콘텐츠 구분하기 18 | 19 | 6.3.2 올바른 캐시 정책 설정하기 20 | 21 | 6.3.3 캐시 주기 결정하기 22 | 23 | 6.3.4 캐시에 적합한 디렉터리 구조 구성하기 24 | 25 | 6.3.5 캐시 키 올바르게 사용하기 26 | 27 | 6.3.6 CDN 사용하기 28 | 29 | 6.4 동적 콘텐츠 캐시 30 | 31 | 6.4.1 동적 콘텐츠 캐시 32 | 33 | 6.4.2 POST 응답 캐시 34 | 35 | 6.5 고급 캐시 전략 36 | 37 | 6.5.1 Edge Side Include 38 | 39 | 6.5.2 HTML5 로컬 스토리지 40 | -------------------------------------------------------------------------------- /basic/6장-캐시-최적화/tococ.md: -------------------------------------------------------------------------------- 1 | # Chapter 06 캐시 최적화 2 | 3 | ## 6.1 캐시 4 | 5 | - 필요한 데이터를 매번 서버에서 가공해 제공하는 것은 그 자체로 오랜시간이 소요된다. 6 | - 만약 사용자의 같은 요청에 응답하는 리소스가 항상 똑같다면 서버가 매번 같은 작업으로 데이터를 가공하지 않아도 된다. 7 | - 이때 특정 요청에 대한 데이터를 메모리나 메모리에 가까운 저장소에 Key, Value 형태로 저장하고 인덱스로 빠르게 찾아 응답한다면 서버의 부담이 줄고 응답 시간도 크게 단축할 수 있다. 8 | - 이처럼 콘텐츠 요청에 빠르게 응답하기 위해 서버와 클라이언트 사이에서 응답 콘텐츠의 사본을 저장하는 공간을 `캐시`라 한다. 9 | - 캐시는 보통 클라이언트와 서버 사이에 존재하며 서버의 성능을 크게 향상시키는 역할을 한다. 10 | - 현재 웹 아키텍처에는 다양한 캐시 서버가 존재한다. 11 | - 부라우저가 사용하는 브라우저 캐시 12 | - 서버에서 성능 향상을 위해 별도로 사용하는 리버스 프록시 형태의 캐시 서버 13 | 14 | - 캐시 서버는 원본 서버뿐만 아니라 프록시 서버, ISP 라우터 등 다양한 위치에 존재하며 네트워크 대역폭 및 비용 절감을 위해 사용된다. 15 | 16 |
17 | 18 | ## 6.2 웹 캐시 동작 원리 19 | 20 | - 웹 캐시를 바르게 사용하려면 동작 원리를 잘 이해해야한다. HTTP 통신을 이해해야 콘텐츠를 캐시하는 과정을 이해할 수 있다. 21 | - 웹 캐시는 웹 서버와 웹 브라우저 중간에 존재하면서 최초 원본 콘텐츠 요청을 최종 서버에 보내 응답을 받은 후 그 복사본을 만들어 저장하고 사용자에게 응답한다. 22 | - 이후 같은 콘텐츠에 대한 요청이 오면 최종 서버에서 원본 서버를 가져오는 대신 복사본을 사용자에게 전달한다. 23 | - 그 결과 원본 서버로의 트래픽을 줄이고 사용자의 요청에 대한 반응 속도를 빠르게 한다. 24 | 25 |
26 | 27 | ### 6.2.1 HTTP 28 | 29 | - 캐시 서버는 HTTP/1.1 규격을 기반으로 동작하므로 HTTP에 대한 기본 지식을 먼저 이해해야 한다. 30 | - HTTP는 인터넷에서 데이터를 주고받기 위한 클라이언트/서버 모델을 따르는 프로토콜이다. 31 | - OSI 7계층 모델의 마지막 7계층인 Application 레벨의 프로토콜이며 TCP/IP 위에서 동작한다. 32 | - etc. 33 | - HTTP 메시지는 크게 헤더와 페이로드로 구분된다. 34 | - 헤더에는 메시지를 전송할 호스트명, URL 패스 등 메시지 전송 및 처리에 필요한 데이터들이 포함되어 있다. 35 | - 페이로드는 html, 이미지 등 서버가 실제 전송하고자 하는 데이터를 포함한다. 36 | 37 |
38 | 39 | ### 6.2.2 HTTP의 캐시 제어 방식 40 | 41 | - HTTP/1.1부터 명시적으로 캐시를 제어할 수 있는 헤더를 추가했는데 이것이 Cache-Control 헤더이다. 42 | - HTTP/1.1에서는 캐시를 제어하는 목적을 크게 두 가지로 정의한다. 43 | - 원본 서버로의 요청 수를 최소화한다. 이는 네트워크 왕복 수를 줄여 결과적으로 사용자 요청에 대한 응답 속도를 단축할 수 있다. 44 | - 완전한 콘텐츠를 응답하지 않아도 된다. 이는 네트워크 대역폭과 리소스 낭비를 줄이고 비용을 효율화한다. 45 | 46 |
47 | 48 | **HTTP 헤더를 통해 위 두 가지 목적을 어떻게 달성할 것인지 살펴보겠다.** 49 | 50 | - Expire 51 | - HTTP/1.0은 Expire 헤더를 사용해 원본 서버 콘텐츠의 유효 기간을 지정하도록 정의한다. 이때 원본 서버는 Expire와 Date 헤더를 함께 보내야 하며 Date 헤더는 요청에 대한 응답이 작성된 시점을 표시한다. 캐시는 간단하게 Expire 날짜에서 Date 날짜를 빼는 것으로 해당 응답의 캐시 유지 시간을 결정할 수 있다. 52 | - Expire 헤더는 캐시를 명시적으로 제어하지는 않지만 브라우저를 포함한 대부분 캐시 서버에서 콘텐츠를 언제까지 저장할 것인지 판단하기 위해 사용한다. 53 | 54 | - Cache-Control: max-age 55 | - HTTP/1.1에서는 Cache-Control: max-age라는 헤더로 콘텐츠의 캐시 유지 시간을 정의한다. 56 | - 원본 서버는 이 헤더를 사용해 캐시에서 특정 콘텐츠를 얼마나 오래 유지하고 있어야 하는 지 명시적으로 설정한다. 57 | - 이 기간이 지나면 캐시 서버는 원본 서버에 해당 콘텐츠 변경 여부를 체크하거나 새로 갱신해야한다. 58 | - Expire 헤더는 만료 일자를 지정하는 반면 Cache-control: max-age는 유효 기간을 지정한다. 59 | 60 | - Cache-Control: s=maxage 61 | - s-maxage를 이용하면 사용중인 모든 CDN의 캐시 주기를 일괄적으로 설정하거나 변경할 수 있다. 62 | - ETag 63 | - ETag(Entity Tag) 헤더는 원본 서버가 리소스를 식별하기 위해 부여하는 고유 번호이다. 캐시 서버에서는 ETag를 사용해 원본 서버의 리소스가 시간이 지나 만료되었는지, 캐시된 리소스를 새로 갱신해야 하는지 여부를 명확히 판단할 수 있다. 64 | - Cache-Control: public 65 | - public으로 설정하면 그 응답은 모든 캐시 서버에 캐시될 수 있고 사용자 제한 없이 모든 사용자에게 응답이 전달될 수 있다. 66 | - Cache-Control: private 67 | - private으로 설정하면 HTTP 요청에 대한 응답은 요청한 사용자만 캐시할 수 있고 CDN 같은 범용 캐시 서버에서는 캐시할 수 없다. 68 | - private은 원본 서버가 일부 응답을 특정 사용자에게만 전달하는 데 목적이 있으므로 캐시 콘텐츠가 공유되면 안 된다. 69 | - Cache-Control: no-cache 70 | - no-cache 지시자는 요청과 응답 헤더에 모두 사용할 수 있지만 약간의 의미 차이가 있다. 71 | - 첫 번째로, 요청 헤더에 있을 경우 브라우저는 원본 서버나 그 중간에 존재하는 캐시 서버들에게 '캐시된 응답을 받지 않겠다'는 메시지를 전달하는 것과 같다. 이 지시자가 있으면 중간에 있는 캐시 서버들은 당연히 이 요청을 원본 서버에 그대로 전달해 원본 서버로부터 최신의 응답을 받아 사용자에게 전달해야한다. 72 | - 두 번째로, 응답 헤더에 포함되면 원본 서버가 캐시 서버들에게 캐시된 응답을 보내기 전 원본 서버를 항상 확인하도록 강제한다. 매 요청마다 캐시된 복사본을 원본 서버와 검증하라 강제하는 것이다. 73 | - Cache-Control no-store 74 | - HTTP 요청 또는 응답 헤더에 모두 사용할 수 있고 쓰임새도 동일하다. 서버가 로컬 저장소에 메시지를 저장하지 않도록 지시하는 것이다. 75 | - 이 지시문의 목적은 캐시 데이터의 예기치 않은 유출을 방지하려는 것이다. 76 | 77 |
78 | 79 | ### 6.2.3 캐시 유효성 체크 80 | 81 | - 캐시된 콘텐츠에 아무런 변화가 없는 상황에서 완전한 응답을 다시 만들어 보내는 비효율적인 요청/응답을 방지하고자 HTTP 표준은 조건부 요청이라는 메커니즘을 정의한다. 82 | 83 | - 이 메커니즘은 저장된 응답 TTL이 만료되었을 경우 캐시가 항상 원본 서버에서 완전한 콘텐츠를 받아오는 대신 TTL 주기 동안 콘텐츠에 변화가 있을 때에만 새 응답을 만들도록 요청한다. 84 | - 원본 서버에서 조건부 요청을 받았다면 해당 콘텐츠에 변경이 있을 때 200 응답 코드와 함께 변경된 콘텐츠를 응답 본문에 포함해 보낸다. 대신 변경이 없다면 응답 본문 없이 304코드만 헤더에 설정하여 보내는데 응답에 본문이 없으므로 서버와 네트워크 자원 낭비를 방지할 수 있다. 85 | 86 | - 조건부 요청을 보낼 때는 시간을 기반으로 보내는 방법과 콘텐츠를 기반으로 보내는 방법이 존재한다. 87 | 88 | **시간 기반의 조건부 요청** 89 | 90 | - 시간 기반의 조건부 요청이란 어떤 요청에 대한 원본 서버의 콘텐츠가 캐시에 저장된 후 변경되었는지 여부를 콘텐츠의 최종 본경 시간 중심으로 확인하는 방법이다. 91 | 92 | **콘텐츠 기반의 조건부 요청** 93 | 94 | - 콘텐츠 기반의 조건부 요청이란 어떤 요청에 대한 원본 서버의 콘텐츠가 캐시에 저장된 후 변경되었는지 여부를 콘텐츠 고윳값 중심으로 확인하는 방법이다. 95 | - 콘텐츠 내용이 약간이라도 수정되면 해시값도 변하기 때문에 이 값을 비교해 콘텐츠의 변경 여부를 파악할 수 있다. 96 | 97 |
98 | 99 | ### 6.2.4 캐시 콘텐츠 갱신 100 | 101 | - 웹 사이트가 개편되었거나 콘텐츠를 급하게 변경했다면 캐시에 저장된 복사본들을 강제로 갱신해야 사용자에게 정상적인 웹 페이지를 서비스할 수 있다. 102 | - 캐시에 저장된 내용을 갱신하기 위해서 다음과 같은 두 가지 방법을 사용할 수 있다. 103 | - **퍼지** 104 | - 퍼지는 저장소를 완전히 지우는 방식으로 대부분의 캐시 서버가 캐시를 모두 지우는 명령이나 API를 제공한다. 105 | - CDN을 비롯한 캐시 서버에서 한꺼번에 많은 콘텐츠를 퍼지하려면 원본 서버에 충분한 자원이 있는지 확인하는 등 주의를 기울여야한다. 106 | - **무효화** 107 | - 무효화는 캐시 저장소를 완전히 지우기보다 조건부 요청을 통해 캐시된 리소스들 중 변경이 있었던 리소스들만 새로 갱신하는 방법이다. 108 | - Cache-Control 헤더를 사용해 캐시 서버의 내용을 강제로 무효화할 수 있다. 109 | - 퍼지와 다르게 실제 변경된 리소스에 한해서만 전체 콘텐츠가 반환되므로 네트워크 대역폭 낭비를 크게 줄일 수 있다. 110 | 111 |
112 | 113 | ## 6.3 캐시 최적화 방안 114 | 115 | - 캐시 사용을 최대화할 수 있는 3가지 기본 원리는 다음과 같습니다. 116 | - 최대한 많이 캐시하라 117 | - 최대한 오래 캐시하라 118 | - 최대한 가까이 캐시하라 119 | 120 |
121 | 122 | ### 6.3.1 캐시 가능한 콘텐츠 구분하기 123 | 124 | - 캐시하기 어려운 콘텐츠는 아래와 같이 분류할 수 있다. 125 | - 개인화된 콘텐츠 126 | - API 호출이나 Ajax 요청에 대한 콘텐츠 127 | - Beacon 전달 또는 쿠키 설정을 위한 호출 128 | 129 |
130 | 131 | ### 6.3.2 올바른 캐시 정책 설정하기 132 | 133 | - 캐시 정책을 세우는 것은 캐시할 콘텐츠들의 성격을 파악하고 그룹화하는 것과 같습니다. 아래와 같은 순서를 참고해 하위 그룹을 나누고 캐시 정책을 정한다. 134 | - 먼저 캐시할 수 있는 콘텐츠인지 판단한다. 135 | - 캐시할 수 있는 콘텐츠들은 매번 원본 서버에 변경 사항을 확인해야 하는지 판단한다. 136 | - 캐시할 콘텐츠들의 성격을 판단한다. 137 | - 캐시 주기를 설정하고 max-age를 추가한다. 138 | 139 |
140 | 141 | ### 6.3.3 캐시 주기 결정하기 142 | 143 | - 기본적인 캐시 정책이 결정되면 구체적으로 얼마 동안 캐시할 것인지 결정해야한다. 144 | - 캐시 주기는 아래와 같은 방법으로 결정할 수 있다. 145 | - 캐시 주기는 콘텐츠 타입별로 다르게 설정할 수 있다. 146 | - 만약 링크 변경 없이 이미지 내용만 바꿔야 한다면 무효화 방식으로 해당 이미지만 캐시에 업데이트 한다. 147 | - 모든 정적 파일에 대해 캐시 주기를 길게 설정하고, 수동으로 캐시 주기를 관리하는 방법도 있다. 148 | 149 |
150 | 151 | ### 6.3.4 캐시에 적합한 디렉터리 구조 구성하기 152 | 153 | - 웹 콘텐츠의 구성 요소들을 파악하고 콘텐츠별 개시 정책을 정의했다면 캐시 친화적 디렉터리 구조를 구성하는 것을 권한다. 154 | - 캐시에 적합한 디렉터리 구조를 구성하려면 아래와 같은 방법으로 한다. 155 | - 첫 번째로 캐시할 수 있는 콘텐츠들을 별도의 폴더에 분류해 관리한다. 156 | - 두 번째로 캐시 주기별로 나누어 구성한다. 157 | - 세 번째로 동일한 파일을 여러 곳에 분산시키지 않아야한다. 웹 사이트를 구성하다 보면 상대 경로를 사용하려고 같은 파일을 여러 폴더에 복제하여 사용하는 경우가 있다. 이는 원본 소스를 관리하는 데도 문제가 되지만 캐시에도 도움이 되지 않는다. 대부분의 캐시 서버는 URL을 키 값으로 하여 동작하므로 복제 생성되는 URL 수만큼 캐시에도 복사본이 생성되기 때문이다. 158 | 159 |
160 | 161 | ### 6.3.5 캐시 키 올바르게 사용하기 162 | 163 | - 캐시 키란 캐시 서버가 원본의 복사본을 저장하고 빠르게 조회하기 위해 사용하는 키 값을 말한다. 164 | 165 |
166 | 167 | ​ **캐시 오염과 캐시 충돌** 168 | 169 | - 원본 서버에 하나의 원본 파일만 존재하는데 캐시에 복사본이 여러 개 존재하는 것을 캐시 오염이라 한다. 170 | - 캐시 충돌이란 요청 URL이 하나인데 브라우저 환경에 따라 서버에서 제공하는 응답이 달라져 결국 최초 요청한 브라우저의 응답만 캐시되는 것을 의미한다. 171 | 172 |
173 | 174 | ​ **캐시 오염 제거** 175 | 176 | - 캐시 오염은 최종 사용자에게 영향을 주지는 않지만 캐시 서버의 효율성에 큰 영향을 미칠 수 있다. 또한 캐시가 퍼지된 경우 원본 서버에 예기치 않은 트래픽 부담을 줄 수 있다. 177 | 178 | - 아래는 이러한 캐시 오염을 피하는 방법이다. 179 | 180 | - 첫 번째로 URL에 붙은 특정 쿼리 스트링 값이 달라지더라도 응답이 항상 같다면 캐시 키에서 쿼리 스트링을 무시하도록 설정해야한다. 181 | 182 | - 두 번째로 쿼리 스트링의 순서를 동일하게 정렬한다. 쿼리 스트링 순서가 달라져도 캐시는 이들을 다르게 인식한다. 따라서 쿼리 스트링을 사용할 때는 오름차순이나 내림차순으로 항상 동일하게 순서를 정렬해 호출하도록 설정해야한다. 183 | 184 | - 세 번째로 Vary 헤더를 바르게 사용해야한다. Vary 헤더가 잘못 사용되었을 때 캐시는 같은 페이지의 복사본을 여러 가지 캐시 키로 다르게 저장하기도 한다. 꼭 필요한 경우가 아니면 Vary 헤더를 사용하지 않거나 Cache-Control: private을 사용해 중간 캐시 서버에는 캐시하지 않도록 하는 것을 추천한다. 185 | 186 | > Vary 헤더는 단어 그대로 서버의 응답이 상황에 따라 달라지는 것을 의미한다. 187 | 188 | **캐시 충돌 방지** 189 | 190 | - 캐시 충돌은 동적 페이지를 캐시할 때 주로 발생한다. 191 | 192 | - 이 현상을 피하려면 기본적으로 동적 페이지에는 캐시를 적용하지 않아야한다. 193 | 194 | - 일부 동적 페이지에 캐시를 사용하고자 한다면 Cache-Control: private으로 사용자 브라우저에만 캐시하여 페이지 로딩 시간을 단축할 수 있다. 195 | 196 |
197 | 198 | ### 6.3.6 CDN 사용하기 199 | 200 | - 캐시 효율화를 위한 3원칙 중 마지막은 사용자에게 가깝게 캐시하라는 것이다. 201 | 202 | - CDN 서비를 사용하면 세계 여러 지역 데이터 센터들에 리버스 프록시 캐시 서버를 두고 필요한 정적 콘텐츠들을 저장해놓을 수 있다. 203 | - 또한 사용자가 관련 콘텐츠를 요청할 때 사용자와 가장 가까운 캐시 서버에서 해당 콘텐츠가 서비스되므로 시간 지연 없이 빠르게 웹 페이지를 로딩할 수 있다. 204 | 205 |
206 | 207 | ## 6.4 동적 콘텐츠 캐시 208 | 209 | - 서버에서 동적 콘텐츠를 처리하는 시간이 전체 응답 시간 중 많은 부분을 차지한다. 따라서 이들을 캐시할 수 있다면 사용자가 체감하는 응답 시간을 단축시킬 뿐만 아니라 서버의 리소스도 절약할 수 있다. 210 | 211 |
212 | 213 | ### 6.4.1 동적 콘텐츠 캐시 214 | 215 | - 동적 콘텐츠를 사용자에게 전달하기 위해 원본 서버는 아래의 두 가지 방법을 사용한다. 216 | - 동적 정보를 쿠키에 넣어 보낸다. 217 | - 요청 쿠키, 헤더 혹은 쿼리 스트링에 동적 콘텐츠에 대한 정보가 있으면 이 정보들을 캐시 키에 추가함으로써 동적 콘텐츠를 캐시할 수 있다. 사용자 로그인 페이지는 로그인 정보가 쿠키에 있는 경우와 없는 경우로 그룹화하고 쿠키가 없을 때만 캐시한다. 218 | - 이때, 첫 번째로 보안에 주의해야한다. 219 | - 두 번째로 캐시 서버 용량에 유의해야 한다. 개인화된 콘텐츠가 지나치게 많아서 캐시 서버의 용량이 소진되면 이전 객체를 지우기 위해 CPU 사용량이 늘어나 결국 캐시 효율이 떨어진다. 220 | - Ajax 요청으로 관련 정보를 동적으로 받아온다. 221 | 222 |
223 | 224 | ### 6.4.2 POST 응답 캐시 225 | 226 | - POST 메소드를 사용하면 HTTP 페이로드에 쿼리 스트링 내용을 포함해 보내므로 데이터 크기에 제한이 없다. 또한 타인이 브라우저를 통해 쉽게 볼 수 없어 보안 측면에서도 상대적으로 안전한다. 227 | - 따라서 POST 메소드는 보통 브라우저 캐시나 조회 이력에 남기지 않고 캐시 서버에 캐시되어서도 안 된다. 228 | - 만약 입력 매개 변수가 동일할 때 서버로부터 항상 동일한 응답이 반환된다면, 또 그 응답 내용이 보안 측면에서 공개되어도 안전한 내용이라면 이 POST 요청/응답 역시 캐시할 수 있다. 단 캐시 키에 요청 매개 변숫값들이 모두 포함되어야 캐시 오염, 캐시 충돌 같은 오류 현상을 방지할 수 있다. 229 | 230 |
231 | -------------------------------------------------------------------------------- /basic/6장-캐시-최적화/yujo11.md: -------------------------------------------------------------------------------- 1 | # Chapter 06 캐시 최적화 2 | 3 | ## 6.1 캐시 4 | 5 | - 콘텐츠 요청에 빠르게 응답하기 위해 서버와 클라이언트 사이에서 응답 콘텐츠의 사본을 저장하는 공간을 **캐시**라 하고, 이 캐시를 유지하고 처리해주는 별도의 서버를 **캐시 서버**라고 한다. 6 | 7 | ## 6.2 웹 캐시 동작 원리 8 | 9 | - 캐시 서버는 HTTP/1.1 규격을 기반으로 동작한다. 10 | 11 | ### 6.2.1 HTTP 12 | 13 | - HTTP는 인터넷에서 데이터를 주고받기 위한 클라이언트/서버 모델을 따르는 프로토콜이다. 14 | - OSI 7계층 모델의 마지막 7계층인 Application 레벨의 프로토콜이며 TCP/IP 위에서 동작한다. 15 | 16 | ### 6.2.2 HTTP의 캐시 제어 방식 17 | 18 | - HTTP/1.0까지는 캐시를 제어하는 명시적 기술이 없었다. 19 | 20 | - HTTP/1.1부터 명시적으로 캐시를 제어할 수 있는 헤더를 추가했는데 이것이 Cache-Control 헤더이다. 21 | - HTTP/1.1에서는 캐시를 제어하는 목적을 크게 두 가지로 정의한다. 22 | - 원본 서버로의 요청 수를 최소화한다. 이는 네트워크 왕복 수를 줄여 결과적으로 사용자 요청에 대한 응답 속도를 단축할 수 있다. 23 | - 완전한 콘텐츠를 응답하지 않아도 된다. 이는 네트워크 대역폭과 리소스 낭비를 줄이고 비용을 효율화한다. 24 | 25 | ### 6.2.3 캐시 유효성 체크 26 | 27 | - 비효율적인 요청/응답을 방지하고자 HTTP 표준은 조건부 요청이라는 메커니즘을 정의한다. 28 | - 이 메커니즘은 저장된 응답 TTL이 만료되었을 경우 캐시가 항상 원본 서버에서 완전한 콘텐츠를 받아오는 대신 TTL 주기 동안 콘텐츠에 변화가 있을 때에만 새 응답을 만들도록 요청한다. 29 | - 원본 서버에서 조건부 요청을 받았다면 해당 콘텐츠에 변경이 있을 때 200 응답 코드와 함께 변경된 콘텐츠를 응답 본문에 포함해 보낸다. 대신 변경이 없다면 응답 본문 없이 304코드만 헤더에 설정하여 보내는데 응답에 본문이 없으므로 서버와 네트워크 자원 낭비를 방지할 수 있다. 30 | 31 | ### 6.2.4 캐시 콘텐츠 갱신 32 | 33 | - 캐시에 저장된 내용을 갱신하기 위해서 아래 두 가지 방법을 사용할 수 있다. 34 | 35 | - 퍼지(purge) 36 | 37 | - 저장소를 완전히 지우는 방식, 대부분의 캐시 서버가 캐시를 모두 지우는 명령이나 API를 제공한다. 38 | - CDN을 비롯한 캐시 서버에서 한꺼번에 많은 콘텐츠를 퍼지하려면 원본 서버에 충분한 자원이 있는지 확인하는 등 주의를 기울여야한다. 39 | 40 | - 무효화(invalidate) 41 | 42 | - 캐시 저장소를 완전히 지우기보다 조건부 요청을 통해 캐시된 리소스들 중 변경이 있었던 리소스들만 새로 갱신하는 방식 43 | 44 | - 아래처럼 Cache-Control 헤더를 사용해 캐시 서버의 내용을 강제로 무효화할 수 있다. 45 | 46 | > Chche-control: max-age=0, must-revalidate 47 | 48 | 49 | 50 | ## 6.3 캐시 최적화 방안 51 | 52 | - 캐시 사용을 최대화할 수 있는 3가지 기본 원리 53 | - 최대한 많이 캐시하라 54 | - 최대한 오래 캐시하라 55 | - 최대한 가까이 캐시하라 56 | 57 | 58 | 59 | ### 6.3.1 캐시 가능한 콘텐츠 구분하기 60 | 61 | - WebPageTest를 통해 얼마나 많은 파일을 캐시할 수 있는지 확인 가능 62 | 63 | ### 6.3.2 올바른 캐시 정책 설정하기 64 | 65 | 1. 캐시할 수 있는 콘텐츠인지 판단 66 | 2. 캐시할 수 있는 콘텐츠들은 매번 원본 서버에 변경 사항을 확인해야 하는지 판단. 67 | 3. 캐시할 콘텐츠들의 성격을 판단. 68 | 4. 캐시 주기를 설정하고 max-age를 추가 69 | 70 | ### 6.3.3 캐시 주기 결정하기 71 | 72 | 1. 캐시 주기는 콘텐츠 타입별로 다르게 설정할 수 있다. 73 | 2. 링크 변경 없이 이미지 내용만 바꿔야 한다면 캐시 무효화 방식으로 해당 이미지만 캐시에 업데이트 한다. 74 | 3. 모든 정적 파일에 대해 캐시 주기를 길게 설정하고 수동으로 캐시 주기를 관리하는 방법도 있다. 75 | 76 | ### 6.3.4 캐시에 적합한 디렉터리 구조 구성하기 77 | 78 | 1. 캐시할 수 있는 콘텐츠들을 별도의 폴더에 분류해 관리한다. 79 | 80 | 2. 캐시 주기별로 나누어 구성한다. 81 | 82 | 3. 세 번째로 동일한 파일을 여러 곳에 분산시키지 않아야 한다. 83 | 84 | ### 6.3.5 캐시 키 올바르게 사용하기 85 | 86 | ### 6.3.6 CDN 사용하기 87 | 88 | ## 6.4 동적 콘텐츠 캐시 89 | 90 | ## 6.5 고급 캐시 전략 91 | 92 | -------------------------------------------------------------------------------- /basic/7장-CDN/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 07 CDN 2 | 3 | 7.1 CDN을 사용하는 이유 4 | 5 | 7.2 CDN의 원리 6 | 7 | 7.2.1 CDN 서비스 아키텍처 8 | 9 | 7.2.2 CDN 동작 방법 10 | 11 | 7.2.3 CDN 적용 방법 12 | 13 | 7.3 다중 캐시 전략 14 | 15 | 7.3.1 캐시 축출 16 | 17 | 7.3.2 롱테일 콘텐츠 18 | 19 | 7.3.3 캐시 서버 간 캐시 콘텐츠 공유 20 | 21 | 7.3.4 다중 계층 캐시 22 | 23 | 7.4 전달 경로 최적화 24 | 25 | 7.4.1 라스트 마일 최적화 26 | 27 | 7.4.2 프로토콜 최적화 28 | 29 | 7.5 기타 성능 옵션 30 | 31 | 7.5.1 CDN이 대신 제공하는 기본 기능 32 | 33 | 7.5.2 신기술 적용을 위한 CDN 기능 34 | -------------------------------------------------------------------------------- /basic/8장-웹-프로토콜-최적화/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 08 웹 프로토콜 최적화 2 | 3 | 8.1 HTTP의 발전 4 | 5 | 8.1.1 HTTP/1.1 6 | 7 | 8.1.2 HTTP/2 8 | 9 | 8.1.3 HTTP/3 10 | 11 | 8.2 HTTP/2의 최적화 기술 12 | 13 | 8.2.1 HTTP/2의 이진 프레임 14 | 15 | 8.2.2 멀티플렉싱 16 | 17 | 8.2.3 헤더 압축 18 | 19 | 8.2.4 서버 푸시 20 | 21 | 8.3 HTTP/3의 최적화 기술 22 | 23 | 8.3.1 QUIC 24 | 25 | 8.3.2 HTTP/3의 등장 배경 26 | 27 | 8.3.3 HTTP/3의 특징 28 | 29 | 8.3.4 HTTP/3을 지원하는 제품군 30 | 31 | 8.3.5 새로운 프로토콜 적용 시 고려할 점 32 | -------------------------------------------------------------------------------- /basic/9장-웹-최적화-트렌드/README.md: -------------------------------------------------------------------------------- 1 | # Chapter 09 웹 최적화 트렌드 2 | 3 | 9.1 웹 최적화의 역사 4 | 5 | 9.1.1 모바일 기기의 등장과 모바일 사이트 최적화 6 | 7 | 9.2 PWA 8 | 9 | 9.2.1 PWA 주요 기술 10 | 11 | 9.2.2 PWA 사례 12 | 13 | 9.3 AMP 14 | 15 | 9.3.1 AMP의 특징 16 | 17 | 9.3.2 AMP의 구성 요소 18 | 19 | 9.3.3 AMP와 반응형 웹 디자인 20 | 21 | 9.4 웹 최적화의 실상과 과제 22 | 23 | 9.4.1 웹 최적화의 실상 24 | 25 | 9.4.2 웹 최적화의 과제 26 | -------------------------------------------------------------------------------- /basic/README.md: -------------------------------------------------------------------------------- 1 | # Basic 2 | 3 | 주마다 한 챕터씩 읽고 각자 폴더에 정리합니다 (모두) 4 | 5 | 형식 : basic/1장-ㅁㅁㅁ/{nickname}.md 6 | 7 | 8 | 9 | # 목차 10 | 11 | 1. 웹 성능이란 무엇인가? 12 | 13 | 2. 웹 최적화 14 | 15 | 3. 웹 사이트 성능을 개선하는 기본적인 방법 16 | 17 | 4. 이미지 최적화 18 | 19 | 5. 웹에서 가속을 이끌어 내는 방법 20 | 21 | 6. 캐시 최적화 22 | 23 | 7. CDN 24 | 25 | 8. 웹 프로토콜 최적화 26 | 27 | 9. 웹 최적화 트렌드 28 | 29 | 10. 웹 최적화 실습하기 30 | 31 | 32 | 33 | 34 | 35 | -------------------------------------------------------------------------------- /practice/2.5-네비게이션-타이밍/rita.md: -------------------------------------------------------------------------------- 1 | ### 2.5.3 네비게이션 타이밍 속성 2 | 3 | key 속성 : API에서 정의한 웹 브라우저가 웹 페이지를 로딩 시 실행하는 각 단계 4 | 5 | value 값 : 이 단계가 완료된 시간은 Unix Epoch Time 형식으로 변환한 값 6 | 7 | 각 performance.timing 속성은 페이지 요청 등의 탐색 이벤트 시간이나 DOM 로딩 시작 등의 페이지 로드 이벤트 시간을 1970년 1월 1일 자정부터 측정한 UTC 형식의 밀리초 단위로 나타냄. 8 | (이미지에서 빨간색 박스) 9 | ![Cap 2021-12-15 21-43-05-174](https://user-images.githubusercontent.com/48556400/146189142-15915268-2a70-4a7b-98b4-a738db8ce325.jpg) 10 | 11 | ### 2.5.4 네비게이션 타이밍 속성값 구하기 12 | 13 | 페이지 로딩에 소요된 시간을 밀리초 단위로 확인가능(이미지에서 노란색 박스) 14 | 15 | ```javascript 16 | function onLoad() { 17 | var now = new Date().getTime(); 18 | var page_load_time = now - performance.timing.navigationStart; 19 | console.log("User-perceived page loading time: " + page_load_time); 20 | } 21 | ``` 22 | 23 | HTML 문서가 실행되면 onLoad()함수가 바로 호출됨 24 | 25 | 아주 짧은 시간에 navigationStart가 실행되었음 26 | 27 | 이를 변경하여 구글 로고 이미지파일을 3번 받아오도록 수정하여 시간을 살펴보자 28 | 29 | ```javascript 30 | function onLoad() { 31 | var now = new Date().getTime(); 32 | document.write( 33 | "
" 34 | ); 35 | document.write( 36 | "
" 37 | ); 38 | document.write( 39 | "
" 40 | ); 41 | var page_load_time = now - performance.timing.navigationStart; 42 | console.log("User-perceived page loading time: " + page_load_time); 43 | } 44 | ``` 45 | 46 | ![image](https://user-images.githubusercontent.com/48556400/146195877-f2295226-9a99-45c8-9d9a-7de3cd49aafe.png) 47 | 48 | (실습해본 결과 이미지를 받던 받지 않던 100~200사이로 비슷했다..(?)) 49 | #### 네비게이션 타이밍 API의 속성값 사용 50 | 네비게이션 타이밍 API에 포함된 각 속성값을 사용하면 다양한 성능 지표를 얻을 수 있다. 51 | pageLoadTime : API 속성값으로 구한 페이지 로딩 시간 52 | 53 | ```javascript 54 | //Navigation Timing API 개체 생성 55 | var perfData = window.performance.timing; 56 | //navigationStart, loadEventEnd 속성을 사용하여 페이지 전체 로드 시간 구하기 57 | var pageLoadTime = perfData.loadEventEnd - perfData.navigationStart; 58 | console.log("pageLoadTime: " + pageLoadTime + "ms."); 59 | //requestStart, responseEnd 속성을 사용하여 HTTP 요청에서 응답까지 걸린 시간 구하기 60 | var connectTime = perfData.responseEnd - perfData.requestStart; 61 | console.log("connectTime: " + connectTime + "ms."); 62 | ``` 63 | 64 | -------------------------------------------------------------------------------- /practice/README.md: -------------------------------------------------------------------------------- 1 | # Practice 2 | 3 | 실습한 과정을 기록합니다. 4 | 5 | 형식 : practice/1장-ㅁㅁㅁ/{nickname}.md 6 | 7 | 8 | 9 | # 목차 10 | 11 | 1. 웹 성능이란 무엇인가? 12 | 13 | 2. 웹 최적화 14 | 15 | 3. 웹 사이트 성능을 개선하는 기본적인 방법 16 | 17 | 4. 이미지 최적화 18 | 19 | 5. 웹에서 가속을 이끌어 내는 방법 20 | 21 | 6. 캐시 최적화 22 | 23 | 7. CDN 24 | 25 | 8. 웹 프로토콜 최적화 26 | 27 | 9. 웹 최적화 트렌드 28 | 29 | 10. 웹 최적화 실습하기 30 | 31 | 32 | 33 | -------------------------------------------------------------------------------- /목차.md: -------------------------------------------------------------------------------- 1 | # Chapter 01 웹 성능이란 무엇인가 ? 2 | 3 | ## 1.1 웹 4 | 5 | 1.1.1 웹의 역사 6 | 7 | 1.1.2 웹의 대표적인 요소 8 | 9 | ## 1.2 웹 성능이 중요한 이유 10 | 11 | ## 1.3 웹 성능 측정 방법 12 | 13 | 1.3.1 크롬 브라우저의 개발자 도구 14 | 15 | 1.3.2 WebPageTest 서비스 16 | 17 | 1.3.3 구글 PageSpeed 18 | 19 | ## 1.4 웹 성능을 만드는 지표 20 | 21 | 1.4.1 사용자 환경 - 프런트엔드 22 | 23 | 1.4.2 공급자 환경 - 백엔드 24 | 25 | 1.4.3 전달 환경 - 네트워크 26 | 27 | ## 1.5 웹 성능과 프런트엔드 28 | 29 | 1.5.1 브라우저 렌더링 30 | 31 | ## 1.6 웹 성능 예산 32 | 33 | 1.6.1 정량 기반 지표 34 | 35 | 1.6.2 시간 기반 지표 36 | 37 | 1.6.3 규칙 기반 지표 38 | 39 | 1.6.4 성능 예산 활용 40 | 41 | # Chapter 02 웹 최적화 42 | 43 | 2.1 웹 최적화란 44 | 45 | 2.1.1 프런트엔드 최적화 46 | 47 | 2.1.2 백엔드 최적화 48 | 49 | 2.1.3 프로토콜 최적화 50 | 51 | 2.2 TCP/IP 프로토콜 52 | 53 | 2.2.1 TCP 혼잡 제어 54 | 55 | 2.3 HTTP 프로토콜 56 | 57 | 2.3.1 HTTP 최적화 기술 58 | 59 | 2.3.2 HTTP 지속적 연결 60 | 61 | 2.3.3 HTTP 파이프라이닝 62 | 63 | 2.4 DNS 64 | 65 | 2.4.1 DNS의 작동 원리 66 | 67 | 2.4.2 사용 중인 다양한 도메인 확인 방법 68 | 69 | 2.4.3 웹 성능을 최적화하는 도메인 운용 방법 70 | 71 | 2.5 브라우저 72 | 73 | 2.5.1 브라우저의 역사와 특징 74 | 75 | 2.5.2 내비게이션 타이밍 API 76 | 77 | 2.5.3 내비게이션 타이밍 속성 78 | 79 | 2.5.4 내비게이션 타이밍 속성값 구하기 80 | 81 | # Chapter 03 웹 사이트 성능을 개선하는 기본적인 방법 82 | 83 | 3.1 HTTP 요청 수 줄이기 84 | 85 | 3.1.1 스크립트 파일 병합 86 | 87 | 3.1.2 인라인 이미지 88 | 89 | 3.1.3 CSS 스프라이트 90 | 91 | 3.2 콘텐츠 파일 크기 줄이기 92 | 93 | 3.2.1 스크립트 파일 압축 전달 94 | 95 | 3.2.2 스크립트 파일 최소화 96 | 97 | 3.2.3 이미지 파일 압축 98 | 99 | 3.2.4 브라우저가 선호하는 이미지 포맷 사용 100 | 101 | 3.2.5 큰 파일은 작게 나누어 전송 102 | 103 | 3.3 캐시 최적화하기 104 | 105 | 3.3.1 인터넷 캐시 사용 106 | 107 | 3.3.2 브라우저 캐시 사용 108 | 109 | 3.4 CDN 사용하기 110 | 111 | # Chapter 04 이미지 최적화 112 | 113 | 4.1 이미지의 중요성 114 | 115 | 4.2 디지털 이미지의 종류와 특성 116 | 117 | 4.2.1 래스터 이미지 vs 벡터 이미지 118 | 119 | 4.2.2 무손실 이미지 형식 vs 손실 이미지 형식 120 | 121 | 4.3 이미지 변환 기법 122 | 123 | 4.3.1 무손실 압축 124 | 125 | 4.3.2 손실 압축 126 | 127 | 4.4 반응형 웹에서의 이미지 배치 전략 128 | 129 | 4.4.1 반응형 웹의 문제점 130 | 131 | 4.4.2 원인은 이미지 132 | 133 | 4.4.3 반응형 이미지 134 | 135 | 4.4.4 반응형 이미지 구현 방법 136 | 137 | 4.5 적응형 이미지 전략 138 | 139 | 4.5.1 적응형 이미지 아키텍처 140 | 141 | 4.5.2 기기 정보에 따라 서버 로직 수행 142 | 143 | 4.5.3 브라우저별 이미지 전달 144 | 145 | 4.5.4 캐시 고려 사항 146 | 147 | # Chapter 05 웹에서 가속을 이끌어 내는 방법 148 | 149 | 5.1 웹 브라우저 현황 알아보기 150 | 151 | 5.2 웹 브라우저 동작 이해하기 152 | 153 | 5.2.1 브라우저 아키텍처 154 | 155 | 5.2.2 중요 렌더링 경로 156 | 157 | 5.3 브라우저 렌더링 최적화하기 158 | 159 | 5.3.1 DOM 최적화하기 160 | 161 | 5.3.2 자바스크립트와 CSS 배치하기 162 | 163 | 5.3.3 자바스크립트 최적화하기 164 | 165 | 5.3.4 CSS 최적화하기 166 | 167 | 5.3.5 이미지 로딩 최적화하기 168 | 169 | 5.4 도메인 분할 기법 이용하기 170 | 171 | 5.4.1 도메인 분할 기법과 HTTP/2 172 | 173 | 5.5 사용자 경험 개선하기 174 | 175 | 5.5.1 사용자 경험 지표 바로 알기 176 | 177 | 5.5.2 사용자 요청에 빠르게 반응하기 178 | 179 | 5.5.3 사용자 시선 붙잡기 180 | 181 | 5.5.4 사용자 상호 작용 방해하지 않기 182 | 183 | # Chapter 06 캐시 최적화 184 | 185 | 6.1 캐시 186 | 187 | 6.2 웹 캐시 동작 원리 188 | 189 | 6.2.1 HTTP 190 | 191 | 6.2.2 HTTP의 캐시 제어 방식 192 | 193 | 6.2.3 캐시 유효성 체크 194 | 195 | 6.2.4 캐시 콘텐츠 갱신 196 | 197 | 6.3 캐시 최적화 방안 198 | 199 | 6.3.1 캐시 가능한 콘텐츠 구분하기 200 | 201 | 6.3.2 올바른 캐시 정책 설정하기 202 | 203 | 6.3.3 캐시 주기 결정하기 204 | 205 | 6.3.4 캐시에 적합한 디렉터리 구조 구성하기 206 | 207 | 6.3.5 캐시 키 올바르게 사용하기 208 | 209 | 6.3.6 CDN 사용하기 210 | 211 | 6.4 동적 콘텐츠 캐시 212 | 213 | 6.4.1 동적 콘텐츠 캐시 214 | 215 | 6.4.2 POST 응답 캐시 216 | 217 | 6.5 고급 캐시 전략 218 | 219 | 6.5.1 Edge Side Include 220 | 221 | 6.5.2 HTML5 로컬 스토리지 222 | 223 | # Chapter 07 CDN 224 | 225 | 7.1 CDN을 사용하는 이유 226 | 227 | 7.2 CDN의 원리 228 | 229 | 7.2.1 CDN 서비스 아키텍처 230 | 231 | 7.2.2 CDN 동작 방법 232 | 233 | 7.2.3 CDN 적용 방법 234 | 235 | 7.3 다중 캐시 전략 236 | 237 | 7.3.1 캐시 축출 238 | 239 | 7.3.2 롱테일 콘텐츠 240 | 241 | 7.3.3 캐시 서버 간 캐시 콘텐츠 공유 242 | 243 | 7.3.4 다중 계층 캐시 244 | 245 | 7.4 전달 경로 최적화 246 | 247 | 7.4.1 라스트 마일 최적화 248 | 249 | 7.4.2 프로토콜 최적화 250 | 251 | 7.5 기타 성능 옵션 252 | 253 | 7.5.1 CDN이 대신 제공하는 기본 기능 254 | 255 | 7.5.2 신기술 적용을 위한 CDN 기능 256 | 257 | # Chapter 08 웹 프로토콜 최적화 258 | 259 | 8.1 HTTP의 발전 260 | 261 | 8.1.1 HTTP/1.1 262 | 263 | 8.1.2 HTTP/2 264 | 265 | 8.1.3 HTTP/3 266 | 267 | 8.2 HTTP/2의 최적화 기술 268 | 269 | 8.2.1 HTTP/2의 이진 프레임 270 | 271 | 8.2.2 멀티플렉싱 272 | 273 | 8.2.3 헤더 압축 274 | 275 | 8.2.4 서버 푸시 276 | 277 | 8.3 HTTP/3의 최적화 기술 278 | 279 | 8.3.1 QUIC 280 | 281 | 8.3.2 HTTP/3의 등장 배경 282 | 283 | 8.3.3 HTTP/3의 특징 284 | 285 | 8.3.4 HTTP/3을 지원하는 제품군 286 | 287 | 8.3.5 새로운 프로토콜 적용 시 고려할 점 288 | 289 | # Chapter 09 웹 최적화 트렌드 290 | 291 | 9.1 웹 최적화의 역사 292 | 293 | 9.1.1 모바일 기기의 등장과 모바일 사이트 최적화 294 | 295 | 9.2 PWA 296 | 297 | 9.2.1 PWA 주요 기술 298 | 299 | 9.2.2 PWA 사례 300 | 301 | 9.3 AMP 302 | 303 | 9.3.1 AMP의 특징 304 | 305 | 9.3.2 AMP의 구성 요소 306 | 307 | 9.3.3 AMP와 반응형 웹 디자인 308 | 309 | 9.4 웹 최적화의 실상과 과제 310 | 311 | 9.4.1 웹 최적화의 실상 312 | 313 | 9.4.2 웹 최적화의 과제 314 | 315 | # Chapter 10 웹 최적화 실습하기 316 | 317 | 10.1 WebPageTest로 웹 성능 진단하기 318 | 319 | 10.1.1 WebPageTest 고급 기능 활용하기 320 | 321 | 10.1.2 WebPageTest의 최적화 진단 요소 322 | 323 | 10.1.3 WebPageTest API 활용하기 324 | 325 | 10.2 구글의 웹 최적화 기술 적용하기 326 | 327 | 10.2.1 Lighthouse 웹 사이트 측정 도구 328 | 329 | 10.2.2 PageSpeed 웹 성능 최적화 모듈 330 | 331 | 10.3 웹 사이트에 프로토콜 최적화 적용하기 332 | 333 | 10.3.1 프로토콜 최적화를 위한 조건 334 | 335 | 10.3.2 Let's Encrypt 인증서 발급 및 설치하기 336 | 337 | 10.3.3 Apache 웹 서버에 HTTP/2 적용하기 338 | 339 | 10.3.4 Nginx 웹 서버에 HTTP/2 적용하기 340 | 341 | 10.3.5 QUICHE 라이브러리를 사용한 HTTP/3 적용 342 | 343 | 10.4 다양한 조건에서 웹 성능 비교하기 344 | 345 | 10.4.1 Golang에서 제공하는 이미지 타일 서비스 346 | 347 | 10.4.2 WebPageTest를 사용한 웹 성능 비교 348 | 349 | 10.4.3 웹 성능 개선 결과 확인 350 | --------------------------------------------------------------------------------