[6주차] 5장 6장 7장 8장

05장/5장_반응형_웹_디자인_배진오.md

@@ -0,0 +1,126 @@
+---
+title: 5장 반응형 웹 디자인
+---
+
+모바일 기기는 다음과 같은 문제를 가지고 있다.
+
+- 모바일 네트워크의 긴 대기시간
+- 배터리를 전원으로 사용하는 하드웨어
+
+이러한 제약사항이 있음에도 불구하고 우리가 디자인하는 웹 사이트는 사용자에게 불필요한 오버헤드를 줄여 체감 성능을 최적화 해야한다.
+
+## 전략적 컨텐츠 로딩
+
+미디어 쿼리를 잘못 사용하면 엄청난 오버헤드를 줄 수도 있다. 특히 데스크톱 버전으로 디자인 한 후 모바일을 디자인 할 때 이러한 현상이 자주 발생한다. 따라서 이러한 점을 고려해 어떤 콘텐츠를 어떻게 로딩할지 결정하고 사용자에게 꼭 필요한 바이트만 전달하도록 해야한다.
+
+### 이미지
+
+이미지는 페이지에 표시되는 크기와 동일한 이미지를 제공해야 한다.
+
+레티나 화면은 같은 물리적 크기의 화면에 두 배 많은 픽셀을 표기하기 때문에 필요에 따라 두 배 큰 이미지를 전송한 후 브라우저에서 표시할 때 크기를 줄일 수 있다. 레티나 디스플레이를 사용하는 사용자는 이미지가 선명하게 보이지만 다른 사용자는 불필요하게 큰 이미지 파일을 다운받도록 하는 것이기도 하다.
+
+사용자에게 어떤 이미지를 전달할지 RESS기법, CSS 미디어 쿼리, picture 태그 등을 활용할 수 있다.
+
+RESS(Responsive web design with server-side components)는 사용자에게 어떤 자원을 제공할지 서버측에서 사용자의 유저 에이전트를 분석하여 화면 크기, 터치 여부 등을 추측하여 제공하는 방식이다. 그러나 이 기법은 사용자 장치의 화면 크기 변화에 올바르게 대응할 수 없다.
+
+CSS 미디어 쿼리를 사용하여 제공할 경우 주의할 점은 브라우저가 예상치 못한 동작을 할 수 있으므로 주기적인 테스트가 필요하다. 예를들어 `display: none`을 설정하는 것으로는 브라우저가 이미지를 다운받는 것을 방지할 수 없다. 배경이미지 역시 동일한데 부모 요소를 `display: none` 설정하거나 미디어 쿼리에서 어떤 파일을 받을지 명시하여 방지할 수 있다.
+
+```css
+#parent {
+    display: none;
+}
+
+#children {
+    background: url(...)
+}
+
+or
+
+@media ... {
+    #children {
+      background: url(...)
+    }
+}
+```
+
+최신 브라우저 가장 권장하는 방법은 picture 태그를 사용하는 것이다. picture 태그는 **위에서 아래의 순서대로 확인하면서 일치하는 이미지를 다운받는다.**
+
+```html
+<picture>
+    <source media="(min-width: 800px)" srcset="big.png">
+    <source media="(min-width: 400px)" srcset="small.png">
+    <img src="small.png">
+</picture>
+```
+
+고해상도 이미지를 제공할 때는 `srcset`을 다음과 같이 작성할 수 있다.
+
+```html
+<picture>
+    <source media="(min-width: 800px)" srcset="big.png 1x, big-hd.png 2x">
+    <source media="(min-width: 400px)" srcset="small.png 1x, small-hd.png 2x">
+    <img src="small.png">
+</picture>
+```
+
+`type` 옵션을 사용하여 브라우저 지원하는 파일 타입을 제공할 수도 있다.
+
+```html
+<picture>
+    <source type="image/svg+xml" srcset="pic.svg">
+    <img src="pic.png">
+</picture>
+```
+
+아래와 같이 브라우저별 최적화 이미지를 제공하기 좋은 방법인 것 같다.
+
+```html
+<picture>
+   <source srcset="img/my-cute-kitty-cat.webp" type="image/webp">
+   <source srcset="img/my-cute-kitty-cat.jxr" type="image/jxr">
+   <source srcset="img/my-cute-kitty-cat.jp2" type="image/jp2">
+   <source srcset="img/my-cute-kitty-cat.jpg" type="image/jpeg">
+   <img src="img/my-cute-kitty-cat.jpg" alt="Photo of my cute Kitty Cat" /> 
+</picture>
+```
+
+sizes...?
+
+### 글꼴
+
+글꼴 역시 추가적인 요청이 발생하고 총 페이지의 크기도 증가하기 떄문에 많은 양의 오버헤드를 줄 수 있다. 미디어 쿼리를 이용하여 모바일 사용자가 접근한 경우에는 글꼴을 다운받지 않도록 (대부분의 브라우저는 글꼴이 필요한 상황에서만 명시된 글꼴를 다운받도록 동작함) 하여 사용자의 트래픽을 아낄 수 있다.
+
+## 접근 방법
+
+### 프로젝트 문서화
+
+사용자가 사용하는 기기가 무엇이든 페이지의 크기나 요청 횟수를 불필요하게 증가시키는 상황을 피하자는 것을 프로젝트 문서에 남겨두는 것이 좋다. 개발할 때 사이트 속도도 타협 대상이 될 수 있다. 상황에 맞는 성능 예산을 정해두고 목표를 얼마나 달성했는지 확인할 것이라는 점도 언급해야 한다. 프로젝트에 참여하는 사람들이 성능에 대한 예상치를 가지도록 돕자. (7장에서 자세히 다룸)
+
+### 모바일 퍼스트
+
+모바일을 중심으로 생각하면 사이트를 디자인할 때 도움이 된다. 다음의 행동들이 자연스럽게 따라오기 때문이다.
+
+- '이 페이지의 가장 중요한 목적은 무엇인가?'와 같은 핵심적인 질문에 대한 고민
+- 사용자에게 가장 중요한 기능과 콘텐츠를 구분
+- 재사용할 수 있는 디자인 패턴을 만들고 그것을 화면 크기기에 따라 변경하는 방법 고민
+- 사이트 접근성, 인터넷이 느리거나 성능이 낮은 기기에서도 접속이 용이한지 생각
+
+데스크톱 대신 모바일을 중심으로 생각하면 기능을 추가하거나 더 강력한 애니메이션과 스타일을 적용하거나 혹은 새로 출시된 디바이스의 기능을 사용할 때마다 이런 새로운 변화가 성능에 미치는 영향을 추적해서 점진적으로 사이트를 향상시킬 수 있다.
+
+모바일 사용자 경험이 데스크톱보다 무조건 빈약해서는 안된다. 의도적으로 어느정도 줄일수는 있지만 렌더링되는 플랫폼의 한계를 이해하고 난 후 결정한 것이어야 한다. 모바일 버전과 데스크톱 버전 모두가 중요하며 한쪽이 다른 한쪽을 보조하는 관계는 아니다.
+
+모바일을 우선하면 자연스럽게 사용자의 요구 사항에 관심이 생기고 이는 사이트의 성능을 개선하는 데도 도움이 된다. 사용자가 사이트에 바라는바를 이해하면 사용자가 원하는 콘텐츠를 중심으로 보여주는 것에 집중할 수 있다. 작은 화면 크기에 적합한 기능과 콘텐츠가 무엇일지 결정하다보면 자연스럽게 총 페이지 크기와 요청 수도 낮게 유지될 것이다.
+
+반응형 웹사이트를 만들 때 가장 작은 화면을 먼저 고려하는 것이 좋다. 가장 작은 화면에 맞는 CSS를 재정렬하고, 사용자의 화면 크기가 커질 때 필요한 콘텐츠와 기능을 추가하는 점진적 개선을 하자. 화면 크기에 적절한 자원을 제공하고 스크롤하는 과정에서 쟁크(버벅거림)가 없는지 확인하자.
+
+## 모든 것 측정하기
+
+반응형 웹사이트에서도 일반 사이트에서 수행했던 방법대로 테스트를 할 수 있다. 하지만 반응형 웹 디자인 측정에는 몇 가지를 추가적으로 고려해야 한다.
+
+먼저 화면 크기게 맞춰 알맞은 콘텐츠만 제공하고 있는지 확인해야 한다.
+
+가능하면 선택한 기준별로 총 페이지 크기를 측정할 수 있는 자동화 테스트를 구현하자. 크롬 개발자 도구를 활용하여 가상 기기를 활용해 수동으로 테스트 할 수도 있다.
+
+특정 기기가 이미지를 의도한대로 다운받는지 혹은 여러 이미지를 동시에 다운받은 것은 아닌지 주의해서 확인해야 한다.
+
+지속적이고 반복적으로 사이트의 성능을 측정해두면 새로운 기능을 추가할 때나 사이트가 오래되어서 페이지 로딩 시간을 개선해야 할 때 좋은 참고 자료가 될 것이다. (6장에서 자세히 다룸)

