The short answer is "Because HTTP wasn't designed for it".
Tim Berners-Lee did not design an efficient and extensible network protocol. His one design goal was simplicity. (The professor of my networking class in college said that he should have left the job to the professionals.) The problem that you outline is just one of the many problems with the ...
Google makes reference to gzip and image/binary files at Minimize payload size
Don't use gzip for image or other binary files.
Image file formats supported by the web, as well as videos, PDFs and other binary
formats, are already compressed; using gzip on them won't provide any
additional benefit, and can actually make them larger. To compress
Google wants to provide its user base with the best experience possible when browsing the web - this is what retains their customers. A poor page load speed can have a serious effect on user experience, that is arguably the main reason Google sometimes ranks these sites less favorably.
It is also an indication that the site isn't perhaps maintained to a ...
In Chrome, you can open the developer tools, click in the device icon (1), and then select the connection throttling (2).
Since around Chrome 45, it actually got a little bit easier: you don't have to be in device mode anymore.
As covered here, GitHub Pages is served with Nginx and automatically gzip's content.
You can confirm gzip compression for your site by checking the HTTP headers with online tools like this one. Enter the URL to a webpage or resource, and type in gzip under "Accept-Encoding" to indicate that the HTTP client (i.e., the online testing tool in this case) ...
Here's an example that forces the browser to download ...
Your web browser doesn't know about the additional resources until it downloads the web page (HTML) from the server, which contains the links to those resources.
You might be wondering, why doesn't the server just parse its own HTML and send all the additional resources to the web browser during the initial request for the web page? It's because the ...
Google will penalize sites that are very slow (greater than 7-10 seconds for the page to become usable). They do this because they state that users are usually not willing to wait that long when they click and usually return to the serps. Google wants to make their users happy.
In addition to the direct penalties applied by Google, there are indirect ...
The technical term for waiting is refereed to as time to first byte and determines the responsiveness of a web server or other network resources.
Some common reasons you might see an high time to first byte:
Overloaded network (normally shared hosting)
Distance from you and the server (geo location plays a minor role)
The base64 image option should be used where you would only have a very small number of images and you want to eliminate the network overhead of fetching a picture from the server. However from what you are indicating in the question I assume this could scale to a large number of images. In this case I would use a single 1px x 1px transparent image from the ...
The max-age directive on a response implies that the response is cacheable
(i.e., "public") unless some other, more restrictive cache directive is
It's conceivable (likely?) that there are proxies in the wild which break this but since the only failure mode could be ...
Because they do not know what those resources are. The assets a web page requires are coded into the HTML. Only after a parser determines what those assets are can the y be requested by the user-agent.
Additionally, once those assets are known, they need to be served individually so the proper headers (i.e. content-type) can be served so the user-agent ...
Browsers download data in parallel and try to start rendering the page as soon as possible.
If you do not specify the size, the browser has no idea how large the image is going to be until after the image download is fully complete.
This delay forces the browser to repaint or reflow the layout - delaying the page load time.
The more images with this ...
Effect for browser:
Though this looks like a bit of work for web browser, but technically it does not make much of a difference. The browsers are too fast to handle these relative url structure and make a call to application server
Effect for application Server:
None, as it needs to return the requested file (relative/absolute link ultimately maps to a ...
You can slow down specific resources with Deelay.me:
Deelay.me is a delay proxy for web resources. You can use it with your images/stylesheets/scripts, to increase their load time.
Because, in your example, web server would always send CSS and images regardless if the client already has them, thus greatly wasting bandwidth (and thus making the connection slower, instead of faster by reducing latency, which was presumably your intention).
You will find that the initial connection includes negotiating the SSL, so since the handshake is high, its a good indicator that something is seriously wrong with the way you have setup the SSL.
Google Chrome: Understanding Resource Timing
Time it took to establish a connection, including TCP handshakes/retries and negotiating a ...
From Modernizr installation page:
Drop the script tags in the HEAD of your HTML. For best performance, you should have them follow after your stylesheet references. The reason we recommend placing Modernizr in the head is two-fold: the HTML5 Shiv (that enables HTML5 elements in IE) must execute before the BODY, and if you’re using any of the CSS classes ...
HTTP2 is based on SPDY and does exactly what you suggest:
At a high level, HTTP/2:
is binary, instead of textual
is fully multiplexed, instead of ordered and blocking
can therefore use one connection for parallelism
uses header compression to reduce overhead
allows servers to “push” responses proactively into client caches
More is ...
Use OpenSSL's speed command to benchmark the two types and compare results. Here's an example command to run on the server to compare only the key types and sizes you mention:
openssl speed rsa2048 rsa4096
For reference, here are some benchmark results from a modest VPS:
sign verify sign/s verify/s
rsa 2048 bits 0.000685s 0.000032s ...
Just to clarify, since it's not explicitly mentioned in the question, that the reason for doing this in the first place is to break the client cache...
As far as I know the only reason to use an "embedded version number" in the filename itself over using a "dynamic" query string was that some (outdated?) proxy servers did not cache URLs that varied only by ...
Bonded T1, DS1, SDSL (Symmetric DSL) Check with your Local Exchange Carrier to see what their offerings are.
Business Cable 20-100Mbit down/3-5Mbit up
It's usually against the TOS to use asymmetrical home use Internet Access like ASDL and Cable. Two of the main reasons are:
a)while the downlink has blazing speed, the uplink speed (control traffic outbound) ...
Reading the title of your question, there are two things you can do to speed up the initial connection and SSL/TLS handshake. These work for any connection, not just 3G, so you should use these as best practice anyway.
First, use HTTP/2 to serve the site. This requires Apache 2.4.17 or later.
Second, configure Apache to use OCSP stapling. This requires ...
Please note: I am answering based on what you've described above only (which, while descriptive, isn't the same as analysing the source(s)).
To your questions above:
From Google Page Speed's own FAQ:
Some of the suggestions differ from the Page Speed browser extensions. Why?
Page Speed Online uses a different rendering engine and user agent, which may ...
The best advice is to put script tags in the bottom of your body and pack them ...
First of all: you are basically doing a lot of things very good at the moment. This results in good grades in PageSpeed for example. Also keep in mind that the biggest part of the waiting time is spent on the frontend, so it makes sense to optimize this before going deep into server configuration.
These are some ideas:
there are a lot of image requests, ...