반응형 디자인 도입하기 #3. 사이트 속도 높이기

Seo·2020년 9월 29일
0

목록 보기
8/8

목차

  1. 주장 입증하기
  2. 계획 세우기
  3. 사이트 속도 높이기
  4. 콘텐츠 정리하기
  5. 협업하기
  6. 테스트와 평가

3. 사이트 속도 높이기

우리가 한 것은 단순한 리디자인이 아니었다. 조직 내에 성능에 신경 쓰는 더 나은 문화가 조성되기 시작했다.
- 팀 카들렉, "'반응형 웹디자인이 성능에 악영향을 미친다'는 말은 오히려 성능에 좋은 영향을 준다"

우리는 보통 설계를 마치고 모든 페이지 제작이 완료된 후에야 웹사이트가 너무도 느리다는 것을 발견하고 뒤늦게 성능 최적화를 고려한다.
그러나 반응형 디자인이 도입되면 더이상 그렇게 일하지 않는다.

3.1 성능에 관한 기초지식

웹 페이지 로딩 속도를 결정하는 요소는 다양한다.

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

성능이란 말이 기술 용어로 느껴져서인지 성능 개선은 보통 엔지니어에게 떠넘긴다.
하지만 이런 인식도 바뀌어야 한다.
디자이너, 마케터를 비롯해 모든 이해관계자 본인이 내리는 결정이 웹사이트의 속도에 어떤 영향을 미치는지,
그리고 희생되는 부분은 어떻게 협상해야 할지 알야아 한다.

3.1.1 페이지 용량

평균 2MB(정확히 1.953MB)
- 30만 웹사이트의 트래픽을 분석한 HTTP 아카이브 리포트의 통계

이미지는 페이지 용량에서 가장 큰 비중을 차지한다.
웹 폰트도 최근 페이지 용량을 키우는 요소 중 하나이다.

개발자들이 파일(특히 CSS, HTML) 크기를 최적화할 수도 있지만 그 정도로는 다른 증가 요소가 상쇄될 만큼 성능이 개선되지는 않는다.

3.1.2 서버 호출

웹 페이지의 모든 요소(HTML, CSS, 이미지, 폰트 등)는 브라우저를 통해 서버에 요청을 보내야 한다.
요청과 리디렉션이 발생하면 이와 관련한 데이터를 받고 처리하는 데도 시간이 걸린다.

대개 시간이 지연되는 것은 사용자와 서버의 물리적 거리에 그 원인이 있다.

그저 전적으로 엔지니어링 문제가 아니라는 것만 이해하면 된다.
모든 팀원이 이런 사실을 인식한 상태에서 의사결정을 내리도록 해야 한다.

3.1.3 다운로드 속도

기기 유형, 네트워크 속도 등 페이지 로딩 속도에 영향을 주는 요소는 많다.
그러한 모든 요소를 통제하는 것은 불가능하다.

웹 성능 전문가들은 네트워크 상태에 따라 다운로드 속도 목표를 정하고
최고속도, 평균 속도, 최저 속도 혹은 첫 번째, 50번째, 99번째 백분위수 등 특정 백분위수에 해당하는 수치가 기준에 부합하는지 확인하며 성능을 평가한다.

3.1.4 체감 성능

인터렉션 시간(time to interact)은 페이지 로딩 속도가 어느 정도로 느껴지는지 사이트의 체감 성능을 평가하는 지표다.

개발자들은 사용자가 느끼는 반응 시간을 개선하기 위해
버튼의 활성 상태 설정, 관성 스크롤(momentum scrolling) 적용, 로딩 스피너나 프로그래스 바의 표시(혹은 제거) 등 다양한 기법을 사용한다.

그러나 체감 성능에 가장 큰 영향을 미치는 요소는 따로 있다.

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

위와 같은 이유는 체감 성능과 작업 완성도 사이에 강력한 상관관계가 형성되어 있었다.

가장 중요한 정보가 먼저 로딩되도록 코딩이 되어 있으면 사용자는 사이트가 빠르다고 느낀다.
우선순위를 정하는 것이 중요하기 때문에 UX 디자이너, 마케터, 콘텐츠 전략 전문가들의 도움이 필요하다.

3.2 성능이 중요한 이유

속도 그 자체가 중요한 것이 아니다.

웹사이트의 속도에 따라 기업이나 사용자에게 제공하는 가치가 변하기 때문에 관심을 기울이라고 하는 것이다.

