보통 웹 앱 설계를 마치고 모든 페이지 제작이 완료된 후에야 웹사이트가 너무도 느리다는 것을 발견하고 뒤늦게 성능 최적화를 고려하는 경우가 많습니다.

그런데 웹 사이트의 성능에 대한 기준은 어떤 것일까요?

성능에 관한 기초지식

무엇인가 만들거나 상호작용에 대한 프로토타입을 제작할 때마다 항상 자신에게 물어보기 바란다. 내 기준에서 생각하는지, 아니면 사용자 입장에서 생각하는지.
- 폴 포드, 열 개의 시간 단위

웹 페이지 성능은 결국엔 사용자에게 얼마나 빠른 속도로 콘텐츠, 상호작용을 제공하는 것인지에 달려있습니다.

웹 페이지 성능을 결정하는 요소는 다양합니다.

• 코드와 콘텐츠 용량
• 서버 호출 횟수
• 네트워크의 상대적 속도
• 브라우저와 기기 성능
• 등등 그 밖에 많은 요소

가장 중요한 척도는 체감 성능

체감 성능 면에서 사이트를 분석하고 싶다면 웹페이지 속도 테스트를 해보도록 하자.
- https://webpagetest.org/

일반적으로 '충분히 빠르게' 페이지를 로딩 한다고 판단하는 사실상의 표준 시간은 1초입니다.

반응 시간이 지연되면 인지적인 비용이 듭니다. 성능과 관련된 요건은 인간의 인지와 지각을 기반으로 합니다. 기술로 바꿀 수 있는 영역이 아닙니다.

즉, 반응 시간이 길어지면 1초 미만의 차이라도 사용자들이 알아채고 영향을 받는다는 것입니다.

제이컵 닐슨("뉴욕 타임스"가 "웹 페이지의 사용성의 대가"라고 칭한 사람)이 25년 전부터 웹 성능과 반응 시간에 대한 글을 썼습니다.

그 연구결과는 지난 25년간 변함이 없습니다.

조금만 지연돼도 사용자의 인터렉션은 변한다.

연구결과는 다음 같습니다.

• 0.1초
  즉각적인 피드백이 필요한 웹 앱에서 반응 시간은 0.1초 미만이어야 한다.
• 1초
  사용자가 읽고 탐색하는 방식으로 쓰는 웹사이트라면 반응 시간이 1초 미만이어야 한다.
• 10초
  어떤 인터랙션이든 10초 미만이어야 한다. 10초가 지연되면 사용자는 그 웹사이트를 포기할 가능성이 높다.

반응 시간이 2초에서 10초로 증가하면 이탈율이 38% 증가한다.
- 고메즈의 연구를 인용한 이컨설턴시, "150개가 넘는 웹사이트와 1억5000개의 페이지를 대상으로 이탈율 데이터를 검토"

3초의 지연이 발생하면 사용자 25%가 웹 앱을 포기한다
- 애버딘의 연구 결과

전환율과 속도와의 관계

페이지 로딩 시간이 8초에서 2초로 줄자 전환율이 74% 증가했다.
- 30개 이상의 주요 소매업체를 대상으로 진행한 고메즈의 연구를 인용한 컴퓨웨어

• 월마트
  로딩 시간이 1초 개선될 때마다 전환율이 2% 증가했다. 0.1초 빨라질때마다 수익이 1% 증가했다.
• 지큐(GQ)
  이 잡지는 페이지 로딩 시간을 2초 미만으로 80% 줄이자 월간 순방문자 수가 600만에서 1100만으로 80% 증가했다.
• 구글과 빙
  업계 선두인 두 검색엔진은 성능에 대한 A/B 테스트를 통해 0.5가 지연되면 트래픽이 20% 감소한다는 것을 밝혀냈다.
• 파이어폭스
  평균 페이지 로딩 시간을 2.2초 줄이자 파이어폭스 다운로드 전환율은 15.4% 증가했다.
• 오바마 선거운동 웹사이트
  오바마의 선거운동 웹사이트는 페이지 로딩 시간을 5초에서 2초로 줄였다. 240번의 A/B 테스트를 수행한 결과 새로운 사이트의 기부 전환율은 14%가 늘었다.

어떻게 성능을 올릴까?

어떻게 하면 속도를 높이고, 로딩 시간을 단축할 수 있을까요?

페이지 로딩 과정을 이해하고 Critical Path를 단축한다면 더 나은 속도를 얻을 수 있지 않을까? 하는 생각이 듭니다.

Critical Path : 페이지를 요청하는 시점부터 페이지를 사용할 수 있게 되는 시점까지 발생하는 이벤트들을 기록한 정보

페이지 로딩 성능과 관련된 작업을 할 때 특히 유용한 것은 개발자 도구입니다. 그 중에서도 네트워크와 퍼포먼스(성능) 탭입니다.

• 네트워크: 페이지를 렌더링하기 위해 브라우저가 요청하는 모든 asset의 상세 정보와 순서
• 퍼포먼스(성능): 여러 가지 asset이 로딩되고 렌더링되는 순서와 성능

구글의 Lighthouse는 웹 사이트 성능과 함께 수치로써 해당 웹 사이트의 성능을 보여주며 모바일 환경, 데스크탑 환경에 따라 어떤 항목에서 최적화가 필요한지 시각화하고 제안사항을 알려줍니다.

https://developers.google.com/speed/pagespeed/insights/?hl=ko

