요즘 웹 사이트에서 텍스트를 즉시 표시하지 않는 이유는 무엇입니까?

최근 많은 웹 사이트에서 텍스트를 표시하는 속도가 느립니다. 일반적으로 배경, 이미지 등이로드되지만 텍스트는로드되지 않습니다. 얼마 후 텍스트가 여기 저기 나타나기 시작합니다 (항상 모든 텍스트가 항상 같은 것은 아님).

기본적으로 텍스트가 먼저 표시 된 다음 이미지와 나머지가로드 될 때와는 반대로 작동합니다. 이 문제를 일으키는 새로운 기술은 무엇입니까? 어떤 생각?

연결 속도가 느리므로 문제가 발생할 수 있습니다.

예제는 아래를 참조하십시오-모든 것이로드되었지만 텍스트가 최종적으로 표시되기까지 몇 초가 더 걸립니다.

한 가지 이유는 오늘날 웹 디자이너가 Google 웹 글꼴 과 같은 웹 글꼴 (일반적으로 WOFF 형식) 을 사용하는 것을 좋아하기 때문입니다 .

이전에는 사이트에 표시 할 수있는 글꼴은 사용자가 로컬로 설치 한 글꼴뿐이었습니다. 예를 들어 Mac과 Windows 사용자가 반드시 같은 글꼴을 가질 필요는 없었기 때문에 설계자는 본능적으로 항상 다음과 같이 규칙을 정의했습니다.

font-family: Arial, Helvetica, sans-serif;

여기서 첫 번째 글꼴이 시스템에서 발견되지 않으면 브라우저는 두 번째 글꼴을 찾은 다음 마지막으로 "sans-serif"글꼴을 찾습니다.

이제 브라우저가 글꼴을 다운로드하도록 글꼴 URL을 CSS 규칙으로 제공 할 수 있습니다.