3.2.1 반응 시간

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

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

제이컵 닐슨("뉴욕 타임스"가 "웹 페이지의 사용성의 대가"라고 칭한 사람)이 25년 전부터 웹 성능과 반응 시간에 대한 글을 써왔다.
그 연구결과는 지난 25년간 변함이 없다.
조금만 지연돼도 사용자의 웹사이트 인터렉션 방식이 변한다는 것이다.

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

3.2.2 이탈율

페이지 로딩이 느리면 사용자 다수는 그 웹사이트를 떠나서 다시는 돌아오지 않는다.

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

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

3.2.3 검색 엔진 최적화

구글은 2010년 페이지 랭킹 알고리즘에 사이트 속도를 포함시켰다.
구글은 잘못된 리디렉션처럼 사이트 성능에 영향을 주는 모바일 설정 문제를 감점 요인으로 본다.

3.2.4 전환율

전환율 : 인터넷 마케팅 분야에 있어서, 전환율이란 웹사이트를 방문한 사람 중, 소정의 유도된 행위를 한 방문자의 비율을 말한다. 유도된 행위란, 예를 들면, 무언가를 구매한다든가 사이트의 핵심 문서를 읽는다든가, 무언가를 다운로드받는다든가 하는 행위를 말한다.
- 위키피디아

스마트폰 전환율은 원래 별로 높지 않다.

전환율을 높이기 위해 신경 써야 할 요소는 이외에도 많지만,
한가지 분명한 사실은 사이트 속도가 개선되면 전환율도 개선된다는 것이다.

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

성능 개선이 바로 사업적 가치의 증가로 이어진 것도 있다.

  • 월마트
    로딩 시간이 1초 개선될 때마다 전환율이 2% 증가했다. 0.1초 빨라질때마다 수익이 1% 증가했다.
  • 지큐(GQ)
    이 잡지는 페이지 로딩 시간을 2초 미만으로 80% 줄이자 월간 순방문자 수가 600만에서 1100만으로 80% 증가했다.
  • 구글과 빙
    업계 선두인 두 검색엔진은 성능에 대한 A/B 테스트를 통해 0.5가 지연되면 트래픽이 20% 감소한다는 것을 밝혀냈다.
    A/B 테스트 : 웹 사이트에서의 A/B 테스트 예제. 한 웹 사이트에서 한 개의 버튼 요소의 디자인만 다른 두 가지 버전을 무작위로 방문자에게 제공해, 두 디자인의 상대적인 효용성을 측정할 수 있다.(위키피디아)
  • 스테이플스
    홈페이지 다운로드 시간 중앙값을 1초 줄이자 전환율은 10% 증가했다.
  • 파이어폭스
    평균 페이지 로딩 시간을 2.2초 줄이자 파이어폭스 다운로드 전환율은 15.4% 증가했다.
  • Shopzilla
    페이지 로딩 시간을 5초 줄이자 사이트 전환율이 7%에서 12% 증가했다.
  • 오바마 선거운동 웹사이트
    오바마의 선거운동 웹사이트는 페이지 로딩 시간을 5초에서 2초로 줄였다.
    240번의 A/B 테스트를 수행한 결과 새로운 사이트의 기부 전환율은 14%가 늘었다.

3.3 반응형과 성능

현실을 인정해야 한다고 본다.
반응형 웹디자인 때문에 빠른 웹사이트를 만들기가 어려워졌다.
- 가이 포자르니, Akamai 웹&모바일 전 CTO

반응형 웹사이트 속도가 느려지는 원인 두 가지가 무엇인지 살펴보자.

3.3.1 복잡한 프론트엔드 코드

반응형 웹사이트에 쓰이는 HTML, CSS는 데스크톱 혹은 모바일 전용 사이트보다 복잡할 수밖에 없다.

사실 HTML, CSS 스트립트가 전체 페이지에서 차지하는 분량은 일부에 불과하다.

진짜 문제는 제대로 구현되지 못한 반응형 디자인에 불필요한 콘텐츠까지 다운로드 될 때 발생한다.

3.3.2 불필요한 콘텐츠 다운로드

