Add another image proxy to give users alternatives

[galpt]

Describe your suggested feature

Kind of similar to #357.
Some manga websites load images really slow.
Image proxies will help boosting image load times from the user's perspective.

Adding wsrv.nl was a good idea, but I think it's better to add more proxies and give users the ability to choose what proxy works better for them.

I would recommend adding this proxy too to help speed up loading the images.
This does not reduce image quality, but it caches the images nearest to the users, so it will still help speeding up image load times.

From the user's perspective, useful for users who aren't worried about bandwidth but keep getting slow load times.
From the manga website's perspective, caching proxy will help reducing the server's burden for manga titles that are frequently visited/downloaded.

tl;dr — as the title suggests, this gives another alternative for users to use & maybe compare too.

Acknowledgements

• I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.

[galpt]

I hope this suggestion will be considered or even implemented as the benefits are really that great, directly related to the manga images (how fast images get loaded without the need to save them offline).

As this app is about how good it is for reading manga images, I'd argue that feature suggestions affecting the images (i.e. if it's about making images load faster) are more important than other suggestions such as sorting or similar issues.

Ofc more discussion about this is great, but I'm sure the above statement is already acceptable as a good reason.

[galpt]

To give everyone an idea about how useful is this if it gets implemented, we can compare the manga image URL with & without using the caching proxy I mentioned above.

Scenario: Reading manga images without using image proxy

Figure 1. The image below shows us that loading all the manga images will be slow for some users, without using any image proxy at all.

Comparison: Measuring image load time for a specific manga image URL

Figure 2. The below image shows us the load time for specific image URL, without using any image proxy.

Figure 3. The below image shows us the load time for specific image URL, after using 0ms caching proxy.

How to Use: Image URL structure

Figure 4. The image URL without using the caching proxy.

Figure 5. The image URL after using the caching proxy.

[galpt]

For caching so many images, it is recommended to use the x.0ms.dev endpoint, as described on the web page (https://0ms.dev/mirrors/).

The reasons are:

1. Robust network and managed by smart algorithm to guarantee performance. Really good peering quality (almost as good as Cloudflare).
2. The caching program is custom-made, designed to be low latency for repetitive HTTP requests.
3. For that endpoint, it doesn't rely on Cloudflare. This is to make sure the caching proxy doesn't get throttled by Cloudflare, in case Kotatsu users will make 100 TB of image traffic or even more.

• Reason (1) is good to make sure network connection between users' ISPs and the proxy is good (a.k.a good peering).
• Reason (2) will help a lot for use cases like caching a lot of images (i.e. for manga reader/downloader apps).
• Reason (3) is needed because according to some sources (reddit, etc.) Cloudflare won't like it if we use their service to cache lots of images. That's why the caching proxy should not rely on them.

fyi

Btw, I'm one of the devs that designed the 0ms caching proxy, so that's why I know some details such as point 1-3.

tl;dr — It's completely okay to use both endpoints. The differences will be explained in the next comment below (also available on the web page).

[Koitharu]

Thank you for so detailed explanation, I'll implement it soon

[galpt]

For Kotatsu app, you can use either 0ms.dev/mirrors/ or x.0ms.dev/q70/.
Both endpoints are handled by the same servers, so there will be no difference with the image results.
It's only that x.0ms.dev/q70/ supports getting images from http:// URLs, while 0ms.dev/mirrors/ will automatically use https:// for all URLs.

Some websites already use x.0ms.dev/q70/ in production so that's why removing them or changing the URL structure might break images on those websites. For now, it is what it is.

[galpt]

Hoping it'll be implemented very soon in the next major releases.

This will make #640 kind of obsolete.
It does some optimizations to the cached files without compressing the files, so technically images will load faster without reducing the quality.
Very useful if the user's phone doesn't have big RAM to keep the cache in memory or bloating the storage but the user still wants to make images load faster. Home users with fast WiFi will love it.

[Koitharu]

I added this proxy however looks like it slow down requests significantly comparing to wsrv.nl and direct requests...

[galpt]

@Koitharu
Can you give me a real example (i.e. the specific image links you're testing)?

Technically, it will be slower only the first time because the proxy needs to download every single image, save them to the storage servers, and cache them globally.
But anything that's already in the storage will be served faster and won't even reach the original image link (unproxied link) for the next 7 days.

The difference between wsrv.nl is that they don't guarantee your images will always be cached, they may have a limited cache so their cache is not guaranteed. The 0ms.dev image proxy is a guaranteed cache, repetitive requests of the same image link(s) will be faster compared to accessing the image via direct link for the next 7 days atleast after the image's already stored in the storage servers..

Performance-wise, it's using Cloudflare and they have 13000+ peering with many ISPs worldwide, so performance is no doubt really good unless people's ISPs have bad peering to Cloudflare.

Also, one thing to note is that since the proxy has to download the image first before saving them to storage servers, the slowness could be caused by the real/original image server. Maybe their server has only 1 Gbps of bandwidth, could be even less than 1 Gbps in some countries.
So that's where the guaranteed cache shines.. the same images will be a lot faster served from the mirror for the next 7 days for other users in different countries

[galpt]

I've tested the latest version (v7.1) and the 0ms mirror is working as it should.

All images are cached (downloaded & stored to storage) with the average size ranging from 500 KB to 1 MB per-image (could be more, depends on the image height+width & quality).

Just like how any caching logic works, the very 1st time we are accessing it, we're going to feel some delay, that means the content was not in the cache and we are telling the logic to cache it.

The 2nd time and the n-time we're accessing it, it will be faster, could be almost instant if our connection to Cloudflare is really good.

As the number of users who are using the mirror increases, the number of cached images will also increase, so the same manga images will definitely load faster.. This is a good thing and it will get better over time.
We're feeling the little delays because we're the first users who're testing it :)

[galpt]

I'm closing this issue as the feature's already implemented. Thank you!

[Ero-gamer]

I'm closing this issue as the feature's already implemented. Thank you!

Your proxy server is amazing and very fast. Can I use your proxy as a DNS resolver like cloudflare DNS 1.1.1.1? If yes, what is 0ms DNS resolver address ?

[galpt]

Hi @Ero-gamer , thanks for testing the proxy.
The DNS resolver is available on homepage, feel free to use it, but only DoH is supported since it's harder to block DoH compared to DoT or other protocols.