programing tip

웹 폰트 또는 로컬로로드 된 글꼴?

itbloger 2020. 8. 31. 07:31

웹 폰트 또는 로컬로로드 된 글꼴?

Cufon 을 사용하여 문제가 발생한 이후로 외부 글꼴 리소스 를 사용하지 않으려 고 노력했지만 최근에는 글꼴을로드하는 다른 방법을 찾고 더 나은 방법이 있는지 확인했습니다. 더 나은 방법은 갑자기 나타나는 방법이 있습니다.

많은 새로운 방법이 있으며 각 방법에 대한 변형이 있습니다. typekit을 사용해야 합니까 ? 또는 Google 웹 폰트 (js 또는 css 포함)? 로컬 로딩 글꼴 (예 : fontsquirrel.com 생성 방법)을 계속 사용해야합니까?

몇 가지 테스트를 통해 가장 잘 받아 들여진 방법을 아래에 나열하겠습니다.하지만 웹 폰트로 이동할 가치가 정말 있습니까? 더 높은 리소스로드 (http 요청)를 수행하고 파일 형식 유형 (호환성이 적음) 등이 적은 것처럼 보이지만 대부분의 경우 파일이 비동기식으로로드되고 효율적으로로드되는 것처럼 보입니다.

상황과 필요의 문제입니까? 그렇다면 그들은 무엇입니까?
이 방법들 사이에 큰 차이가 있습니까?
내가 나열하지 않은 더 나은 방법이 있습니까?
성능에 대한 장단점은 무엇입니까? 보기? 의존성? 호환성?

저는 여기서 모범 사례를 찾고 있습니다. 성능은 중요하지만 확장 성과 사용 편의성도 중요합니다. 외모와 느낌은 말할 것도 없습니다.

구글 CSS

외부 스타일 시트 만 사용
가장 작은 호환 파일 유형 만 사용
스타일 쉬 ( ) 의 내용을 사용 @import하거나 <link>가져 와서 @font-face자신의 스타일 시트에 직접 넣을 수 있습니다.

시험 결과

  78ms load of html
  36ms load of css

여기에 이미지 설명 입력

Google JS 방법

webfont.js스타일을로드 하는 데 사용
가장 작은 호환 파일 유형 만 사용
:root클래스 에 요소를 추가합니다.
헤드에 스크립트를 추가합니다.

시험 결과

    171ms load of html
    176ms load of js
    32ms load of css

여기에 이미지 설명 입력

Typekit 방법

:root클래스 에 요소를 추가합니다 .
*.js스 니펫 또는 외부에서로드 된 파일 *.js파일을 사용할 수 있습니다.
data:font/opentype글꼴 파일 대신 사용 합니다.
머리에 스크립트 추가
포함 된 CSS를 헤드에 추가
헤드에 외부 스타일 시트 추가

typekit.com에서 글꼴 및 대상 선택기를 쉽게 추가 / 제거 / 조정할 수 있습니다.

시험 결과

  169ms load of html
  213ms load of js
  31ms load of css
  3ms load of data:font/

여기에 이미지 설명 입력

… & 글꼴 다람쥐 방법

