long delay before download

Hello @rdzman,

Thanks for reaching out to us!

Could you please share a bit more about where the files you’re trying to download through the plugin are coming from? Understanding where the files are being served from can help us diagnose any potential issues.

Thank you,

Beatrice.

Thanks for the response, Beatrice.

As mentioned in my original post, they are hosted on GitHub (asset files associated with a release). For example …

https://github.com/MATPOWER/matpower/releases/download/7.0/matpower7.0.zip

And as I mentioned, a direct download from the GitHub URL is quick, whereas a download of the same file through Download Monitor (e.g. the matpower7.0.zip link on this page) takes a long time before it begins. You should be able to try both to see the difference.

Thanks again.

Hello @rdzman,

Thanks for letting us know!

The file download process is facilitated through our server. In other words, we send a request to GitHub, which then provides us with the necessary data. Subsequently, we relay it to you, the user. This process may slightly extend the duration due to its indirect nature.

Thank you for your understanding!

Warm regards,

Beatrice.

Could you clarify for me what you mean by the download process being “facilitated through our server”? By “our server” are you referring to the WordPress site running Download Monitor (i.e. matpower.org in my case), or to some other server operated by the Download Monitor developers?

I’m guessing (and hoping) you meant the former. Either way, why is this necessary? Would you consider at least implementing an option to avoid this overhead by redirect the user’s download request directly to GitHub?

If not, do you have any ideas about how to reduce the delay? E.g. WordPress or hosting settings?

Thanks again.

Hello @rdzman ,

It is facilitated through your server, not ours, was a misspell there. Regarding the redirect, there is a Redirect option for the Download. If you go and edit the Download, on the right side in a meta box you’ll see a “Redirect to file” option, and if you check that it will “redirect” the user to your Github file.

There are 2 main problems that result in your issue:
– the size of the file apparently is not sent from Github, so we do not know the percentage downloaded
– the transfer speed seems painfully slow on some files ( 100-200 KB/s in some cases ), do not know why that is, possibly it is limited by the host.

Because of these 2 problems, we can’t show the visitor the download percentage, so it’s just the loading icon there. Seems to be delayed because it downloads bits by bits and when it’s done it gives the user the whole file, so the waiting time is the same as it would be in a normal download.

If you want to disable the XHR download, you can do it by adding the following PHP snippet in your child theme’s functions.php file:

add_filter( 'dlm_do_xhr', '__return_false' );

Warmly,
Razvan

Marking this support thread as resolved due to inactivity. If you have any other questions or need further help please open a new thread.

Sorry for my late reply. Thanks @raldea89, I finally got a chance to test these options.

The combination of disabling XHR download and choosing the “Redirect to file” option was exactly what I needed.

The redirect option gives me the download progress (so apparently the browser is getting the file size from GitHub somehow), but then my popup (via Popup Maker) isn’t showing up unless I disable the XHR too.

With both, I get my popup (immediately, not 30 sec later when everything finishes, like before), immediate and fast downloads, and download progress display.

Thanks for a great tool and excellent support!

Check if there are any updates or patches available for Download Monitor that specifically address performance issues with external URLs. Additionally, you might want to look into whether there are any server-side settings or caching mechanisms that could be contributing to the delay. If your server is attempting to pre-fetch or verify the external files before serving them, this could be causing the lag.