I'm having a weird problem with Cloudinary. We moved over last week and found that our image load times were now significantly worse than serving the images from our AWS server. Looking into it, it appears that the images are being served from the ip address 151.101.17.137, which is in San Francisco. I'm finding that similar sized images are taking 3 times as long to load when compared with images being served from the AWS server.
So why does the CDN appear not to be working?
We've already implemented PRECONNECT as advised by Cloudinary.
Using Chrome Devtools and webpagetest.org I can see each of the Cloudinary image responses with a long ttfb and Header Response, Remote Address: 151.101.17.137
Any help or advice would be appreciated.
Adding to James' comment above, that IP is Fastly's but the location the traffic is served from may differ based on where you're accessing it from.
Likely, the IP is part of an Anycast network and served from multiple locations
Related
I have a website where users have the option to upload their profile images. Currently, I'm using Cloudinary to host those images. My client has asked me if I can host those images on HostGator since they already have a paid shared hosting account there. My question is
Can I even do that? I tried that on Heroku and they warn you that images etc stored on their server will be deleted in 24 hours when their dynos restart, and they recommend Amazon S3.
If yes, then I will definitely need some kind of API to work with since all this is handled by my server and there must be a way to upload and delete images programmatically. It would be great if you could point me towards particular resources.
If no, then what are the industry standards for my particular use case?
We're using Google Cloud Platform to host a WordPress site:
Google Load Balancer with CDN -> Instance Group with single VM -> Nginx + WordPress
From step 1 (only VM with WordPress, no cache) to the last step (whole setup with Load Balancer and CDN) I could progressively see the improvement when testing locally from my browser and from GTmetrix. But PageSpeed Insights always showed little improvement.
Now we're proud of an impressive 98/97 score in GTmetrix (woah!), but PSI still shows we're pretty average, specially on mobile (range from 45-55).
Problem: we're concerned about page ranking in Google so we'd like to make PSI happy as well. Also... our client won't understand that we did make an improvement while PSI still shows that score.
I was digging and found a few weird things about PSI:
When we adjusted cache-control in nginx, it was correctly detected by local browser and GTmetrix, but section Serve static assets with an efficient cache policy in PSI showed the old values for a few days.
The homepage has a background video hosted in 3 formats (mp4, webm, ogv). Clients are supposed to request only one of them (my browser and GTmetrix do), but PSI actually requests the 3 of them. I can see them in Avoid enormous network payloads section.
When a client requests our homepage, only the GET / request reaches our backend server (which is the expected behaviour) and the rest of the static assets are served from the CDN. But when testing from PSI, all requests reach our backend server. I can see them in nginx access log.
So... those 3 points are making us get a worse score in PSI (point 1 suddenly fixed itself yesterday after days since we changed cache-control), but for what I understand none of them should be happening. Is there something else I am missing?
Thanks in advance to those who can shed some light on this.
but PSI still shows we're pretty average, specially on mobile (range from 45-55).
PSI defaults to show you a mobile score on a simulated throttled connection. If you look at the desktop tab this is comparable to GT Metrix (which uses the same engine 'Lighthouse' under the hood without throttling so will give similar results on Desktop).
Sorry to tell you but the site is only average on mobile speed, test it by going to Performance tab in developer tools and enabling 'Network:Fast 3G' and 'CPU: 4x Slowdown' in the throttling options.
Plus the site seems really JavaScript computation heavy for some reason, PSI simulates a slower CPU so this is another factor. One script is taking nearly 1 second to evaluate.
Serve static assets with an efficient cache policy in PSI showed the old values for a few days.
This is far more likely to be a config issue than a PSI issue. PSI always runs from an empty cache. Perhaps the roll out across all CDNs is slow for some reason and PSI was requesting from a different CDN to you?
Videos - but PSI actually requests the 3 of them. I can see them in Avoid enormous network payloads section.
Do not confuse what you see here with what Google has used to actually run your test. This is calculated separately from all assets that it can download not based on the run data that is calculated by loading the page in a headless browser.
Also these assets are the same for desktop and mobile so it could be for some reason it is using one asset for the mobile test and one for the desktop test.
Either way it does indeed look like a bug but it will not affect your score as that is calculated in other ways.
all requests reach our backend server
Then this points to a similar problem as with point 1 - are you sure your CDN has fully deployed? Either that or you have some rule set up for a certain user agent / robots rule set up that bypasses your CDN. Most likely a robots rule needs updating.
What can you do?
double check your config, deployment etc. Ensure it has propagated to all CDN sites and that all of the DNS routing is working as expected.
Check that you don't have rules set for robots, I notice the site is 'noindex' so perhaps you do have something set up while you are testing things that is interfering.
Run an 'Audit' from Developer Tools in Google Chrome -> this uses exactly the same engine that PSI uses. This may give you better results as it uses your actual browser rather than a headless browser. Although for me this stops the videos loading at all so something strange is happening with that.
We currently experience a diminished with one of our customers at our main production site. All subpages and resources seem to be affected as well.
The customer reports a completely broken experience for themselves with the site not working correctly at all, mostly due to assets not loading correctly.
We already started investigating and have found that - so far - nothing seems to be wrong with the site itself.
Quick rundown:
The production site has a Cloudflare layer and almost all of it's assets are delivered either via CDNjs or Amazon's Cloudfront (behind Cloudflare) - all assets are reachable via HTTP as well
The site uses SSL and enforces it (the dynamic cert from Cloudflare)
We could secure a HAR from one of the requests for the request to one of our sites, the request times are extremely long. If you like to try, here is an online HAR viewer, be sure to uncheck validation of the file.
The customer uses Internet Explorer 8 and Chrome (39). While the site is not optimized for IE8. It should run fine in Chrome, in fact, in runs in most browsers above IE9 just fine for all of us.
Notes
We already ruled out:
Virtual delivery problems (there could be physical limitations we are not aware of)
General faultiness of our setup (We tried three different open VPNs to verify this)
Being on the customers blacklist by accident (although we cannot be entirely sure of this)
SSL Server name indication (SNI) problems
(Potentially) a general problem with the customers network, the customer does not report any problems with "the rest of the internet".
The customer will not give access to their VPN/disclose security details so we cannot really test for the situation ourselves. We suspect that the customer uses an internal proxy that might cause the problems described, but we are not sure.
Questions
My questions here are:
Is there any known problem caused by internal networking in conjunction with our setup that can cause this behaviour?.
Are there potential problems on our end that we could have overlooked or things that we do different from other sites?
It seems the connection is being done (or routed) through a low bandwidth high latency link (or a very congested one). Most of the dns lookups and connects seems to be taking ~10s.
In the HAR you can see that it affects fonts.googleapis.com and cdnjs.cloudflare.com. https://www.google-analytics.com/analytics.js has no data captured. To me the affirmation that the customer does not report any problems with "the rest of the internet" seems kind of dubious, seeing that in this HAR it hasn't been able to load the analytics js and access to usual cdns are very slow.
My guesses (pick one or more):
they are testing in a machine different than the one they have no problems with "the rest of the internet"
this machine is very, very slow
it has some kind of content filtering, antivirus, whatever filtering the web (perhaps with a ssl certificate installed in order to forge & inspect https traffic)
the access is done through a congested route, or a low bandwidth high latency link
Two hotspots:
It happens sometime for CDN points to be inconsistent, I spent a lot of time to understand this issue. How? In a live session with the client when I opened each resource loaded one by one I understand there are differences between CDN access points (Mine eastern Europe - His central Europe ). CDN hosting was one of the biggest US player in the world, anyhow we fixed this by invalidating(deleting) all files from CDN as so new/correct ones were loaded.
You need to have CDN that supports serving files over HTTPS, then use that CDN for the SSL requests.
I am suggested by a friend to use nginx for my site http://www.imgzzz.com . its an image hosting site with loads of traffic.
Currently im on a vps ..CentOS 5.4 x64 , Apache
Most views are on image pages. So far to decrease the load on server i have done cache of almost all data like user details, image name, path, category details etc.
Still i have to go with about 3 sql queries every page/view.
Addition of Views
Displaying Views
Addition of user ad views with respect to their ads shown
Considering the traffic from social media sites like digg, stumbleupon. per second online user peaks upto 1500-2500. So i guess you can get the idea of php queries per second.. Sometimes it causes the server to lag.
The rest of the stuff on image pages is static. So now do you guys suggest nginx or any other better option for my server?
Thanks in advance :)
Edit : This is a custom system not any cms
I would recommend using nginx as your static file server. I run nginx for this and it works great, and I could vouch for alot of other people I know that uses it. It's fast and reliable.
I've come across an issue where some images on a site load under https but do not load under http.
For example if you go to https://www.mydomain.com/myimage.gif, the image appears fine, but if you go to http://www.mydomain.com/myimage.gif the image comes back with a not found error. This happens to only certain images. Other images load fine either way. Even images in the same directory as the problem images load fine.
I know that if SSL is not set up correctly I've seen a similar issue, but it's always been with the entire site, not with a few images.
This is on an IIS6 server.
Problem solved. It turns out that the https site was created using a physical copy of the actual site under the SSL port, this means there were 2 versions of the site being served under the same domain name, one under port 80 and one under port 443.
The issue appeared because someone updated the port 443 site. The images missing in the port 80 site were actually not there, causing the 404 error.
Thanks for the help. Too bad this got modded down... I guess this question is not strictly a programming question?
Moving a comment out to answer in the hopes it'll get a response:
Is this behavior consistent across browsers and/or PCs/Macs?
Try using Fiddler to see what is happening with that particular image when the page is loaded.