Use a CDN

  • Idea
  • Updated 2 years ago
  • Implemented
Archived and Closed

This conversation is no longer open for comments or replies and is no longer visible to community members. The community moderator provided the following reason for archiving: Community cleanup. Idea was implemented 1+ years ago.

Serve getsatisfaction JS from cloudfront/cdn rather than s3

Geoff Evason

  • 1 Post
  • 0 Likes

Posted 3 years ago

  • 5

Ivan Torres, Engineering Manager

  • 37 Posts
  • 12 Likes
Hi Geoff,

We are working on it, we can't give any dates but we are definitely on it.

Thanks!

Jason Yang

  • 1 Post
  • 0 Likes
If you use cloudfront, you only need to link a couldfront distribution to your s3 bucket. And it's all set to go.

You can invalidate the file on the CDN whenever you update it via the numerous tools and the AWS SDKs provided.

BatchGeo Support

  • 1 Post
  • 1 Like
This request is 8 months old? You should be able to do this in a few hours at the most. I already have a CloudFront instance sitting in front of your widget loader, but most of the assets still load from S3.

S3 is very slow and your widgets are by far the slowest loading elements of my site. CloudFront is cheap and simple to setup, please turn it on so I don't need to switch providers!

BatchGeo Support

  • 1 Post
  • 1 Like
BTW, here is a performance report on your home page:

http://www.webpagetest.org/result/120...

You guys are much too big to be this poorly optimized, faster = more customers. Get to it!

Jenn Lin, GetSat Alumni

  • 529 Posts
  • 19 Likes
Hi BatchGeo!

Can we have a bit more information to do an informed investigation?

Can you provide the URL of your page that loads our widgets slowly? We can then investigate the performance from that perspective.

Thanks in advance!
Jenn

BatchGeo Support

  • 1 Post
  • 1 Like
You could load your own home page: http://getsatisfaction.com

When I say "slowly" ... I guess I mean by my standards =o)

Loading components from S3 isn't a good idea, its much better to use CloudFront as recommended above. Much much faster. Also using cache control headers so that your content can be properly cached.

Also take a look at the performance report of your own home page:

http://www.webpagetest.org/result/120...

There are many basic optimizations like minifying javascript and gzip'ing your content. This is very easy stuff to do that can make a big difference in performance.

Webmasters these days are trying to target sub second load times, every bit counts.

Jenn Lin, GetSat Alumni

  • 529 Posts
  • 19 Likes
Thanks! It is good to better understand the context.

I'll see what the engineering team thinks about this. It is great to get this kind of thoughtful feedback. Thank you!

Jenn

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
Hi everyone,

As of this evening we are using a CDN (CloudFront as it turns out) to serve the vast majority of our assets. We hope that you notice improved load times for our application pages and widgets.

Cheers,

Nick

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
Hi BatchGeo,

We haven't yet made changes to the way the feedback-v2.js is loaded. We expect to do so in the near future, and when we do those other assets should also be loaded via CloudFront as well.

Cheers,

Nick

Eric P. Scott

  • 17 Posts
  • 0 Likes
Some advance notice would have been nice. Half the time I see a site loading content from cloudfront.net, it's something undesirable. Too many creeps like to hide behind the anonymity afforded by a long string of incomprehensible alphanumeric characters.

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
BatchGeo,

We've made the appropriate changes to ensure that feedback-v2.js and its related assets are loaded over CloudFront.

To implement this, you may take one of these two approaches:

(1) Log in to the Community Admin -> Widgets area to fetch new widget HTML containing the CDN-ified asset host name

OR

(2) Manually edit your widget HTML to replace 's3.amazonaws.com/getsatisfaction.com' with 'd3rdqalhjaisuu.cloudfront.net' wherever it appears

Please feel free to ping me back if you have any trouble with this upgrade.

Cheers,

Nick

BatchGeo Support

  • 1 Post
  • 1 Like
Thanks so much for this change! One final request:

Make sure your server is setting cache headers so that the CDN and browsers can properly cache the resources:

(from webpagetest.org):
FAILED - (No max-age or expires) - https://d1xklv3tn7qmp2.cloudfront.net...
FAILED - (No max-age or expires) - http://d3rdqalhjaisuu.cloudfront.net/...

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
Hi BatchGeo,

I'm seeing a max-age and expires headers for the first item:

[nick@nick-mba ~]$ curl -v -O https://d1xklv3tn7qmp2.cloudfront.net... 2>&1 | egrep -i '(expires|age)'

* Trying 205.251.203.30... % Total % Received % Xferd Average Speed Time Time Time Current
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
< Cache-Control: max-age=315360000
< Content-Type: image/png
< Expires: Sun, 27 Mar 2022 21:03:31 GMT
< Age: 10783

but I agree with your observation about the second item:

[nick@nick-mba ~]$ curl -v -O http://d3rdqalhjaisuu.cloudfront.net/... 2>&1 | egrep -i '(expires|age)'

* Trying 205.251.203.33... % Total % Received % Xferd Average Speed Time Time Time Current
> User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5
< Age: 8325

I'll look into setting the correct expiry S3 headers for the feedback-v2.js object so that they'll get passed through to CloudFront.

Cheers,

Nick

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
Hi BatchGeo,

Looks like we have an inconsistent behavior in our servers. Sometimes our assets are served with ETag set, sometimes with Expires/Cache-Control set. The cases where it is served with ETag are resulting in the problem you demonstrated for https://d1xklv3tn7qmp2.cloudfront.net...

I'm working on getting it fixed this afternoon.

Thanks again for your patience and technical feedback. It's very valuable to us.

Cheers,

Nick

Nick Marden, Systems Engineer

  • 3 Posts
  • 4 Likes
Hi BatchGeo,

One last post on this (I hope!).

We've rectified the inconsistencies about how our servers were setting the Expires and Cache-Control headers on our assets, so I believe that the examples that you cited above about assets with no max-age or expires settings should be fixed now.

After priming my cache with a single visit to batchgeo.com, I see that only two round-trip requests are made to our servers:

http://getsatisfaction.com/batchgeo/f... (302)

https://getsatisfaction.com/batchgeo/... (200)

The second one is the one that is absolutely necessary to give you an up-to-date topics list in the feedback widget, so there's not much we can do there short of pushing our entire DB out to edge servers - something that's not in the short-term plan for us.

The reason for two requests rather than one is our recent upgrade to SSL everywhere in the GSFN app. If you'd like to speed it up to just a single round-trip request, you can remove modify the is_ssl logic in our provided HTML to simply always return true, and then only the second 200 request will ever get made. That's an improvement I'll put on our road map as well.

Cheers,

Nick

BatchGeo Support

  • 1 Post
  • 1 Like
This is great, thank you for these improvements!

This conversation is no longer open for comments or replies.