워드프레스 폰트 최적화 후 PageSpeed 54점: 중복 선로딩 수정 기록

워드프레스 홈에서 내려받는 폰트 용량을 줄였다. 한국어 홈은 약 2.41MB에서 103KB로, 영어 홈은 약 565KB에서 53KB로 줄어드는 것을 초기 브라우저 시험에서 확인했다. 화면도 정상으로 보였다.

운영에 반영한 뒤 확인한 PageSpeed Insights 모바일 점수는 54점이었다. 가장 큰 콘텐츠가 표시되는 데 걸리는 시간인 LCP는 19.6초였다.

다시 살펴보니 새 폰트 묶음은 정상으로 들어가 있었다. 문제는 최적화된 공개 HTML에 남아 있던 기존 분할 폰트 24개의 선로딩 태그였다. 새 묶음을 쓰면서 이전 파일까지 미리 내려받고 있었다.

중복 선로딩을 제거한 뒤의 단일 PageSpeed 측정은 모바일 91점, LCP 2.9초였다. 비교 대상은 선로딩 수정 전후다. 처음 폰트 최적화를 적용하기 전의 같은 조건 PageSpeed 결과는 확보하지 못했다.

홈에서 쓰는 글자부터 묶었다

이 사이트는 한국어와 영어 홈에서 Pretendard를 사용한다. 한글과 영문, 기호를 처리하기 위해 나눈 폰트 파일이 있었는데, 한국어 홈의 초기 로딩에서 여러 파일을 요청했다.

홈 문구에 필요한 글자를 언어별로 묶은 WOFF2 파일을 만들었다. 글이 바뀌었을 때 필요한 문자가 빠지지 않도록 기존 보완 폰트의 CSS도 유지했다. 새 묶음이나 보완 파일이 없으면 기존 폰트 전달 방식으로 돌아가도록 했다.

폰트만 바꾸고 본문·URL·배경·글자 크기는 유지하는 것이 작업 범위였다. 한국어 홈과 영어 홈에만 적용했고, 다른 글과 앱에는 같은 변경을 일괄 적용하지 않았다.

표 전체가 보이지 않으면 좌우로 이동할 수 있습니다.

표의 단위는 바이트(B)이며 브라우저가 기록한 encoded 응답 크기를 합했다. 한국어는 약 95.7%, 영어는 약 90.5% 줄었다. 이 값은 초기 브라우저 시험에서 관찰한 요청에 한정된다. 공개 최적화 HTML에 남아 있던 선로딩 요청까지 확인한 결과는 뒤에서 따로 설명한다.

화면 원본 열기

화면 원본 열기

로컬 시험과 운영 최적화는 조건이 달랐다

실제 WordPress 홈 구성과 캐시를 연결한 테스트 환경에서도 한영 PC·모바일을 비교했다.

제한 회선 시험에서는 폰트 용량 감소가 load 시간에 반영됐다. 예를 들어 1.6Mbps·지연 150ms 조건의 PC 시험 중앙값은 한국어 홈 14.443초에서 3.463초, 영어 홈 4.367초에서 3.458초였다. FCP는 대체로 비슷했다.

이 수치는 외부 광고·추적 요청을 제외한 로컬 시험 결과다. CPU 제한을 포함한 PageSpeed의 모바일 시험과도 조건이 다르다. 로컬의 load 시간은 운영 LCP나 PageSpeed 점수와 직접 비교할 수 없다.

FlyingPress 클라우드 최적화도 별도로 확인해야 했다. 기존 라이선스는 localhost 테스트 환경에 인증할 수 있었지만, 클라우드 서버가 localhost의 페이지와 자산에 접근할 수는 없었다. FlyingPress 공식 문서도 로컬 환경에서 클라우드 최적화가 정상 동작하지 않는다고 설명한다.

이후 운영 반영 승인을 받아 홈 두 곳에 적용했다. 운영에 설치된 FlyingPress 5.6.6에서 클라우드 응답 200, 분석 JSON 저장, PC·모바일 HTML 캐시 생성과 공개 응답의 HIT를 확인했다.

