최신 브라우저의 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그는 클래식과 비차단이라는 두 가지 새로운 유형으로 나뉩니다. 이 두 태그를 사용하여 페이지를 최대한 빨리 로드하는 방법에 대해 논의해 보겠습니다. 1. 차단 스크립트는 어디로 가나요? 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그의 표준 버전을 차단 태그라고도 합니다. 이 용어는 문맥에 맞게 이해해야 합니다. 최신 브라우저에서는 차단하는 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그를 볼 때 차단 지점을 건너뛰고 계속해서 문서를 읽고 다른 리소스(스크립트 및 스타일시트)를 다운로드합니다. 그러나 브라우저는 스크립트가 다운로드되어 실행될 때까지 초크 포인트를 넘어 해당 리소스를 평가하지 않습니다. 따라서 웹 문서의 93f0f5c25f18dab9d176bd4f6de5d30e 태그 내에 5개의 차단 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그가 있는 경우 5개의 스크립트가 모두 다운로드되어 실행될 때까지 사용자에게는 페이지 제목만 표시됩니다. 그뿐만 아니라 이러한 스크립트가 실행되더라도 문서에서 차단 지점 이전 부분만 볼 수 있습니다. 6c04bd5ca3fcae76e30b72ad730ca86d 태그에 로드되기를 기다리는 모든 항목을 보려면 document.onreadystatechange와 같은 이벤트에 이벤트 핸들러를 바인딩해야 합니다. 위 이유에 따라 페이지의 6c04bd5ca3fcae76e30b72ad730ca86d 태그 끝에 스크립트를 배치하는 것이 점점 더 인기를 얻고 있습니다. 이러한 방식으로 사용자는 페이지를 더 빠르게 볼 수 있고, 스크립트는 이벤트가 스스로 트리거될 때까지 기다리지 않고 DOM에 적극적으로 액세스할 수도 있습니다. 대부분의 스크립트에서 이 "이동"은 엄청난 개선입니다. 하지만 모든 스크립트가 동일한 것은 아닙니다. 스크립트를 아래로 이동하기 전에 스스로에게 2가지 질문을 던져보세요. 6c04bd5ca3fcae76e30b72ad730ca86d 태그에서 인라인 JavaScript로 이 스크립트를 직접 호출할 수 있나요? 대답은 분명할 수도 있지만 확인해 볼 가치가 있습니다. 이 스크립트가 렌더링된 페이지의 모양에 영향을 미치나요? Typekit 호스트 글꼴이 한 가지 예입니다. Typekit 스크립트를 문서 끝에 배치하면 페이지 텍스트가 문서를 읽을 때 즉시 렌더링되고, 스크립트가 실행될 때 다시 두 번 렌더링됩니다. 위 질문에 대한 대답 중 하나가 '예'라면 스크립트는 93f0f5c25f18dab9d176bd4f6de5d30e 태그에 있어야 하며, 그렇지 않으면 문서는 다음과 같습니다. 이것은 실제로 로딩 시간을 크게 단축하지만 bodyScripts.js가 로드되기 전에 사용자에게 페이지와 상호 작용할 수 있는 기회를 제공할 수 있다는 점에 유의하세요. " 준비 완료" "이벤트 비용입니다. 그러나 이 접근 방식에는 전체 문서가 로드될 때까지 브라우저가 이러한 스크립트를 로드할 수 없다는 단점도 있습니다. 이는 느린 연결을 통해 전송되는 대용량 문서의 경우 병목 현상이 발생할 수 있습니다. 이상적으로는 문서가 로드되는 동시에 스크립트도 로드되어야 하며 DOM 렌더링에 영향을 주지 않습니다. 이렇게 하면 스크립트가 3f1c4e4b6b16bbbd69b2ee476dc4f83a 태그 순서대로 이미 로드되어 있으므로 문서가 준비되면 스크립트를 실행할 수 있습니다. 여기까지 읽으셨다면 이러한 요구 사항을 충족할 수 있는 사용자 정의 Ajax 스크립트 로더를 작성하고 싶어하실 것입니다! 그러나 대부분의 브라우저는 더 간단한 솔루션을 지원합니다. defer 속성을 추가하는 것은 브라우저에 "지금 이 스크립트 로드를 시작하십시오. 하지만 문서에서 실행하기 전에 문서가 준비되고 defer 속성이 있는 모든 이전 스크립트의 실행이 완료될 때까지 기다리십시오."라고 말하는 것과 같습니다. 93f0f5c25f18dab9d176bd4f6de5d30e 태그에 지연된 스크립트를 배치하면 6c04bd5ca3fcae76e30b72ad730ca86d 태그에 스크립트를 배치하는 것의 모든 이점을 얻을 수 있을 뿐만 아니라 대용량 문서의 로딩 속도도 크게 향상됩니다. 단점은 모든 브라우저가 defer 속성을 지원하지 않는다는 것입니다. 이는 문서가 로드된 후 지연된 스크립트가 실행될 수 있도록 하려면 모든 지연된 스크립트 코드를 jQuery의 $(document).ready와 같은 구조로 캡슐화해야 함을 의미합니다. 이전 섹션의 페이지 예제가 다음과 같이 개선되었습니다. deferredScripts의 캡슐화가 중요하므로 브라우저가 defer를 지원하지 않더라도 deferredScripts는 문서 준비 이벤트가 끝날 때까지 실행되지 않습니다. 페이지의 주요 콘텐츠가 몇 킬로바이트보다 훨씬 크다면 그만한 가치가 있습니다. 3. 스크립트 병렬 로딩 페이지 로딩 시간을 밀리초 단위까지 신경쓰는 완벽주의자라면 지연은 맛없는 간장과 같을 수 있습니다. 이전의 모든 연기 스크립트 실행이 완료될 때까지 기다리고 싶지 않으며 이러한 스크립트를 실행하기 전에 문서가 준비될 때까지 기다리고 싶지도 않을 것입니다. 가능한 한 빨리 이러한 스크립트를 로드하고 실행하기만 하면 됩니다. 이것이 최신 브라우저가 비동기 속성을 제공하는 이유입니다. 如果说defer 让我们想到一种静静等待文档加载的有序排队场景，那么async 就会让我们想到混乱的无政府状态。前面给出的那两个脚本会以任意次序运行，而且只要JavaScript 引擎可用就会立即运行，而不论文档就绪与否。对大多数脚本来说，async 是一块难以下咽的鸡肋。async 不像defer那样得到广泛的支持。同时，由于异步脚本会在任意时刻运行，它实在太容易引起海森堡蚁虫之灾了（脚本刚好结束加载时就会蚁虫四起）。当我们加载一些第三方脚本，而且也不在乎它们谁先运行谁后运行。因此，对这些第三方脚本使用async 属性，相当于一分钱没花就提升了它们的运行速度。上一个页面示例再添加两个独立的第三方小部件，得到的结果如下： 这个页面结构清晰展示了脚本的优先次序。对于绝大多数浏览器，DOM的渲染只会延迟至headScripts.js 结束运行时。进行DOM渲染的同时会在后台加载deferredScripts.js。接着，在DOM 渲染结束时将运行deferredScripts.js 和那两个小部件脚本。这两个小部件脚本在那些支持async 的浏览器中会做无序运行。如果不确定这是否妥当，请勿使用async！
