diff options
| -rw-r--r-- | doc/todo/css_and_javascript_aggregation.mdwn | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/doc/todo/css_and_javascript_aggregation.mdwn b/doc/todo/css_and_javascript_aggregation.mdwn index 4b3e5f766..7e38f7600 100644 --- a/doc/todo/css_and_javascript_aggregation.mdwn +++ b/doc/todo/css_and_javascript_aggregation.mdwn @@ -1,5 +1,7 @@ One of the goals of using a static site generator like ikiwiki, for me, is not only future-proofing and portability, but also performance. By having a small set of HTML pages with a minimal theme, we can deliver raw content much faster than a traditional CMS. This does not, however, keep us from doing optimizations that those same CMS must do in order to deliver good page performance. +> For the CSS case, this was already proposed at [[todo/concatenating or compiling CSS]] --[[smcv]] + Take, for example, this [performance report of the main ikiwiki site](https://gtmetrix.com/reports/ikiwiki.info/rwUIfK6d). For a very minimal site, it is still making 8 requests and taking ~700ms to load. That's quite fast, but it could probably be cut down to 400ms if CSS and JS were aggregated. If you look at [my homepage](https://gtmetrix.com/reports/anarc.at/uAkMmZaT) the results are worse, because I have larger JS and CSS files: the impact is therefore much bigger and we're looking at 2000ms load times. (Obviously, part of the problem here is the slowness of the uplink here, but one could argue the same problem would occur for downstream users that have a slower connexion.) One of the recommendations "YSlow" is giving is "Make fewer HTTP requests": |