여기까지는 배포와 캐시 생성이 정상이라는 확인이었다. 공개 페이지가 필요한 파일만 받는지, 느린 모바일 조건에서도 빨라졌는지는 더 확인했어야 했다.

PageSpeed에서 LCP 19.6초가 나왔다

2026년 10월 23일 밤 확인한 모바일 보고서는 성능 54점이었다. FCP는 3.887초, LCP는 19.582초였다. LCP 대상은 대표 이미지가 아니라 홈의 제목이었다.

화면 원본 열기

이 보고서에는 새 홈 전용 폰트 묶음도 보였다. 동시에 기존 PretendardVariable.25.woff2, .16.woff2 같은 분할 파일도 내려받고 있었다.

처음에는 이전 캐시나 CDN에서 다른 파일을 제공하는지 의심했다. 원본 서버와 CDN에서 새 WOFF2 파일을 받아 해시를 비교했고, 파일 내용과 형식, CORS 응답이 정상임을 확인했다. 새 파일의 누락이나 손상으로 설명할 상황은 아니었다.

다음으로 실제 공개 HTML의 선로딩 태그를 확인했다. 여기에 기존 폰트 요청이 남아 있었다.

새 폰트와 이전 preload가 함께 남아 있었다

브라우저는 CSS를 보고 필요한 폰트를 고른다. 그런데 preload 태그는 해당 자원을 일찍 가져오도록 브라우저에 힌트를 준다. 이번 공개 HTML에는 아래와 같은 형태의 태그가 여러 개 남아 있었다.

<!-- 실제 문제를 설명하기 위해 주소를 줄인 예시 -->
<link rel="preload"
      href="/fonts/PretendardVariable.25.woff2"
      as="font"
      type="font/woff2"
      crossorigin="anonymous">

홈 전용 묶음을 추가해도 이 태그가 남아 있으면 이전 파일을 추가로 가져올 수 있다. 실제 최적화 HTML에서 확인한 구형 폰트 선로딩 태그는 24개였다. PageSpeed의 다운로드 목록에서도 기존 분할 파일을 확인했다.

FlyingPress의 분석 결과 재사용 과정도 살펴봤다. 설치 버전의 코드는 HTML 구조 등을 바탕으로 만든 해시로 분석 결과를 재사용한다. inline 폰트 CSS가 바뀌었을 때 기존 폰트 힌트와 어긋날 가능성이 있었다. 다만 힌트가 만들어진 내부 원인의 전부를 확정한 것은 아니다. 확인한 사실은 공개 HTML의 구형 선로딩 24개와 실제 추가 다운로드다.

수정은 홈 두 곳으로 제한했다. 새 홈 전용 묶음이 있는 응답에서만 사이트와 CDN의 구형 Pretendard 분할 파일 선로딩을 제거했다. CSS의 보완 폰트 선언은 남겨 두었다. 나중에 홈 문구에 새 글자가 들어가면 필요한 보완 파일을 요청할 수 있다.

다른 페이지의 선로딩이나 외부 출처의 태그, 새 폰트 힌트는 유지하도록 회귀 검사도 했다. 모든 페이지에서 preload를 꺼 버리는 방식은 쓰지 않았다.

파일을 교체한 직후에도 처음 생성된 HTML에는 이전 태그가 남았다. 서버의 PHP 코드 캐시는 파일 변경을 60초마다 다시 확인하는 설정이었다. 이 주기가 지난 뒤 홈 캐시를 다시 만들었고, 저장된 HTML과 공개 HIT 응답에서 구형 선로딩 태그가 24개에서 0개로 줄었음을 확인했다. 설정 확인과 재생성 시점을 함께 기록했다.

수정 후 모바일은 91점이었다

중복 선로딩이 사라진 공개 응답을 확인한 뒤 PageSpeed를 다시 실행했다. 모바일은 91점, LCP는 2.853초였다.

표 전체가 보이지 않으면 좌우로 이동할 수 있습니다.

화면 원본 열기

캐시가 완전히 갱신되기 전의 중간 측정은 56점, LCP 14.912초였다. 이 결과는 수정 완료 후 성과에 섞지 않고 별도로 보관했다.

