MegaZ

I am guessing the performance issue has to do with a boatload of disposable emails you’ve added in the 2020.4 branch. It is a giant array, and I am guessing that PHP slows down to crawl when you try to parse through that list.

Test it out in your own environment, compare 2020.3 to .4 and you will see exactly what I mean. My load time more than doubles with the 2020.4.1 branch!

@bhadaway, no, this has nothing to do with poor hosting – I have dedicated servers running excellent hardware.

The problem is with your code. I just rolled back to version 2020.3 and the load went back to normal. Your 2020.4 release is very buggy. Run a timed curl between the two and see for yourself…

Thank you @gvectors-team for your quick response.

Yes, it is good that you are supplying a minified file, but that does not do anything to reduce Javascript / CSS file size, which is the issue with Google PageSpeed. Please keep in mind that Google now ranks every website according to how quickly it loads. Unfortunately, your plugin loads a bunch of unnecessary Javascript and CSS code, which is a problem. Try disabling your plugin, running Google PageSpeed Insights, then re-enable it and see for yourself.

If I may suggest (and only in the interest of making this the best comment plugin on the Internet), I would kindly request the following:

1) Only load Javascript as required by what is enabled in the plugin. It is totally OK to separate Javascript into many different .js files. Many of us are already using caching plugins like W3 Total Cache, Super Cache, etc, and we can easily put all the Javascript files into a single minified file. You don’t have to worry about providing more Javascript files, it is really not an issue. In fact, this is the preferred method of doing this going forward, in order to make the web pages load faster.
2) Only load required CSS – also section it off to smaller files. There is no need to preload a giant CSS file containing everything, since 90% of that file is unused by the browsers, especially for those of us that have some or all of your features disabled. Don’t worry about making calls to many CSS files. As I said above, we can easily put them all into a single file using caching plugins.
3) I have requested it a number of times, and will request it again – remove FontAwesome from your library, or make it completely optional. Move the most important icons as inline SVG, or CSS SVG (background-image). You are already doing this partially for some of the icons, so why not do the rest? I bet 99% of your user base does not care about icon customizations, especially once they find out how much faster their websites will get without loading a font library, and a giant FontAwesome CSS file.
4) Completely avoid both inline CSS and Javascript to make HTML content lighter.

I bought your whole suite because I like this plugin and I want to support it. If you can optimize the plugin with my suggestions, it will only make it shine! If you guys move your code to Github, I would be happy to contribute – I’m sure there will be others who are looking forward to bringing some good changes to your plugin…

@gvectors-team, just because of this feature, every single one of your plugin users must load a gigantic FontAwesome library. This is slowing down page load time, reduces server response time and causes all kinds of Google PageSpeed ranking drops.

This is not a good idea. Please remove this feature, and replace FontAwesome with inline SVG icons. This will make your plugin load so much faster, and will make many users happy!

I bet 99% of your users does not care about being able to replace an icon from the FontAwesome library. If you don’t believe me, feel free to ask the community…

Actually, the issue extends to the use of minified Javascript as well.

You guys are loading the whole Javascript JQuery library into a single file, which is not right for those of us who are not using most of the functionality of the plugin. I have all the modules disabled, and yet the Javascript file contains the following:

/* Media Uploader */
JQuery code
/* Lity */
JQuery code
/* Social */
JQuery code

I am not using Media uploader, social login, etc, and yet the above Javascript has to be loaded each time a person visits my page.

Please feed only Javascript that the user has enabled.

I love this plugin, but the clean-up it needs is pretty massive…

• This reply was modified 4 years, 6 months ago by MegaZ.

Guys, ideally, you should be loading the CSS from three different files, depending on which one is chosen, instead of shoving it all into a single CSS file.

As requested previously, please remove FontAwesome and change the icons to inline SVG to load everything fast. Additionally, I would love to see each function be loaded via a different CSS file, so that we can control exactly what should and should not be loaded. Your CSS files are massive even without the Rich Editor…

I fully agree, and it is something I have been asking about. Some of the icons have already been converted to SVG, and I hope the team moves away from the heavy FontAwesome library into tiny inline SVG code instead…

Now that the version 7 is official (yay), I would like to bump this up and hope that you guys do this on the next release.

Please note that WpDiscuz puts a heavy burden on CSS, font load and Javascript because of the large framework of FontAwesome. You have already converted some of your icons to SVG format, please do the rest of them and free us from the heft of FontAwesome. Once this is done, Google’s Pagespeed rank will go up tremendously.

Thank you for your consideration!

Jason, do you realize that your plugin causes caching not to work on every page of a website, simply because you choose to count total number of visits to the website?

I look at this as a very serious flaw – you are essentially helping make the Internet slower. Are your customers aware of this? Any proxy cache server, including Cloudflare, will not cache ANY pages of a website that uses your plugin. You guys need to take this into account and move the tracking feature as an option, which is NOT enabled by default.

I know how to fix your code and I can easily do this. But what about everyone else who is not technical enough to implement these fixes?

Is this true?

Plugin authors, please reply. Many of us do not want anyone touching our image files!

Andrew, how many more months until you fix this basic problem that is affecting EVERY single person who downloads and uses your plugin?

In all seriousness, I find it baffling that your team cannot add one line of code. Do you realize that every customer of yours cannot cache ANY page of WordPress because of your plugin?

I can confirm this issue. All of my links are getting a trailing slash as well.

Please fix ASAP.

Four months, still no traction. Is it really this hard to add a single line of code to fix this problem? Plugins like this are the reason why so many WordPress sites on the Internet underperform. People have no clue that one of their plugins is causing every page to generate a cookie, avoiding caching completely.

I am shocked that I have to patch every single one of your releases. Time to move on to something else…

I reported this problem a long time ago now and you guys still have not fixed it!

Look, all you have to do is change the following file:
adminpages -> reports -> login.php

Insert on line 401:
if(!is_user_logged_in()) return false;

Once this is done, the cookie is not going to set and caching is going to work. Is this so hard to fix? I do not want to be patching your plugin every single time you guys release an update.

Please fix this.

The latest W3TC definitely broke GravityForms. And this has nothing to do with minification, since I am not minifying GF.

As soon as I reverted back to 10.2, everything started working again. Whatever changes you’ve implemented since the last release broke GF.