DO Spaces Request timing is slow - basic images load slowly, poor performance.

Posted December 1, 2018 7.7k views

I ran a test on the same image across DO block storage [e.g. basic web server $10/mo tier], DO Spaces, and AWS S3.

The results confirm what I’ve been seeing:
DO Block loaded image in 0.41s
DO Spaces loaded image in 1.25s
AWS S3 loaded image in 0.49s

It appears that the lag is the request portion of the load timing [Connect -> Request -> Response -> Dom.. etc]. Connect and response timings appear faster than block storage.

I’m just really confused as to why anybody is using Spaces at this point – on a normal webpage it has noticeable lag across images. I’ve also been using as asset storage for Craft CMS and the images in backend UI take forever to load, nothing I’ve ever noticed with block or S3.

Question is does DO acknowledge this service is generally slow? Not intended for web usage and intended for something else? I’ve read the optimization guide, and it does mention to avoid small files, but it begs to question what in the world is any web developer using Spaces for? We need fast delivery of lots of little files. I really would like an alternative to AWS S3 bundled into the beautiful and function DO backend. If DO Spaces is not going to be fast please stop advertising it as CDN an alternative to S3.

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Submit an Answer
15 answers

To Digital Ocean admins: it’s a shame to let many users complaining about a basic paid service that obviously does not work, without bringing any answer.
It shows a lack of transparency about your infrastructure issues, a lack of customer support (stop trying to hide issues by saying “please open a ticket”), and will lead to people to migrate to AWS or GCS. Just saying..

I’m suffering the same.

I’m using DO Spaces CDN configuration and I don’t know the origin of the problem, but requests that contains assets of image type are unseemly slow.

A little real example of a request:

image1.jpeg 249 KB –> 5.41 s
image2.jpg 279 KB –> 3.94 s
image3.svg 818 B –> 2.20 s
image4.svg 1.5 KB –> 2.13 s
image5.svg 1.6 KB –> 2.13 s
image6.svg 997 B –> 1.88 s


DROPLET in AMS3 location
STORAGES in AMS3 location

Can anyone explain this bad beaviour?? I’m very frustrated.

I have the same problem all the images load very slowly

Even I can confirm the same. Our 480P videos served from DO CDN do not load at all.

Same problem here. Small jpg images (~250 KB) take quite long to load (~ 1s).

Same here. Slow performance. I think I made an mistake choosing Spaces.

Hey friend,

I’m sorry for the trouble you’ve experienced here. If you don’t mind opening a ticket with our support team and helping us better understand your setup and use case, that might give us what we need to run with it. You can do that here:

Basically we’d like to know everything necessary to be able to reproduce a similar environment and situation.


I have this same problem loading thumbnails from 80 - 300kb in size. It lags when loading in an image feed. Just migrated all content from amazon s3 to spaces and spaces performance is visually unappealing. 1.5s total load time on a thumbnail 25kb in size.

I have the same issue. Spaces performance has been a problem for us since we started to use Spaces more than 6 months ago.

We use Spaces (in AMS3 region) for both writing and reading data, of anything between 512 bytes and 15MB.

Read/write operation times vary a lot, and it is not uncommon for read/write operations to be more than 10 seconds - which is a real performance killer for us.

What guarantees does Spaces offer in regards to read/write operations? “None” is not good enough.

(Despite my username, I am not a DigitalOcean admin :) ).

Previous 1 2 Next