Support » Plugin: Fast Velocity Minify » A word of caution

  • Resolved vwondra


    On of our clients installed this plugin 2 days ago. We spend a good part of yesterday tracking down. The hosting server was experiencing high resources usage. Late last night we isolated the issue to a lone IP address from Romania hammering one of the websites on that server. In looking at the time logs this started about the time that Fast Velocity Minify was installed on that site. We have since then blocked that IP and removed the Fast Velocity Minify plugin from that site.

    We suspect that either there was some bad coding in the plugin, or some possible malware hidden in it.

Viewing 1 replies (of 1 total)
  • Plugin Author Raul P.


    This is not true and I am I’m 100% sure that any Romania IP has nothing to do with our plugin. I do not know where you install the plugin, and neither the plugin collects any information about your site.
    Furthermore, I have no servers or any IP addresses in eastern europe.

    a) Plugins on the public repositories, are scanned for malware before being published live. There is zero chance of it containing any, unless your site already had some malware somewhere else. I suggest using wordfence to do a complete scan on your site.

    b) The plugin works without requests to any other server. There is zero information leaving your site through FVM to any server.

    c) FVM needs to download your JS and CSS files in order to merge them. High load can only occur, if you have dynamic css or js code, which will then trigger a request on every pageview.

    This is explained o our faqs:

    And that’s one of the reasons, why we clearly state that the plugin is for developers or advanced users, than can configure it properly. If you don’t understand what it does, I suggest trying a simpler plugin or ask for a developer’s help to setup the plugin.

    d) Because FVM will merge your CSS and JS files, sometimes it needs to use wordpress to request files which cannot open directly from disk. Please make sure that the IP you blocked, is actually not your own server IP (or reverse proxy, or cdn if you use it).

    e) The fact that the high load started at roughly the same time you installed the plugin is irrelevant. If you have access to the logs, you should be able to see exactly which requests are being made, which urls, how many times they are being requested, by whom, and you should be able to trace back the IP to some origin.

    FVM will only make requests to JS or CSS files, using your own server IP and only if, it cannot open those files directly on the disk.

    High load is also explained in our faqs.
    Basically, if you have a css or js file that keeps changing the url on every pageview, FVM will assume it’s a new file and recreate the cache.

    The method is correct.
    Any different code, is different, thus FVM will have to recreate the cache files everytime it sees a different code.

    That being the case… if there is bad coding, it’s somewhere else on your site.
    Styles or javascript code should not be dynamic, as it’s meant to be static.

    You may not notice high load without FVM even with the dynamic css/js code, simply because of the amount of data.
    If you have one line of dynamic code, wordpress only needs to regenerate that one if files are loading separately. But obviously, if you are installing a plugin to merge all files, any small different is going to trigger the whole cache file to be recreated.

    Finally, even if you have no dynamic css or js code, note that FVM will create a cache file for any new requirements it finds. That could be one file per conditional or even per page.

    The first hit cache regeneration is expensive (again it’s explained on our faqs), so if your server is under-powered and you have a lot of traffic, enabling FVM may cause an initial high load while it generates the cache files for each url that requires, different set of css/js files.

    If your classes or js code keep changing names (some plugins generate inline code wrongly, that way, such as some modules on wpbakery)… this is even more visible.

    Note that I am not stating that FVM will cause high load.
    I’ only saying that IF you have a lot of different requirements per page, it needs to generate them (once only) per each difference it sees.
    And IF you have dynamic CSS code or dynamic JS file names, that also trigger a new cache generation, because practically, it’s brand new code in every pageview (use page caching).

    If you have a well built website, without dynamic classes or js code, or if the request per page hardly change, then FVM will only generate a few cache files and use them for all pages that match that usage (it’s very efficient in that sense).
    It also uses static files, instead of PHP to serve the generated files, and those files are only created once, not always (unless you have dynamic code, a explained).

    Again, make sure you are an advanced user or a developer before using the plugin, or test it properly on a staging version, before implementing it on a live site.

    Speed optimization is not as easy as to install a plugin.
    You have the tools, but you need to know how to use it.

    There is absolutely, zero possibility of any Romania or any other IP which is not your own server or under your network architecture, remotely causing high load related to our plugin.

    If that IP was causing high load, make sure to track down what exactly was it doing and check it’s useragent (could be a scrapper, bot, etc).

    Also please make sure you understand what FVM does and how it works, before implying here, that we are using some sort of malware to try to hack you server, or that we are in any way affiliated with some other random IP which decided to DoS your site.

    It may have been a coincidence, but regardless, if it’s your client you should make sure of what was the reason for that, rather than to just assume that “it must have been that new plugin” (which happens to be open source for anyone to review).

    I also remind you as well, that the plugin is used in over 80,000 sites, mostly managed by programmers and developers. All plugins are reviewed by the wordpress team before publishing as well.

    What you are basically saying… is that your client bought an umbrella, and then because it suddenly started raining, you went and return the umbrella because it must have been the umbrella’s fault.

    I’m sorry if I sound too critical, but I work very hard on this plugin and I am proud of my work. Therefore, if you have no technical evidence and irrefutable details to sustain your claims that my plugin can be related to your issue, you should not post this kind of topic.

    Thanks again,

    Raul Peixoto

Viewing 1 replies (of 1 total)
  • You must be logged in to reply to this topic.