Open hostz-frank opened 1 year ago
nico-martin
commented
1 year ago Hi Frank
Git-installer won't send any data to the client if not in WP-Admin interface. So not logged in users won't load any data from the plugin.
Therefore I am not quite sure what to improve to close this issue. Do you have some concrete suggestions? Performance is really an important issue and I certainly don't want git-installer to slow down a website.
hostz-frank
commented
1 year ago Hi Nico,
I really appreciate that you are taking my concerns serious. Thank you for this.
Speed is not only about reducing the amount of data sent over the Internet. It's also about reducing server response time, which will increased by every plugin you have installed, because a script language like PHP takes time to evaluate, compile and execute. I'm talking about non-cached page requests.
For visualisation are plugins out there like "Query Monitor" and/or "Code Profiler" to finally realise that every plugin adds up time to page calls - especcially when code is not organised due to the context where it's needed.
E. g. settings page code is only needed on the settings page, literally nowhere else. So why should it be loaded on all admin pages and even on the front end? Why should the plugin even run at all on the front end, why at all for non-admins who return false by the current_user_can( 'manage_options' ) function?
I know that WP itself is doing too many update checks when admins make frequent requests inside the admin area - with the effect of slowing down admin work tremendously when you have 4 or 5 premium plugins installed which check their separate sources all the way. Those checks run again and again after a few minutes when you're doing intense configuration work.
That means that even hooking into the usual WP amount of updates with another source to load from will harm at least admin work.
I've seen that you load all your plugin files unconditionally. 2 impacts: this enlarges load times of all the pages and even ajax requests on the front end. It also makes a dance with WP's too many update requests when admins do actively their work.
I have no detailed ideas at the moment in how to refactor a plugin like yours that loads like all the others "everything everywhere" (except CSS and JS which is a great exception!) but I know the effects of plugins with their update routines. Usually you spare several seconds on each request if you restrict those external background requests via WP hooks to run only in certain contexts like on the update page and maybe on the plugin page (where otherwise checks are executed insanely often).
Thank you for your time reading this.
The best, Frank
Nico Martin @.***> schrieb am So., 27. Nov. 2022, 05:53:
Hi Frank
Git-installer won't send any data to the client if not in WP-Admin interface. So not logged in users won't load any data from the plugin.
Therefore I am not quite sure what to improve to close this issue. Do you have some concrete suggestions? Performance is really an important issue and I certainly don't want git-installer to slow down a website.
— Reply to this email directly, view it on GitHub https://github.com/SayHelloGmbH/git-installer/issues/36#issuecomment-1328177387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABOUH3ARTUWVA7BQNMXCR6LWKLZNVANCNFSM6AAAAAASMD5TEI . You are receiving this because you authored the thread.Message ID: @.***>
Would love to see your plugin loading it's code only when necessary.
I know that it is common WP worst practice to load everything everywhere at any time. But I feel this pattern is shifting slowly to the better, for performance reasons which get more and more attention.
So why include all the project's files in general in any load situation? The more plugins do so the worse the dynamic speed of the whole site. An example: Why should an authenticated user who is not an admin load your plugin at all?
So my wish for any plugin I install (even WP itself) would be to see it loading depending on context.
BTW - the plugin has been mentioned here today: https://wp-sofa.de/news-divi-macht-sich-zukunftsfaehig-ein-bisschen-fediverse-google-fonts/ (see topic no. 12)