@font-face{
    font-weight:400;
    font-style:normal;
    font-family:open_sanslight;
    src:url(../font/opensans-light-webfont.eot);
    src:url(../font/opensans-light-webfont.eot?#iefix) format(embedded-opentype),
        url(../font/opensans-light-webfont.woff) format(woff),
        url(../font/opensans-light-webfont.ttf) format(truetype),
        url(../font/opensans-light-webfont.svg#open_sanslight) format(svg)
}

… 또는 data : font 방법으로…

@font-face {
    font-family: 'open_sanslight';
    src: url('opensans-light-webfont-f.eot');
}

@font-face {
    font-family: 'open_sanslight';
    src: url(data:application/x-font-woff;charset=utf-8;base64,d09GRgABAAAAAF4sABMAAAAArXQAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAABGRlRNAAABqAAAABwAAAAcZLn0KkqwK44Jq866WBSpzpsNY2IyGAhoJFBbYjuxmyns5sNa4NwldcJ7eh3Uy5gQkURIlqWzONe3HcLsDX1x/+jifDXvbzgTBjopZElndil3hJkERJkmRJkVRJk3TJkEzJkmzOc4HLXOEOF7nEX/*thisisnotafullencodingjustanexample*/bZwUnK4yS3JlTx2Sr4USKEUSbHVX9fcGNBs4fqgw+GoNHU7lKr36Eqn0lCWt6pHFpWaUlc6lS6loSxRlirLlP/uuU01dVfT7L6gPxyqraluCpgj3WtqeC1V4VBDW2N4K1r1esw/IupKp9L1FwlqnuIAAAB42j3NvQ7BUBjG8R5tTz/0u2UjNTTESYQbMGmXLiISbeI6zBYjbuWtye7CeMJxtuf3LP8ne1+IXbWa7G3TMXZru4qLZkJRW1O2wzi3I+Li2Gik5yXpYkNGXj70YU98YQLGHxwwXxIWwO8SNmAdJBzAXku4gFNI9AF38QMjTwZ9vN6yJzq9OoEB6I8VQzDYK0ZguFKMwWiumIDxTDEFk6liBqaF4gDMFFvKxAfOxFUGAAABUxSL9gAA) format('woff'),
         url('opensans-light-webfont-f.ttf') format('truetype'),
         url('opensans-light-webfont-f.svg#open_sanslight') format('svg');
    font-weight: normal;
    font-style: normal;

}

먼저 Google의 서비스에 대해 설명하겠습니다. 실제로 브라우저에서 처리 할 수있는 가장 작은 형식을로드합니다. WOFF는 작은 파일 크기를 제공하며 브라우저가이를 지원하므로 바로 볼 수 있습니다. WOFF도 상당히 광범위하게 지원됩니다. 그러나 예를 들어 Opera에서는 TrueType 버전의 글꼴을 얻을 수 있습니다.

파일 크기 논리는 Font Squirrel이 그 순서대로 시도하는 이유이기도합니다. 그러나 그것은 대부분 내 입장에서 추측입니다.

모든 요청과 바이트가 중요한 환경에서 작업하는 경우 사용 사례에 가장 적합한 것을 찾기 위해 몇 가지 프로파일 링을 수행해야합니다. 사람들이 한 페이지 만보고 다시는 방문하지 않을까요? 그렇다면 캐싱 규칙은 그다지 중요하지 않습니다. 그들이 탐색하거나 돌아 오는 경우 Google은 서버보다 더 나은 캐싱 규칙을 가질 수 있습니다. 대기 시간이 더 큰 문제입니까, 아니면 대역폭입니까? 지연이 발생하는 경우 요청 수를 줄이는 것을 목표로하므로 로컬에서 호스팅하고 가능한 한 파일을 결합하십시오. 대역폭의 경우 가장 작은 코드와 가장 작은 글꼴 형식으로 끝나는 옵션을 선택하십시오.

이제 CSS 대 JS 고려 사항에 대해 살펴 보겠습니다. 다음 HTML 부분을 살펴 보겠습니다.

<head>
    <script type="text/javascript" src="script1.js"></script>
    <link rel="stylesheet" type="text/css" href="style1.css" />
    <style type="text/css">
        @import url(style2.css);
    </style>
    <script type="text/javascript">
        (function() {
            var wf = document.createElement('script');
            wf.src = 'script2.js';
            wf.type = 'text/javascript';
            wf.async = 'true';
            var s = document.getElementsByTagName('script')[0];
            s.parentNode.insertBefore(wf, s);
        })();
    </script>
</head>

많은 경우에 script1, style1및 style2차단 될 것입니다. 이는 해당 리소스가로드 될 때까지 브라우저가 문서를 계속 표시 할 수 없음을 의미합니다 (최신 브라우저에서는이 문제를 조금 더럽 힙니다). 특히 스타일 시트에서는 실제로 좋은 일이 될 수 있습니다. 스타일이 지정되지 않은 콘텐츠의 플래시를 방지하고 스타일을 적용 할 때 발생하는 큰 변화도 방지합니다 (콘텐츠 이동은 사용자에게 정말 짜증이납니다).

다른 한편으로 script2는 차단하지 않을 것입니다. 나중에로드 할 수 있으며 브라우저는 문서의 나머지 부분을 구문 분석하고 표시 할 수 있습니다. 그래서 그것도 유익 할 수 있습니다.

특히 글꼴에 대해 이야기하고 (더욱 구체적으로 Google에서 제공하는) CSS 방법을 고수 할 것입니다 ( @import스타일 시트로 스타일을 계속 유지하기 때문에 좋아 하지만 나뿐 일 수도 있음). 스크립트 ( http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js )에 의해로드 된 JS 파일 은 @font-face선언 보다 크고 훨씬 더 많은 작업처럼 보입니다 . 그리고 실제 글꼴 자체 (WOFF 또는 TTF)를로드하는 것이 차단되고 있다고 생각하지 않으므로 너무 지연되어서는 안됩니다. 저는 개인적으로 CDN의 열렬한 팬은 아니지만 사실 그들은 정말 빠릅니다. Google의 서버는 대부분의 공유 호스팅 계획을 압도적으로 능가 할 것이며, 글꼴이 매우 유명하기 때문에 사람들은 이미 캐시에 저장했을 수도 있습니다.

그게 제가 가진 전부입니다.

Typekit에 대한 경험이 없어서 이론에서 제외했습니다. 인수를 위해 브라우저 간 일반화를 계산하지 않고 부정확 한 부분이 있으면 지적 해주세요.

귀하의 질문에서로드 시간을 매우 잘 처리했다고 생각합니다. 내 관점에서 목록에 추가해야 할 몇 가지 소스와 옵션을 전체적으로보기 위해 검토해야 할 몇 가지 다른 고려 사항이 있습니다.

다른 평판 좋은 글꼴 소스

cloud.typography

http://www.typography.com/cloud/

내가 알 수 있듯이 글꼴은 CSS 파일에 데이터로 포함됩니다.

@font-face{ 
    font-family: "Font Name"; 
    src: url(data:application/x-font-woff;base64,d09GRk9UVE8AACSCAA0AAAAARKwAAQAAAAAiVAAAAi4AAAadAAAAAAAAAABDRkYgAAAIyAAAFCgAABmIK5m+CkdERUYAABzwAAAAHQAAACAAXQAER1BPUwAAHRAAAAQlAAAYAq+OkMNHU1VC ... ); 
    font-weight:400; font-style:normal; 
}

내 사양은 다음과 같습니다.

94ms load of css from their server
37ms load of css from our server (will vary based on your configuration)
195ms load of data:fonts from our server (will vary based on your configuration)

다음은 배포에 대한 매우 높은 수준의 설명입니다 .

Fonts.com

나는이 서비스를 사용 해본 적이 없지만 그들은 매우 확고한 글꼴 공급 업체이고 그들이 그들의 사이트에 나열한 정보는 매우 인상적입니다. 정확한 방법에 대한 사양은 없지만 다음과 같이 알고 있습니다.

사용 가능한 세계에서 가장 잘 알려진 글꼴 중 일부
정말 큰 글꼴 라이브러리 (20,000 개 이상)
모형 제작을위한 데스크탑 글꼴 다운로드
브라우저에서 웹 글꼴을 테스트하기위한 사용자 지정 도구
정밀한 타이포그래피 컨트롤 및 부분 설정
자체 호스팅 옵션

FontSpring

FontSquirrel과 제휴. 여기에서 고정 가격으로 글꼴을 구입할 수 있습니다. CSS와 함께 제공되는 글꼴 파일은 FontSquirrel과 같이 자체 서버에 배포되도록 제공됩니다.

확장 된 사양

각 글꼴 서비스의 전반적인 장단점은 다음과 같습니다.

글꼴 라이브러리 크기

Fonts.com : 20,000+
FontSpring : 1000+
FontSquirrel : 300+
Google : 600+
타입 킷 : 900+
Typography.com (cloud.typography.com) : 300 개 이상 (35 개 제품군)

가격

Fonts.com : 500,000 페이지 뷰에 $ 20 / 월
FontSpring : 글꼴에 따라 다름 (글꼴 1 회 구매)
FontSquirrel : 무료
Google : 무료
Typekit : 500,000 페이지 뷰에 대해 월 $ 4
Typography.com : 1,000,000 페이지 뷰에 월 $ 12.50

글꼴 품질

웹 글꼴의 품질은 상당히 다를 수 있습니다. 여기에는 문자 양식 자체 나 문자 집합의 간격 또는 크기와 같은 항목이 포함될 수 있습니다. 이 모든 것이 글꼴이 제공 할 전반적인 품질의 인상을 결정합니다. 무료 옵션에는 좋은 옵션이 있지만 품질이 좋지 않은 글꼴도 있으므로 해당 소스에서 신중하게 선택해야합니다.

Fonts.com : 높음
FontSpring : 혼합에서 높음
FontSquirrel : 혼합
Google : 혼합
Typekit : 높음
Typography.com : 매우 높음 (Fonts.com, FontSpring 및 Typekit이 여러 유형 파운드리를 지원하기 때문에 "매우 높음"으로 지정합니다. 여기에서는 H & FJ 파운드리의 글꼴 만 세계 최고 수준입니다)

글꼴 품질 II : 타이포그래피

웹 글꼴에서 얻기가 정말 어려웠던 데스크탑 타이포그래피에는 많은 개선이 있습니다. 이러한 서비스 중 일부는 이러한 서비스를 제공하는 방법을 제공합니다.

Fonts.com : 커닝, 글자 간격, 합자, 대체 문자, 분수 등
FontSpring : 없음
FontSquirrel : 없음
Google : 없음
Typekit : 없음
Typography.com : 작은 대문자, 합자, 대체 문자, 대체 숫자 스타일, 분수 등

브라우저 지원

이것은 대부분 각 서비스에서 지원하는 글꼴 형식으로 귀결됩니다. 주요 내용은 다음과 같습니다.

EOT : Internet Explorer (IE 4+) 용
TrueType 및 OpenType : 기존 형식 (Safari 3.1+, FF 3.5+, Opera 10+)
WOFF : 웹 글꼴의 새로운 표준 (FF 3.6+, Chrome 5+)
SVG : IOS <4.2

@ Font-Face 규칙 및 유용한 웹 글꼴 트릭 에서 자세한 정보

이러한 모든 서비스는 주요 글꼴 형식을 지원합니다. 자체 호스팅 글꼴의 경우 올바른 구문을 사용하는 한 다루어야합니다. 다음은 FontSpring 의 방탄 구문에 대한 2011 업데이트입니다 .

@font-face {
  font-family: 'MyWebFont';
  src: url('webfont.eot'); /* IE9 Compat Modes */
  src: url('webfont.eot?#iefix') format('embedded-opentype'), /* IE6-IE8 */
       url('webfont.woff') format('woff'), /* Modern Browsers */
       url('webfont.ttf')  format('truetype'), /* Safari, Android, iOS */
       url('webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
  }

성능 I : 다운로드

내가 이해하는 한 위의 구문을 사용하면 브라우저가 자신에게 맞는 특정 형식을 잡을 수 있으므로 작동하지 않는 글꼴 형식에 대한 다운로드 낭비가 없습니다.

Fonts.com, Typekit 또는 Typography.com과 같은 유료 서비스는 방법을 사용하여 올바른 형식을 감지 한 다음 올바른 글꼴 형식 (종종 CSS 파일의 base64 데이터)을 제공합니다.

내가 볼 수 있듯이 위에 나열된 방법의 차이점은 고속 인터넷 사용자에게는 상당히 무시할 수 있지만 (<200ms 차이처럼 보임) 느린 네트워크의 장치, 특히 캐시되지 않은 페이지 히트의 경우 고려할 가치가 있습니다.

성능 II : 부분 집합 화

사용하려는 특정 문자 만 있다는 것을 알고있는 경우 일부 문자로 글꼴을 빌드하여 다운로드 크기를 줄일 수 있습니다.

Fonts.com : 매우 상세한 제어
FontSpring : FontSquirrel 웹 폰트 생성기 를 통해 서브 세트로 재 컴파일 가능
FontSquirrel : 웹 폰트 생성기 를 통해 서브 세트로 재 컴파일 가능
Google : 매우 세부적인 제어
Typekit : "모든 문자"또는 "기본값"의 제한된 옵션
Typography.com : 매우 상세한 제어

성능 III : 배송

Fonts.com : 글로벌 CDN 또는 자체 서버
FontSpring : 서버 기반
FontSquirrel : 서버 기반
Google : 글로벌 슈퍼 CDN
Typekit : 글로벌 CDN
Typography.com : 글로벌 CDN (125,000 개 서버)

언어 지원

Fonts.com : 아시아 및 중동을 포함한 40 개 언어
FontSpring : 서체, 글꼴에 따라 다름
FontSquirrel : 글꼴에 따라 서양
Google : 서체, 글꼴에 따라 다름
Typekit : 서체, 글꼴에 따라 다름
Typography.com : 서체, 글꼴에 따라 다름

테스트 및 구현

Fonts.com : 광범위하고 사용자 정의 가능한 도구로 매우 쉽습니다.
FontSpring : 기술 (직접 수행)
FontSquirrel : 기술 (직접 수행)
Google : 쉬움
Typekit : 쉬움
Typography.com : 쉬운 테스트, 배포 후 변경에 조금 더 관여

글쎄, 당신이 이후에

... 여기서 모범 사례를 찾으면 성능이 중요하지만 확장 성과 사용 편의성도 중요합니다. 외모와 느낌은 말할 것도 없습니다.

대답은 (웹 디자인에서 항상 그렇듯이) : 상황 에 따라 다릅니다!

한 가지 확실한 것은 JS 접근 방식을 사용하지 않는 것이 좋습니다 (두 번째 예제에 표시됨).

Personally I dislike making presentational things and CSS styles depending on Javascript, even though the vast majority of users have it enabled. It is a question of not mixing things up.

And as you can see in your given example there is some kind of FOUC (flas of unstyled content), because the page is already rendered by the browser before the font is available. As soon as it is, the page is redrawn. And the larger the site the larger the (performance) impact!

So I would never ever use any JS solution for fonts embedding.

Now let's have a look at the pure CSS methods.
Since quite a while here is a discussion about " vs. @import". Personally I prefer to avoid the use of @import and always use <link> only. But this is mainly a question of personal preferences. The one thing you should never do indeed is to mix them both!

Local vs. CDN
When deciding if to host your font files locally or use a CDN, then imho it mostly depends on the number of different fonts and the respective fonts you want to embed.

Why is this important, or plays a role?
From the performance point of view, I would recommend to include the font Base64 encoded in your (one) style sheet. But only the .woff format, as this is used by nearly all modern browsers, which means for the majority of your visitors. For all other users live with the additional request.

But due to the "overhead" caused by Base64 encoding and the size of a font file (even in .woff format) this technique should only be used, if you have not more than 3 or 4 different fonts. And always make sure, that your server delivers the (CSS) files gzip'ed.

The big advantage of doing so is that you don't have an additional request for the font file. And after the first page load (no matter which page of your site) the CSS file is cached. This is also an advantage if you use the HTML5 application cache (which you certainly will do).

Beside the fact, that an author shouldn't use more than a maximum of 3 or 4 different fonts on his site, let's have a look at the method of using Google's CDN.

First of all be aware, that you can (and always should) include all desired fonts into one single <link>, like so:

<link href='http://fonts.googleapis.com/css?family=PT+Serif:400,700,400italic,700italic|PT+Sans:400,700,400italic,700italic|Montez' rel='stylesheet' type='text/css'>

This will result in the following response:

@font-face {
  font-family: 'Montez';
  font-style: normal;
  font-weight: 400;
  src: local('Montez'), local('Montez-Regular'), url(http://themes.googleusercontent.com/static/fonts/montez/v4/Zfcl-OLECD6-4EcdWMp-Tw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 400;
  src: local('PT Sans'), local('PTSans-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/LKf8nhXsWg5ybwEGXk8UBQ.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: normal;
  font-weight: 700;
  src: local('PT Sans Bold'), local('PTSans-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/0XxGQsSc1g4rdRdjJKZrNBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 400;
  src: local('PT Sans Italic'), local('PTSans-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/PIPMHY90P7jtyjpXuZ2cLD8E0i7KZn-EPnyo3HZu7kw.woff) format('woff');
}
@font-face {
  font-family: 'PT Sans';
  font-style: italic;
  font-weight: 700;
  src: local('PT Sans Bold Italic'), local('PTSans-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptsans/v6/lILlYDvubYemzYzN7GbLkHhCUOGz7vYGh680lGh-uXM.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 400;
  src: local('PT Serif'), local('PTSerif-Regular'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/sDRi4fY9bOiJUbgq53yZCfesZW2xOQ-xsNqO47m55DA.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: normal;
  font-weight: 700;
  src: local('PT Serif Bold'), local('PTSerif-Bold'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/QABk9IxT-LFTJ_dQzv7xpIbN6UDyHWBl620a-IRfuBk.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 400;
  src: local('PT Serif Italic'), local('PTSerif-Italic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/03aPdn7fFF3H6ngCgAlQzBsxEYwM7FgeyaSgU71cLG0.woff) format('woff');
}
@font-face {
  font-family: 'PT Serif';
  font-style: italic;
  font-weight: 700;
  src: local('PT Serif Bold Italic'), local('PTSerif-BoldItalic'), url(http://themes.googleusercontent.com/static/fonts/ptserif/v6/Foydq9xJp--nfYIx2TBz9QFhaRv2pGgT5Kf0An0s4MM.woff) format('woff');
}

As you can see, there are 9 different font files, which means a total of 10 (including the one of the link element) requests, if the user does not have one or more of the requested fonts installed locally. And these requests are repeated at every single new page request to your site (although no more data is transferred)! Also the response to the request of the <link> is never be cached.

Recommendation:
After all I really would recommend to include your font file(s) in .woff format Base64 encoded in your style sheet!

See this nice article for an example and description of how to do it!

I use the inline css method because the overhead of the extra request is more than the size increase when bease64 encoding. This is also further offset by gizip compression by the server of the css files.

Other option is to use asynchronous loading of fonts but most often users will see the fonts popping in after load.

Regardless of the method, you can reduce the size of the font file by only including the character sets you will use.

Personally I use Google Fonts. They have a nice variety of choices and they have recently improved compression on the fonts by moving to Zopfli compression too. Google is striving to make the web faster, so I guess more optimization on that part is going to come from them as well.

Whatever you choose as an outsourced font delivery, you will always get reductions in speed by the requests for getting the fonts. The best thing, viewed from a speed perspective, would be to serve the fonts yourself. If you do not care for those extra milliseconds it takes to load from an outsourced delivery, you should go with that if you think the ease of using them is worth the milliseconds.

I do not know about Typekit and the others, but with Google Fonts you can choose to be served specific subsets and range of characters to speed up the delivery even more.

Choosing a subset:

<link href="http://fonts.googleapis.com/css?family=Open+Sans&subset=latin" rel="stylesheet">

Choosing a range of characters:

<!-- Only serve H,W,e,l,o,r and d -->
<link href="http://fonts.googleapis.com/css?family=Open+Sans&text=HelloWorld" rel="stylesheet">

You can use dns-prefetch to improve speeds even further with font delivery.

저는 Google이 가능한 한 글꼴 전달 속도를 높이기 위해 최선을 다할 것이라고 생각하고 희망합니다. 로드하는 데 걸리는 밀리 초는 내 웹 사이트를 해치지 않으므로 즐겁게 사용합니다.

짧은 이야기 :

예를 들어 권장되는 1 초 이상로드하도록 만드는 등의 밀리 초 글꼴 전달로 인해 사이트가 손상되는 경우 직접 호스팅해야한다고 생각합니다.

가장 좋은 옵션은 다음과 같이 ajax를 사용하여 글꼴을 가져 오는 것입니다.

<script>
    (function() {
        var font = document.createElement('link'); 
        font.type = 'text/css'; 
        font.rel = 'stylesheet';
        font.href = '/url/to/font.css';
        var s = document.getElementsByTagName('link')[0]; 
        s.parentNode.insertBefore(font, s);
      })();
</script>

내 웹 페이지에서이 작업을 수행하고 Google Insights 테스트에서 9 점을 올립니다.

참고 URL : https://stackoverflow.com/questions/22116682/webfonts-or-locally-loaded-fonts

'programing tip' 카테고리의 다른 글

Android 7 네이티브 크래시 : libc.so tgkill (0)	2020.08.31
REST API가 정말 RPC입니까? (0)	2020.08.31
Android에서 MediaPlayer와 VideoView의 차이점은 무엇입니까? (0)	2020.08.31
grid.arrange를 사용하여 임의의 수의 ggplot을 정렬하려면 어떻게해야합니까? (0)	2020.08.31
내 Android 앱을 어떻게 프로파일 링 할 수 있습니까? (0)	2020.08.31

현재글웹 폰트 또는 로컬로로드 된 글꼴?

itbloger

웹 폰트 또는 로컬로로드 된 글꼴?

웹 폰트 또는 로컬로로드 된 글꼴?

구글 CSS

Google JS 방법

Typekit 방법

… & 글꼴 다람쥐 방법

다른 평판 좋은 글꼴 소스

cloud.typography

Fonts.com

FontSpring

확장 된 사양

글꼴 라이브러리 크기

가격

글꼴 품질

글꼴 품질 II : 타이포그래피

브라우저 지원

성능 I : 다운로드

성능 II : 부분 집합 화

성능 III : 배송

언어 지원

테스트 및 구현

'programing tip' 카테고리의 다른 글

'programing tip'의 다른글

티스토리툴바

웹 폰트 또는 로컬로로드 된 글꼴?

웹 폰트 또는 로컬로로드 된 글꼴?

구글 CSS

Google JS 방법

Typekit 방법

… & 글꼴 다람쥐 방법

다른 평판 좋은 글꼴 소스

cloud.typography

Fonts.com

FontSpring

확장 된 사양

글꼴 라이브러리 크기

가격

글꼴 품질

글꼴 품질 II : 타이포그래피

브라우저 지원

성능 I : 다운로드

성능 II : 부분 집합 화

성능 III : 배송

언어 지원

테스트 및 구현

'programing tip' 카테고리의 다른 글

'programing tip'의 다른글

관련글

티스토리툴바