Re: css minification
On 2015-01-17 19:23, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right? I wish. Was that honest? I got the impression that you and Walter was satisfied with using Ddoc for the website. -- /Jacob Carlborg
Re: css minification
On 1/18/15 1:01 AM, Sebastiaan Koppe wrote: On Sunday, 18 January 2015 at 07:42:10 UTC, Andrei Alexandrescu wrote: On 1/17/15 11:23 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? Not quite getting the logic there. -- Andrei It is unrelated to my point about compression. The reasoning is as follows: if you are maxed out on resources We're not maxed out on resources. The question was whether compression adds a net benefit. -- Andrei
Re: css minification
On Sunday, 18 January 2015 at 07:42:10 UTC, Andrei Alexandrescu wrote: On 1/17/15 11:23 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? Not quite getting the logic there. -- Andrei It is unrelated to my point about compression. The reasoning is as follows: if you are maxed out on resources, you will have problems when the site gets more visitors. Compression can still help there. If the file is compressed the server needs to send less bytes, and can close the connection quicker. Pre-compression instead of doing on-demand, like Adam Ruppe said, will optimize it even more. Btw. I build the dlang.org site on my computer but the script links have an %0 in the src attribute. Then 5 min later I saw the same on dlang.org Funny thing is, all stuff is still functioning. Affirming my hunch that you can remove a lot of the js stuff. The site now loads in 124kb. Whoever put that %0 there, you just cut down the site from 300kb to 124kb. Nice Job!
Re: css minification
On Sunday, 18 January 2015 at 17:46:52 UTC, Andrei Alexandrescu wrote: On 1/18/15 9:41 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Saturday, 17 January 2015 at 18:00:01 UTC, Andrei Alexandrescu wrote: Would be a nice tools/ thing. Wanna do it/ --- Andrei First try: https://github.com/schuetzm/shrinkcss/blob/master/shrinkcss.d Reads from stdin, writes to stdout. Removes comments, superfluous whitespace, and the closing ; before }. WARNING: This is mostly untested, the lexer is probably missing a few corner cases. Noice. Would be interesting to see how much Brian's lexer generator would help. If it reduces size considerably or makes it a lot easier to do things, that would be a good proof of utility. -- Andrei It might help, maybe I'll try it out (not today, though). One improvement I'd like to have would be to avoid the duplication of the `case`s of `lex()` in the `readXXX()` functions.
Re: css minification
On 1/18/15 1:01 AM, Sebastiaan Koppe wrote: Btw. I build the dlang.org site on my computer but the script links have an %0 in the src attribute. Then 5 min later I saw the same on dlang.org Urgh, typo. https://github.com/D-Programming-Language/dlang.org/commit/807d471e602c1d8e6eff671ab1fe94b20b2e5cf1 Andrei
Re: css minification
On Saturday, 17 January 2015 at 18:00:01 UTC, Andrei Alexandrescu wrote: Would be a nice tools/ thing. Wanna do it/ --- Andrei First try: https://github.com/schuetzm/shrinkcss/blob/master/shrinkcss.d Reads from stdin, writes to stdout. Removes comments, superfluous whitespace, and the closing ; before }. WARNING: This is mostly untested, the lexer is probably missing a few corner cases.
Re: css minification
On 1/18/15 1:01 AM, Sebastiaan Koppe wrote: Btw. I build the dlang.org site on my computer but the script links have an %0 in the src attribute. Then 5 min later I saw the same on dlang.org Funny thing is, all stuff is still functioning. Affirming my hunch that you can remove a lot of the js stuff. The site now loads in 124kb. Whoever put that %0 there, you just cut down the site from 300kb to 124kb. Nice Job! Much of that was to enable running D code in the browser, which has been disabled as of late. No problem! I'll ask one of our many lieutenants to look into it :o). Andrei
Re: css minification
On 1/18/15 9:41 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net wrote: On Saturday, 17 January 2015 at 18:00:01 UTC, Andrei Alexandrescu wrote: Would be a nice tools/ thing. Wanna do it/ --- Andrei First try: https://github.com/schuetzm/shrinkcss/blob/master/shrinkcss.d Reads from stdin, writes to stdout. Removes comments, superfluous whitespace, and the closing ; before }. WARNING: This is mostly untested, the lexer is probably missing a few corner cases. Noice. Would be interesting to see how much Brian's lexer generator would help. If it reduces size considerably or makes it a lot easier to do things, that would be a good proof of utility. -- Andrei
Re: css minification
On 2015-01-16 22:32, Vladimir Panteleev wrote: 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 / Or a hash of the file content in the filename. -- /Jacob Carlborg
Re: css minification
don't know if it's already said but if you are using nginx, there's a plugin for minification and builtin support for compressing html pages or static assets. therefore, nobody needs a third-party dependency for building the docs.
Re: css minification
On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer
wrote:
On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
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.
At the cost of adding dependencies for builds, and requiring
builds be done with Internet access. I don't think it's out of
line to ask that if we are going to add extra build
requirements, we should make sure it's really making decent
progress.
Why do we need an external services?
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g
Strictly speaking, this is overzealous (e.g. it also operates
inside strings), and I didn't even test it, but it will probably
work for almost all cases. The current main CSS file of dlang.org
(style.css) shrinks from 14757 to 11720 bytes, a reduction of
~21%.
But even writing a compressor in D should be trivial, as you'd
only need a lexer.
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 think you misunderstand. We are not saying do a research
project, it takes seconds to gzip 2 files (the minified and
not minified) and see the size difference. If it's
super-significant, let's go for it! If you send me the minified
file, I can test it for you.
There doesn't need to be any research, but all the suggestions
that have been provided have NOT required extra tools or
dependencies. That is a significant difference.
-Steve
Re: css minification
On Friday, 16 January 2015 at 22:02:27 UTC, Kiith-Sa wrote: 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. You'd use the DOM inspectors in this case, no? They don't care about the formatting of the CSS file.
Re: css minification
Another cheap addition, down to 11577 bytes:
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g |
sed 's/;}/}/g'
Re: css minification
On 1/17/15 4:58 AM, Mengu wrote: don't know if it's already said but if you are using nginx, We use Apache as far as I know. there's a plugin for minification and builtin support for compressing html pages or static assets. therefore, nobody needs a third-party dependency for building the docs. Opt-in is fine. Please review and pull: https://github.com/D-Programming-Language/dlang.org/pull/770 Andrei
Re: css minification
On 1/17/15 8:44 AM, Marc =?UTF-8?B?U2Now7x0eiI=?= schue...@gmx.net
wrote:
On Friday, 16 January 2015 at 22:32:07 UTC, Steven Schveighoffer wrote:
On 1/16/15 5:23 PM, Andrei Alexandrescu wrote:
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.
At the cost of adding dependencies for builds, and requiring builds be
done with Internet access. I don't think it's out of line to ask that
if we are going to add extra build requirements, we should make sure
it's really making decent progress.
Why do we need an external services?
cat style.css |
tr '\n' ' ' |
sed 's/\/\*[^*]*\*\///g' |
sed 's/\s\+/ /g' |
sed 's/ \?\([(){},;]\) \?/\1/g
Strictly speaking, this is overzealous (e.g. it also operates inside
strings), and I didn't even test it, but it will probably work for
almost all cases. The current main CSS file of dlang.org (style.css)
shrinks from 14757 to 11720 bytes, a reduction of ~21%.
But even writing a compressor in D should be trivial, as you'd only need
a lexer.
Would be a nice tools/ thing. Wanna do it/ --- Andrei
Re: css minification
On Friday, 16 January 2015 at 17:40:40 UTC, 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? Andrei I have taken a look at http://dlang.org and assessed some of the improvements to be made. I will probably step on someones toes, sorry, but that is just because I have big feet. A lot of people have already said this, but minification is the last thing on the list. My browser needs to parse 299kb to display the page. Javascript alone takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery and 33kb is widget.js. That widget.js thing is probably because of the twitter stream on the right. A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@#, try zepto. But codemirror-compressed.js and run.js are by far the worst contenders and should be addressed as first. You can bring down loading times to half (yes, you read that correctly, you can cut 150kb). Besides, do you really need 100+kb of codemirror JS? What is it even doing? Even if you really need it, why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. These are the files that are referenced by http://dlang.org and are not using caching (nor compression!): dlang.org/ codemirror.css style.css print.css codemirror-compressed.js run-main-website.js run.js search-left.gif search-button.gif dlogo.png gradient-red.jpg search-bg.gif Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. At the end of the day, watching `mb-downloaded per resource per total` tells you nothing. What only matter is the time it takes for users to enter `http://dlang.org` in the browser, up until the time they get to see something they can click on. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. OT: And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right?
Re: css minification
On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. Great. You forgot to link to your pull request :o). Wait, one step back. I was still in assessment mode. I haven't committed to doing anything. jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@#, try zepto. I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. Well, then they should use http://zeptojs.com/ why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. I do not know the obscure reasons, but it should be as simple as: nano /etc/apache2/mods-enabled/deflate.conf IfModule mod_deflate.c # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javacript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/json /IfModule I know I am imposing on somebodies else's work here, but compressing resources should really be done. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. Where should these be cached? I don't understand. In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference. True. If you can get a 4% difference by minimizing CSS, just do it. I am just saying you can do a lot better. Plus, I think with all the expertise around here, most of us who do web development, did this at one stage or the other. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. Then do it. regex to select comments: /(\/\*[^(*\/)]+\*\/)/g regex to select whitespace: /(\s+)/g and then delete those. I know css minimizers do more, but if comments and whitespace is your issue, this does the trick. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. Then improve it. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. The choice is very simple: keep it like it is, do what everybody else is doing
Re: css minification
On 1/17/15 12:00 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. Well, then they should use http://zeptojs.com/ Of course. :o) why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. I do not know the obscure reasons, but it should be as simple as: nano /etc/apache2/mods-enabled/deflate.conf IfModule mod_deflate.c # these are known to be safe with MSIE 6 AddOutputFilterByType DEFLATE text/html text/plain text/xml # everything else may cause problems with MSIE 6 AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javacript application/ecmascript AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/json /IfModule I know I am imposing on somebodies else's work here, but compressing resources should really be done. Forwarded to our webmaster, thanks. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. Where should these be cached? I don't understand. In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. How do we improve that on our side? Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. Awesome. Don't forget you said this. regex to select comments: /(\/\*[^(*\/)]+\*\/)/g regex to select whitespace: /(\s+)/g and then delete those. Tested PR or by the end of the day this will slide into obsolescence. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. It's clear that once in a while we need to change the design just because it's old. Also, there are a few VERY obvious design improvements that need be done and would be accepted in a heartbeat, but NOBODY is doing them. I'm not an expert in design but I can tell within a second whether I like one. Yet no PR is coming for improving the design. The choice is very simple: keep it like it is, do what everybody else is doing False choice. Andrei
Re: css minification
On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: On Friday, 16 January 2015 at 17:40:40 UTC, 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? Andrei I have taken a look at http://dlang.org and assessed some of the improvements to be made. I will probably step on someones toes, sorry, but that is just because I have big feet. Fantastic. A lot of people have already said this, but minification is the last thing on the list. Measurements contradict that. Anyhow my point was one line of code reduces all site traffic by 5% - they call that a good day. My browser needs to parse 299kb to display the page. Javascript alone takes up 210kb of that. 131kb of that is uncompressed. 33kb is jQuery and 33kb is widget.js. That widget.js thing is probably because of the twitter stream on the right. A seasoned JS programmer can rewrite that stuff in about 6kb, if not less. Great. You forgot to link to your pull request :o). jQuery is the enabler of all bad habits; best to remove it quickly, if only because of principles. If you really got addicted to that horse*@#, try zepto. I'm not an expert or an ideologist in the area. It was added by others who obviously have a different opinion from yours. But codemirror-compressed.js and run.js are by far the worst contenders and should be addressed as first. You can bring down loading times to half (yes, you read that correctly, you can cut 150kb). Besides, do you really need 100+kb of codemirror JS? What is it even doing? Even if you really need it, why not compress the thing? It takes around 4 lines in apache conf to accomplish this. Give me SSH access and I'll do it in under 2 min. I'm working with our webmaster to create accounts for a few folks. For now you may want to send me what needs to be done and I'll take it with him. N.B. I vaguely recall I've tried that once but it was not possible for obscure reasons. Caching is the next trick in the list. Remember that ISP's, proxy, etc. may also cache your files, not just browsers. These are the files that are referenced by http://dlang.org and are not using caching (nor compression!): dlang.org/ codemirror.css style.css print.css codemirror-compressed.js run-main-website.js run.js search-left.gif search-button.gif dlogo.png gradient-red.jpg search-bg.gif Where should these be cached? I don't understand. Next point on the list is bundling resources. The browser can only load some much stuff async. If you have too much, part of those resource are going to be blocked. Which basically means you have another round-trip + data that you have to wait for. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? While there are some other optimizations to be made - like putting that twitter stream js at the bottom of the page - the point is this: If I wanted to optimize this website, minifying style.css would be the last thing on my list. Yah, the problem is everything on your list is hypothetical and not done, whereas css minimization is actual and done. Big difference. Very big difference. Besides, minimizing CSS is tantamount to removing comments and whitespace. Like Adam Ruppe said, a regex program in D can accomplish that; no need to use a online service. It probably takes you more time to integrate the online service than to write the D program including the regex. Then do it. At the end of the day, watching `mb-downloaded per resource per total` tells you nothing. What only matter is the time it takes for users to enter `http://dlang.org` in the browser, up until the time they get to see something they can click on. Agreed. Being among this group of knowledgeable programmers it amazes me this site is still pre 2000. I for one, am required to use Lynx just because my eyes can't stand the design. Then improve it. OT: And lets be honest here, why the hell do we even use apache+php and not D+vibe.d? I just rewrote my companies corporate website in under 4 hours. Granted, it is a simple one. But this community should be able to rewrite this site in D in under a week, right? I wish. Andrei
Re: css minification
On Sat, Jan 17, 2015 at 12:52:29PM -0800, Andrei Alexandrescu via Digitalmars-d wrote: I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei +1 for dogfooding! T -- Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.
Re: css minification
I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei
Re: css minification
On second thought this way works better: http://stackoverflow.com/questions/7509501/how-to-configure-mod-deflate-to-serve-gzipped-assets-prepared-with-assetsprecom though that's some ugly configuration, I hate apache. But I just tested that locally and it all worked from a variety of user agents. All I had to do was gzip the file and also keep a copy of the uncompressed version to server to the (very few btw... but popular - curl, by default, is one of them) UAs that don't handle receiving gzipped info.
Re: css minification
On Saturday, 17 January 2015 at 20:17:51 UTC, Andrei Alexandrescu wrote: On 1/17/15 12:00 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 18:23:45 UTC, Andrei Alexandrescu wrote: On 1/17/15 10:01 AM, Sebastiaan Koppe wrote: In the browser. So that on a reload of the page, the browser, instead of making HTTP calls, uses it's cache. How do we improve that on our side? 2 things: a) Set the proper cache headers in the http response. b) Have a way to bust the cache if you have a new version of an resource. If you have both in-place, you can set the expires header to 1 year in the future. Then bust the cache every time you have a new version of the file. Yah, we do a bunch of that stuff on facebook.com. It's significant work. Wanna have at it? Yes. Please. But the compression thing takes precedence. Awesome. Don't forget you said this. I won't. Design is a *very* touchy issue. It is basically a matter of choice. Without a definite choice made, I won't waste my time improving it. It's clear that once in a while we need to change the design just because it's old. Also, there are a few VERY obvious design improvements that need be done and would be accepted in a heartbeat, but NOBODY is doing them. If I may suggest, I would split up the site into a couple of sections. One for Introduction/About, one for Docs/Api, one for Blogs, one for Community/Forum. Which is basically what everybody else is doing. Just some random sites: http://facebook.github.io/react/ https://www.dartlang.org/ I'm not an expert in design but I can tell within a second whether I like one. Yet no PR is coming for improving the design. Then why not just make a list of sites that we like. And then design this site like those. It is what all the designers are doing.
Re: css minification
On Sunday, 18 January 2015 at 02:11:13 UTC, Andrei Alexandrescu
wrote:
Who's you? :o) -- Andrei
I'd do it myself, but after spending 30 minutes tonight trying
and failing to get the website to build on my computer again
tonight, I'm out of time.
It really isn't hard though with access to the html and .htaccess
or something.
I just slapped this on my this-week-in-d local thingy:
.htaccess:
RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} \b(x-)?gzip\b
RewriteCond %{REQUEST_FILENAME}.gz -s
RewriteRule ^(.+) $1.gz [L]
FilesMatch \.css\.gz$
ForceType text/css
Header set Content-Encoding gzip
/FilesMatch
FilesMatch \.js\.gz$
ForceType text/javascript
Header set Content-Encoding gzip
/FilesMatch
FilesMatch \.rss\.gz$
ForceType application/rss+xml
Header set Content-Encoding gzip
/FilesMatch
ExpiresActive on
ExpiresDefault access plus 1 days
Then ran
$ for i in *.html *.css *.rss *.js; do gzip $i; zcat $i.gz
$i; done;
(gzip replaces the original file so i just uncompressed it again
after zipping with zcat. idk if there's a better way, the man
page didn't give a quick answer so i just did it his way)
and the headers look good now. So like if that can be done on
dlang.org too it should hopefully do the trick.
Re: css minification
On 1/17/15 11:23 PM, Sebastiaan Koppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? Not quite getting the logic there. -- Andrei
Re: css minification
On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Doing it on demand might be a mistake here, but we can also pre-compress the files since it is a static site. You just run gzip on the files then serve them up with the proper headers. here's a thing about doing it in apache http://stackoverflow.com/questions/75482/how-can-i-pre-compress-files-with-mod-deflate-in-apache-2-x Also, how would this work if we switch to vibe.d? -- Andrei I don't know about vibe, but it is trivially simple in HTTP, so if it isn't supported there, it is probably a three (ish) line change. Caching is the same deal btw, just set the right header and you'll get a huge improvement. Cache-control: max-age=36000 will cache it for ten hours, without even needing to change the urls. (Changing urls is nice because you can set it to cache forever and still get instantly visible updates to the user by changing the url, but we'd probably be fine with a cache update lag and it is simpler that way.) ETags are set right now and that does some caching, it could be improved further by adding the max-age bit tho. This is an apache config of some sort too. http://stackoverflow.com/questions/16750757/apache-set-max-age-or-expires-in-htaccess-for-directory though I don't agree it should be one year unless we're using different urls, we should do hours or days, but that's how it is done.
Re: css minification
On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: I know I am imposing on somebodies else's work here, but compressing resources should really be done. Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Also, how would this work if we switch to vibe.d? -- Andrei If you do not have spare horsepower for compression, how will you handle twice the load? I have used vibe.d to fetch gzipped resources, it has all the deflateinflate stuff, so delivering gzipped resources should be easy as flipping a switch.
Re: css minification
On 1/17/15 4:22 PM, Adam D. Ruppe wrote: On Saturday, 17 January 2015 at 20:52:28 UTC, Andrei Alexandrescu wrote: Our webmaster got back. He said compression is more CPU work and on a fat pipe (which we do have) that may make things actually worse. Doing it on demand might be a mistake here, but we can also pre-compress the files since it is a static site. You just run gzip on the files then serve them up with the proper headers. Who's you? :o) -- Andrei
Re: css minification
On Friday, 16 January 2015 at 17:40:40 UTC, 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? I would advise against this. If added, it should be opt-in. I see the following issues: - The service in question might be occasionally down, or might be shut down completely at some point. This makes it an additional point of failure. - High website load or poor Internet speeds will increase the time needed to build the website. - We can't know for sure that at some point the owners of cssminifier.com won't decide to inject evil code in the output. Even if you trust the owners, the service might get hacked with the same outcome. - As the request goes over HTTP, you also need to trust every peer between your machine and the website to not perform a MITM attack. I think relying on a random 3rd-party service is acceptable for an amateur or hobbyist website, which we are not. Instead, I suggest adding an optional (opt-in) rule which invokes an offline CSS minifier.
Re: css minification
On 1/16/15 9:58 AM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 17:40:40 UTC, 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? I would advise against this. If added, it should be opt-in. Thanks for the feedback. I see the following issues: - The service in question might be occasionally down, or might be shut down completely at some point. This makes it an additional point of failure. To counter that I was thinking of: curl -X POST -s --data-urlencode 'input@$' http://cssminifier.com/raw $@ || cp $ $@ This is nice modulo possible delays due to slow timeouts. I should also add that we already connect online to fetch LATEST from github. Incidentally today that takes forever :o). - High website load or poor Internet speeds will increase the time needed to build the website. Actually that's not the case in my experience. Did you build the site recently, i.e. with dub in tow? Build time is dominated by running dub, and it's impossible to run it on only the modified portions of the site. make -j on my laptop takes one full minute without doing anything online. Running a few curls in parallel with that have plenty of time to finish. Then dub generates 286 MB worth of stuff, which takes a long time to rsync. (For perspective: the pre-dub site, images and all, was 19 MB.) I'm not sure whether rsync gets further confused by the necessity of wiping all files and generating them again, whether they're identical or not. I confess I'm unhappy with dub. I was hoping for a turnkey solution that also opens up new possibilities. Sadly it adds its own problems, and those it solves I know how to do simpler with ddoc and tooling around it. As things are, I found myself with another project in my lap that I need to babysit. - We can't know for sure that at some point the owners of cssminifier.com won't decide to inject evil code in the output. Even if you trust the owners, the service might get hacked with the same outcome. Good point. We could, of course, store the converted css and inspect it before uploading, but seems a bit like meteor insurance to me. - As the request goes over HTTP, you also need to trust every peer between your machine and the website to not perform a MITM attack. I think relying on a random 3rd-party service is acceptable for an amateur or hobbyist website, which we are not. Instead, I suggest adding an optional (opt-in) rule which invokes an offline CSS minifier. That's a rather dim view of online services :o). What would be a trustworty offline CSS minifier? Overall I'm unconvinced of your arguments and I think we should move forward with https://github.com/D-Programming-Language/dlang.org/pull/770 or a variation thereof. Andrei
Re: css minification
On 1/16/15 9:58 AM, Vladimir Panteleev wrote: [snip] Just made css minification opt-in. -- Andrei
Re: css minification
On Fri, Jan 16, 2015 at 10:37:38AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/16/15 9:58 AM, Vladimir Panteleev wrote: [snip] Just made css minification opt-in. -- Andrei Thanks!! T -- Maybe is a strange word. When mom or dad says it it means yes, but when my big brothers say it it means no! -- PJ jr.
Re: css minification
On Fri, Jan 16, 2015 at 10:16:55AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/16/15 9:58 AM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 17:40:40 UTC, 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? I would advise against this. If added, it should be opt-in. [...] I also advise against this. I do run documentation builds a lot when working on PRs -- to verify the generated docs are satisfactory, for example. Sometimes I work on PRs when I don't have a network connection. It would really, *really* suck if I can't do any useful work unless I have a stable connection. (Not to mention, sometimes I have to work behind firewalls, which can make otherwise reliable internet hosts unreliable.) Please make this opt-in. Otherwise I will really lose a lot of motivation to work on docs. It's already bad enough that the dlang.org repo depends on all sorts of external tools, like kindle, latex, etc., most of which I don't (immediately) care about. Fortunately, the 'html' target of the makefile allows me to successfully generate the HTML docs without installing all sorts of software that I otherwise never use. If you feel absolutely compelled to use an online minifier, can you at least make it possible to build the docs *without* it? And I mean a dedicated build target that bypasses that step completely; half-hearted hacks like waiting for the connection to timeout is not a viable option because it would just slow things down to the point I would probably just give up and throw away any doc contributions. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Re: css minification
On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: What would be a trustworty offline CSS minifier? http://yui.github.io/yuicompressor/ Its only dependency is Java. Usage: java -jar yuicompressor-*.jar --type css input.css output.css
Re: css minification
On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: I should also add that we already connect online to fetch LATEST from github. Incidentally today that takes forever :o). We (and a lot of other people) already trust GitHub. Also, GitHub is HTTPS-only. That's a rather dim view of online services :o). This is not so much about online services in general, but more about online services created by some random guy which process code that will end up on our website. If the website was created by a generally trusted organization, transferred data securely, and/or operated on e.g. plain text, then some of my points would not apply. What would be a trustworty offline CSS minifier? FWIW, YUI compressor is what I use for DFeed.
Re: css minification
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
Re: css minification
On 1/16/15 10:40 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Jan 16, 2015 at 10:37:38AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/16/15 9:58 AM, Vladimir Panteleev wrote: [snip] Just made css minification opt-in. -- Andrei Thanks!! Glad it works for you. Vladimir, is opt-in okay with you as a first step toward a more secure solution? -- Andrei
Re: css minification
On Friday, 16 January 2015 at 20:40:29 UTC, Andrei Alexandrescu wrote: On 1/16/15 10:40 AM, H. S. Teoh via Digitalmars-d wrote: On Fri, Jan 16, 2015 at 10:37:38AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/16/15 9:58 AM, Vladimir Panteleev wrote: [snip] Just made css minification opt-in. -- Andrei Thanks!! Glad it works for you. Vladimir, is opt-in okay with you as a first step toward a more secure solution? -- Andrei I do not build the documentation often, so my post was an attempt at advice from experience rather than an objection based on personal motives. Generally, and as I mentioned at the top of my post, I think opt-in is acceptable, as the default no longer has risks of security or unexpected failure.
Re: css minification
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
Re: css minification
On 1/16/15 12:27 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: What would be a trustworty offline CSS minifier? http://yui.github.io/yuicompressor/ Its only dependency is Java. Usage: java -jar yuicompressor-*.jar --type css input.css output.css $ java No Java runtime present, requesting install. $ _ Andrei
Re: css minification
On Friday, 16 January 2015 at 20:51:34 UTC, Andrei Alexandrescu wrote: On 1/16/15 12:27 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: What would be a trustworty offline CSS minifier? http://yui.github.io/yuicompressor/ Its only dependency is Java. Usage: java -jar yuicompressor-*.jar --type css input.css output.css $ java No Java runtime present, requesting install. $ _ No idea what that means. Google says it's a Mac problem. I am neither a Java nor Mac person, sorry.
Re: css minification
On 1/16/15 12:56 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 20:51:34 UTC, Andrei Alexandrescu wrote: On 1/16/15 12:27 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: What would be a trustworty offline CSS minifier? http://yui.github.io/yuicompressor/ Its only dependency is Java. Usage: java -jar yuicompressor-*.jar --type css input.css output.css $ java No Java runtime present, requesting install. $ _ No idea what that means. Google says it's a Mac problem. I am neither a Java nor Mac person, sorry. That's why online services rok. Anyone knows of a secure css minimizing service? -- Andrei
Re: css minification
On Friday, 16 January 2015 at 21:04:58 UTC, Andrei Alexandrescu wrote: On 1/16/15 12:56 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 20:51:34 UTC, Andrei Alexandrescu wrote: On 1/16/15 12:27 PM, Vladimir Panteleev wrote: On Friday, 16 January 2015 at 18:16:55 UTC, Andrei Alexandrescu wrote: What would be a trustworty offline CSS minifier? http://yui.github.io/yuicompressor/ Its only dependency is Java. Usage: java -jar yuicompressor-*.jar --type css input.css output.css $ java No Java runtime present, requesting install. $ _ No idea what that means. Google says it's a Mac problem. I am neither a Java nor Mac person, sorry. That's why online services rok. Anyone knows of a secure css minimizing service? -- Andrei I could put one up in a few minutes. But I think it'd be better if it was on dlang.org's servers. Now... does the server have Java installed? ;)
Re: css minification
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? -Steve
Re: css minification
On Friday, 16 January 2015 at 21:04:58 UTC, Andrei Alexandrescu
wrote:
That's why online services rok. Anyone knows of a secure css
minimizing service? -- Andrei
Minification in general is of dubious value, but doubly so with
css, it barely makes a difference compared to gzip and client
side caching.
If comments are a problem, just write a little regex thingy to
strip them out. You could do the same to leading and trailing
whitespace on a line, though that's really negligible too.
Or, you could use something like my css macro expand which
transforms css in a useful way and strips out comments in the
process.
.foo {
.nesting-supported-with-css-expand {
}
}
http://code.dlang.org/packages/cssexpand
Re: css minification
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. 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. Andrei
Re: css minification
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.
Re: css minification
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
Re: css minification
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
Re: css minification
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
Re: css minification
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.
Re: css minification
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
Re: css minification
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
Re: css minification
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
Re: css minification
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
Re: css minification
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 Uncompressed16028 11959 gzip -9 4252 3194 Looks closer to 25%, but same ballpark.
Re: css minification
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
Re: css minification
On 1/16/15 2:17 PM, 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. No, I didn't do any compression. Please do it and beat me over the head with your pull request. -- Andrei
Re: css minification
On 1/16/15 5:23 PM, Andrei Alexandrescu wrote: 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. At the cost of adding dependencies for builds, and requiring builds be done with Internet access. I don't think it's out of line to ask that if we are going to add extra build requirements, we should make sure it's really making decent progress. 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 think you misunderstand. We are not saying do a research project, it takes seconds to gzip 2 files (the minified and not minified) and see the size difference. If it's super-significant, let's go for it! If you send me the minified file, I can test it for you. There doesn't need to be any research, but all the suggestions that have been provided have NOT required extra tools or dependencies. That is a significant difference. -Steve
Re: css minification
On 1/16/15 2:26 PM, Vladimir Panteleev wrote: 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 Uncompressed16028 11959 gzip -9 4252 3194 Looks closer to 25%, but same ballpark. So then the two optimizations don't compete. I hate it when I'm right :o). -- Andrei
Re: css minification
On 1/16/15 5:30 PM, Andrei Alexandrescu wrote: On 1/16/15 2:26 PM, Vladimir Panteleev wrote: 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 Uncompressed16028 11959 gzip -9 4252 3194 Looks closer to 25%, but same ballpark. So then the two optimizations don't compete. I hate it when I'm right :o). -- Andrei If the CSS isn't frequently changing, a 4kb file should not comprise 5% of all traffic if caching is enabled. I certainly think this is well worth the optimization, though, 25% is a good improvement. -Steve
Re: css minification
On 1/16/15 2:32 PM, Steven Schveighoffer wrote: I think you misunderstand. We are not saying do a research project, it takes seconds to gzip 2 files (the minified and not minified) and see the size difference. If it's super-significant, let's go for it! If you send me the minified file, I can test it for you. There doesn't need to be any research, but all the suggestions that have been provided have NOT required extra tools or dependencies. That is a significant difference. The more involved part is figuring out what support is out there for compressed transfers, configuring the site, etc. --- Andrei
Re: css minification
On 1/16/15 2:35 PM, Steven Schveighoffer wrote: If the CSS isn't frequently changing, a 4kb file should not comprise 5% of all traffic if caching is enabled. May be a sign we have lots of new visitors :o). -- Andrei
Re: css minification
On 1/16/15 5:58 PM, Andrei Alexandrescu wrote: On 1/16/15 2:32 PM, Steven Schveighoffer wrote: I think you misunderstand. We are not saying do a research project, it takes seconds to gzip 2 files (the minified and not minified) and see the size difference. If it's super-significant, let's go for it! If you send me the minified file, I can test it for you. There doesn't need to be any research, but all the suggestions that have been provided have NOT required extra tools or dependencies. That is a significant difference. The more involved part is figuring out what support is out there for compressed transfers, configuring the site, etc. --- Andrei Right, I understand. I'm not in a position to actually make those changes or support those servers, so I'll shut up. I was just saying my experience with what works and what doesn't with optimizing web traffic. -Steve
Re: css minification
On 17/01/2015 6:40 a.m., 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? Andrei For reference, Cmsed has a port of a css/javascript minifier. Feel free to extract it (its a subpackage so pretty easy). In fact I believe its one file.
Re: css minification
On 1/16/15 6:39 PM, Rikki Cattermole wrote: On 17/01/2015 6:40 a.m., 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? Andrei For reference, Cmsed has a port of a css/javascript minifier. Feel free to extract it (its a subpackage so pretty easy). In fact I believe its one file. Just googled it. For further reading: https://github.com/rikkimax/Cmsed -Steve
