• Resolved GermanKiwi

    (@germankiwi)


    Hi @awelzel,

    I noticed that you have minimised versions of the .js files that the plugin loads on the front end, but not for the following .css files:

    wp-content/plugins/lightbox-photoswipe/lib/photoswipe.css
    wp-content/plugins/lightbox-photoswipe/lib/skins/SKIN-NAME/skin.css

    Would you consider adding minimised versions of all of the CSS files too, to help with loading speeds?

Viewing 9 replies - 1 through 9 (of 9 total)
  • Thread Starter GermanKiwi

    (@germankiwi)

    And a somewhat related question, if I may:

    I also noticed that the plugin’s .js files are loaded inside the <head> section of the page. Would it not be better for performance if they were loaded in the footer area instead? I’ve heard that the general recommendation is for .js files to load in the footer.

    Plugin Author Arno Welzel

    (@awelzel)

    About minimising CSS files:

    No, there are no plans yet to create minimized version of the CSS files, since these files are very small already and minimizing would only save a few hundred bytes (the CSS is about 17 KB).

    About putting the scripts to the footer:

    The plugin does not decied where to put the scripts itself. I use the official API of WordPress – wp_enqueue_script() – and WordPress decides itself where to put the scripts. If you want to move scripts down to the footer use a plugin which does this for you like https://www.ads-software.com/plugins/scripts-to-footerphp/.

    Also the real benefit is very small. Just see my website – you won’t notice any real performance issue there because of the scripts: https://arnowelzel.de/en/

    Usually if people ask to put scripts to the footer is when they have much too many heavy plugins on their site. Also using pagebuilders like Divi or Elementor often slows things down. In this case you get much better results wich caching plugins instead of just moving scripts to the footer.

    Thread Starter GermanKiwi

    (@germankiwi)

    Hi Arno, thanks for your reply!

    Regarding CSS minimisation: you’re right, the two CSS files are relatively small, but I think minimising them would still help a bit.

    I used https://www.minifier.org to do a test, using the photoswipe.css and skin.css files.

    Together, the two files were 16.6 KB.
    After being minimised, they were 10.7 KB.
    So that’s a reduction of nearly 7 KB.

    Mainly the benefit of minimising them is to help with the scores given by speed test sites such as GTmetrix or Google’s PageSpeed Insights, which a lot of clients consider to be important (and Google’s PageSpeed is also used for ranking on Google). Plus, even 7 KB can make a difference on a slow mobile 3G or 4G connection, for example.

    Would you consider doing this at some point in the future?

    Thread Starter GermanKiwi

    (@germankiwi)

    Regarding JS scripts in the footer: please excuse me, but I must disagree that WordPress decides itself where to put the scripts when you use wp_enqueue_script(). According to the documentation at https://developer.www.ads-software.com/reference/functions/wp_enqueue_script/ it’s up to the plugin developer to make this decision. There is a parameter called $in_footer which lets you put the script in the footer area. Currently your plugin is not using this parameter, which is why your scripts are going in the <head> section instead.

    Google themselves recommend to put JS scripts in the footer if possible. Their PageSpeed tool will flag JS files that are in the <head> section and label them as a “render blocking resource”:
    https://web.dev/render-blocking-resources/

    The reason is because when JS files are in the <head>, it can slow down the rendering of the page:
    https://www.wpbeginner.com/wp-tutorials/how-to-move-javascripts-to-the-bottom-or-footer-in-wordpress/

    Therefore many WordPress optimisation guides and articles recommend to load JS files at the end of the page. (Although for me, the most important reason is that Google themselves recommend this). Yes, having a caching plugin is also helpful too, but the point is that to get the absolute fastest page load speeds – and the best score at GTmetrix or PageSpeed – it’s recommended to optimise everything possible, not to simply use a caching tool and nothing else. Every little thing adds up! ?? And caching plugins are not always possible to use, in every situation.

    Therefore I hope you might reconsider to use the $in_footer parameter with your plugin?

    Plugin Author Arno Welzel

    (@awelzel)

    I’ll consider minimising CSS for future updates.

    Thanks for the hint about wp_enqueue_script() – it seems I’ve overlooked this.

    I created a new issue to fix these issues for the next upate:
    https://github.com/arnowelzel/lightbox-photoswipe/issues/67

    And happy new year 2021! Some of us seem to be busy improving software even now ??

    Thread Starter GermanKiwi

    (@germankiwi)

    Thank you for considering these two things – I appreciate it! ??

    And yes, frohes neues Jahr! Like you, I also live in Germany (although I’m from New Zealand) – but we have an Ausgangsbeschr?nkung here in BW, in addition to the lockdown, so there’s no chance to go out anywhere tonight. ??

    Thanks @germankiwi for asking this, as I was about to attempt this myself. I also would love to these adjustments made.
    And thank you @awelzel for your attention to these issues!
    Looking forward to updates ??

    Plugin Author Arno Welzel

    (@awelzel)

    Release 3.1.4 now uses optimized scripts and styles – only one script in the footer and one CSS file and all images in the skin are contained in the CSS file as well as data-urls.

    Note: since this release also adds support for SCRIPT_DEBUG (see https://www.ads-software.com/support/article/debugging-in-wordpress/), you get the uncompressed original files when enabling script debugging.

    Thread Starter GermanKiwi

    (@germankiwi)

    Thanks so much – greatly appreciated! ??

Viewing 9 replies - 1 through 9 (of 9 total)
  • The topic ‘Minimised CSS files’ is closed to new replies.