On 1/16/15 4:26 PM, Andrei Alexandrescu wrote:
On 1/16/15 1:13 PM, Steven Schveighoffer wrote:
On 1/16/15 3:53 PM, Andrei Alexandrescu wrote:
On 1/16/15 12:37 PM, Steven Schveighoffer wrote:
On 1/16/15 12:40 PM, Andrei Alexandrescu wrote:
I just added
https://github.com/D-Programming-Language/dlang.org/pull/770, which
generates minified css files. This is because in the near future css
files will become heftier (more documentation comments, more detailed
styles etc).
The disadvantage is that now one needs to be online to generate
documentation. Thoughts?
Almost all browsers support gzip transfer of files. You'd get much
better mileage with just gzipping the file.
-Steve
That's part of the protocol, right? We should be doing that anyway.
Anyhow, the css is really hot and comments just add to it, compressed or
not. -- Andrei
I think this is way over-optimization.
If the system already sends gzipped, I don't think any kind of
minification is going to improve enough to the point of justifying all
this.
(Dons Walter hat): have you profiled to see how much it saves?
Well good point. As of January two of the css files are in the top 3
most trafficked files off of dlang.org, second only to favicon.ico.
Loading css accounts for 12.78% of all dlang.org hits and 5.73% of all
dlang.org bytes transferred. I'd say improvements would be measurable.
Well, this is looking at the wrong statistic. I don't care how much of
the overall bandwidth it is, what I was asking is how much does the file
shrink if you minify. Saving 1% file size isn't going to put any kind of
dent in the traffic.
BTW are there ways to compress favicon.ico better? It's #1 with 10.28%
of all hits and 16.27% of all bytes transferred.
On an embedded product we have with a dead-simple web server, there is
terrible network performance. Adding gzip support saved way more than
minification ever could. But the best performance improvement was to add
caching support to the server. Both the browser and the server have to
cooperate there.
-Steve