• 구글 Lighthouse는 크롬 브라우저에서도 제공하고 있고 해당 웹 사이트의 전체적인 성능을 볼 수 있습니다.
• 지속적으로 성능 지표가 업데이트 되고 그에 따른 결과도 다르기 때문에 주기적으로 체크해주는 것이 좋습니다.
• 페이지별로도 성능 지표가 차이가 있기에 모든 레이아웃 페이지에 대해서 체크하는 것도 좋을 것 같아요.
• 최근엔 Javascript 모듈에 대한 treemap도 지원해주기 때문에 브라우저에서 확인가능하여 번들된 파일에 대한 treemap을 확인하는 것도 간편해졌습니다.

성능 지표 중 주요항목으로는

• FCP: First Contentful Paint
  • 첫 번째 텍스트 또는 이미지가 표시되는 시간
• Time to Interactive
  • 완전히 페이지와 인터렉션할 수 있게 될 때까지 걸리는 시간
• Spped Index: 속도 색인
  • 페이지 콘텐츠가 얼마나 빨리 표시되는지
• Total Blocking Time
  • FCP ~ Time to interactive 사이에 모든 시간의 합으로 작업 지속 시간이 50ms를 넘으면 밀리초 단위로 표현
• LCP: Largest Contentful Paint
  • 최대 텍스트 또는 이미지가 표시되는 시간
• CLS(Comulative Layout Shift): 누적 레이아웃 이동
  • 뷰포트 안에 보이는 요소의 이동을 측정
  • 사용자가 예상치 못한 레이아웃 이동을 경험하는 빈도를 수량화
  • 시각적 안정성을 측정할 때 중요한 정보
  • 낮을수록 좋음

Browser Rendering

1. DOM Tree 생성 / Style Rules 생성
   • browser가 HTML 을 전달받으면,
   • render 엔진이 이를 파싱하고
   • DOM 노드(Node) 로 이뤄진 트리를 생성(노드(Node) = HTML element)
2. Attachment: 스타일을 처리하는 과정
   • DOM 트리의 모든 노드들은 ‘attach’ 라는 메소드가 있어서 스타일 정보를 계산해서 객체형태로 반환
   • DOM 트리에 새로운 노드가 추가되면 그 노드의 attach 메소드가 실행
   • 렌더 트리를 만드는 과정에서 요소들의 스타일이 계산
   • 계산되는 과정에서 다른 요소들의 스타일 속성들을 참조하기도 함
3. Render Tree 생성: DOM + Style
   • Style Rules를 사용하여 DOM Tree에 따라 새로운 Tree(Render Tree)를 생성
4. Layout (reflow): 스크린에 좌표 계산
   • 각 노드들은 스크린의 좌표가 주어지고, 정확히 어디에 나타나야 할 지 위치가 주어집니다.
5. Painting: 렌더링 된 요소들에 색을 입히는 과정
   • 트리의 각 노드들을 거쳐가면서 'paint' 메소드를 호출
   • 그리고 스크린에 원하는 정보가 나타남
6. Painting 후 DOM에 변화가 생기면
   • Render Tree를 재생성하고 (그러면 모든 요소들의 스타일이 다시 계산됩니다) Layout, Painting을 하는 과정이 다시 반복됩니다.

참고로 복잡한 SPA(싱글 페이지 어플리케이션) 에서는 DOM 조작이 많이 발생합니다. 그 뜻은 그 변화를 적용하기 위해 브라우저가 많은 연산을 해야한다는 뜻입니다.

그래서 VDOM을 이용하여 Layout, Painting 부분을 최소화 하는 방향으로 나온것이 React 입니다.

1. 자바스크립트로 이뤄진 가상 DOM 에 한번 렌더링을 하고
2. 기존의 DOM 과 비교를 한 다음
3. 정말 변화가 필요할 때만 DOM을 업데이트를 하는 것

React의 거짓과 진실

거짓: React가 DOM 보다 빠르다.
사실: React는 유지보수 가능한 어플리케이션을 만드는것을 도와주는데 대부분의 경우에 ‘충분히 빠르다’
- Dan Abramov-

인지 시간

사용자들이 대상 사이트 중 가장 느린 아마존을 빠른 사이트 중 하나로 인식한 반면
다운로드 속도가 가장 빠른 about.com을 가장 느린 사이트로 평가한다는 사실을 알아냈다. - 유저 인터페이스 엔지니어링 연구

asset을 구성하고 전달하는 방식에 따라 실제 사용자가 느끼는 페이지 로딩 속도가 엄청나게 달라집니다.

가장 중요한 정보가 먼저 로딩되도록 코딩이 되어 있으면 사용자는 사이트가 빠르다고 느낍니다.

우선순위를 정하기 위해서 UX 디자이너, 마케터, 콘텐츠 전략전문가들의 도움받을 수 있다면 더 좋을 수 있을 것 같아요.

마무리하며

이번 포스트에서는 웹 사이트 성능의 척도와 그 중요성에 대해 알아보았습니다. 물론 아직 빠진 부분이나 오류가 있을 수 있습니다. 웹 사이트 성능 향상에 필요한 구체적인 방법은 다음 포스트에서 다룰 예정입니다.

다음 포스트에서는 개발자의 관점에서 웹 사이트 성능을 향상시키기 위해 고려해야 할 체크리스트를 소개할 예정입니다. 이를 통해 웹 사이트의 사용자 경험을 개선하는 데 도움이 되길 바랍니다.