Post

기초부터 완성까지 프론트엔드 - day8

Posted Updated
By hyemin 15 min read

Day 8

오늘 읽은 범위

  • 15장 프론트엔드 테스트
  • 부록1 렌더링 방식과 프론트엔드 프레임워크
  • 부록2 타입스크립트
  • 부록3 코드 리뷰하기

책에서 기억하고 싶은 내용을 써보세요.

애플리케이션의 규모가 커지며 페이지의 로딩 속도, 반응 속도, 메모리 사용률 등 다양한 요소들의 성능 최적화가 중요해지기 시작

개발자 도구 - Performance

  • 웹 페이지 로딩 과정을 기록하고 단계마다 걸리는 시간이나 렌더링 상태를 확인할 수 있음
  • 웹 페이지 성능 척도에 중요한 Web Vitals의 결과도 확인할 수 있음
  • (1) Overview 영역:
    • 렌더링 결과를 시간에 흐름에 맞춰 보여줌
  • (2) Main 영역:
    • 선택한 구간의 상세 내용을 보여줌
    • 작업이 수행된 시간과 하위 작업이 무엇인지 시각적으로 확인할 수 있음
  • (3) Summary 영역:
    • 선택한 작업의 상세한 정보를 보여주는 영역
    • 리소스를 로딩하고 파싱하여 실행하는 데에 걸린 시간, 레이아웃 스래싱이 발생했다면 어디서 발생하였는지 Summary 영역에서 자세히 확인할 수 있음

렌더링 블록

브라우저의 HTML 렌더링을 막는 것
렌더링 블록의 원인이 되는 리소스 = 블록 리소스

CSS 렌더링 블록

■ @import : import로 가져온 스타일 시트를 병렬로 다운로드할 수 없기 때문에 파싱 시간이 증가함 ■ inline CSS inline CSS는 HTML 문서에 직접 삽입하는 것이기 때문에 파일 다운로드 리소스 요청이 줄어들지만 inline CSS는 캐시가 되지 않고, 용량이 큰 CSS 파일은 내용 자체가 크기 때문에 inline css로 변경해도 렌더링이 지연될 수 있음

자바스크립트 렌더링 블록

브라우저는 HTML 요소를 파싱하는 도중 <script>태그를 만나면 로딩 및 실행이 완료될 때까지 DOM 트리 생성을 중단 함

렌더링 블록을 막는 가장 간단한 방법은 <body> 태그 바로 앞에 <script> 태그를 배치하는 것

  • defer:
    • 브라우저가 페이지의 렌더링을 차단하지 않도록 백그라운드에서 스크립트를 다운로드 함
    • 백그라운드에서 다운로드되기 대문에 로딩 시간을 빠르게 단축할 수 있고 HTML 파싱을 막지 않음
    • defer가 여러 개인 경우 정의된 순서로 실행됨
  • async:
    • 비동기로 자바스크립트 코드를 실행
    • 백그라운드에서 다운로드되지만 다운로드가 되면 즉시 실행됨
    • 이 시점에 브라우저 async 스크립트의 실행이 끝날 때까지 HTML 파싱이 멈춰짐
    • 정확한 실행 시점을 예측하기 어렵기 때문에 다른 스크립트와 의존성이 있거나 특정 이벤트 발생 시점 발생 시점과 연관이 있는 경우 사용하지 않는게 좋음
    • 광고나 데이터 수집 및 분석처럼 독립적인 역할을 담당하는 외부 스크립트를 로딩할 때 좋음

레이아웃 최소화

부모나 자식 요소들의 크리를 재계산하기 위해 비용이 많이 들어가는 과정

렌더링 병목 현상을 막기 위해서는 레이아웃 실행을 최적화하는 것이 중요함

■ 강제 동기 레이아웃

  • 비동기로 실행되지만 동기적으로 발생하여 실행 시간이 불필요하게 증가하는 경우
  • 속성을 계산하여 반환하기 전에 스타일을 변경하는 것

■ 레이아웃 스래싱

  • 강제 동기 레이아웃이 연속적으로 발생하는 것
  • 구글에 what-forces-layout을 검색하면 레이아웃을 발생시키는지 찾을 수 있음

Web Vitals

■ LCP

  • 로딩 속도를 측정하는 항목
  • 페이지 뷰포트에서 가장 큰 영역을 차지하는 이미지나 텍스트 블록이 렌더링되는 시간을 측정
  • 2.5초 이하의 로딩 속도를 만족시켜야 좋은 점수를 받음
  • 초기 로딩 성능 속도에서 충분히 의미있는 지표

■ FCP

  • 전체 페이지를 대상으로 측정

■ FID

  • 사용자가 처음 페이지와 인터랙션을 하였을 때 얼마나 빠르게 응답하였는지 속도를 측정
  • 이벤트 처리에 대한 지연만 측정
  • 이벤트를 처리하는 시간, 실행된 후 업데이트 되는 시간까지 측정하지 않음

■ TTI

  • 사용자와 페이지가 인터랙션하는 시간을 측정
  • 시간이 오래걸리는 작업들이 모두 완료된 후 페이지가 완전히 사용자와 상호작용할 수 있는 상태가 되기까지 걸리는 시간

■ CLS

  • 불필요한 레이아웃의 변경 빈도를 측정하여 시각적 안정성을 판단

라이트 하우스

구글에서 제공하는 오픈 소스

