CSS는 항상 JavaScript보다 앞서야 합니까?
온라인에서 JavaScript 전에 CSS를 포함하라는 권고를 많이 봐왔습니다.그 이유는 일반적으로 다음과 같습니다.
CSS와 JavaScript를 주문할 때는 CSS를 우선시해야 합니다.그 이유는 렌더링 스레드에 페이지를 렌더링하는 데 필요한 모든 스타일 정보가 있기 때문입니다.JavaScript include가 우선인 경우 JavaScript 엔진은 다음 리소스 세트로 진행하기 전에 모두 해석해야 합니다.이는 렌더링 스레드에 필요한 스타일이 모두 없기 때문에 페이지를 완전히 표시할 수 없음을 의미합니다.
실제 테스트 결과와는 전혀 다른 점이 발견되었습니다.
내 테스트 하니스
다음 Ruby 스크립트를 사용하여 다양한 리소스에 대한 특정 지연을 생성합니다.
require 'rubygems'
require 'eventmachine'
require 'evma_httpserver'
require 'date'
class Handler < EventMachine::Connection
include EventMachine::HttpServer
def process_http_request
resp = EventMachine::DelegatedHttpResponse.new( self )
return unless @http_query_string
path = @http_path_info
array = @http_query_string.split("&").map{|s| s.split("=")}.flatten
parsed = Hash[*array]
delay = parsed["delay"].to_i / 1000.0
jsdelay = parsed["jsdelay"].to_i
delay = 5 if (delay > 5)
jsdelay = 5000 if (jsdelay > 5000)
delay = 0 if (delay < 0)
jsdelay = 0 if (jsdelay < 0)
# Block which fulfills the request
operation = proc do
sleep delay
if path.match(/.js$/)
resp.status = 200
resp.headers["Content-Type"] = "text/javascript"
resp.content = "(function(){
var start = new Date();
while(new Date() - start < #{jsdelay}){}
})();"
end
if path.match(/.css$/)
resp.status = 200
resp.headers["Content-Type"] = "text/css"
resp.content = "body {font-size: 50px;}"
end
end
# Callback block to execute once the request is fulfilled
callback = proc do |res|
resp.send_response
end
# Let the thread pool (20 Ruby threads) handle request
EM.defer(operation, callback)
end
end
EventMachine::run {
EventMachine::start_server("0.0.0.0", 8081, Handler)
puts "Listening..."
}
위의 미니 서버를 사용하면 JavaScript 파일(서버와 클라이언트 모두)의 임의의 지연과 임의의 CSS 지연을 설정할 수 있습니다.를 들어, 「」라고 하는 것은,http://10.0.0.50:8081/test.css?delay=500CSS 전밀500 밀 c c c c밀밀
다음 페이지를 사용하여 테스트합니다.
<!DOCTYPE html>
<html>
<head>
<title>test</title>
<script type='text/javascript'>
var startTime = new Date();
</script>
<link href="http://10.0.0.50:8081/test.css?delay=500" type="text/css" rel="stylesheet">
<script type="text/javascript" src="http://10.0.0.50:8081/test2.js?delay=400&jsdelay=1000"></script>
</head>
<body>
<p>
Elapsed time is:
<script type='text/javascript'>
document.write(new Date() - startTime);
</script>
</p>
</body>
</html>
처음에 CSS를 포함하면 다음 렌더링에 1.5초 걸립니다.
처음에 JavaScript를 포함하면 페이지를 렌더링하는 데 1.4초가 걸립니다.
Chrome, Firefox, Internet Explorer에서도 비슷한 결과를 얻을 수 있습니다.하지만 오페라에서는 순서가 중요하지 않습니다.
모든 CSS가 다운로드될 때까지 JavaScript 인터프리터는 부팅을 거부합니다.따라서 JavaScript 스레드가 실행 시간이 길어질수록 JavaScript에 먼저 포함시키는 것이 더 효율적일 수 있습니다.
내가 뭘 빼놓았나요?JavaScript에 포함되기 전에 CSS에 포함시키는 권장사항이 올바르지 않습니까?
비동기 추가 또는 set Timeout을 사용하여 렌더 스레드를 해방하거나 JavaScript 코드를 바닥글에 넣거나 JavaScript 로더를 사용할 수 있습니다.여기서 포인트는 헤드의 필수 JavaScript 비트와 CSS 비트의 순서에 관한 것입니다.
이것은 매우 흥미로운 질문입니다. 내 CSS를 <link href="...">는 JavaScript s java JavaScript 다 앞 my 앞 s s s s s s s s<script src="...">알겠습니다할 입니다!당신 말이 맞아요. !!실!!!!!!!!!!!!
Node.js(아래 코드)에서 자체 테스트 하니스를 설정했습니다.기본적으로, 저는:
- 페이지가 로드될 때마다 브라우저가 완전히 다운로드해야 하는 HTTP 캐시가 없는지 확인.
- 현실을 시뮬레이트하기 위해 jQuery와 H5BP CSS를 포함했습니다(따라서 해석할 스크립트/CSS의 양은 충분합니다).
- 스크립트 전에 CSS가 있는 페이지와 스크립트 후에 CSS가 있는 페이지를 2장 설정합니다.
- 의 외부 스크립트가 실행될 때까지의 시간을 기록했습니다.
- 의 인라인 스크립트가 실행될 때까지의 시간을 기록했습니다.이것은 다음과 같습니다.
DOMReady. - 브라우저로의 CSS 및/또는 스크립트 전송이 500밀리초 지연되었습니다.
- 3대 브라우저에서 테스트를 20회 실행.
결과.
첫 번째로 CSS 파일이 500밀리초 지연된 경우(단위: 밀리초)
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 583 36 | 559 42 | 565 49
St Dev | 15 12 | 9 7 | 13 6
------------|--------------|--------------|------------
Body Exec | | |
Average | 584 521 | 559 513 | 565 519
St Dev | 15 9 | 9 5 | 13 7
다음으로 CSS 대신 jQuery를 500ms 지연으로 설정합니다.
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 597 556 | 562 559 | 564 564
St Dev | 14 12 | 11 7 | 8 8
------------|--------------|--------------|------------
Body Exec | | |
Average | 598 557 | 563 560 | 564 565
St Dev | 14 12 | 10 7 | 8 8
마지막으로 jQuery와 CSS를 모두 500ms 지연하도록 설정했습니다.
Browser: Chrome 18 | IE 9 | Firefox 9
CSS: first last | first last | first last
=======================================================
Header Exec | | |
Average | 620 560 | 577 577 | 571 567
St Dev | 16 11 | 19 9 | 9 10
------------|--------------|--------------|------------
Body Exec | | |
Average | 623 561 | 578 580 | 571 568
St Dev | 18 11 | 19 9 | 9 10
결론들
중요한 저는 , 라는 가정 을 하고 입니다.<head>되는) <body>)의이 있습니다<head>이 답변의 범위를 벗어납니다.이것은 엄밀히 말하면<script>는 앞에 합니다.<link>는 s s s s s s s 。<head>.
최신 DESTAP 브라우저에서는 처음에 CSS에 링크해도 퍼포먼스가 향상되지 않는 것처럼 보입니다.스크립트 뒤에 CSS를 배치하면 CSS와 스크립트가 모두 지연될 때는 약간의 이득을 얻을 수 있지만 CSS가 지연될 때는 큰 이득을 얻을 수 있습니다.(표시:last컬럼이 표시됩니다.)
마지막으로 CSS에 링크해도 퍼포먼스가 저하되는 것은 아니지만 특정 상황에서 이점을 얻을 수 있기 때문에 오래된 브라우저의 퍼포먼스가 문제가 되지 않는 경우 데스크톱브라우저에서만 외부 스크립트에 링크한 후 외부 스타일시트에 링크해야 합니다.모바일 상황에 대해 읽어보십시오.
왜요?
가 ""를 했을 때<script>외부 자원을 가리키는 태그는 브라우저가 HTML의 해석을 중지하고 스크립트를 취득하여 실행한 후 HTML의 해석을 계속합니다.대조적으로 브라우저가 html을 검출했을 경우,<link>외부 스타일시트의 경우 CSS 파일을 (병렬로) 가져오는 동안 HTML 해석을 계속합니다.
따라서 스타일시트를 우선시하라는 널리 반복되는 조언은 다운로드가 먼저 되고 다운로드가 가능한 첫 번째 스크립트가 병렬로 로드될 수 있습니다.
단, 최신 브라우저(위에서 테스트한 모든 브라우저 포함)는 HTML에서 "앞을 내다보고" 스크립트를 다운로드하여 실행하기 전에 리소스 다운로드를 시작하는 추측 구문 분석을 구현하고 있습니다.
추측 구문 분석 기능이 없는 오래된 브라우저에서는 스크립트를 먼저 배치하면 병렬로 다운로드되지 않기 때문에 성능에 영향을 미칩니다.
브라우저 지원
추측적 해석은 다음에서 처음 구현되었습니다. (2012년 1월 현재 이 버전 이상을 사용하는 전 세계 데스크톱 브라우저 사용자 비율과 함께)
- Chrome 1 (WebKit 525) (100%)
- Internet Explorer 8 (75 %)
- 파이어폭스 3.5 (96 %)
- Safari 4 (99 %)
- Opera 11.60 (85 %)
현재 사용되는 데스크톱 브라우저의 약 85%가 투기적 로드를 지원하고 있습니다.CSS 앞에 스크립트를 배치하면 전 세계 사용자의 15%가 퍼포먼스에 영향을 받습니다.사용자의 마일리지가 사이트의 특정 사용자에 따라 다를 수 있습니다(또한 그 수는 감소하고 있습니다).
모바일 브라우저에서는 모바일 브라우저와 OS의 종류가 다르기 때문에 정확한 수치를 파악하기가 조금 어렵습니다.투기적인 렌더링이 WebKit 525(2008년 3월 출시)에 구현되어 있고, 거의 모든 가치 있는 모바일 브라우저가 WebKit에 기반하고 있기 때문에, 우리는 "대부분" 모바일 브라우저가 이를 지원할 것이라고 결론지을 수 있다.쿼크스 모드에 따르면 iOS 2.2/Android 1.0은 WebKit 525를 사용합니다.Windows Phone이 어떻게 생겼는지 전혀 모르겠어요.
다만, Android 4 디바이스에서 테스트를 실행해, 데스크탑의 결과와 같은 수치를 확인했을 때에, Chrome for Android 의 새로운 리모트 디버거에 접속했습니다.Network 탭에는 브라우저가 실제로 JavaScript 코드가 완전히 로드될 때까지, 즉 최신 버전의 W에서도 CSS를 다운로드하기 위해 대기하고 있는 것이 나타났습니다.Android용 ebKit은 추측 구문 분석을 지원하지 않는 것으로 보입니다.모바일 디바이스 고유의 CPU, 메모리 및/또는 네트워크 제약으로 인해 전원이 꺼질 수 있습니다.
코드
허술한 것은 용서하십시오.Q&D였습니다.
파일 app.js
var express = require('express')
, app = express.createServer()
, fs = require('fs');
app.listen(90);
var file={};
fs.readdirSync('.').forEach(function(f) {
console.log(f)
file[f] = fs.readFileSync(f);
if (f != 'jquery.js' && f != 'style.css') app.get('/' + f, function(req,res) {
res.contentType(f);
res.send(file[f]);
});
});
app.get('/jquery.js', function(req,res) {
setTimeout(function() {
res.contentType('text/javascript');
res.send(file['jquery.js']);
}, 500);
});
app.get('/style.css', function(req,res) {
setTimeout(function() {
res.contentType('text/css');
res.send(file['style.css']);
}, 500);
});
var headresults={
css: [],
js: []
}, bodyresults={
css: [],
js: []
}
app.post('/result/:type/:time/:exec', function(req,res) {
headresults[req.params.type].push(parseInt(req.params.time, 10));
bodyresults[req.params.type].push(parseInt(req.params.exec, 10));
res.end();
});
app.get('/result/:type', function(req,res) {
var o = '';
headresults[req.params.type].forEach(function(i) {
o+='\n' + i;
});
o+='\n';
bodyresults[req.params.type].forEach(function(i) {
o+='\n' + i;
});
res.send(o);
});
파일 css.html
<!DOCTYPE html>
<html>
<head>
<title>CSS first</title>
<script>var start = Date.now();</script>
<link rel="stylesheet" href="style.css">
<script src="jquery.js"></script>
<script src="test.js"></script>
</head>
<body>
<script>document.write(jsload - start);bodyexec=Date.now()</script>
</body>
</html>
파일 js.html
<!DOCTYPE html>
<html>
<head>
<title>CSS first</title>
<script>var start = Date.now();</script>
<script src="jquery.js"></script>
<script src="test.js"></script>
<link rel="stylesheet" href="style.css">
</head>
<body>
<script>document.write(jsload - start);bodyexec=Date.now()</script>
</body>
</html>
파일 test.js
var jsload = Date.now();
$(function() {
$.post('/result' + location.pathname.replace('.html','') + '/' + (jsload - start) + '/' + (bodyexec - start));
});
jQuery는 jquery-1.7.1.min.js 입니다.
JavaScript보다 CSS를 우선시하는 주된 이유는 두 가지입니다.
오래된 브라우저(Internet Explorer 6-7, Firefox 2 등)는 스크립트 다운로드를 시작할 때 이후의 모든 다운로드를 차단합니다. 만약에 ★★★★★★★★★★★★★★★★★★★★★★★.
a.js에 어 followed가 붙는다.b.css하다(, b) (a, bb.css에 어 followed가 붙는다.a.js병렬로 다운로드되므로 페이지가 더 빨리 로딩됩니다.모든 스타일시트가 다운로드될 때까지 렌더링되지 않습니다. 이는 모든 브라우저에서 적용됩니다.스크립트는 다릅니다. 페이지의 스크립트 태그 아래에 있는 모든 DOM 요소의 렌더링을 차단합니다.HEAD에 스크립트를 넣으면 모든 스타일시트와 모든 스크립트가 다운로드될 때까지 페이지 전체가 렌더링되지 않습니다.스타일시트에 대해 모든 렌더링을 차단하는 것은 타당하지만(따라서 처음에 올바른 스타일링을 얻고 스타일링되지 않은 콘텐츠의 FUC 플래시를 피함), 스크립트에 대해 페이지 전체의 렌더링을 차단하는 것은 타당하지 않습니다.대부분의 경우 스크립트는 DOM 요소나 DOM 요소의 일부에만 영향을 주지 않습니다.스크립트는 가능한 한 페이지에서 낮게 로드하거나 비동기식으로 로드하는 것이 좋습니다.
Cuzilion과 함께 사례를 만드는 것은 즐겁습니다.예를 들어, 이 페이지는 HEAD에 스크립트가 있기 때문에 다운로드가 완료될 때까지 페이지 전체가 공백입니다.단, 스크립트를 BODY 블록의 끝으로 이동하면 이 페이지에서 볼 수 있듯이 DOM 요소는 SCRIPT 태그 위에 있기 때문에 페이지 헤더가 렌더링합니다.
저는 당신이 얻은 결과에 대해 너무 강조하지 않을 것입니다.주관적이라고 생각합니다만, JavaScript보다 먼저 CSS를 넣는 것이 좋다고 설명할 이유가 있습니다.
웹 사이트를 로드하는 동안 다음 두 가지 시나리오가 표시됩니다.
사례 1: 화이트 스크린 → 스타일 없는 웹사이트 → 스타일링된 웹사이트 → 인터랙션 → 스타일링된 인터랙티브 웹사이트
사례 2: 화이트 스크린 → 스타일 없는 웹사이트 → 인터랙션 → 스타일링된 웹사이트 → 스타일링된 인터랙티브 웹사이트
난 솔직히 누가 케이스2를 선택했는지 상상할 수 없어.이것은 느린 인터넷 접속을 사용하는 방문자들이 자바스크립트를 사용하여 대화할 수 있는 스타일 없는 웹사이트에 직면하게 된다는 것을 의미합니다(이미 로딩되어 있기 때문에).게다가 스타일 없는 웹 사이트를 보는 데 소비하는 시간은 이 방법으로 극대화 될 것이다.누가 왜 그걸 원하겠어?
또한 jQuery에서 설명한 바와 같이 더 잘 작동합니다.
"CSS 스타일 속성의 값에 의존하는 스크립트를 사용하는 경우 스크립트를 참조하기 전에 외부 스타일시트를 참조하거나 스타일 요소를 포함하는 것이 중요합니다."
파일이 잘못된 순서(처음 JavaScript, 그 다음 CSS)로 로드되면 CSS 파일에 설정된 속성(예를 들어 div 폭이나 높이)에 의존하는 JavaScript 코드가 올바르게 로드되지 않습니다.로드 순서가 잘못되면 올바른 속성이 JavaScript에 '때로는' 알려진 것 같습니다(레이스 조건에 의한 것일 수도 있습니다).이 효과는 사용하는 브라우저에 따라 더 크거나 더 작아 보입니다.
테스트는 개인 컴퓨터 또는 웹 서버에서 수행되었습니까?공백 페이지입니까, 아니면 이미지나 데이터베이스 등이 포함된 복잡한 온라인 시스템입니까?스크립트는 단순한 호버 이벤트 액션을 실행하고 있습니까?아니면 웹 사이트의 렌더링 및 사용자와의 대화 방법에 대한 핵심 컴포넌트입니까?여기에는 고려해야 할 몇 가지 사항이 있으며, 이러한 권장사항의 관련성은 높은 수준의 웹 개발에 도전할 때 거의 항상 규칙이 됩니다.
"스타일시트를 맨 위에, 스크립트를 맨 아래에 배치" 규칙의 목적은 일반적으로 최적의 프로그레시브 렌더링을 실현하기 위한 최선의 방법이며, 이는 사용자 경험에 매우 중요합니다.
다른 모든 것은 제쳐두고, 당신의 테스트가 유효하고, 당신이 정말로 일반적인 규칙과 반대되는 결과를 내고 있다고 가정한다면, 그것은 전혀 놀랄 일이 아니다.모든 웹사이트(및 모든 것을 사용자의 화면에 표시하기 위해 필요한 모든 것)는 서로 다르며 인터넷은 끊임없이 발전하고 있습니다.
다른 이유로 자바스크립트 앞에 CSS 파일을 포함시킵니다.
JavaScript 코드가 일부 페이지 요소의 동적 사이징을 수행할 필요가 있는 경우(CSS가 실제로 후면의 메인인 코너 케이스의 경우) JS가 러싱된 후 CSS를 로드하면 레이스 조건이 발생할 수 있습니다.이 경우 CSS 스타일이 적용되기 전에 요소의 사이즈가 변경되어 최종적으로 스타일이 실행되었을 때 이상하게 보입니다.사전에 CSS를 로드하면 원하는 순서대로 작업이 실행되며 최종 레이아웃이 제가 원하는 레이아웃임을 보증할 수 있습니다.
JavaScript 전에 CSS를 포함하도록 권장하는 것은 무효입니까?
그냥 추천으로 취급하지 않는다면 그렇지 않을 것이다.하지만 만약 당신이 그것을 엄격하고 빠른 규칙으로 취급한다면? 네, 그것은 무효입니다.
[From Window] : DOMContentLoaded 이벤트 :
실행을 에, 「」가 .
<script>a a a<link rel="stylesheet" ...>.
- 및 DOMContentLoaded는 스타일시트가 로드될 때까지 실행되지 않습니다.
각 스크립트가 무엇에 의존하고 있는지 알고 스크립트 실행이 적절한 완료 이벤트 이후로 지연되는지 확인해야 합니다.스크립트가 DOM에만 의존하는 경우 ondomready/domcontentloaded로 재개할 수 있습니다.로드해야 할 이미지 또는 스타일시트에 의존하는 경우 위의 참조를 올바르게 읽으면 해당 코드는 로드 이벤트까지 연기해야 합니다.
양말 한 짝이 다 맞는다고는 생각하지 않습니다만, 판매방식이기도 하고, 신발 한 짝이 다 맞는 것은 아닙니다.스타일과 대본 중 어느 것을 먼저 불러올지 확실한 답은 없다고 생각합니다."중요 경로"에 있지 않기 때문에 무엇이 어떤 순서로 로드되어야 하는지, 그리고 무엇이 나중에 연기될 수 있는지 결정하는 것이 더 많은 경우입니다.
시트가 예뻐질 때까지 사용자의 대화 능력을 늦추는 것이 좋다고 말한 관찰자에게 말합니다.여러분 중 많은 사람들이 밖에 있고 여러분은 정반대로 느끼는 상대방을 짜증나게 합니다.목적 달성을 위해 사이트에 와서 로딩이 끝나기를 기다리면서 사이트와 대화하는 능력이 지연되는 것은 매우 짜증나는 일입니다.당신이 틀렸다고 말하는 게 아니라 당신의 우선순위를 공유하지 않는 다른 파벌이 있다는 것을 알아야 합니다.
이 질문은 특히 웹 사이트에 게재되는 모든 광고에 적용됩니다.사이트 작성자가 광고 콘텐츠에 대해 플레이스홀더 디바이스만 렌더링하고 사이트가 로드되고 인터랙티브한지 확인한 후 광고를 로드 이벤트에 삽입해 주었으면 합니다.그래도 한꺼번에 로드되는 게 아니라 연속적으로 로드되는 광고를 보고 싶다.왜냐하면 비대해진 광고가 로딩되는 동안 사이트 콘텐츠 스크롤에도 영향을 주기 때문이다.하지만 그것은 한 사람의 관점에 불과하다.
- 사용자와 사용자의 가치를 파악합니다.
- 사용자와 사용자가 사용하는 브라우징 환경을 파악합니다.
- 각 파일의 기능과 그 전제 조건을 파악합니다.모든 것을 작동시키는 것이 속도나 예쁜 것보다 우선될 것이다.
- 개발할 때 네트워크 타임라인을 보여주는 도구를 사용합니다.
- 사용자가 사용하는 각 환경에서 테스트합니다.사용자 환경에 따라 로드 순서를 동적으로 변경해야 할 수도 있습니다(서버 측, 페이지 작성 시).
- 확실하지 않은 경우 순서를 변경하고 다시 측정합니다.
- 로드 순서로 스타일과 스크립트를 혼재시키는 것이 최적이 될 수 있습니다.다만, 어느쪽이든 다른 한쪽만 혼재하는 것은 아닙니다.
- 파일을 로드하는 순서뿐만 아니라 어디에 로드하는지도 시험해 보십시오.머리? 몸통?시체 뒤에?DOM Ready/Loaded?장전?
- 적절한 경우 비동기 옵션과 지연 옵션을 검토하여 페이지와 대화하기 전에 사용자가 경험하는 순 지연을 줄입니다.도움이 되는지, 아픈지를 테스트합니다.
- 최적의 부하 순서를 평가할 때는 항상 트레이드오프를 고려해야 합니다.예쁜 vs 반응형 하나뿐입니다.
2017-12-16 갱신
나는 OP의 시험에 대해 확신하지 못했다.나는 약간의 실험을 하기로 결심했고 결국 몇몇 신화들을 깨부수게 되었다.
★★
<script src...>및 합니다.
이것은 더 이상 사실이 아니다.Chrome 63에 의해 생성된 폭포를 살펴보십시오.
<head>
<script src="//alias-0.redacted.com/payload.php?type=js&delay=333&rand=1"></script>
<script src="//alias-1.redacted.com/payload.php?type=js&delay=333&rand=2"></script>
<script src="//alias-2.redacted.com/payload.php?type=js&delay=333&rand=3"></script>
</head>
<link rel=stylesheet>는, 그 하지 .
틀렸습니다.스타일시트는 다운로드를 차단하지 않지만 스크립트의 실행을 차단합니다(여기에 설명이 거의 없음).Chrome 63에서 생성된 성능 차트를 참조하십시오.
<link href="//alias-0.redacted.com/payload.php?type=css&delay=666" rel="stylesheet">
<script src="//alias-1.redacted.com/payload.php?type=js&delay=333&block=1000"></script>
OP의 결과는 위와 같이 설명할 수 있습니다.
CSS First:
CSS Download 500 ms:<------------------------------------------------>
JS Download 400 ms:<-------------------------------------->
JS Execution 1000 ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1500 ms: ◆
JavaScript First:
JS Download 400 ms:<-------------------------------------->
CSS Download 500 ms:<------------------------------------------------>
JS Execution 1000 ms: <-------------------------------------------------------------------------------------------------->
DOM Ready @1400 ms: ◆
2020년도의 답변: 아마 중요하지 않을 것입니다.
여기서 가장 좋은 답은 2012년에 나온 것이었기 때문에 직접 테스트해보기로 했습니다.Android용 Chrome에서는 JS와 CSS 리소스가 병렬로 다운로드되어 페이지 렌더링 속도의 차이를 검출할 수 없었습니다.
블로그에 좀 더 자세한 글을 올렸습니다.
JavaScript를 사용하여 테스트 시간을 어떻게 '렌더'하는지 정확히는 모르겠습니다.단, 다음 사항을 고려하십시오.
당신의 사이트의 한 페이지는 50kB로 무리하지 않습니다.사용자는 East Coast에 있고 서버는 West에 있습니다.MTU는 10K가 아니기 때문에 몇 번 왕복할 수 있습니다.페이지와 스타일시트를 받는 데 1초에 1/2초 정도 걸릴 수 있습니다.일반적으로 자바스크립트(jQuery 플러그인 등)는 CSS보다 훨씬 많습니다.또, 인터넷 접속이 페이지 도중에 끊어졌을 때에 발생하는 현상도 있습니다만, 무시합시다(가끔 있는 일이 있어, CSS가 렌더링한다고는 생각합니다만, 100% 확신할 수 없습니다).
CSS는 선두에 있기 때문에 취득하기 위한 추가 접속이 있을 수 있습니다.즉, 페이지가 종료되기 전에 종료될 가능성이 있습니다.어쨌든 페이지의 나머지 부분과 JavaScript 파일(더 많은 바이트)을 입력하는 동안 페이지 유형이 설정되지 않아 사이트/접속이 느려 보입니다.
JavaScript 인터프리터가 CSS가 완료될 때까지 부팅을 거부하더라도 자바스크립트 코드를 다운로드하는 데 걸리는 시간이 CSS 시간으로 단축되어 사이트가 불편해 보입니다.
이것은 작은 최적화이지만, 그것이 그 이유입니다.
다음은 지금까지의 주요 답변의 요약입니다.
최신 브라우저의 경우 CSS 콘텐츠를 원하는 위치에 배치합니다.HTML 파일(이것을 추측 구문 분석이라고 부릅니다)을 분석하여 HTML 구문 분석과 병행하여 CSS 다운로드를 시작합니다.
오래된 브라우저의 경우 CSS를 계속 맨 위에 둡니다(네이키드가 아닌 인터랙티브한 페이지를 먼저 표시할 필요가 없는 경우).
모든 브라우저에서 JavaScript 콘텐츠는 HTML의 해석을 중지하기 때문에 가능한 한 페이지 아래쪽에 둡니다.가능하면 비동기적으로 다운로드(Ajax 콜)해 주세요.
(CSS를 최우선으로 하는 기존의 지혜와는 달리) JavaScript를 최우선으로 하는 것이 더 나은 성능을 제공한다고 주장하는 특정 사례에 대한 실험 결과도 있지만, 이에 대한 논리적인 추론이 주어지지 않았고 광범위한 적용 가능성에 대한 검증이 부족하기 때문에 현재로서는 무시해도 됩니다.
그래서 질문에 대답하자면: 네.JavaScript 전에 CSS를 포함하도록 권장하는 것은 최신 브라우저에서는 유효하지 않습니다.원하는 위치에 CSS를 배치하고 JavaScript를 가능한 마지막에 배치합니다.
스티브 수더스는 이미 명확한 대답을 했지만...
Sam의 원래 테스트와 Josh의 반복 테스트에 문제가 있는지 궁금합니다.
두 테스트 모두 TCP 접속 셋업 비용이 적게 드는 저지연 접속에서 실행된 것으로 보입니다.
이것이 테스트 결과에 어떤 영향을 미치는지 확실하지 않으며 '정상' 지연 연결을 통해 테스트를 위해 폭포를 살펴보고 싶습니다만...
다운로드 받은 첫 번째 파일은 HTML 페이지에 사용되는 연결을 얻어야 하며 두 번째 파일은 새 연결을 얻습니다. (<head>를 조기에 플러시하면 동적 변경은 되지만 여기서는 수행되지 않습니다.)
새로운 브라우저에서는 두 번째 TCP 연결이 추측적으로 열리기 때문에 연결 오버헤드가 감소하거나 사라집니다.오래된 브라우저에서는 이는 사실이 아니며 두 번째 연결은 열림이라는 오버헤드가 발생합니다.
이것이 테스트 결과에 어떤 영향을 미치는지 나는 잘 모르겠다.
모든 경우에 해당되는 것은 아니라고 생각합니다.왜냐하면 CSS 콘텐츠는 병렬로 다운로드되지만 JavaScript 코드는 다운로드 할 수 없기 때문입니다.같은 경우를 고려합니다.
하나의 CSS 콘텐츠를 보유하는 대신 2, 3개의 CSS 파일을 가져와 이러한 방법으로 시험해 보십시오.
CSS..CSS..자바스크립트
CSS..JavaScript..CSS
JavaScript..CSS..CSS
분명히 CSS는..CSS..JavaScript는 다른 어떤 것보다도 좋은 결과를 얻을 수 있습니다.
우리는 새로운 브라우저가 자바스크립트 엔진, 파서 등에서 작동하여 Internet Explorer 8이나 이전과 같은 고대 브라우저에서 경험했던 일반적인 코드와 마크업 문제를 최적화하고 마크업뿐만 아니라 자바스크립트 변수, 요소 선택 사용에도 더 이상 관련이 없다는 것을 유념해야 한다.CTR 등
머지않은 장래에 테크놀로지가 퍼포먼스의 문제가 되지 않게 된 것을 알 수 있습니다.
저는 개인적으로 그런 '민간의 지혜'를 너무 중시하지 않습니다.과거에 진실이었을지도 모르는 것이 지금은 사실이 아닐지도 모른다.웹 페이지의 해석과 렌더링에 관한 모든 조작은 완전히 비동기적이며('무엇을 불러오는' 것과 '그에 대해 행동하는' 것은 서로 다른 스레드 등에 의해 처리될 수 있는 완전히 다른 두 가지 사항입니다), 어떤 경우에도 사용자의 통제나 관심사를 완전히 벗어난다고 가정합니다.
이 문서의 "헤드" 부분에 외부 스크립트에 대한 참조와 함께 CSS 참조를 입력합니다(본문에 삽입할 필요가 있는 스크립트가 있을 수 있습니다).
그 이상은..."이 브라우저에서 이 관찰이 더 빠르거나 더 빠른 것 같다"고 관찰한 경우, 이 관찰을 흥미로우나 무관한 호기심으로 간주하고 설계 결정에 영향을 미치지 않도록 하십시오.너무 많은 것들이 너무 빨리 변해요.(Firefox 팀이 제품의 또 다른 중간 릴리스를 발표하기까지 몇 분 정도 걸릴지 내기할 사람? 네, 저도요.)
언급URL : https://stackoverflow.com/questions/9271276/should-css-always-precede-javascript
'programing' 카테고리의 다른 글
| 표시할 java.sql 타임스탬프 포맷 방법 (0) | 2022.11.27 |
|---|---|
| C에서의 \b 및 \r 사용방법 (0) | 2022.11.27 |
| 해석 오류: 구문 오류, 내 PHP 코드의 예기치 않은 파일 끝 (0) | 2022.11.27 |
| PDF 파일 병합 (0) | 2022.11.27 |
| 요소에서 텍스트 선택(마우스로 강조 표시) (0) | 2022.11.27 |