[1.0.1] Fixed rejection of inline style declarations that had lots of extra space...
[htmlpurifier.git] / SLOW
blob00f372faaa989264b0a4a971d0e7b2a63cf4dfff
2 SLOW
3   also known as the HELP ME LIBRARY IS TOO SLOW MY PAGE TAKE TOO LONG LOAD page
5 HTMLPurifier is a very powerful library.  But with power comes great
6 responsibility, or, at least, longer execution times.  Remember, this
7 library isn't lightly grazing over submitted HTML: it's deconstructing
8 the whole thing, rigorously checking the parts, and then putting it
9 back together.
11 So, if it so turns out that HTMLPurifier is kinda too slow for outbound
12 filtering, you've got a few options:
14 1. Inbound filtering - perform filtering of HTML when it's submitted by the
15 user.  Since the user is already submitting something, an extra half a
16 second tacked on to the load time probably isn't going to be that huge of
17 a problem.  Then, displaying the content is a simple a manner of outputting
18 it directly from your database/filesystem.  The trouble with this method is
19 that your user loses the original text, and when doing edits, will be
20 handling the filtered text.  Of course, maybe that's a good thing.  If you
21 don't mind a little extra complexity, you can try...
23 2. Caching the filtered output - accept the submitted text and put it
24 unaltered into the database, but then also generate a filtered version and
25 stash that in the database.  Serve the filtered version to readers, and the
26 unaltered version to editors.  If need be, you can invalidate the cache and
27 have the cached filtered version be regenerated on the first page view.  Pros?
28 Full data retention.  Cons?  It's more complicated.
30 In short, inbound filtering is almost as simple as outbound filtering, but
31 it has some drawbacks which cannot be fixed unless you save both the original
32 and the filtered versions.
34 There is a third option: profile and optimize HTMLPurifier yourself.  ;-)