• Resolved Daedalon

    (@daedalon)


    I really like the initiative you’re taking with the new performance option that aims to avoid loading CSS and JS on pages where they’re not needed. I think it’s be possible to automate that, not requiring the user to specify the pages on which they’re disabled or enabled. When the automation works properly, it can be set to be on by default.

    The aim would be to enqueue the scripts only if the page calls for those features of Events Manager that would use those CSS or JS files. For example on the creation of a EM_Event(s) or EM_Location(s) object there’d be a call for a function that:

    • checks which CSS and JS files will be needed,
    • whether they’re already enqueued,
    • and if not, enqueues them.

    http://wordpress.org/extend/plugins/events-manager/

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Author Marcus (aka @msykes)

    (@netweblogic)

    This was something I did think extensively about, and came to the conclusion that it’s not possible to do in an efficient manner, will explain briefly why:

    wp_enqueue_… must be done before wp_head, meaning before any content is produced, meaning you have to guess if there’s shortcode, widgets etc. that’ll be produced on the page, meaning you need to generate the page before WP does. I can’t think of an efficient way of doing that without creating unecessary burden on the server.

    you could enqueue stuff at the footer (e.g. like we do with booking forms), but then you can’t use dependencies.

    so… that’s why we have specific bits for you to add pages which will load JS files aside from the usual places we can guess.

    Thread Starter Daedalon

    (@daedalon)

    Ok, good to know, thanks!

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘Performance options for CSS and JS: don't require selecting pages’ is closed to new replies.