11 Mar
2016
11 Mar
'16
9:47 a.m.
Hi devs and especially Guillaume,
I was creating a subwiki locally and accessing it the first time was taking quite long
(several seconds) and I was wondering why. My guess is that the less cache is indexed on
the wiki id and it had to recompile the LESS files from the flamingo skin for that wiki.
I was wondering why since the compilation will result in the same CSS than the one used
for the main wiki! So it would seem to be some extra work for nothing.
So I was thinking: What about computing a checksum of the file to compile and use that as
the less cache id instead of our current cache id?
Would that work?
Thanks
-Vincent
11 Mar
11 Mar
10:09 a.m.
On Fri, Mar 11, 2016 at 9:47 AM, vincent(a)massol.net <vincent(a)massol.net> wrote:
Hi devs and especially Guillaume,
I was creating a subwiki locally and accessing it the first time was taking quite long
(several seconds) and I was wondering why. My guess is that the less cache is indexed on
the wiki id and it had to recompile the LESS files from the flamingo skin for that wiki.
I was wondering why since the compilation will result in the same CSS than the one used
for the main wiki! So it would seem to be some extra work for nothing.
So I was thinking: What about computing a checksum of the file to compile and use that as
the less cache id instead of our current cache id?
Not sure it's that easy, at least there is several files compiled with
includes between them from what I remember. But Guillaume would know
better what can been done.
Would that work?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
14 Mar
14 Mar
10:47 a.m.
Indeed, there is a lot of incudes. It would need to compute the checksum of
the flamingo theme too, but that is not the hard part.
Since the Flamingo skin, stored on the filesystem, is not supposed to
change (except when Caty and I are working on the skin), maybe it's not
necessary to compute the checksum of that skin (except on upgrades).
Note also that a LESS resource can contains Velocity code, so some parts
can be dynamic (ex: a color which depends on the wiki id).
2016-03-11 10:09 GMT+01:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
On Fri, Mar 11, 2016 at 9:47 AM, vincent(a)massol.net
<vincent(a)massol.net>
wrote:
--
Guillaume Delhumeau (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Hi devs and especially Guillaume,
I was creating a subwiki locally and accessing it the first time was
taking quite
long (several seconds) and I was wondering why. My guess is
that the less cache is indexed on the wiki id and it had to recompile the
LESS files from the flamingo skin for that wiki.
I was wondering why since the compilation will result in the same CSS
than the one
used for the main wiki! So it would seem to be some extra work
for nothing.
So I was thinking: What about computing a checksum of the file to
compile and use
that as the less cache id instead of our current cache id?
Not sure it's that easy, at least there is several files compiled with
includes between them from what I remember. But Guillaume would know
better what can been done.
Would that work?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:01 p.m.
Guillaume Delhumeau wrote:
Note also that a LESS resource can contains Velocity
code, so some parts
can be dynamic (ex: a color which depends on the wiki id).
I've met this claim
on a steady basis since quite some time, e.g. using
the /skin/ URLs, and dare say that this is ruining normal caching based
optimization (e.g. on Apache or CloudFront).
If there's something dynamic in the CSS or JS it should really be
requested separately from the mass (and probably not need LESS).
paul
3161
days inactive
3164
days old
3 comments
4 participants
participants (4)
-
Guillaume Delhumeau -
Paul Libbrecht -
Thomas Mortagne -
vincent＠massol.net