티스토리 뷰

There are no solutions: there are only trade-offs.

해법이라는 것은 없다. 오직 절충만이 있을 뿐이다.


    프로그램의 성능은 비즈니스 요구사항 충족이라는 우선적인 과제에 늘 밀리기 마련이지만, 개발자에게는 성능을 관리하고 개선 시켜야할 역할과 책임이 있다고 생각한다. 성능을 개선하기 위해서는 먼저 성능을 측정해야 한다. 그래야만 성능이 개선 되었을 때, 어느정도 개선되었는지 그 수치를 정확하게 측정할 수 있다.

    오늘은 Lighthouse에서 웹페이지의 품질을 분석하고 그 분석 결과를 통해 간단한 개선 위주로 정리해보려고 한다. 회사에서 일본 웹 서비스의 SEO 개선을 목표로 하고 있어, 점진적으로 개선을 시도할 예정이다. (SEO를 핑계로 프로그램 성능 왕왕 업그레이드 해보자구.!!!)

Lighthouse 소개

Lighthouse는 크롬에서 제공하는 웹페이지의 품질을 개선하기 위한 오픈소스 자동화 도구이다. 성능을 개선한다? 그럼 개발자도구의 Performance 탭과 더불어 가장 먼저 기본적으로 사용해볼 수 있는 도구 이다. 크게 다섯가지 항목에 대해서 검사(audit)를 진행한다.

  • Performance: 성능
  • Accessibility: 접근성
  • Best Practices:
  • SEO
  • 그리고 Progressive Web App

검사를 진행하는 방법에는 크롬 확장도구를 이용하는 방법, 개발자 도구에서 이용하는 방법, CLI에서 사용하는 방법, 검사 사이트를 이용하는 방법 등등 여러가지가 있는데, 이 포스팅에서는 개발자도구를 이용해서 분석하는 방법을 설명하려고 한다.

분석 결과 및 문제 해결

Performance

성능 측정 값은 측정 할때마다 변할수 있는데 이는 인터넷 트래픽, 컴퓨터 사양 등의 영향을 받기 떄문이다. 5가지 항목정도 있지만, 그중에서 나는 LCP 시간 감소와 Render-Blocking 시간 감소 두가지에서 개선을 진행하였다. 

Largest Contentful Paint Element: 콘텐츠가 포함된 최대  페인트

사용자가 처음 페이지로 이동한 시점을 기준으로 가장 큰 이미지 또는 텍스트 블록의 렌더링 시간. GOOD의 기준은 2.5초, POOR의 기준은 4.0초이다.

⛳️ 용어 정리 하고 가자

코어 웹 바이탈
좋은 사용자 경험을 제공하기 휘애 어떤 점을 개선해야 하는지에 대한 웹 성능 지표이다. 크게 LCP, FID, CLS가 있다.

Cf) FCP(First Contentful Paint)
사용가가 처음 페이지로 이동한 시점을 기준으로 우수한 사용자 환경을 제공하려면 FCP가 1.8초 이하여야 한다.

 

일본 웹 서비스의 경우 최초 사이드 진입시 APP CTA버튼이 있었는데, 해당 이미지를 webp로 바꾸고(Render Delay), <img> 태그에 fetchpriority="high"로 attribute를 삽입하였다.

Eliminate render-blocking resources

기존에는 Google Font를 동기적으로 블러와 이미지를 최적화 하였다.  web.dev에서는 폰트를 인라인 @font-face로 선언하여 처리하기를 권장하고 있는것 같았자만, 가장 적은 변경으로 최대 효과를 내고자 했던지만 일단은 우선적으로 link태그에 요소를 삽입하여 font를 비동기적으로 불러와 오류를 해결하였다.

구글 폰트로 인한 render-blocking

// _document.js
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

<link
  href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@300;400;700&display=swap"
  rel="stylesheet"
  media="print"
  onload="this.onload=null;this.removeAttribute('media');" fetchpriority="high"
/>
<noscript>
  <link
    href="https://fonts.googleapis.com/css2?family=Noto+Sans+JP:wght@300;400;700&display=swap"
    rel="stylesheet"
  />
</noscript>

Accessibility

접근성 검사의 해결 방법은 비교적 간단하다. 

[user-scalable="no"] is used in the <meta name="viewport">...

웹 페이지의 확대는 기본적으로 허용되어야 하는데 그 이유는 부분 시력, 저시력의 사용자가 웹의 텍스트를 더 쉽게 읽을수 있도록 하기 위해서 이다. 단, 경험적으로 봤을때 해당 옵션을 true로 했을 때 일부 모바일 기기에서 (특히 iOS) 의도하지 않은 scale-up으로 인해(예컨데, <input> field focusing) 문제가 발생하지는 않을지 고려가 필요하다. 가중치는 10점이다.

 

<html> element does not have a [lang] attribute

Screen Leader와 같은 기능을 사용할 때 해당 속성을 기본으로 페이지를 읽어준다. 따라서 lang 속성에 유효한 값이 있어야 하낟. 

SEO

Image elements do not have [alt] attributes

SEO는 정말이지 alt를 엄청나게 중요하게 생각하는 거 같다. 전역 검색을 통해 모든 alt태그에 값을 추가해준다.

개선 결과

개선 결과를 간략하게 표시하면 다음과 같다. 다음에는 사용하지 않는 스크립트와 스타일 시트를 최적화 하는 방향으로 개선을 시도해보고자 한다.

 

  • Performance: 51 -> 69 (35% 향상)
  • Accessibility: 51 -> 91 (78% 향상)
  • SEO: 92 -> 100 (8% 향상)

 

 

 

Reference

라이트하우스 Chrome For Developers

 

개요  |  Lighthouse  |  Chrome for Developers

Lighthouse를 설정하여 웹 앱을 감사하는 방법을 알아봅니다.

developer.chrome.com

 

Asynchronouse Google Fonts

 

Asynchronous Google Fonts For Page Speed

Eliminate the render blocking effect of Google Fonts and optimize for page speed by loading font CSS asynchronously and adding a preconnect resource hint. Hold On! Before we get into the finer points of optimizing Google Fonts, don't forget to first apply

pagespeedchecklist.com