프리온보딩 3회차 1월

오늘은 성능 측정 도구와 최적화 방법에 대해 간단히 알아보고 이력서에 대해 배웠다.

 

성능 측정 도구

소개드릴 도구들은 말 그대로 성능을 측정하는 도구들인데 따로 설치가 필요하지 않고 크롬에서 제공하는 도구들입니다.

 

1. Lighthouse

개발자 도구에 관심을 가지다 보면 여러 탭들을 볼 수 있습니다. 그중에 요소 탭과 콘솔 탭을 위주로 사용하고 가끔 네트워크 탭과 애플리케이션(스토리지, 쿠키 등) 탭을 사용하는 저로써는 존재만 알고 사용해보지 못한 도구입니다. 간단하게 설명하자면 웹 성능을 종합적으로 분석하는 도구이며 주요 기능으로는 성능 분석, 접근성검사, SEO평가, PWA기준 평가 등이 있습니다. 이 외에도 다양한 기능을 제공하기 때문에 필요하다면 더 많은 공부를 통해 활용해 보는 것이 좋을 듯합니다.

 

Lighthouse를 사용할 때 주의사항이 존재합니다. 일반적으로 개발을 하는 경우 배포 모드가 아닌 개발 모드 환경에서 개발을 합니다. 이때 Lighthouse를 이용해 점수를 측정하면 점수가 낮게 나올 수 있습니다. 왜냐하면 배포를 하기 전 코드가 최적화가 덜 되어있기 때문입니다. 간단한 예로 빌드하게 되면 js 파일의 공백은 모두 사라집니다. 그렇기 때문에 반드시 배포 후 또는 배포되는 환경과 동일한 환경에서 Lighthouse를 이용해야 정확한 점수가 나올 수 있습니다. 또한 Lighthouse는 개발자에게 오류를 수정하도록 권유하기도 하는데, node_modules 등 개발자가 컨트롤할 수 없는 에러는 무시하셔도 됩니다.

 

2. Performance(성능)

성능 탭의 경우 runtime에서의 성능을 측정합니다. 필요한 부분을 동작시켜 특정 부분만 볼 수 있다는 장점이 있습니다. 측정되는 성능으로는 렌더링, 자바스크립트, 메모리 관리, 반응성(FID), 네트워크 성능 등 다양한 성능에 대한 정보를 알려줍니다.

 

3. Performance insights(성능 통계)

아직 실험 단계이지만 다른 측정 도구들과 달리 간소화해 관련된 정보만 알려준다고 합니다.

 

4. Profiler

https://ko.legacy.reactjs.org/docs/profiler.html

Profiler는 react 내장 기능으로 API를 이용해 컴포넌트 별 렌더링 빈도와 비용을 측정합니다. 렌더 중 로그를 찍어 원하는 값을 볼 수 있습니다. 하지만 약간의 오버헤드를 발생시키기 때문에 배포하기 전에 해당 코드들은 지우는 것이 좋습니다.

 

위와 같이 측정하는 도구들이 있다면 측정하는 기준들도 당연히 있겠죠? 웹 바이탈(Web vital)은 Google에서 필수적인 품질의 통합 지침을 나타내 줍니다. 웹 바이탈 중에도 모든 웹 페이지에 적용되는 항목들 중 중요한 코어 웹 바이탈이 있습니다.

core web vital

• LCP : 최대 콘텐츠 렌더링 시간으로 로드 성능을 측정.
• FID : 최초 입력 반응 시간으로 상호작용을 측정.
• CLS : 레이아웃 변경 횟수로 시각적 안정성을 측정.

현재는 위 3가지 항목들이 정식 항목들이며 다가올 3월에는 FID 대신 INP로 대체한다는 Google의 계획도 존재합니다.

 

최적화

1. Code splitting(코드 분할)

길고 많은 코드를 번들된 코드 또는 컴포넌트로 분리하는 방법입니다. 분리된 번들이나 컴포넌트는 필요시 특정한 컴포넌트만 로딩하거나 병렬로 로딩할 수 있습니다. 코드 분할을 사용하는 이유는 개발을 진행하다 보면 코드가 길어지고 third-party 라이브러리를 사용할 수도 있습니다. 이때 우리는 커진 번들을 넘기지 않고 작게 쪼개서 보낸다면 로딩하는 시간이 단축되고 이에 따라 성능 향상이 발생할 것입니다. 물론 코드 분할을 한다고 해서 번들의 크기가 작아지지 않습니다.

 

