개요
랜딩페이지가 어느정도 완성되어 다른 기능들을 하나 둘 개발 중, 메인 화면에 유독 컨텐츠들이 많아 실제 배포환경에서 렌더링이 늦거나 유저경험을 저해하는 해프닝이 생길까 하고 검사를 받아보고 싶었다.
마침, 크롬 브라우저의 관리자 모드에서 제공하는 Lighthouse가 웹 페이지의 성능, 접근성, SEO(검색 엔진 최적화), 그리고 기타 웹 품질 지표를 분석하고 개선할 수 있도록 도와주는 오픈 소스 도구라고 해서 사용해보았다.
Lighthouse 사용
검사를 받고 싶은 페이지에서 개발자 모드를 킨 후, (윈도우는 f12, 맥은 cmd+option+i 또는 fn+f12) 하단의 요소들 중 Lighthouse를 선택한다.
모드, 기기, 카테고리를 선택 후 페이지 로드 분석을 클릭
나의 경우 모드 : 기본 값, 기기 : 데스크톱, 카테고리 : 전부 선택 후 진행했다.
결과화면에선 성능, 접근성, 권장사항, 검색엔진 최적화가 뜨고 아래 측정항목이 뜬다.
스크롤을 더 내리면 각 4가지 항목에 대한 상세 점검내용과 개선방안을 보여준다. 각 항목들은 다음을 의미한다.
- 성능: 페이지 로딩 시간, 인터랙티브성, 시각적 안정성 등을 측정하여 성능 점수를 제공한다.
- 접근성 : 웹사이트가 장애인을 포함한 모든 사용자에게 얼마나 접근 가능한지를 평가한다.
- 권장사항 : 현재 페이지가 웹에 대한 표준 모범 사례를 따르고 있는지 확인한다
- 검색엔진 최적화 : 검색 엔진 최적화 관련 요소를 분석하여 웹사이트가 검색 엔진에서 잘 노출될 수 있도록 한다.
내가 주로 볼 부분은 성능으로 물론 라이트 하우스를 통한 코드 리팩토링의 경우 향후 어느정도 전체 페이지의 짜임이 완료되었을 때, 한번에 하는게 바람직하겠지만, 앞으로 마주칠 반복될 문제들은 미리고치고 다른 페이지에서도 반복하지 않고자 미리 시도해 보았다.
검사 및 개선
아, 참고로 로컬환경과 배포환경에서 다른 수치가 검사되므로 난 실제 배포환경을 최대한 검사받고자
npm run build && npm run start
위와 같이 빌드 후 실행해서 Lighthouse 검사를 진행했다. 세부 진단요소는 다음과 같았다.
아무래도 메인 페이지다 보니, 사진, 아이콘과 같은 컨텐츠들이 큼지막 하게 자리잡아 해당 파트에서 감점된 것 같았다.
개선방안 중 좀 코드 전체적으로 적용 시킬 수 있는 방법들을 이번에 적용해보기로 했다.
1. 이미지 최적화 패키지 sharp필요
Error: 'sharp' is required to be installed in standalone mode for the
image optimization to function correctly.
- 다음 같은 에러가 발생했고 내용은 이미지 최적화 패키지인 ‘sharp’를 설치해달라는 것. 설치를 했다.
- npm install sharp
2. 이미지 확장자 변경 → webp,avif
- webp의 경우 jpg, png에 비해 크기를 26% 이상 줄일 수 있다.
- avif의 경우 webp에 비해 20% 향상된 압축률을 제공하나 해당 확장으로의 변환이 가능한지는 모름
- 사파리에선 안한다곤 한다.
- 넥스트에서 제공하는 이미지 포맷기능을 사용
- next.config.js 다음과 같이 작성해서 확장자를 변환하도록 함.
- images: { formats: ['image/avif', 'image/webp'], },
3. Image 컴포넌트 사용
- 일반 html 이미지 태그인 img와 다르게 Next에서 제공하는 Image의 경우 다음과 같은 기능을 제공
- lazy lodaing : 로딩 시 필요한 이미지만 가져옴
- 이미지 사이즈 최적화 : srcset을 통한 뷰포트 너비에 로드될 이미지를 결정
- placeholder : ui변화로 인한 CLS현상을 일으키지 않고자 빈 화면을 보여줌 or blur이미지 설정 가능
- 본격적 Image 컴포넌트 사용
- 일부 img 태그를 사용중이던 BlogComment, SearchBar등 img태그를 Image컴포넌트로 변경
- Image 사이즈 fill을 사용
- 부모 요소에 relative와 width, height를 지정하는 경우 브라우저에서 사이즈를 다시 계산하지 않아 효율적이라고 한다.
4. font Dela 로컬폰트로 변경 (본인은 오히려 성능 떨어짐)
- 현재 구글 폰트인 Dela를 Next를 통해 가져오고 있는데 해당기능 사용 시 매 렌더링 마다 폰트를 받아와 적용시키는 과정에서 지연 발생
- 로컬폰트와 Next local 폰트를 통해 로고 관련 렌더링 최적화
- 나의 경우
- Pretendard를 사용중인데 배포시에 폰트 적용문제가 많아 Next에서 제공하는 localFont를 통해 지정했다.
- 이 방법은 폰트 로드 시 최적화해 FCP(First Contentful Pait)성능을 개선시킨다고 한다.
- 적용 코드
import type { Metadata } from 'next';
import localFont from 'next/font/local';
import Header from '../components/common/layout/Header';
import Rum from '../components/common/layout/Rum';
import UserProvider from '../components/common/layout/useProvider';
import '../styles/globals.css';
export const metadata: Metadata = {
title: 'Flex',
description: '내 곁에 든든한 재테크 친구! Flex',
};
const pretendard = localFont({
src: '../static/fonts/PretendardVariable.woff2',
display: 'swap',
weight: '45 920',
variable: '--font-pretendard',
});
export default function RootLayout({
children,
}: Readonly<{
children: React.ReactNode;
}>) {
return (
<html lang="ko">
<body
className={`${pretendard.variable} min-w-[1100px] mx-auto font-pretendard`}
>
<Rum>
<UserProvider>
<Header />
{children}
</UserProvider>
</Rum>
</body>
</html>
);
결론
확실히 처음 검사 때보다 더 나은 결과가 나왔지만 여전히 LGP의 경우 그렇게 좋지 못한 점수를 받은걸로 보아 사진 및 캐치프레이즈 파트에서 좀 더 최적화 할 필요가 있어보인다.
DataDog에서도 초기 페이지 로딩 및 성능에 대한 지표를 보여주곤 하는데 Lighthouse와 DataDog모두 각 서비스만의 강점이 있을 것 같다.
프로젝트 성능 개선 시기가 온다면 두 툴을 잘 사용해서 성능을 높여보고자한다.
'코딩 > Flex프로젝트' 카테고리의 다른 글
| 재테크 블로그 프로젝트 (9) - 리팩토링 [번들 사이즈 줄이기] (0) | 2024.12.29 |
|---|---|
| 재테크 블로그 프로젝트 (8) - 리팩토링 [번들 사이즈 측정] (1) | 2024.12.28 |
| 재테크 블로그 프로젝트 (6) - Next.js와 Datadog 연결 (1) | 2024.11.21 |
| 재테크 블로그 프로젝트 (5) - Next.js의 API 사전 연결 (3) | 2024.11.20 |
| 재테크 블로그 프로젝트 (4) - 중간 개발 점검 NextJS 폴더구조 재구성 (4) | 2024.10.28 |