■ 측정 지표

  • FCP
  • LCP
  • CLS
  • SI
  • 화 면에 보이는 영역의 로딩 속도를 측정한 지표
  • TTI
    • 페이지가 완전히 사용자와 상호작용할 수 있는 상태가 되기까지 걸리는 시간
    • FCP부터 마지막 Long Task의 종료 시점
  • TBT
    • 페이지가 마우스 클릭, 화면 탭 또는 키보드 누름과 같은 사용자 입력에 응답하지 못하도록 차단하는 총 시간

■ Best Practice

오래된 관행, 안티 패턴을 찾아주고 더 적합한 API로 대체하여 코드를 작성하도록 도와줌

Single Page Appplication

한개의 페이지로 이루어진 애플리케이션을 의미 필요한 부분만 재렌더링해서 가져오는 방식

단점:

  • 규모가 커지면 초기에 로딩해야 하는 자바스크립트나 CSS 번들 파일의 용량이 증가
  • 검색엔진최적화(SEO)가 어려움 (검색 엔진 봇이 자바스크립트를 실행하지 않고 파싱된 HTML만 대상으로 크롤링하기 때문에)
  • 트리 셰이킹이나 코드 스플리팅과 같은 기법을 사용해 파일 용량을 줄일 수 있음

Server Side Rendering

서버에서 사용자에게 보일 페이지를 모두 구성해 사용자에게 보여주는 방식

장점:

  • SEO를 쉽게 처리할 수 있음
  • 페이지의 전체 콘텐츠가 구성되는 시점이 빠름

타입스크립트

정적인 타입 개념을 도입한 언어

장점:

  • 자바스크립트 문법을 거의 그대로 사용하면서 타입을 통해 개발자의 의도를 그대로 코드에 투영해 문제를 미연에 방지할 수 있음
  • 코드의 가독성이 높아짐
  • 추가 트랜스파일 없이 코드를 작성하는 시점에 오류를 바로 확인할 수 있음

단점:

  • 추가로 학습하고 적응하는 시간이 오래걸림
  • 타입이 선언되지 않은 타사 라이브러리를 사용하면 사용할 여러 메서드와 프로퍼티의 타입을 하나하나 선언해야하는 번거로움이 있음

코드 리뷰 단계에서 확인해야하는 내용

  • 이 변경사항이 개발자가 의도한대로 동작하나요? 성능의 문제는 없나요?
  • UI 변경이 있다면 합리적으로 변경되었나요? 디자인을 올바르게 반영했나요?
  • 변수, 함수의 이름이 적절하게 작성되었나요? 의미를 잘 나타내나요?
  • 팀에서 정한 코드 스타일을 지키나요? 일관적인 스타일로 코드를 작성하나요?
  • 이 변경사항이 나머지 시스템과 잘 통합되나요? 다른 코드, 기능에 영향을 주나요?
  • 변경된 코드가 생각보다 너무 복잡한가요? 코드의 가독성은 높은가요?
  • 새로 추가된 내용에 대해 문서를 추가했나요? 변경된 사항을 문서에 반영했나요?
  • 멋진 코드를 발견했다면 칭찬을 남겨주세요

코드 리뷰를 통해 얻는 것

  • 버그를 초기에 발견합니다. 실제 배포되기 전에 인지해 수정할 수 있습니다
  • 컨벤션을 일관되게 유지해 가독성을 높이고 유지 보수를 더 쉽게 합니다. 이를 통해 한 사람이 작서한 것처럼 코드 스타일을 유지할 수 있습니다
  • 코드 전반에 대한 이해가 늘어납니다. 개인이 작성한 부분 외에 다른 부분이 어떻게 동작하는지 이해를 높일 수 있습니다. 이를 통해 중복된 코드를 작성하지 않고 재사용되는 코드를 모듈화할 수 있습니다.
  • 지식을 공유할 수 있습니다. 비교적 최근 합류한 개발자들에게 히스토리를 전달할 수 있고, 새로운 문법이나 기술을 학습할 기회가 됩니다. 도한 잘 작성된 코드를 통해 고정된 코드 스타일을 더 발전시킬 수 있습니다. 이 과정을 통해 팀 자체의 역량이 함께 올라갑니다.
  • 자신이 작성한 코드에 대해 모든 팀원이 함께 책임을 집니다. 이후 이부분에 문제가 발생했을 때 리뷰 단계에서 확인하지 못한 팀원들에게도 책임이 있어 누군가를 탓하는 문화를 없앨 수 있습니다.

코드 리뷰시 주의해야할 점

  • 리뷰 내용에 개인을 투영하지 않아야한다.
  • 코드 리뷰를 적정한 양으로 자주하는 것이 좋다.- 컨벤션에 대한 생각을 주기적으로 나눌 필요가 있다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

성능을 검사할 때 Performance 탭에서 보면 된다는 사실에 대해서는 알고있었지만 보는 방법과 세부 지표들에 대해 알게 되었다. 최대한 크게 레이아웃을 변경하지 않도록 position과 같은 속성을 덜 사용하도록 노력해야겠다.

500페이지가 넘는 책을 북챌린지를 통해 완독해서 뿌듯하고, 부족했던 부분은 채우고 알고 있던 내용들은 정리하는 유익한 시간이었다.

책리뷰, 기초부터 완성까지 프론트엔드
This post is licensed under CC BY 4.0 by the author.