[Plugin: Hackadelic SEO Table Of Contents] Queries on post-view, when there's no TOC included (5 posts)

  1. Gravitydk
    Posted 6 years ago #


    I found that TOC was doing queries on post-view even if there was no TOC shortcode in the post itself. This was shown by using WPDB Profiler. I wanted to reduce any unnecessary queries.

    I presume this is not a problem in general, but out of principle wanted to do whatever I could to reduce CPU load, so have disabled the plugin.


  2. hackadelic
    Posted 6 years ago #

    The plugin needs to first collect the headers of the post before it can display them in a freely positional toc box. Hence it queries the post/page content unconditionally, but only in singular view (when there's only a single post/page shown).

    There is no other way. Even to scan the content for a "[toc]" shortcode first, it would have to query it nonetheless.

    However, the plugin does not do any extra database queries. It processes already retrieved content, so it should not really create any significant overhead in terms of CPU load.

    On the other hand, I see little sense in reducing CPU load by all means, "out of principle". If you have enough CPU power, it would be a waste not to use it. (The opposite extreme is, to reduce CPU load by 100%, you'll have to stop using the computer.) In my experience, today's servers all have plenty of CPU power to cope with a couple of dozens, or hundreds, WP plugins.

  3. Gravitydk
    Posted 6 years ago #

    Thanks Hack. I was just surprised that data wasn't put together in a cron job or when the post was created.

    Reassuring to know the query is so small.
    I had to eliminate CPU because I was overpeaking the shared host. Turns out YARPP and Simple Tags were really culprits though; they had terrible and huge queries.

  4. hackadelic
    Posted 6 years ago #

    "I was just surprised that data wasn't put together in a cron job or when the post was created."

    If the plugin would build the TOC when the post is stored, it would have to store that data somehow. Modifying the post before it is stored is problematic in a whole bunch of ways. Hence it would have to store the data in extra database storage, but then it would have to perform an extra query at post render time to retrieve that data, and that would add to CPU load even more. (Database queries are usually amongst the most expensive in terms of performance).

  5. Gravitydk
    Posted 6 years ago #

    Ah, I knew you were a good coder Hack. That's reassuring. If only the other guys did their part to use the least-CPU method.

Topic Closed

This topic has been closed to new replies.

About this Topic