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
images, see ...
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 ...
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)
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 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 Lighthouse tool is now part of Chrome, and you can access it from Developer Tools (F12) -> Audit. You can use it on logged-in pages, and even against Chrome on a real mobile device (which you should use instead of emulators whenever possible). Lighthouse provides audits for performance, accessibility, progressive web apps, and more.
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 ...
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 ...
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 ...
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).
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 ...
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 ...
As @Evgeniy has already covered in his answer, in order to add HTTP response headers to resources external to your site, you need to copy these resources locally - to a server that you control - so you can send the HTTP response header as part of the HTTP response.
However, whether you should do this or not is another matter and each instance should be ...
TL;DR answer: I don't think that exists in the way you mentioned similar to webp and, if it's possible, it would be with messy/unsupported workarounds. It may even trigger some ad blockers / antivirus. Unlike with webp, which is just a test of browser capability and not user-specific at all. I don't really know, but privacy laws are changing fast and don't ...
Here are some areas to consider in general, without going into detail:
Physical configuration/server specs:
RAM (the more the better)
CPU processor speed, and number of cores for multi-core applications
Drive speed and physical RAID to increase read/write speed (not software RAID used for mirrors and backups)
OS and server configuration: (This is ...
I think this help document from Google should be solving my problem:
Change the crawl rate:
On the Webmaster Tools Home page, click the site you want.
Click the gear icon , then click Site Settings.
In the Crawl rate section, select the option you want.
The new crawl rate will be valid for 90 days.
Responsive Design does not normally use any width or height attributes
Google Development Tools is a guide and you shouldn't need to enforce everything you read on their site, in fact some of the stuff is outdated. The majority of responsive websites do not use width or height because they want the images to adapt to the screen size and by using fixed ...
Page speed is a ranking factor to some degree, as mentioned by Matt Cutts in this related video (Aug 2013): Is page speed a more important factor for mobile sites?.
However, pages are also ranked on their own merits. So that one page may not (should not) bring down the ranking of the other (fast) pages on your site (if that is what you are implying). But ...
Adding the height and width attributes to your IMG SRC HTML tag allows
the browser to know how much space to leave for an image. Without
these values, the browser gives an image no space until the image is
loaded, which means anything surrounding the image is adjusted after
the image has loaded.
You are using the ^ and $ (anchors in regex speak) because you are matching the whole URL, which is what most people want to do, so this is the most common example you see.
If you omit the ^ and/or $ anchors then you are only going to be matching part of the URL. eg. anything$ is going to match "anything" at the end of the URL - this could match too many ...