반응형 웹사이트 72%가 모든 해상도에서 해당 웹사이트 전체 콘텐츠를 다운로드 한다는 것을 알아냈다.
화면이 줄어들 때 용량이 크게 줄어드는 사이트는 단 6%뿐이었다.
- 가이 포자르니 2012~2013 연구자료 중-

  • 다운로드하고 숨기기
    모바일 사용자에게 부담을 주지 않기 위해 가장 간단한 방법은 화면이 작아질 때 콘텐츠를 숨기는 것이다. 가령 display:none 같은 경우 모든 콘텐츠를 다운로드하지만 사용자에게는 보이지 않는다.
  • 다운로드하고 줄이기
    큰 이미지를 비롯해 여러 유형의 미디어를 다운로드한 후 작은 기기에 맞게 크기를 줄인다.

문제는 실행에 있다.
기술을 탓하지 마라
- 팀 카들렉, 반응형 디자인 실무의 저자

개발자들이 연습을 하면 할수록 실행 수준은 높아질 것이다.

3.4 콘텐츠 전략

개발자는 CSS, JS를 리팩터링하고 서버 호출 횟수를 줄이기 위해 파일을 결합하고 파일과 이미지를 압축하고 캐시할 뿐 아니라 코드에서 불필요한 공백도 없앤다(minification, jquery-min.js 같은 파일)

그러면 나머지 다른 이해관계자들이 영향을 미치는 것은 무엇인가?

3.4.1 불필요한 콘텐츠

"데스크톱 사이트가 너무 비어 보이지 않을까요?"

이러한 의견이나 생각은 실제로는 물건을 좀 버려야 하는 상황인데 정리함을 사러 가는 것인 격이다.

필요 없는 콘텐츠를 정리하는 것은 꼭 필요한 일이다.

3.4.2 큰 이미지

이미지는 데스크톱 사이트에서도 페이지 용량을 키우는 주원인이다.
반응형 사이트에서는 특히 더 큰 문제가 된다.

불필요하게 큰 이미지를 다운로드하는 것이 반응형 사이트의 성능을 떨어뜨리는 가장 큰 원인이다.
더 심한 경우 똑같은 이미지를 여러 크기로 다운로드하기도 한다.
- 팀 카들렉, 반응형 디자인 실무의 저자

이미지를 최적화하는 다양한 기법이 있지만 개발자라면 그보다 먼저
이 이미지가 정말 필요할까? 라는 생각을 해보아야 한다.

3.4.3 이미지 슬라이드

웹사이트에 큰 이미지가 몇 개 있다면 '성능을 저하시키는 녀석들을 최대한 작은 공간에 모아두려면 어떻게 해야 하지?' 이럴 때 이미지 슬라이드가 답이라고 생각할 수 있다.

마케터와 이해관계자들은 이미지 슬라이드를 사랑한다.
귀중한 부동산(정해진 페이지 크기)을 제대로 분배하겠다는 결단을 내리기보다 슬라이드 속에 회전하게 두면 그만이라고 생각하는 것이다. 당연히 이런 방식은 문제를 해결할 수 없다.

슬라이드에 맨 처음 등장하지 않는 다른 이미지와 인터렉션하는 사용자는 소수에 불과하다고 한다.
- 에릭 러니언, 노트르담대학 테크니컬 디렉터

슬라이드를 넣는 건 문제가 있는 목표를 달성하겠다는 구실로 코드와 페이지 용량만 불필요하게 늘리는 행위다.

3.4.4 웹 폰트

오늘날 웹에는 타이포그래피 안전지대가 없다.
- 조던 무어, Eyekiller 웹디자이너 겸 프론트엔드 개발자

웹폰트가 존재하여 이러한 문제를 해결할 수 있지만 사용자가 더 많은 파일을 다운로드해야 하기 때문에 성능에도 영향을 미친다.
(화면 렌더링을 방해하거나 텍스트 깜빡임(FOUT: Flash Of Unstyled Text))

마케터와 디자이너도 어떤 폰트가 반드시 꼭 필요한 것인지 제대로 결정할 책임이 있다.

  • 그 폰트가 진짜 전부 필요한가?
  • 그 폰트를 위해 그만한 용량과 문자 집합이 꼭 필요한가?
    가령 일정 폰트의 볼드체, 이텔릭체가 없어도 된다면 그 부분을 제외시켜도 된다.
  • 다른 서체를 써도 되는가?
    비슷한 스타일 중 파일 사이즈가 더 작은 대안 서체를 선택하는 방법도 있다.
  • 작은 화면도 큰 화면과 똑같이 보여야 하는가?
  • 아이콘 폰트를 SVG로 대체할 수 있을까?
    하지만 아이콘 폰트는 스크린 리더나 난독증 전용 시스템 폰트를 쓰는 이들의 접근성을 저해한다.