같은 최종 보고서의 데스크톱은 86점이었다. LCP는 0.766초였지만 TBT가 306ms여서, 폰트 외에 JavaScript 실행 비용도 남아 있었다. 미사용 JavaScript와 렌더링 차단 CSS 역시 다음에 살펴볼 항목이다.

처음 검증에서 놓친 점

가장 큰 누락은 새 폰트 파일이 내려오는 것과 전체 공개 로딩 경로가 가벼워진 것을 같은 결과로 본 데 있었다.

초기 브라우저 시험에서는 언어별 묶음 한 개만 요청하는 것을 관찰했다. 하지만 PageSpeed가 측정한 최적화된 공개 응답에는 기존 폰트를 강제로 미리 받는 태그가 남아 있었다. 일반 CSS 폰트 선택 경로뿐 아니라 최적화기가 최종 HTML에 넣는 힌트까지 확인해야 했다.

또 캐시 HIT와 클라우드 API 200은 성공 범위가 좁다. 분석과 캐시 생성이 정상으로 끝났다는 뜻이지, 그 결과에 중복 요청이 없다는 뜻은 아니다. 브라우저의 전체 폰트 요청과 최종 HTML을 함께 확인했어야 했다.

측정 조건도 충분히 구분하지 못했다. 로컬 제한 회선 시험, 운영 브라우저 초기 로딩, PageSpeed의 모바일 시뮬레이션은 서로 다른 결과다. 폰트 응답이 줄었다는 표를 운영 페이지 전체 성능의 증거처럼 제시하면 실제보다 넓은 결론이 된다.

처음 배포 때 적용·캐시 생성 확인과 성능 개선 확인을 분리해 설명했어야 했다.

54점에서 91점으로 바뀌었다고 말할 수 있는 범위

두 보고서 사이에서 점수와 LCP가 개선된 것은 확인했다. 구형 선로딩을 제거했다는 HTML 증거도 있다. 다만 모든 차이를 이 수정 하나의 효과로 계산하지는 않았다.

비교값은 각 상태의 단일 PageSpeed 보고서다. 광고·분석 스크립트, 서버와 CDN의 캐시 상태, 네트워크와 실행 환경의 변동이 함께 영향을 줄 수 있다. 처음 폰트 최적화를 배포하기 전과 동일 조건으로 측정한 PageSpeed 기준값도 없다. 따라서 “폰트 변경 때문에 정확히 몇 점 떨어졌다”거나 “원래보다 반드시 빨라졌다”고 단정하지 않는다.

이 보고서에서는 실제 사용자 경험 데이터인 CrUX가 ‘데이터 없음’이었다. 91점은 실험실 측정 결과이며, 현장 Core Web Vitals 통과를 확인한 결과가 아니다. Lighthouse의 점수 계산 설명도 함께 참고할 만하다.

광고 소재가 실제로 나타났을 때 본문·목차와 겹치는지 확인하는 작업도 아직 남아 있다. 광고 스크립트가 로딩됐다는 사실로 화면 검증까지 끝냈다고 보지 않았다.

현재 운영에는 중복 선로딩 수정까지 반영했고, 소스와 검증 기록은 메인 브랜치에 병합했다. 다음 성능 작업에서도 새 파일의 크기만 보지 않고, 비로그인 공개 응답의 최종 HTML과 실제 요청 목록을 먼저 확인하려 한다.

참고 자료

• 수정 전 모바일 PageSpeed 보고서: 54점
• 수정 후 모바일 PageSpeed 보고서: 91점
• FlyingPress의 로컬·스테이징 환경 안내
• FlyingPress 클라우드 preload 접근 요건
• 최초 홈 폰트 개선 기록 PR #12 (저장소 접근 권한 필요), 중복 선로딩 수정 PR #14 (저장소 접근 권한 필요)

• 프리텐다드 셀프호스팅 가이드
• 워드프레스·클라우드 가이드 모음

대표 사진: Matthew Fournier / Unsplash · Unsplash License. 개발 작업을 나타내는 참고 사진이며 본문의 실제 측정 화면은 아닙니다.