@import url(http://fonts.googleapis.com/css?family=Droid+Serif:400,700);

다음과 같이 특정 요소의 글꼴을로드하십시오.

font-family: 'Droid Serif',sans-serif;

이것은 사용자 정의 글꼴을 사용할 수있는 인기가 있지만 다운로드 시간, 글꼴 로딩 시간 및 렌더링 시간을 포함하여 브라우저가 리소스를로드 할 때까지 텍스트가 표시되지 않는 문제가 발생합니다. 이것이 당신이 겪고있는 인공물이라고 생각합니다.

예를 들어, 내 국가 신문 중 하나 인 Dagens Nyheter 는 헤드 라인에 웹 글꼴을 사용하지만 리드는 사용하지 않습니다. 따라서 해당 사이트가로드되면 일반적으로 리드가 먼저 표시되고 0.5 초 후에 위의 모든 빈 공간이 채워집니다. 헤드 라인 (최소한 Chrome 및 Opera에서 적용됩니다. 다른 사용자는 시도하지 않았습니다).

(또한, 디자이너는 요즘 어디서나 JavaScript를 뿌릴 수 있으므로 누군가가 텍스트로 영리한 무언가를 시도하고 있기 때문에 지연되는 이유가 있습니다. 사이트에 따라 다르지만 일반적으로 텍스트가 지연되는 경향이 있습니다. 시간은 위에서 설명한 웹 글꼴 문제입니다.)

부가

이 답변은 크게 자세하게 설명되지 않았지만 아마도 이것으로 인해 크게 반박되었습니다 . 질문 스레드에 많은 의견이 있었으므로 조금 확장하려고 시도합니다 (주제가 보호 된 후 많은 의견이 잠시 사라진 것 같습니다-일부 중재자가 수동으로 주석을 청소했을 수도 있음). 또한이 스레드의 다른 답변은 모두 자체 방식으로 확장되므로 읽으십시오.

이 현상은 일반적으로 "스타일이없는 컨텐츠의 플래시"로, 특히 "스타일이없는 텍스트의 플래시"로 알려져 있습니다. "FOUC"및 "FOUT"을 검색하면 자세한 정보가 제공됩니다.

웹 글꼴과 관련하여 FOUT에 관한 웹 디자이너 Paul Irish의 게시물을 추천 할 수 있습니다 .

주목해야 할 것은 다른 브라우저가 이것을 다르게 처리한다는 것입니다. 나는 위에서 비슷하게 행동했던 Opera와 Chrome을 테스트했다고 위에서 썼다. 모든 WebKit 기반 항목 (Chrome, Safari 등) 은 웹 글꼴로드 기간 동안 대체 글꼴로 웹 글꼴 텍스트를 렌더링 하지 않으므로 FOUT을 피하도록 선택합니다 . 경우에도 웹 글꼴 캐시,이 것 렌더 지연 될 . 이 질문 스레드에는 그렇지 않다고 말하는 많은 주석이 있으며 캐시 된 글꼴이 이와 같이 동작하지만 위의 링크와 같이 잘못 작동하는 것은 잘못되었습니다.

어떤 경우에 FOUT을 받게 되나요?

• Will : 원격 ttf / otf / woff 다운로드 및 표시
• Will : 캐시 된 ttf / otf / woff 표시
• Will : data-uri ttf / otf / woff 다운로드 및 표시
• Will : 캐시 된 데이터 표시 uri ttf / otf / woff
• 하지 않습니다 : 기존의 글꼴 스택에 이미 설치되어 이름이 지정된 글꼴 표시
• 안함 : local () 위치를 사용하여 설치되고 이름이 지정된 글꼴 표시

렌더링 전에 FOUT 위험이 사라질 때까지 Chrome이 대기하기 때문에 지연이 발생합니다. 되는 정도 효과를 볼 수 있습니다 (특히 캐시에서로드 할 때) 필요 텍스트의 양이 렌더링 할 다른 것들과 아마 다른 요인들에 의존하는 것 같다,하지만 캐싱은 완전히 효과를 제거하지 않습니다.

아일랜드어는 또한 2011 년 4 월 14 일 ~ 14 일 현재 게시물의 맨 아래에 브라우저 동작과 관련된 일부 업데이트가 있습니다.

• Firefox (FFb11 및 FF4 Final) 는 더 이상 FOUT을 갖지 않습니다! 와우 후! http://bugzil.la/499292 기본적으로 텍스트는 3 초 동안 보이지 않으며 대체 글꼴을 다시 표시합니다. 웹 폰트는 아마도 3 초 안에로드 될 것입니다.
• IE9는 WOFF 및 TTF 및 OTF를 지원합니다 ( 임베디드 비트 세트 가 필요하지만 WOFF를 사용하는 경우 무음). 하나!!! IE9에는 FOUT이 있습니다. :(
• 웹킷에 0.5 초 후에 대체 텍스트를 표시 하기 위해 대기중인 패치 가 있습니다. FF와 같은 동작이지만 3 대신 0.5로 작동합니다.
• 추가 : Blink 에 버그도 등록되어 있지만 WebKit과 동일한 구현에 대해서는 최종 합의에 도달하지 못한 것 같습니다.

이것이 디자이너를위한 질문이라면,와 같은 이런 종류의 문제를 피할 수있는 방법으로 갈 수 webfontloader있지만 또 다른 질문이 될 것입니다. Paul Irish 링크는이 문제에 대해 더 자세히 설명합니다.

그 이유는 아직 읽을 수없는 텍스트 가 브라우저로 파이프를 내려가는 웹 글꼴 로 렌더링되고 있기 때문입니다.

웹킷을 사용하는 브라우저 구글 크롬, 페이지를 렌더링하기 때문에, 그것은 그들에 의해 결정되었다 웹 폰트가 다운로드 될 때까지 모든 텍스트를 볼 수없는 것이 최선의 것을입니다 (웹킷). 그러나 텍스트 대신 적절한 대체 시스템 글꼴로 읽을 수있는 텍스트를 선호하는 개발자 인 경우 Google WebFont Loader 와 같은 것을 사용 하여이를 달성 할 수 있습니다 .

짧은 답변 : AJAX 또는 WOFF

웹 사이트가 "텍스트를 느리게 표시"하는 데는 몇 가지 원인 이 있습니다 . portableapps.com 의 속도 저하 는 WOFF 글꼴 을 다운로드하여 발생합니다 . 그러나 "텍스트가 여기저기서 나타나기 시작합니다"라고 설명 하는 것이 AJAX 에 의해 더 자주 발생합니다 .

웹 사이트는 여러 부분으로 구성되어 있습니다. 이러한 부품을 다운로드하고 조립하는 방법 은 웹 디자이너 의 통제하에 디자인 선택 입니다. 속도 저하는 개발자가 다음 빌딩 블록을 조립하는 방법에 따라 발생합니다.

• 초기 HTML 페이지
• CSS
• JS
• 이미지
• WOFF 폰트
• AJAX 요청
• DOM 조작

전통적으로 웹 사이트 :

전통적으로 개발자는 텍스트 내용을 초기 HTML 페이지에 넣고 가능한 빨리 표시하는 것이 일반적이었습니다 . HTML은 다운로드 할 여러 리소스를 참조합니다. 그런 다음 브라우저는 점차 스타일과 이미지가 포함되도록 화면을 다시 그립니다. AJAX 및 WOFF를 사용할 수 없습니다.

WOFF 웹 사이트 :

WOFF 글꼴을 사용하면 웹 사이트에서 글꼴을 다운로드하여 웹 사이트 에서 브라우저에서 일반적으로 사용할 수없는 글꼴을 사용할 수 있습니다 . 일부 개발자는 모든 WOFF 글꼴을 다운로드 할 때까지 브라우저에 텍스트 내용을 표시하지 않도록 지시합니다. 내 경험상이 접근법은 아직 널리 사용되지 않았습니다.

AJAX 웹 사이트 :

일부 개발자는 텍스트 내용을 초기 HTML 페이지에 포함하지 않기로 선택합니다. 대신 AJAX를 사용하여 텍스트 컨텐츠를 다운로드하도록 선택합니다. 기본 페이지가로드 된 후에 발생합니다 . 필자의 경험에 따르면이 방법은 WOFF 글꼴보다 훨씬 더 광범위하게 채택 되었으며 가장 느리게 설명하는 원인입니다.

원인 결정

특정 사이트의 원인을 파악하려면 Firebug 또는 Chrome 개발자 도구 와 같은 도구를 사용하여 분석해야합니다 . 또는 AJAX는 지원하지만 WOFF는 지원하지 않는 Internet Explorer 8을 사용하여 사이트를 열 수 있습니다 . 사이트가 여전히 느리면 문제는 AJAX이며 WOFF가 아닙니다.

"스타일이 지정되지 않은 콘텐츠의 플래시"를 피하는 것이 종종 고의적 인 선택 일 수 있습니다. CSS가로드되기 전에 표시되는 텍스트가 있으면 텍스트가 그대로 표시되고 잠시 후 브라우저가 다시 그려 질 때 플래시가 표시됩니다. 실제 스타일 시트에서 재정의 된 컨텐트를 처음 숨기거나 JS를 사용하는 기본 인라인 스타일을 사용하면 개발자는이 플래시를 피할 수 있습니다.

다른 사람들이 지적했듯이, 사용자 정의 글꼴은 지연에 기여할 수 있습니다.

조금 더 배경을주기 위해 브라우저는 페이지 내용을 화면에 렌더링하기 전에 대략 다음을 수행합니다.

1. HTML 가져 오기 (DNS, TCP, 요청 / 응답에 대한 여러 번의 왕복)
2. HTML 구문 분석을 시작하고 외부 CSS 및 JS와 같은 외부 리소스를 검색하십시오. CSS는 레이아웃을 차단하고 JS는 구문 분석을 차단합니다. 따라서 문서 (예 : 헤드)에 초기에로드 된 CSS 및 JS와 같은 외부 리소스는 페이지에 화면에 내용을 표시하는 데 걸리는 시간이 느려집니다.
3. 외부 CSS 및 JS 가져 오기 (여러 라운드 트립 : 이러한 리소스가 CDN과 같은 다른 도메인에있는 경우 DNS 및 TCP 및 요청 / 응답에 대한 RTT)
4. 외부 CSS와 JS가 로딩, JS 구문 분석 / 실행, 구문 분석 / 적용 스타일을 완료하면
5. CSS가 사용자 정의 글꼴을 참조하는 경우 해당 글꼴도 다운로드해야하므로 사용자 정의 글꼴에 의존하는 페이지의 모든 부분을 렌더링하기 위해 추가 왕복 지연이 발생합니다.

특히 사용자 정의 글꼴로 인한 지연에 관한 것이 아니지만 최근 렌더링 게시물의 원인에 대한 추가 정보를 제공하는 블로그 게시물을 작성했습니다. 페이지의 페인트 시간을 최소화하기위한 몇 가지 제안을 제공합니다. 사용자 지정 글꼴을 사용하려는 페이지를 포함하여 페이지 내용을 더 빠르게 표시하려는 독자에게 유용 할 수 있기를 바랍니다. http://calendar.perfplanet.com/2012/make-your-mobile-pages-render-in-under -일초/

짧은 대답 : 개발자.

외부 문서 (.css 또는 .js 파일 등)를 참조하는 링크 및 스크립트 태그가 문서의 헤드 (본문 및 해당 요소보다 흐름이 높음)에 배치되면 먼저로드됩니다. JavaScript는이를 참조하는 마크 업에서 실행됩니다. 처리해야 할 코드가 많거나 번거로운 코드이거나, 일반적으로 예상되는 텍스트가 서버에서 렌더링되고로드시 문서에 채워져 있고 서버 측 코드도 번거로운 경우 여러 동시 요청의 처리로 인해 I / O가 크거나 차단되는 경우 HTML이 렌더링되기 전에 다운 타임이 발생할 수 있습니다. 일부 개발자는 마크 업 및 스타일 (본문 끝에서) 후에 비보기 관련 JavaScript를로드하기로 선택합니다.

인터넷 연결 속도는 데이터 다운로드 속도가 느리지 만 명백하게 작성되지는 않았지만 코드 작성이 잘못되었거나 웹 사이트 유형에 적합하지 않은 기술 스택이 네트워크 연결 속도가 빨라짐에 따라 동적 콘텐츠를 느리게로드하는 데 점점 더 중요한 역할을합니다. 편재에 접근하십시오.

간단히 말해서 페이지를 표시하기 전에 별도의 HTTP GET에서로드해야하는로드 가능한 오브젝트가 너무 많으며 사이트 상태를 측정하기 위해 평균 대기 시간에 지나치게 의존합니다.

첫 번째는 페이지가로드하는 모든 .css, .js 및 웹 폰트를 나타내며 많은 사이트에서 XHR 요청에 대한 JSON 객체를 검색 한 다음 일종의 템플릿을 사용하여 HTML을 생성해야한다는 사실은 말할 것도 없습니다.

그러나 왜 그들은 사이트가 느리다는 것을 알지 못합니까?

아마도 어딘가에 memecache가있어 속도를 높이거나 파일 시스템 캐시에 의존하기 때문에 평균 대기 시간을 사용하여 사이트 상태를 측정하고 있기 때문입니다. 따라서 캐시 된 객체는 6 미크로 초의 대기 시간으로 반환되며 많은 GET 요청이 완료하는 데 5000 밀리 초가 걸린다는 사실을 숨 깁니다. 평균은 죽어야한다. 허용 가능한 최대 임계 값을 초과하는 RTT 수를 오래 산다! 이 숫자는 0이거나 정의에 따라 RTT를 사용할 수 없습니다.

여러 가지 이유가 있습니다. 한 가지 이유는 배경을 정의하거나 html 페이지의 상단에 명령을 자주 또는 먼저로드 된 별도의 CSS에서 검색하기 때문입니다. 텍스트가 포함 된 문서 본문이로드되기 전에

또 다른 원인은 대부분의 경우 웹 디자이너가 이미지를 사용하지 않는 경우 이미지 크기를 입력 할 수 있다는 것입니다. 따라서 brouwser는 텍스트를 감싸는 방법을 알 수 있도록 전체 이미지를 페이지에 먼저로드해야합니다.

일부 디자이너는 또한 첫 번째 그림과 다음 텍스트를 보여주기를 원합니다. 예를 들어 간단한 페이지는 먼저 배너를 표시하고 그 다음에 모든 것을 표시합니다.

그러나 뉴스를 읽고 싶은데 왜 내 페이지에 스팸 광고가 많이 있는지 궁금해하는 경우 해결책이 있습니다. 파이어 폭스를 사용하는 경우 스팸 차단기를 사용할 수 있습니다. 이러한 애드온을 통해 webrowser는 스팸을 제공하는 사이트를 알고 단순히 차단하여 훨씬 빠른 페이지로드를 제공하는 동시에 읽은 기사와 관련된 중요한 이미지를 계속 볼 수 있습니다.

나는 fidler를 시도하기 위해 느린 페이지 로딩을 다루는 모든 사람들에게 추천 할 것입니다. fidler는 IEexplorer 또는 FireFox (프록시 기능 사용)와 함께 사용할 수 있습니다. 실제로 Fidler는 실제로 걸리는 시간과 웹 페이지의 일부가로드되는 시간을 보여줍니다. HTML 디버깅 도구입니다.