안녕하세요.
최근에 본 책이 혹시 도움이 되지 않을까 해서 글을 적어봅니다.
다들 읽어보셨을지도..
High Performance Web Sites라는 책에서 발췌한 내용을 첨부합니다.
요약하자면,
같은 내용의 one HTML document that is 87K 와,
an HTML document (7K), one stylesheet (59K), and three scripts (1K, 11K, and 9K) for a total of 87K의
response times 을 비교해 봤더니...전자가 30%에서 50% 정도 더 빠르다는 것입니다.
이유는 overhead of multiple HTTP requests 때문이라고 합니다.
그럼에도 불구하고 이 책에서는 프론트엔드 성능향상을 위해서 "Make JavaScript and CSS External"라고 합니다.
이유는 캐쉬사용을 할 수 있어서라고 하구요.
이 책에서 "HTTP 요청수를 줄이는 것이 파일의 용량을 줄이는 것보다 더 더 중요하다" 라는 말은 찾을 수가 없습니다.
이 책에서 제안하는 것은.."HTTP 요청수를 줄여라" 그리고 "파일의 용량을 줄여라" 입니다.
이미지 리퀘스트가 이미 수십에서 수백에 이른데 css나 js파일 request를 줄이는데 너무 크게 개의치 않아도 되지 않을까 하는게 저의 생각입니다.
물론 css와 js는 하나만 만들어서 최소화 시키는 것이 좋을 것 같구요 
request 2번 더 날리는 것쯤은 괜찮지 않을까요?
다른 포탈들이 css나 js를 인라인으로 삽입한데는 단순히 request를 줄이는 것 외에, 다른 이유(위에서 다른 분들이 언급해주신)도 분명히 존재할 것이라고 생각합니다.
참고로, HTTP 리퀘스트가 많아진다는 것은 단순히 헤더의 용량이 늘어나는 것만은 아닙니다.
(아래에 관련 된 내용을 첨부했는데...음 그림도 없구... )
------------------------------------------------------------------------------------------
HTTP Overview 2
------------------------------------------------------------------------------------------
Before diving into the specific rules for making web pages faster, it’s important to
understand the parts of the HyperText Transfer Protocol (HTTP) that affect performance.
HTTP is how browsers and servers communicate with each other over the
Internet.The HTTP specification was coordinated by the World Wide Web Consortium
(W3C) and Internet Engineering Task Force (IETF), resulting in RFC 2616.
HTTP/1.1 is the most common version today, but some browsers and servers still
use HTTP/1.0.
HTTP is a client/server protocol made up of requests and responses.A browser
sends an HTTP request for a specific URL, and a server hosting that URL sends back
an HTTP response.Like many Internet services, the protocol uses a simple, plaintext
format.The types of requests are GET, POST, HEAD, PUT, DELETE,
OPTIONS, and TRACE.I’m going to focus on the GET request, which is the most
common.
A GET request includes a URL followed by headers.The HTTP response contains a
status code, headers, and a body.The following example shows the possible HTTP
headers when requesting the script yahoo_2.0.0-b2.js.
GET /us.js.yimg.com/lib/common/utils/2/yahoo_2.0.0-b2.js
Compression
The size of the response is reduced using compression if both the browser and server
support it.Browsers announce their support of compression using the Accept-
Encoding header.Servers identify compressed responses using the Content-Encoding
header.
Notice how the body of the response is compressed.Chapter 4 explains how to turn
on compression, and warns about edge cases that can arise due to proxy caching.
The Vary and Cache-Control headers are also discussed
Conditional GET Requests
If the browser has a copy of the component in its cache, but isn’t sure whether it’s
still valid, a conditional GET request is made.If the cached copy is still valid, the
browser uses the copy from its cache, resulting in a smaller response and a faster user
experience.
Typically, the validity of the cached copy is derived from the date it was last modified.
The browser knows when the component was last modified based on the Last-
Modified header in the response (refer to the previous sample responses).It uses the
If-Modified-Since header to send the last modified date back to the server.The
browser is essentially saying, “I have a version of this resource with the following last
modified date. May I just use it?”
If the component has not been modified since the specified date, the server returns a
“304 Not Modified” status code and skips sending the body of the response, resulting
in a smaller and faster response.In HTTP/1.1 the ETag and If-None-Match headers
are another way to make conditional GET requests.Both approaches are
discussed in Chapter 13.
Expires
Conditional GET requests and 304 responses help pages load faster, but they still
require making a roundtrip between the client and server to perform the validity
check.The Expires header eliminates the need to check with the server by making it
clear whether the browser can use its cached copy of a component.
When the browser sees an Expires header in the response, it saves the expiration
date with the component in its cache.As long as the component hasn’t expired, the
browser uses the cached version and avoids making any HTTP requests.Chapter 3
talks about the Expires and Cache-Control headers in more detail.
Keep-Alive
HTTP is built on top of Transmission Control Protocol (TCP).In early implementations
of HTTP, each HTTP request required opening a new socket connection.This
is inefficient because many HTTP requests in a web page go to the same server.For
example, most requests for images in a web page all go to a common image server.
Persistent Connections (also known as Keep-Alive in HTTP/1.0) was introduced to
solve the inefficiency of opening and closing multiple socket connections to the same
server.It lets browsers make multiple requests over a single connection.Browsers
and servers use the Connection header to indicate Keep-Alive support.The
Connection header looks the same in the server’s response.
The browser or server can close the connection by sending a Connection: close
header.Technically, the Connection: keep-alive header is not required in HTTP/1.1,
but most browsers and servers still include it.
Pipelining, defined in HTTP/1.1, allows for sending multiple requests over a single
socket without waiting for a response.Pipelining has better performance than persistent
connections.Unfortunately, pipelining is not supported in Internet Explorer (up
to and including version 7), and it’s turned off by default in Firefox through version
2.Until pipelining is more widely adopted, Keep-Alive is the way browsers and servers
can more efficiently use socket connections for HTTP.This is even more important
for HTTPS because establishing new secure socket connections is more time
consuming.
There’s More
This chapter contains just an overview of HTTP and focuses only on the aspects that
affect performance.To learn more, read the HTTP specification (http://www.w3.org/
Protocols/rfc2616/rfc2616.html) and HTTP: The Definitive Guide by David Gourley
and Brian Totty (O’Reilly; http://www.oreilly.com/catalog/httptdg).The parts highlighted
here are sufficient for understanding the best practices described in the
following chapters.
---------------------------------------------------------------------------------
In Raw Terms, Inline Is Faster
---------------------------------------------------------------------------------
I have generated two examples that demonstrate how inlining JavaScript and CSS
results in faster response times than making them external files.
Inlined JS and CSS
http://stevesouders.com/hpws/inlined.php
External JS and CSS
http://stevesouders.com/hpws/external.php
The inline example involves one HTML document that is 87K, with all of the Java-
Script and CSS in the page itself.The external example contains an HTML document
(7K), one stylesheet (59K), and three scripts (1K, 11K, and 9K) for a total of
87K.Although the total amount of data downloaded is the same, the inline example
is 30–50% faster than the external example.This is primarily because the external
example suffers from the overhead of multiple HTTP requests (see Chapter 1 about
the importance of minimizing HTTP requests).The external example even benefits
from the stylesheet and scripts being downloaded in parallel, but the difference of
one HTTP request compared to five is what makes the inline example faster.
Despite these results, using external files in the real world generally produces faster
pages.This is due to a benefit of external files that is not captured by these examples:
the opportunity for the JavaScript and CSS files to be cached by the browser.
HTML documents, at least those that contain dynamic content, are typically not
configured to be cached.When this is the case (when the HTML documents are not
cached), the inline JavaScript and CSS is downloaded every time the HTML document
is requested.On the other hand, if the JavaScript and CSS are in external files
cached by the browser, the size of the HTML document is reduced without increasing
the number of HTTP requests.
The key factor, then, is the frequency with which external JavaScript and CSS components
are cached relative to the number of HTML documents requested.This
factor, although difficult to quantify, can be gauged using the following metrics.