06장/6장_반복적_성능_측정_배진오.md

@@ -0,0 +1,61 @@
+---
+title: 6장 반복적 성능 측정
+---
+
+벤치마크는 현재 사이트가 제공하는 사용자 경험의 상태를 이해하기 위해서만 중요한게 아니라 시간에 따라 무엇이 성능에 영향을 미치고 있는지 파악하는 데도 도움이 된다.
+
+## 브라우저 도구
+
+### 와이슬로우
+
+와이슬로우는 자원의 총 파일 크기를 확인할 수 있고 로딩 시간 개선을 위한 기본 권장사항도 얻을 수 있다. (플러그인 설치가 불가능하여 사용해보지 않음)
+
+> 권장사항을 검토할 때 우리 사이트는 우리가 가장 잘 알고 있다는 사실을 잊어서는 안된다. 권장사항 중에는 사이트에 적용하기 적합하지 않은 항목들이 있을 수 있다. 모든 권장 사항은 읽고 적용이 가능할지 고민해야 하지만 모든 안을 적용하지 못한다 해도 상관없다.
+
+### 크롬 개발자 도구
+
+크롬 개발자 도구 내 검사(Audits, 아마도 Lighthouse로 바뀐 거겠죠?)에서 제공하는 개선 권장사항을 확인할 수 있다.
+
+네트워크 탭에서 자원에 대한 요청의 타임라인을 확인할 수 있다. 어떤 자원이 로딩할 때 오래 걸리는지, 각 요청마다 어떤 종류의 대기 시간이 발생했는지 쉽게 확인할 수 있다. 중요 랜더링 경로가 양호하고 긴 시간을 잡아먹는 요청이 없다는 것을 확인하기 위해 네트워크 탭을 계속 확인하는 것이 좋다.
+
+쟁크를 구분할 때도 크롬 개발자 도구를 사용할 수 있다. 렌더링 도구창에서 FPS 미터를 켜면 페이지를 스크롤할 때 페이지의 어떤 부분이 프레임 드롭하는지 볼 수 있다.
+
+## 모의테스트
+
+모의테스트는 다른 기기에서 사이트에 접속한 경우에 어떻게 동작하는지 살펴보는 것이다. 인위적 성능 도구를 사용하면 전세계 여러 지역, 다양한 플랫폼에서 접속한 것처럼 테스트가 가능하다.
+
+[웹페이지테스트](https://www.webpagetest.org/)는 가장 인기있고 문서화가 잘 되어있는 테스트 솔루션이다. 기본 설정으로 테스트를 하면 같은 화면을 두 번 확인한다. 이를 통해 페이지에 처음 로딩했을 때와 자원이 캐싱된 후 로딩했을 때를 비교할 수 있다. 보통 다섯 번 정도는 테스트하는 것을 권장한다. 최대 1년 동안의 테스트 결과를 보관하므로 페이지 로딩 시간을 개선할 때 이전에 수행했던 테스트와 비교가 가능하다.
+
+개인 인스턴스를 호스팅해 볼 수도 있는데 이를 통해 개발중인 사이트를 테스트 할 수 있다. 또한 개인 인스턴스에서는 자동화 테스트를 실행할 수 있어 시간을 절약할 수 있는 장점이 있다.
+
+성능 리뷰와 첫 바이트 시간(TTFB), 이미지 압축 점수만 볼 것이 아니라 폭포수 차트를 주의깊게 살펴보아야 한다. 이를 통해서 긴 시간을 잡아먹는 요청을 구별할 수 있다. 어떻게 하면 짧은 폭포수를 가질 수 있을지 고민하자.
+
+## 실제 사용자 모니터링
+
+실제 사용자 모니터링은 사용자가 사이트의 페이지를 방문했을 때 웹 트래픽을 기록하여 사이트를 이용하는데 걸리는 실제 시간을 분석할 수 있게 도와주는 도구다. 구글 애널리틱스, 엠펄스, 글림스 등이 대표적인 실제 사용자 모니터링 도구이다. 이를 통해서
+
+- 지리적 위치 (거주하는 지역과 데이터 센터의 물리적인 거리)
+- 네트워크의 종류 (모바일 네트워크, 무선 랜)
+- 중간 값과 페이지 로딩 시간의 95번째 백분위수
+
+> 페이지 로딩 속도의 중간 값은 사용자가 페이지를 로딩하는데 걸리는 시간에 대한 일반적인 경우를 설명하는 경우에 유용하다. 한편 95번째 백분위수 지표는 대부분의 사용자가 우수한 사용자 경험을 느끼고 있는지를 확인하는데 유용하다. 95번째 백분위수를 다시 말하면 가장 느린 하위 5% 페이지뷰인데 총 사용자 수의 5%는 무시할 수 없는 숫자다.
+
+95번째 백분위수의 페이지 로딩 시간과 평균 페이지 로딩 시간은 어떻게 다를까? 각 국가에 따라 사이트가 어떻게 다르게 동작할까? 모바일 기기를 통해 접속한 사용자는 어떨지? 사이트 상위 다섯 개 페이지의 로딩 시간들 사이에 큰 차이가 있는지? 등의 내용을 생각해보면 좋을 것이다.
+
+## 시간에 따른 변화
+
+콘텐츠가 추가되고 디자인도 바뀌는 등 사이트는 계속 변하기 때문에 정기적인 사이트 성능 점검을 통해 페이지 크기, 총 로딩 시간, 체감 성능의 큰 변화 혹은 다른 부서에서 비롯된 갑작스러운 일을 최대한 빨리 찾는 것이 중요하다.
+
+예를 들어 새로 추가한 이미지 전시 방식 때문에 로딩 속도가 갑자기 느려졌는가? 사이트 내의 모든 페이지에 마케팅을 위한 스크립트가 추가되었는가? 컨텐츠 담당자가 권장 파일 크기보다 큰 이미지를 업로드했는가? 이처럼 성능에 갑작스러운 일이 생길 때 문제 지점을 찾을 수 있도록 정기적으로 주요 페이지를 검사해야 한다.
+
+혹은 조금씩 꾸준히 성능이 낮아지는 경우도 있을 수 있다. 이럴때는 발견하기도 수정하기도 어렵다. 가능하다면 매주 정기적으로 성능을 벤치마크해 두면 성능 저하가 미세하게 발생하는 경우라도 감지할 수 있다.
+
+3장에서 살펴본 것처럼 정기적으로 이미지를 확인해야 한다. 이미지 스프라이트, 이미지 형식, 압축을 확인하는 정기적인 일정을 만들자. 새로 추가한 이미지는 자동으로 압축이 되는지 필요한 크기에 다라서 제공되는지 확인하자.
+
+사용자가 가장 많이 접속하는 상위 5개 페이지의 크기도 확인하자. 만약 페이지 크기가 눈에 띄게 증가했다면 이유가 무엇인지 찾아 수정하고, 만약 수정할 수 없다면 다른 부분을 개선할 수는 없는지 찾아보자. 그러나 이 모든 작업은 정기적으로 사이트의 성능을 확인하고 시간에 따라 차이점을 비교하기 쉽도록 문서화했을 때만 가능하다.
+
+성능 지표로서의 가치뿐만 아니라 성능 변화의 원인을 파악하기 위해서라도 문서화는 하는 것이 좋다. 문서화를 하면 어떤 종류의 변화가 사이트의 성능에 큰 영향을 주었고, 어떤 것이 그렇지 않은지 등 시간에 따라 확인할 수 있기 때문이다.
+
+(스크립트의 사이즈 변화나 파일의 사이즈 변화를 PR에서 체크할 수 있도록 기본적인 셋팅을 해볼 수 있을 것 같다.)
+
+지속적으로 지켜봐야 할 것이 하나 더 있다. 바로 경쟁 사이트의 로딩 시간이다. 할 수 있다면 경쟁 사이트도 어떻게 동작하는지 지속적으로 테스트하고 벤치마크하자. 이를 통해 그들이 성능을 얼마나 중요하게 생각하고 사이트를 만들 때 어떤 측면의 사용자 경험을 중요하게 여기는지 알 수 있다.