3.4.5 소셜네트워크 관련 도구

페이스북, 트위터, 텀블러, 핀터렛트, 링크드인, 구글, 레딧...

소셜미디어 위젯 때문에 페이지 로딩 속도나 품질이 저하될 수 있다.

  • 공유 기능이 진짜 필요할까?
  • 링크로 충분할까?
  • 지구에 등장한 모든 소셜네트워크가 필요한가?

3.4.6 서드파티 서비스

모든 서드파티 서비스는 성능에 영향을 미친다.
(추천 엔진, 분석, 지도, 동영상, 광고...)

애초에 서드파티 서비스가 필요한 이유는 대개 그 서비스가 전환율을 높이는 사업적 가치가 있다고 믿어서다.
하지만 페이지 로딩이 느려지면 사용자는 떠나고 전환율도 낮아진다.

  • 전환율 증가 목표는 얼마인까?
    해당 서비스를 추가했을 때 기대하는 만큼 전환율이 오르는 것이 중요하다
  • 성능 저하는 어느 정도 일어날까?
    간단한 A/B 테스트를 통해 해당 서드파티 서비스가 있을 때와 없을 때를 비교하면 성능이 어느 정도 저하되는지 확인할 수 있다.
  • 성능이 저하되었을 때 전환율은 얼마나 낮아질까?
    계산하기 어려울 수 있다. 일반적으로 1초가 지연될 때마다 전환율이 7%가량 내려간다고 한다.

3.5 성능 예산 설정

측정하지 않은 것은 관리할 수 없다.

마크 퍼킨스(Clearleft의 시니어 프론트엔드 개발자)는 성능 예산이라는 개념을 처음 제안했다.
이해관계자들이 사전에 각 페이지의 최대 용량을 1MB 등으로 정해두는 것을 가리키는 말이다.

설계, 제작 프로세스 전반에서 일어나는 모든 결정이 다른 부분에 영향을 미친다는 인식을 만들어야 한다.
사전에 정해둔 '예산'이 있으면 프로젝트 초기에 포함시킬 수 있는 것과 없는 것을 분명하고 구체적으로 평가할 수 있다.
- 마크 퍼킨스

성능 예산은 이혜관계자들이 통제할 수 있는 범위 내에서 성능의 여러 측면에 주의를 기울이게 할 장치를 만드는 것이다.

성능 예산을 세울 때 고려할 사항은 다음과 같다.

  • 현재 페이지 용량
    용량이 가장 큰 페이지는 어느 정도 수준인가?
    공격적이면서 동시에 현실적인 목표를 세워라
  • 경쟁자와 비교
    페이지 용량 예산 이야기에 눈 하나 깜빡하지 않던 이해관계자라도 더 빠른 경쟁자를 보여주면 즉시 동기부여가 된다.
  • 서버 호출
    이해관계자들이 파일이나 서드파티 서버 호출을 추가할 때 얼마나 많은 호출이 일어나는지까지 알 필요는 없다.
    하지만 각 페이지에 어떤 영향을 미치는지 정도는 알아두어야 한다.
  • 경험적 지표
    전체 로딩 시간이나 첫 번째 인터렉션 시간 지표는 이해관계자들이 직접적으로 제어할 수 없는 부분이기는 하다. 그러나 각 지표에 대한 목표치를 설정해두면 논의에 도움이 된다.
  • 맞춤형 로딩 지표
    트위터는 첫 번째 트윗을 본 시점을 측정하는 것으로 유명하다.
    링크를 클릭한 시점부터 각 페이지 타임라인의 첫 번째 트윗을 보는 시점까지 걸린 시간을 측정한다.

상대에 따라 적절한 언어를 선택해야 한다는 말이다.
개발 팀에 말할 때는 첫 번째 렌더링 시점과 첫 번째 인터렉션 시점 같은 지표에 집중해야 한다.
마케팅 팀에 이야기할 때는 전환율과 이탈율에 초점을 맞추어야 한다.
- 제이슨 티볼트, Limelight Networks의 마케팅 전략 시니어 디렉터

성능 예산은 이해관계자들에게 개발자가 쓰는 지표를 알려주기 위해 세우는 것이 아니다.

모두가 성능에 집중하게 하는 것이 목표다

profile
개발관심자

0개의 댓글