리액트에서는 React lazy와 suspense의 조합을 이용하면 구현할 수 있습니다.

 

추가적으로 $npm dedupe 기능을 활용한다면 실제 라이브러리의 크기가 작아지는 효과를 얻을 수 있습니다.

 

2. Lazy loading(지연 로딩)

개발하면서 최적화 이슈가 발생할 때 들어본 경험이 있는 단어입니다. 간단하게 말하면 필요한 요소만 로딩하고 당장 필요하지 않는다면 로딩을 지연시켜 성능을 향상시키는 방법입니다. 지연 로딩은 다양한 곳에 적용시킬 수 있는데 바로 위에서 설명한 코드 분할에서도 이용되고, css, image, Intersection Observer API 등 여러 곳에서 활용할 수 있습니다.

 

이력서 팁!

최적화에서 중요한 것은 어떤 최적화를 말해주는 것보다 문제를 어떻게 찾고 어떻게 해결했는지 작성하는 것이 좋다. 예를 들어 'code splitting과 lazy loading을 통해 최적화를 이뤘다.'라는 멘트보다 '이미지가 많아 화면의 로딩을 느렸는데 lazy loading을 이용해 로딩 속도를 줄였다.'라는 멘트가 좀 더 좋다는 이야기이다. 이때 실제 로딩 속도가 얼마나 감소했는지 수치적으로 적어주면 더 좋다.

 

아하 모먼트 - 이력서 / 포트폴리오 작성 방법

이력서의 큰 틀을 보면,

1. 자기소개
   • 적당한 썰풀이와 그에 맞는 스토리가 있어야 함. 일관성이 필요함.
2. 연락처
3. 개인프로젝트
   • 최신순
   • 본인이 담당한 업무
     • 무엇을 어떻게 왜 했는지. 왜?라는 질문에 대한 답변까지 기록
     • 경력직은 실적 어필.
4. readme.md 정리하기 https://github.com/365kim/2021-woowacourse-frontend?tab=readme-ov-file
   1. 간단한 프로젝트 설명
   2. 빌드하는 법
   3. 인증이 필요하다면 테스트할 수 있도록 인증 정보 제공

위 사항들이 필수 사항이라고 볼 수 있습니다.

 

추가적인 사항들을 살펴보면,

• 이력서와 포폴에서 겹치는 부분은 이력서에서는 간결하게 줄이고, 포폴에서 자세하게 기록하는 것이 좋습니다.
• 경험을 적을 때 프론트(본인이 지원하는 직무)에 적절한 경험인가를 고민하는 게 좋습니다.
• 포맷의 일관성. 프로젝트를 작성하는데 프로젝트마다 포맷이 다르다면 보는 사람이 불편할 수 있습니다.
• 기능 구현 작성 시 구현하게 된 이유도 같이 적으면 좋습니다. 해당 사항은 특이한 구현이나 본인이 필요에 의해 구현했을 때 적는 것이 적절합니다.
• 기여도 여부(필요하다면 적어도 되고 적지 않아도 괜찮습니다.)

 

질의응답

https://blog.ull.im/engineering/2019/03/10/logs-on-git.html

https://f-lab.kr/blog/developer-blog-tips

쉽게 시작하는 타입스크립트(책추천)

https://www.youtube.com/playlist?list=PL4C4720A6F225E074 (CS 지식)

재그지그 개발자 블로그(포폴 참고)

 

기타

nginx, reverse proxy, certbot, cronjob, vercel, windowing, 우피, minification, tree shaking, Intersection Observer API

 

참고
https://web.dev/articles/vitals?hl=ko (web vital)

https://developer.mozilla.org/en-US/docs/Glossary/Code_splitting (code splitting)

https://legacy.reactjs.org/docs/code-splitting.html (code splitting)

https://developer.mozilla.org/ko/docs/Web/Performance/Lazy_loading (lazy loading)

학습 2024.01.09

느낀점 매번 아 이 단어~하고 넘어갔던 것들에 대해 어느 정도 알게 되어 좋았고, 이력서를 고민하고 있는 지금 좋은 팁들을 많이 들었다.