On 1/16/15 1:32 PM, Vladimir Panteleev wrote:
> On Friday, 16 January 2015 at 21:26:04 UTC, Andrei Alexandrescu wrote:
>> 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.
>
> That's probably because HTTP caching is not configured.
>
> Ideally, you'd put the file's modification time in its path, e.g.:
>
> <link rel="stylesheet" type="text/css" href="css/1421443851/style.css" />
>
> css/*/style.css would point to the same style.css (via internal, not
> HTTP redirect).
>
> Then, css/* can be cached forever, as the URL of the file would change
> when the file changes.
>
> This is what DFeed does, but I'm not sure if this is feasible with just
> DDoc and makefiles, though.

Nice. Wanna take it up? Generally I'm looking for less work for me and more work for others :o). -- Andrei

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

I looked at the favicon, and...

the file is .ico (bad format), stores 5 versions of the icon (16x16 to 64x64) even though only 16x16/32x32 are supported.


Here are just the 16x16(383b) and 32x32(1.77kiB) versions, as PNGs (better compression than gif, and official standard - used RGBA, as 8-bit lost quality with almost identical size): http://imgur.com/l4612WV,ThgDnJH#0 . Pick one and use it. I cut 1 pixel column from the 16x16 version because it was... 17x16.

See http://www.w3.org/2005/10/howto-favicon

On Friday, 16 January 2015 at 21:39:52 UTC, Andrei Alexandrescu wrote:
> On 1/16/15 1:32 PM, Vladimir Panteleev wrote:
>> On Friday, 16 January 2015 at 21:26:04 UTC, Andrei Alexandrescu wrote:
>>> 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.
>>
>> That's probably because HTTP caching is not configured.
>>
>> Ideally, you'd put the file's modification time in its path, e.g.:
>>
>> <link rel="stylesheet" type="text/css" href="css/1421443851/style.css" />
>>
>> css/*/style.css would point to the same style.css (via internal, not
>> HTTP redirect).
>>
>> Then, css/* can be cached forever, as the URL of the file would change
>> when the file changes.
>>
>> This is what DFeed does, but I'm not sure if this is feasible with just
>> DDoc and makefiles, though.
>
> Nice. Wanna take it up? Generally I'm looking for less work for me and more work for others :o). -- Andrei

Also, -1 for CSS minification, if I'll ever want to make any CSS contibutions I'll start by looking at the CSS in the browser.

+1 for gzip and caching. *don't even consider* microoptimizations like this if you're not even doing that yet, whatever gains you might get are negligible by comparison.

On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
> 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.

30% -- ANDREI

On 1/16/15 5:12 PM, Andrei Alexandrescu wrote:
> On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
>> 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.
>
> 30% -- ANDREI

so d-minified.css.gz is 30% smaller than d.css.gz? Just want to clarify.

-Steve

On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
> 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.

Pretty cool. The problem I'm having right now is the following pattern:

1. I have a mini-idea that takes me minutes to implement and turns the ratchet in the right direction.

2. I post it here in the hope that others will build upon or come with better ideas.

3. I get feedback here that essentially demonstrates me that if I spent some hours or days on a small research project on a better idea, it would yield better results.

I encourage anyone who has more expertise in this kind of stuff to help out with turning the mythical ratchet one tooth forward. Thanks!


Andrei

On 1/16/15 1:54 PM, Kiith-Sa wrote:
> I looked at the favicon, and...
>
> the file is .ico (bad format), stores 5 versions of the icon (16x16 to
> 64x64) even though only 16x16/32x32 are supported.
>
>
> Here are just the 16x16(383b) and 32x32(1.77kiB) versions, as PNGs
> (better compression than gif, and official standard - used RGBA, as
> 8-bit lost quality with almost identical size):
> http://imgur.com/l4612WV,ThgDnJH#0 . Pick one and use it. I cut 1 pixel
> column from the 16x16 version because it was... 17x16.
>
> See http://www.w3.org/2005/10/howto-favicon

Thanks. Could you please Just Do It(tm) or paste this into a bug report. Thanks! -- Andrei

On Friday, 16 January 2015 at 22:17:51 UTC, Steven Schveighoffer wrote:
> On 1/16/15 5:12 PM, Andrei Alexandrescu wrote:
>> On 1/16/15 1:44 PM, Steven Schveighoffer wrote:
>>> 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.
>>
>> 30% -- ANDREI
>
> so d-minified.css.gz is 30% smaller than d.css.gz? Just want to clarify.
>
> -Steve

              Original  Minified
Uncompressed    16028     11959
gzip -9          4252      3194

Looks closer to 25%, but same ballpark.

On 1/16/15 2:02 PM, Kiith-Sa wrote:
> +1 for gzip and caching. *don't even consider* microoptimizations like
> this if you're not even doing that yet, whatever gains you might get are
> negligible by comparison.

I'm estimating about one third of 12%, or 4% of the total traffic. That's a hell of a ROI for one line of code. -- Andrei