Insane Autoload Size

Hi Rafael,

I have no idea how the plugin could cause this. “Autoload” (or “autoloud”) are not part of the plugin vocabulary. Plus its makes a very light usage of the database. It only has a fixed set of options, so this behavior should be unlikely.

What makes you think RFG plugin could be the cause of what you observe?

Regards,
Philippe

@phbernard

Because when I remove the record from the database manually and then I remove the plugin, the database autoload will go from over 1MB to 0.13MB. If you also look on the image the biggest autoload entree is: fbrfg_favicon_non_interactive_api_request that has a total size of “1019576” which is over 1mb for some reason. And I do think this is related to your plugin is it not?

Removing all records and the plugin combined with the files to start fresh will only result in the same values and size.

This is the first time it happens as I’m using your plugin on other sites as well where this behaviour does not seem to be present.

@rafaeldejongh

Honestly speaking, 1Mb is not a big at all, at first.

And second, option “fbrfg_favicon_non_interactive_api_request” keeps master picture for generating favicon purpose.

If you use for favicon image over 1Mb, so it will be stored in your database.
But usually, at least for me, favicons no more 100Kb, even less.
Just now I checked one picture for favicon 500x500px png – it’s just 10Kb! A hundred times less than yours.

So, use a smaller (in Kb) master picture for favicon. ??

@Imigd

It wouldn’t be a problem if it wasn’t an auto loud item in the database, it is good to know that it is caused by storing the image. But for me it is weird that it is storing the image in the database and not just in the folder the plugin creates in the upload folder on top of that being an autoload item.

Could n’t this be done differently or removed as part of the autoload? As this does cause quite a bit of slowdown and in general the autoload shouldn’t be more than 0.10MB at best as recommended by many people and database optimisation plugins.

That said the favicon in question (https://www.lifeflows.nl/wp-content/uploads/2018/11/LifeFlows-FavIcon.png) is only 190KB in size so I am not entirely sure to why this would go up to 1MB if the source is like you’re saying saved there if it is only 190KB (Even if I compress it with TinyPNG or Shortpixel it will only give me a -10% reduction so it wouldn’t change much at this size). Sure I could downscale the original input, but that wouldn’t really change much for the actual generated items as they need to be lossless compressed afterwards on top of that. The source image I really don’t need the use of it to be honest as the generated icons are only used, but if it is bloating the database and especially in terms of that size, it isn’t really favourable.

If your database in total is only 0.6MB in size and that this one item (that is being auto loaded) is 1MB is quite a huge difference for something as small as the usage of the favicons.

It be great to have an option to disable this or reduce this as this is really unwanted, as this was already a problem over two weeks I’ve done various research regarding this and did various experiments like different icons and sizes, but the only conclusion I came to fixing this to not have this bloat size in my autoload in my database was to manually insert the generated icons in the header via functions.php, while this works I still like to use the plugin but currently can’t with this problem I am having.

1MB in general for a single record in a database is in my opinion quite a lot, especially if your ENTIRE database isn’t even a full megabyte in size, so if I can save even a couple bytes I will, but having a 1MB record there is really not something that should be just ignored and kept.

Thanks for the reply, but would like to know a solid fix for this other than the manual addition to the functions.php/header if this ever happens in the future.

• This reply was modified 6 years, 3 months ago by RafaelDeJongh.

Hi,

Oh… now I get it.

When you generate a favicon, RealFaviconGenerator also returns a standalone API request that can be reused to generated the same favicon. This request is stored by the plugin in order to re-generate the favicon automatically when something has changed (eg. Apple has introduced yet another high resolution Touch icon, which RealFaviconGenerator now creates).

This is not a core feature, rather a nice to have. And something that happens in the background and should definitely not impact the regular access to the web site.

The size of the request is not surprising. The image is encoded in base64, which increases the size. And if you used multiple images (one for iOS, another one for Android…), they are all stored in the request.

It seems to me that the fix should come in two ways:

• The plugin should not use autoload for this option.
• Make the favicon auto-update (and so, API request storage) optional.
  This is the first time I am reported this issue, so I assume most people can live
  with a 1MB field. Thus opt-out is okay.

Would these changes solve the issue you observe?

Regards,
Philippe

@phbernard

Thanks for the reply, and yea those suggestions would work great!
I guess it also differs from image to image and I do now also understand the reason to why it is that size.

So thank you for the explenation and looking into things, your suggestions for it would be highly appreciated!