Looking good

  • kwikbreaks

    (@kwikbreaks)


    11 years, 1 month ago

    My host doesn’t support php exec so I don’t get minification although as I have gzip compression enabled I think that would only be of minor benefit. The real benefit I see immediately is the reduction in requests from css and js combination. It would be nice if the developer could find an alternative for others without this functionality.

    so far as can see nothing has been broken which is more than I can say for some other similar plugins. I suspect this one doesn’t mess with inline js and scripting.

    Jury is still out on how the cache grows of course. It is something I will be keeping a careful eye on as the other similar (and highly rated) plugin I tried had issues in this area as well as breaking pages.

    ====

    Update.

    Developer has added a fallback minify function when php exec is not available.

    I see no problems with the cache so far.

    So – still looking good 🙂

Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author launchinteractive

    (@launchinteractive)

    11 years, 1 month ago

    We’ve got some other sites that don’t support exec too. We are investigating some alternatives that we might roll in as replacements or fallbacks. Thanks for the review!

    Thread Starter kwikbreaks

    (@kwikbreaks)

    11 years, 1 month ago

    Cache seems to be reasonable. I have purged all a few times but I think it may be a mistake to do so…

    Since google has moved over to being very hot on mobile friendliness their crawler wants to see all css + js. I’ve seen some 404s from their bot on both this and a previous plugin cached files and my multiscreen entry in adsense is showing a down arrow even though I’ve made no changes that impact responsiveness.

    I think google are crawling pages for keyword ranking etc. then using their cached source to later do the mobile friendly bit. As all those pages will be specifying stuff in cache and if you purge cache then they can’t do the mobile friendly testing.

    Might all be complete rubbish but I won’t be purging my cache unless I see it getting silly and even then I’ll just bin really old items.

    Plugin Author launchinteractive

    (@launchinteractive)

    11 years, 1 month ago

    Thats interesting. As the filename changes when the CSS or JS changes then Google should be pulling the latest each time. I’d be surprised if this isn’t the case.

    Also, we are thinking about saving the last accessed date of a resource so that it will be easy to see stale files in the admin and potentially automatically delete them.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    11 years, 1 month ago

    Yes they should be getting current files for sure which is why I suspected the scenario I mentioned with one bot doing the initial crawl and the rendering engine using the cached crawl bot results.

    Here are some examples…

    66.249.67.6 – – [28/Apr/2015:19:40:00 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.6 – – [28/Apr/2015:19:40:01 +0100] “GET /wp-content/mmr/7de6c2e13d0130a9d9147004ef57a60a-1429818370.js HTTP/1.0” 404 4566 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.150 – – [29/Apr/2015:20:10:21 +0100] “GET /wp-content/mmr/7de6c2e13d0130a9d9147004ef57a60a-1429818370.js HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.6 – – [29/Apr/2015:20:10:23 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.67.150 – – [29/Apr/2015:22:10:14 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1430043995.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    180.76.5.72 – – [30/Apr/2015:12:33:53 +0100] “GET /wp-content/mmr/02b65adfebe230ee649fc28b692c1c27-1429973119.css HTTP/1.0” 404 4567 “-” “Mozilla/5.0 (compatible; Baiduspider/2.0; +http://www.baidu.com/search/spider.html)”

    Same thing with Autoptimise which I stopped using…

    66.249.64.10 – – [12/Apr/2015:13:41:11 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_1def9452184e35355f8bea6938800833.js HTTP/1.0” 404 3431 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.64.10 – – [12/Apr/2015:15:20:14 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_701631908f497308ac278a379c57b69e.js HTTP/1.0” 404 3431 “http://www.kwikbreaks.co.uk/site-1752/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
    66.249.64.14 – – [12/Apr/2015:16:34:25 +0100] “GET /wp-content/cache/autoptimize/js/autoptimize_8202e63df1d5530042d6d0701dd44226.js HTTP/1.0” 404 3431 “http://www.kwikbreaks.co.uk/holmbrook-cumbria/” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

    Plugin Author launchinteractive

    (@launchinteractive)

    11 years, 1 month ago

    Ahh I see now. Currently with MMR when a new CSS or JS file is generated the old file is removed. To minimize 404 errors I could update the plugin to remove the old files after a few days. What do you think?

    Thread Starter kwikbreaks

    (@kwikbreaks)

    11 years, 1 month ago

    Well assuming the behaviour is going to continue it may be worth setting a cron event to erase them say a week later but it does depend on how often they change and how big the cache gets. Wouldn’t it be possible to base the name on the names of the inner files? That way if the detail changed it wouldn’t lead to a new one.

    TBH I thought the 404s came because I purged all the old files after I made a change to the google cookiechoices.js to avoid bitching about tap areas being too close for mobiles and again when there was a plugin update.

    Plugin Author launchinteractive

    (@launchinteractive)

    11 years, 1 month ago

    We are basing the filenames on the inner files. We are hashing it so they don’t become a massive filenames.

    The names of the CSS and JS is in this format:

    enqueued handles – last modified date .css/js

    The modified date ensures the latest file gets output when something has changed in that group of handles. This happens when a change is manually made to the theme files or if say a plugin is updated.

    When you got the 404 errors was that with a pre 1.0 version of the plugin?
    We were removing the un-minified files once the minified files were created. We found that on rare occasions it was possible to load a page and wordpress would output the path to the unminified file then in the background the minification would take place and remove the minified file before the browser had downloaded the file. This might of been what happened to you?

    I think it would be pretty crazy if Google does read from cache. Websites change all the time and they would get 404’s all over the place.

    Plugin Author launchinteractive

    (@launchinteractive)

    11 years, 1 month ago

    BTW. Version 1.1 has just been released which has a fallback when exec not available.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    11 years, 1 month ago

    It don’t think it could have been anything to do with minification because I wasn’t getting any – unless you were doing some name changes despite that.

    Thanks for your new version I’ll give that a try immediately. I can erase the cache on a couple of unimportant sites when I install it and look for future 404s. I’ll leave the existing cache in place on the off chance that google are doing something strange.

    My host must be filtering out stuff from the logs I see because there appears to be a lot of stuff missing – for instance the only /mmr/ references I get are the 404s. The only time I see a .jpg is when accessed by a bot. In other words I see the first access by an IP but the subsequent accesses don’t appear. That means I can only guess at why those 404s occurred.

    ====

    I see from the cache logs that the new version kept the old names and did not minify until after I purged the old logs. That’s maybe in some instructions on the new version I didn’t read or or maybe something you hadn’t anticipated. Anyway I will take my chances on 404s and purge logs post install then visit the site myself to bet the merged and minified files.

    Thread Starter kwikbreaks

    (@kwikbreaks)

    11 years, 1 month ago

    Incidentally I see these 404s in my May AWstats…

    /wp-content/cache/autoptimize/js/autoptimize_2563c81971f88e08f56a96145a24139c.js 1 –
    /wp-content/cache/autoptimize/js/autoptimize_8aaa9603015384ae0a22ef1fe3a81a70.js

    I removed Autoptimize in the middle of April.

    There are others for mmr too.

    All a little strange – certainly there must be some access of filenames cached quite a while back. I recall baidu spider showed one in the logs extract I posted above.

Viewing 10 replies - 1 through 10 (of 10 total)

The topic ‘Looking good’ is closed to new replies.