시뮬레이터
- localhost 로 구동되는 화면에 대한 모바일 기종에 따라 테스트 할 수 있다.
- OS, 기종에 맞춰서 모바일 별 액션
- 디버깅 가능
- IO 와 제스처 같은 테스트 가능
IO 와 같은 제스처 테스트가 가능하다.
입사 후에는 웹 뷰를 자주 다루게 되며, 사파리의 경우 화면을 맞추기 어렵기 때문에 미리 경험해보면 좋다.
→ IOS Safe Area , 노치 등등
Layout
- 브라우저에서 노출되는 화면도 감안하여 레이아웃
- bottom floating 되는 버튼 및 네비게이션 등을 브라우저에서 여는 경우의 화면 고려
- 부트스트랩 Grid 참고
- GetCha 반응형 참고
최적화
- 지금 시점이 아니라도 경험하는 것이 좋음
- 해보는 것은 무조건 추천이나 눈에 띄는 가시성이 없을 수 있다.
- Virtual Scroll도 구현해보면 좋음
- 데이터를 많이 넣어서 측정해보는 것도 좋다.
- 라이트 하우스를 사용해서 최적화해보는 방법 추천
최적화 방법
- 웹 데브를 통해서 최적화
- 라이트 하우스
- 라이트 하우스는 지표와 의미가 있으며, 이러한 의미를 아는 것이 중요하다.
- 매해 중요하다고 공표되는 의미가 달라지나 통용 기준이 있으므로 이를 따라가는 것이 중요하다.
- 진단에 영향을 미치는 요소들을 알아보는 것이 중요하다.
- 우리 프로젝트에 어떤 요소가 나쁘게 나왔으며, 진단 상세 내역을 구체적으로 확인하여 수정해보기
- 점수의 가중치가 다르다.
- 점수가 높게 뛰는 것과 낮게 뛰는 편차가 존재한다. 면접관들은 이런 편차를 직접 분석하고 개선해보는 경험을 선호한다.
- 크롬 최신 브라우저라면 도구 - 더보기를 통해서 퍼포먼스 인사이트에서 라이트하우스에서 볼 수 있는 지표를 손 쉽게 확인 할 수 있다.
- 이러한 지표가 의미하는 바와 왜 개선이 필요한지 찾아보는 것이 중요하다.
- detail에 들어가면 어떤 것들을 개선하면 좋은지 나온다.
→ 개발자 도구를 들어가서 측정 할 수 있다. (다만 컴퓨팅 영향을 받음.)
— 어떤 자원들 불러오는지 등등
→ 이후 익숙해지면 ‘성능’ (performance) 탭을 확인하면 더 상세한 내용을 확인 할 수 있다.
(Long Time 내역 등, 이후 라이브러리 개발 시에는 필요한 함수 시간까지 측정 가능하다.)
- Web Performance Test
- 최근에는 클라우드 이동하는게 중요해져서 어떤 서버를 사용해서 클라우트 올릴때 지표가 어떻게 달라지는지 확인 할 수 있다.
웹 라이트 하우스와 쌍벽의 테스트 웹사이트
Indicator가 필요한가?
최근에는 전반적으로 서비스에 필요한 성능이 빨라져서, Indicator가 필요하지 않은 경우도 많이 생긴다.
정말 Indicator가 필요한 경우인지 고민해 볼 필요가 있다.
실제로 서비스 회사(토스 등)에서는 응답이 빨라서 Indicator가 필요하지 않다면 넣지 않는 경우도 다수이다.
→ 서버에서 여러 요청와 응답이 필요해서 늦어지는 경우가 발생하는 화면에는 사용
Others
- Date-picker는 직접 만들어보면 도움이 된다.
- 약 1~2일 소요될 것
- 랜더링을 lazy하게하는 방법 고려해보기
- 좋은 라이브러리를 선택하는 것도 좋은 경험이 된다.
- 이후에 라이브러리 코드를 직접 확인해보고, 실제로 어떻게 구현하는지 확인해보면 좋다.
→ 생각보다 어렵지 않는 코드일 수 있다.
- 마감 기한이 존재한다면, 서비스를 성공할 수 있는 역할을 수행하는데 집중하는 것이 중요하다.
- 개발자는 서비스를 제한 된 시간 내에 만들어야 하는 사람