1441 단어
7 분

Page Speed Insight 웹사이트 최적화하기

2026-05-13
2026-05-16

PageSpeed Insights에 URL을 넣어보면 내 사이트의 최적화 상태를 검사할 수 있다.

점수 자체에 집착하다 보면 끝이 없지만, 어떤 부분이 성능을 저하시키고, 접근성을 헤치는지, 권장사항을 못지키는지를 이해하고 고치는 과정은 레이아웃과 접근성, 번들 구조를 한 번씩 훑어보게 해 준다.

page-speed-insight-desktop

Cumulative Layout Shift#

Lighthouse에서 Cumulative Layout Shift라는 원인으로 점수가 떨어져 있었다.

원인 후보로 찍힌 건 거의 전부 sidebar 였다.

알아보니, 로드 직후에만 도는 진입 애니메이션 클래스가 사이드바와 그 안의 위젯에까지 걸려 있었다. transform으로 위아래를 살짝 움직이는 것만으로도 눈에 보이는 안정성 점수에는 크게 불리하고, animation-fill-mode: both처럼 지연 구간까지 키프레임 시작 상태를 유지하는 설정이 겹치면 첫 화면에서 박스가 한 번 더 밀리는 느낌이 났다.

그래서 한 일은

  • 사이드바 루트와 카테고리·태그·광고 카드 쪽에서는 진입 애니메이션을 제거했다.
  • 전역 애니메이션도 조정해서 애니메이션 때문에 레이아웃이 미끄러지는(?) 패턴을 줄였다.
  • 사이드바에는 레이아웃 틀을 유지하게 해서, 안쪽에서 생기는 변화가 메인 그리드까지 번지지 않게 했다.

점수만이 아니라 실제로 스크롤할 때 눈에 덜 거슬리는 쪽으로 체감이 좋아졌다.

LCP와 중요 요청 체인#

다른 진단 항목에서는 Largest Contentful Paint와 함께, 문서 다음에 이어지는 긴 JS 체인이 문제라고 짚어주었는데, 주로 이미지를 처리하는 부분에 끼어있는 자바스크립트들이 연결되어 있는 부분이었다.

대표적으로 본문 이미지를 눌렀을 때만 쓰면 되는 라이브러리가 있었는데, 번들이 초기 페이지와 한 줄로 이어지면 Lighthouse 입장에서는 LCP까지 가는 길목에 불필요한게 낀 것처럼 보인다.

그래서 정리한 방향은

  • 라이브러리에 대한 정적 import를 없애고, import()로 필요한 때에 동적으로 불러온다.
  • 사용자가 갤러리 이미지를 건드리면 그때 로드되도록 처리했다.

접근성, 색이 점수를 깎을 때#

성능 탭만 보다가 접근성 쪽에서 색 대비가 부족하다는 메시지가 뜬 적도 있다.

다크 모드에서 강조색으로만 텍스트를 칠해 두면, 카드 배경 위에서는 채도가 살아 있어도 대비가 모자란 경우가 있다. 위젯 안의 더 보기 같은 보조 문구는 본문용 토큰으로 바꾸는 편이 낫고, 브랜드 색 자체도 다크 모드에서 명도만 살짝 올려 전체적인 균형을 맞추는 식으로 조정했다.

점수용이라기보다, 나중에 다시 봐도 읽기 편한 UI를 목표로 한 수정에 가깝다.

Tailwind와 “사용하지 않는 CSS”#

Lighthouse가 한 덩어리 CSS에 미사용 비율이 높다고 짚은 적이 있다. 스니펫을 보면 Tailwind의 preflight 쪽 변수들이 줄줄이 나온다.

원인 중 하나는 content 스캔 경로가 넓게 잡혀 있으면, Obsidian용으로 src/content 아래에 들어 있는 플러그인 JS 같은 것까지 훑으면서 클래스 이름 조각이 섞일 수 있다는 점이었다.

그래서 Tailwind의 content 설정에서 .obsidian 폴더와, 실수로 들어간 중복 경로는 제외하도록 좁혔다. 빌드 결과의 CSS 덩어리가 조금 가벼워지는지는 환경마다 차이가 있지만, “블로그 빌드에 안 쓰는 파일은 스캔하지 말자”는 원칙으로는 맞는 선택이다.

검색 UI는 포커스될 때만#

네비게이션에 붙어 있는 검색 도 초기 번들에 합류하면 체인이 길어진다.

그래서 아주 얇은 스텁만 먼저 올려 두고, 데스크톱에서는 검색창에 포커스가 들어오거나 마우스로 눌렀을 때, 모바일에서는 검색 버튼을 누르거나 포커스가 들어왔을 때 본 컴포넌트를 import() 하도록 바꿨다. Pagefind를 지연 로딩하던 로직과도 맞춰, “검색을 건드리기 전에는 굳이 안 불러도 된다”는 선으로 맞췄다.

처음 한 번만 네트워크 비용이 들고, 검색을 쓰지 않는 방문자에게는 부담이 줄어든다.

TTFB와 문서 지연#

문서 요청 지연 시간이나 TTFB가 수백 ms로 잡힐 때는, 정적 사이트라도 엣지·리전·콜드 스타트 같은 요인이 크다. 코드 몇 줄로 100ms를 깎는 것보다, 배포 환경과 캐시 헤더를 점검하는 쪽이 현실적인 경우가 많다.

이 글에서는 코드로 손댄 부분 위주로만 적어 두었다.


정리#

점수보다 원인

PageSpeed Insights는 어디를 더 보면 좋을지 알려 주는 지도에 가깝다. 숫자 하나에 매몰되기보다, 레이아웃이 왜 움직였는지, 스크립트가 왜 이른지, 색이 왜 흐릿한지를 하나씩 짚어 가는 편이 낫다고 느꼈다.

함께 보면 좋은 글

구글 검색엔진 색인 삽질기