오늘의 집 성능 및 접근성 분석

jjyung·2022년 1월 16일
7

분석

목록 보기
1/1

글을 적게 된 계기

오늘의 집에는 조은 개발자님이 계신다. 프론트엔드 개발자를 꿈꾸는 사람이라면 프론트계의 핵인싸 조은님을 모를 수가 없다!(고 생각합니다...) 조은님께서는 접근성과 성능의 중요성을 많이 언급하셨고, 그래서 조은님이 계신 오늘의 집 사이트는 어떻게 구성되어있을까 상당히 궁금해졌다.

들어가자마자 예쁜 콘솔창을 보고 '역시.. 조은님이 계신 곳은 다른가?' 라는 생각을 했다. 다른 사이트도 방문해서 개발자 도구를 열어보았지만 이렇게 이쁘게 해놓은 곳은 처음이었다. '이런 곳에서 프론트엔드 개발자로 일하면 어떨까?' 라는 생각도 하게 되었다! (나 뽑아줘요...열심히 일할게요...ㅠㅠ)

측정 기준

네트워크 환경

서비스의 성격에 따라 초점을 맞추는 것이 합리적이기 때문에 고객의 특징부터 생각해보았다. 오늘의 집 이용 고객들은 대부분 안정적인 환경에서 앱을 이용하겠지만, 처음 방문한 사람들이나 모바일을 이용해 접근하는 사람은 답답함을 느낄 수 있다. 그래서 제한된 네트워크와 캐시 비활성화를 통해 답답할 수 있는 환경을 시뮬레이션해보기로 했다.

성능

성능 이야기에 앞서 우선 웹 바이탈에 대해 이야기 해보고자 한다. 웹 바이탈이란 구글에서 정한 "필수적인 품질 신호에 대한 통합 지침"이다. 즉, 우수한 사용자 경험을 위해 구글에서는 성능 측정을 단순화하여 보여주며 사용자의 관점에서 항목들을 분석했다. 그 중 core web vitals에는 LCP, FID, CLS가 존재한다.

LCP란 Largest Contentful Paint로 로딩 성능을 측정한다. 즉, 2.5초 이내에 로딩이 되어야 우수한 사용자 경험을 제공한다는 것이다.

FID는 First Input Delay로 사용자와의 인터렉션을 의미하는데, 사용자가 어떤 인풋을 넣었을때 아웃풋이 나올때까지의 시간이 100ms보다 적어야 우수한 사용자 경험을 제공한다.

CLS는 Cumulative Layout Shift로 0.1 이하로 FOUT 발생해야 사용자가 알아차리지 못하고 시각적 안정성을 제공한다고 규정했다.


이 이미지에서 레이아웃이 총 시간의 30% 가량을 차지한다는 것을 알 수 있는데 그 이유는 스크립트를 평가하고 레이어 트리를 업데이트하기위해 많은 시간을 사용했다는 것을 알 수 있다.(그래서 다시 레이아웃 계산 및 리페인팅을 최소화 시키는 것이 좋다)


이미지가 많은 사이트인데도 불구하고 성능 점수가 높았고, 그럴 수 밖에 없는 이유는 데이터 지연 로딩, 이미지 스프라이트 등을 사용했기 때문이 아닐까라는 생각을했다.

이런 그래프들을 보면서 과연 오늘의 집의 웹 성능 예산이 궁금해지면서 동시에 성능 개선을 위해서는 어떻게 해야할까라는 고민을 더 하게되었다.(분석을 하면 할수록 아직 배울것이 많고 모르는 것이 많다고 느껴졌다)
*** 웹 성능 예산이란 서비스의 품질을 유지하기 위한 합의점이자 약속이다

2. Treemap


라이트하우스에서는 2021년부터 트리맵이라는 기능을 제공해주기 시작했다. 소스맵을 설정해두면 트리맵을 사용할 수 있게 되는데, 어떤 부분을 최적화해야하는지 보여준다. 마치 웹팩 번들러 분석기처럼 동작을 한다.

이 이미지에서는 리소스 바이트와 사용하지 않는 바이트가 적혀져있다. 그리고 계층 구조도 알 수 있지만 오늘의 집 사이트의 트리맵으로는 세분화를 잘 파악하기는 어려웟다.

접근성

1. 시멘틱하지 않은 태그, 하지만 명확한 클래스 이름


대부분 div 태그로 이루어져있어 깜짝 놀랬다. 아무래도 div를 사용했을때가 가장 편하고 오류가 덜 발생하기는 하지만 시멘틱하지않아 개발자가 코드 구조를 파악하기는 쉽지 않다.

하지만 클래스 이름은 BEM 방식을 사용하여 명확하게 나타내서 어떤 역할을 부분인지 알 수 있었다. 사실 클래스명 짓기 정말 힘든데 이런 노고를 보면 대단하다고 생각되었다 (프로젝트 할 때마다 클래스명 지을때 상당한 고통을 받았다)

2. WAI-ARIA의 생략 및 불일치

  • aria-label의 생략

button에 aria-label을 지정해주며 스크린 리더기가 어떤 역할인지 명확히해주어야 하는데 많은 버튼의 aria-label이 생략되어있다.

(조금 일관적이지 않다고 생각했던 부분은, 어떤 버튼에는 aria-label에 '닫기'라고 명확히 지정되어있었고 몇몇의 버튼은 aria-label이 생략되어있었다. 아마 이런부분은 스크랩 형태로 넘어간것이 대다수여서 aria-label을 생략했다고 생각한다. 하지만, 그럼에도 aria-label은 스크린 리더기를 위한 속성이기때문에 꼭 넣어야하지 않을까라는 생각을 했다)

결론

  • 라이트 하우스 하나로도 사이트의 많은 정보를 얻을 수 있다는 점은 정말 좋았지만, 여전히 라이트 하우스를 온전히 이해하지 못하는 부분이 있어 아쉬웠다. 다음번에는 라이트 하우스에 대해 조금 깊게 공부해봐야겠다.
  • 이미지가 많이 사용되었음에도 성능 점수가 높다는 것이 정말 인상깊었다. 저기서 더 성능 개선을 하기 위해서는 어떻게 해야할까 궁금하다...
  • 접근성 점수가 낮다는 점이 좀 아쉬웠다. 물론 아무리 큰 기업이라도 국내에서 접근성 점수가 높은 기업은 거의 없다고 선생님께 듣기는 했지만 점차 접근성을 고려하는 개발자가 늘어나서 모든 사람이 정보를 얻는데 있어서 차별을 받지 않는 세상이 오면 좋겠다는 생각을 했다.

Word Cited

  1. 성능분석 측정 및 최적화
  2. 렌더링 측정 및 최적화
profile
🏃‍♀️movin' forward, developer

0개의 댓글