Viewing 5 replies - 1 through 5 (of 5 total)
  • In my plugin settings when I test, it says it’s fine.

    Where did you see this? As far as I know WPSC doesn’t add anything in terms of browser caching.

    However, if your site is on a Apache server, you can easily take care of that by adding some lines to your .htaccess file. See this or many other instructions/suggestions.

    After you’ve done this, go to webpagetest.org and test a couple of your pages. On the results page click on ‘Cache Static Content’ to see the relevant details.

    Thread Starter eyedia

    (@eyedia)

    Where did you see this? As far as I know WPSC doesn’t add anything in terms of browser caching.

    What do you mean? The plugin is built to cache your site? What are you using it for? Isn’t the point of the plugin to write the code for you and add it in your .htaccess file (among other places)

    It is meant to do server-side caching (as most caching plugins do). (Page is cached/prebuilt on the server.)

    Browser caching is client-side caching. (Page is cached in the visitor’s browser.)

    To allow browser caching you have to send the appropriate headers to the visitor’s browser. (See the links in my previous post). But in the end it’s always up to the visitor, e.g. the visitor’s browser setting, if your pages are effectively cached in the browser.

    BTW, there are some caching plugins out there that also write the necessary lines (for browser caching) to your .htaccess file. But usually it’s not worth the bloat, as you can easily paste these 20 lines to the .htaccess yourself.

    Tom

    Thread Starter eyedia

    (@eyedia)

    Awesome! Thanks for the lesson Tom! I guess this is why I am confused.
    So if I add the lines in my .htaccess, and I then change something, how would I ensure someone is getting the new version? I am often updating the site so I want to make sure I can set things fresh if I make a big overhaul.
    Thank you again Tom!

    The good thing, if you add the lines yourself, is that you can configure it to your needs.

    If you look at the example from the GTMetrix article you’ll notice that the only things that have a really long expiry are images (1 year). CSS and JS have 1 month, the remaining, e.g. HTML, has just 2 days.

    This makes sense, since (normally) you won’t change your images every week or so.

    But if this seems to long to you, you have basically two possibilities:

    • Set the images for example to 2 weeks or 1 month instead of 1 year, CSS and JS etc. to 1 week, and the default to 1 day.
    • Leave the expires as suggested and take care that updated images have unique URLs, e.g. a new version number in the filename (‘image_blabla-2.png’).

    But I’m anything but an expert with these things, and my own expire settings are object of permanent optimization attempts 😉 So, if you want more than the usually suggested standard expire settings (e.g. the ones from GTMatrix), I strongly recommend to read some articles or forum posts by people who have really founded knowledge!

    PS: Two things:

    • Depending on your site content you may have to add some types that are missing in the standard settings (e.g. ‘image/svg+xml’ for SVGs. Check this on webpagetest.org. Others you can securely remove (Anybody still using shockwave-flash today?!)
    • Your settings won’t affect elements that are remotely loaded, for example from a CDN, or from GoogleFonts, etc.
Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Is it actually working?’ is closed to new replies.