options – Optimizing WP: Questions about get_options(); and autoload-feature
I’m currently trying to optimize my WP-page.
I checked with “Query Monitor” and I see a lot of options which are fetched on every pageload (not a huge runtime cumulated, but still ~15-20 get_options SQL calls logged by Query Monitor) – would it make sense to just set those specific identified options to “autoload” if I see them in every pageload – and is it safe to do, or will maybe the corresponding plugin override this to “autoload=no” again in future? And if the latter could be the case – how to deal with such things – I mean, maybe the plugin developer has not thought of the implications and just implemented it the way he has, how can I “safely” (i.e. sustainably) change the way it behaves?
And second question:
Is there no mechanism which purges old options from the DB?
I tried a few plugins in the past and I found out that there are a few pretty long option strings which are set to autoload but IMHO not used at all – as I’m not using those plugins anymore.
So I guess it makes sense to remove those options completely – but I’m not 100% sure whether I miss some implications? Am I mistaken, or this the unfortunate result of bad plugins which really needs individual optimization every now and than?
And I’m just trying to think of a good methodology, e.g. by logging, to find options which are fetched on a regular basis (i.e. on every pageload or similarly) which are NOT set to autoload yet. Maybe implement a temporary logging of get_option SQL calls and count, how often it occurs. Than set those to autoload. Anyone seen a code which does it already – hence to not reinvent the wheel?
Leave an answer