On Dec 18, 2014, at 9:56 AM, Stephan Beal <sgb...@googlemail.com> wrote:
> On Thu, Dec 18, 2014 at 5:47 PM, Richard Hipp <d...@sqlite.org> wrote:
> much time was required to generate the page on the server. I'm interested to
> know how much time was used to generate some of your multi-megabyte /tree
> pages.
>
> i'd be interested to know what those megs are - maybe we can consolidate
> symbols, optimize HTML, shorten CSS names, or some such to cut that down.
YSlow and PageSpeed give the current tree view pretty high marks.
The biggest thing I expected to find missing — and was surprised to find that
it is not — is gzip compression on the HTTP layer. That alone will help
tremendously with multi-MB pages. I wonder if the person reporting that is
counting the on-the-wire size or the uncompressed size.
PageSpeed reports that Fossil isn’t minifying the skin CSS. Little wonder,
since it offers an inline editor for the raw CSS. Nevertheless, it would be
good if Fossil created a minified shadow copy of it and served that instead.
YSlow gives a confusing report about favicon.ico not having an Expires header,
but what it really means is that Fossil doesn’t provide a favicon.ico, so the
browser wastes time trying to fetch it on every page load. If Fossil were to
serve such a file along with a far-future Expires header, it would prevent the
browser from repeatedly trying, speeding page loads. (Yes, you must serve more
content to make things faster. Welcome to the modern Internet.) It should be
part of the skinning mechanism, of course.
Other than that, Fossil’s generated tree-view HTML looks pretty good to me. (I
speak as a professional web app developer.) It has little unnecessary
whitespace, and I found no inline styling; Fossil is delegating all styling to
CSS, as far as I can see.
The generated HTML is highly redundant in its form, but gzip takes care of
that. I see roughly 3:1 compression on the largest single directory under
Fossil’s control here.
The only thing that could be a bit better is that the inline JS could be
minified, but that is notoriously difficult to do in an automated fashion.
I’ve used JSMin and YUI Compressor for this in my own web apps; it is not
something you want to try and roll by hand.
…says he to the one who rolled his own RDBMS, parser generator, and DVCS. :)
Annnnyway, if you do add JS minification to Fossil, it should be part of the
build process for Fossil, rather than something it does on the fly.
JSMin has a very “Fossil” sort of feel to it: single C source file, with no
external dependencies other than a C compiler. It doesn’t even ship with a
Makefile! It’s under a BSDish license, so it could be put into the Fossil
source tree and used during the build process.
http://www.crockford.com/javascript/jsmin.html
I used JSMin successfully for years. I only switched to YUI Compressor
recently because I wanted CSS minification. Also, JSMin would occasionally do
the wrong thing with certain very large 3rd party JS libraries, particularly
when concatenated with *other* very large 3rd party JS libraries, in order to
reduce the number of HTTP round trips. Fossil doesn’t have either of these
problems.
Besides that, YUI Compressor isn’t suited to the nature of Fossil: it ships as
a ¾ MB JAR file.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
