1. 문제점
•
시스템 폰트를 사용할 경우 최대한 빨리 렌더 되는게 보장될 수 있으나 운영체제가 다를 경우 디자인의 일관성을 해칠 수 있다.
웹폰트
•
일관적인 디자인을 보장받을 수 있고, 간단한 방법 이지만 최적화 관련 이슈가 발생한다.
•
추가적인 네트워크 요청이 발생하므로 CLS가 발생. → self-hosting fonts로 해결 가능
<link href="https://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;500;700&display=swap" rel="stylesheet" />
Bash
복사
•
display=swap 옵션이 추가되면 폰트가 설치 된 직후 브라우저를 재 렌더링 한다. → 폰트가 다시 적용되는 과정에 대한 명령
•
display=block이 존재할 경우 폰트를 다운로드 하기 전 까지 텍스트를 보여주지 않는다.
웹폰트 vs self hosting font
좌 웹폰트 사용 우 next.js폰트 사용
•
폰트를 가져오는 주체가 google에서 직접 가져오는지, 자체 서버에서 직접 가져오는지에 대한 차이가 존재한다.
•
google에서 직접 가져올 경우 stylesheets를 가져오며 자체 서버에서는 font(woff 파일)를 직접 가져올 수 있다.
•
CSS 파일에 존재할 경우 CSS 파일을 전부 다운로드 + 파싱까지 마친 후 폰트를 불러오기 때문에 폰트 다운로드가 더욱더 느려진다.
next.js 13의 폰트 시스템
self-host 폰트 결과
•
폰트 최적화 과정을 간단하게 바꿔줌 → 간단하다는 뜻은 추상화 되어있다는 뜻. 실제로 돌아가는 로직을 알기 힘들다.
•
자동으로 모든 종류의 구글 폰트를 self-host 형태로 배포시켜준다.
•
외부 요청을 보내지 않으므로 최초 로드 시간을 최대한 빠르게 만들 수 있다. → 구글로 이용자 개인정보를 보내지 않는 효과까지 존재.
rel=”preload”
•
해당 리소스가 페이지에서 바로 사용될 리소스라는걸 선언해주는 attribute → 결과적으로 높은 우선순위로 다운로드 하겠다 라는 뜻
•
일반적으로 모든 리소스에 preload attribute를 줄 경우 preload attribute의 이유가 희석된다. 꼭 필요한 파일들만 해당 attribute를 추가해줘야 한다.
•
page lifecycle 초기에 로딩을 시작한다.
•
퍼포먼스 개선 → pre”load”라는 이름을 가지고는 있지만스크립트를 로드하거나 실행하는게 아닌 더 높은 순위로 다운로드하고 캐시한다는 뜻
2. Critical Rendering Path(CRP)
웹 브라우저가 HTML, CSS,JS 코드를 유저의 화면에 그리기 위한 단계의 순서
•
여러가지 프로세스를 가지고 있다. e.g.) DOM 생성, CSSOM 생성, 두개의 Object Model 생성 후 렌더트리 생성 → Layout 만들고 Paint 까지
•
브라우저가 방문자의 화면에 표현하기위해 HTML, CSS, JS파일을 다운 받는 순서
Light House에서 확인할 수 있는 Avoid chaining critical requests 항목
3. Google fonts는 stylesheet다
<link href="https://fonts.googleapis.com/css?family=Muli:400" rel="stylesheet"/>
HTML
복사
•
구글 웹폰트를 사용할 경우 font 파일을 직접 받아오는게 아닌 stylesheet를 받아오는 것 이다.
@import url("https://fonts.googleapis.com/css?family=Open+Sans:400,700");
CSS
복사
•
이와 같은 방법은 오히려 사이트 로딩 속도를 늦춘다 → Critical Request Depth가 증가하므로
2. 구글 CDN보다 self-hosting이 더 빠른 이유
•
웹사이트에서 이미 HTTP/2가 활성화 되어있는 경우(좋은 호스팅/CDN이 구축 되어있다는 가정이 필요하다) self-hosting이 Google CDN을 outperform한다. → DNS lookups, SSL Handshake 할 필요없이 이미 존재하는 HTTP/2 연결을 재사용하기 때문이다.
Cache Partitioning
•
Cache Partitioning(double key caching)은 사이트 A에 존재하는 캐싱은 사이트 B에서 사용할 수 없다, 즉 A 사이트에서 z파일을 이미 받았고 캐시가 남아있다 하더라도 B 사이트에서는 캐시에 남아있는 z를 참조할 수 없는것. 완벽히 나뉘어져 있다.