We have mod_pagespeed on Apache and filters like convert_jpeg_to_webp.
We would however, also like to add CDN to the website, especially for the images and javascript files, in order to further enhance the performance and the Pagespeed score for this website. However, once we enable CDN, jpeg versions of the image are delivered via the CDN. We would like, however, to get the webp versions of the images (which work totally as expected) like when CDN is not enabled.
For example, without cdn, www.domainname.com/assets/images/imagename.jpg.pagespeed.ce.fqqfe4pa.jpg
is converted to
www.domainname.com/assets/images/imagename.jpg.pagespeed.ce.fqqfe4pa.webp
But with CDN enabled, we get something like this in return:
cdn.domainname.com/assets/images/imagename.jpg.pagespeed.ce.fqqfe4pa.jpg
Anyone maybe has a solution?
Have you authorized your CDN domain? You can find further details here: https://www.modpagespeed.com/doc/domains
Related
I have site resources like js, css and images hosted on S3 with Cloudfront distribution site's headers has cloudfront CDN url to load resources. Site is working fine and loads properly but some customers reported that site is not loading anymore, it was working 1 day before. Clearing cache did not work. On the cloudfront there is no method to check the issue. Any help will be appreciated.
This might get flagged as inappropriate question but I am not sure how and where to ask this as I have no clue about reasons and debugging methods for it.
if you have issues about TTL....this may help you
AWS TTL solve
I have an existing live application based on php/Mysql/apache stack. A quick performance evaluation revealed that a CDN solution would help us gain a lot of speed. Planning to use cloudfront for the CDN.
The issue is existing code wasnt written with CDN in mind.
At the moment, our html outputs contain statuc resources under link tags and are referenced with "./images/test.png" etc...
is there anyway to identify these links just before sending the output and replace it to load from local CDN url.
I am using React and React Router in my single page web application. Since I'm doing client side rendering, I'd like to serve all of my static files (HTML, CSS, JS) with a CDN. I'm using Amazon S3 to host the files and Amazon CloudFront as the CDN.
When the user requests /css/styles.css, the file exists so S3 serves it.
When the user requests /foo/bar, this is a dynamic URL so S3 adds a hashbang: /#!/foo/bar. This will serve index.html. On my client side I remove the hashbang so my URLs are pretty.
This all works great for 100% of my users.
All static files are served through a CDN
A dynamic URL will be routed to /#!/{...} which serves index.html (my single page application)
My client side removes the hashbang so the URLs are pretty again
The problem
The problem is that Google won't crawl my website. Here's why:
Google requests /
They see a bunch of links, e.g. to /foo/bar
Google requests /foo/bar
They get redirected to /#!/foo/bar (302 Found)
They remove the hashbang and request /
Why is the hashbang being removed? My app works great for 100% of my users so why do I need to redesign it in such a way just to get Google to crawl it properly? It's 2016, just follow the hashbang...
</rant>
Am I doing something wrong? Is there a better way to get S3 to serve index.html when it doesn't recognize the path?
Setting up a node server to handle these paths isn't the correct solution because that defeats the entire purpose of having a CDN.
In this thread Michael Jackson, top contributor to React Router, says "Thankfully hashbang is no longer in widespread use." How would you change my set up to not use the hashbang?
You can also check out this trick. You need to setup cloudfront distribution and then alter 404 behaviour in "Error Pages" section of your distribution. That way you can again domain.com/foo/bar links :)
I know this has been a few months old, but for anyone that came across the same problem, you can simply specify "index.html" as the error document in S3. Error document property can be found under bucket Properties => static Website Hosting => Enable website hosting.
Please keep in mind that, taking this approach means you will be responsible for handling Http errors like 404 in your own application along with other http errors.
The Hash bang is not recommended when you want to make SEO friendly website, even if its indexed in Google, the page will display only a little and thin content.
The best way to do your website is by using the latest trend and techniques which is "Progressive web enhancement" search for it on Google and you will find many articles about it.
Mainly you should do a separate link for each page, and when the user clicks on any page he will be redirected to this page using any effect you want or even if it single page website.
In this case, Google will have a unique link for each page and the user will have the fancy effect and the great UX.
EX:
Contact Us
I'm having a doozy of a time trying to serve static HTML templates from Amazon CloudFront.
I can perform a jQuery.get on Firefox for my HTML hosted on S3 just fine. The same thing for CloudFront returns an OPTIONS 403 Forbidden. And I can't perform an ajax get for either S3 or CloudFront files on Chrome. I assume that Angular is having the same problem.
I don't know how it fetches remote templates, but it's returning the same error as a jQuery.get. My CORS config is fine according to Amazon tech support and as I said I can get the files directly from S3 on Firefox so it works in one case.
My question is, how do I get it working in all browsers and with CloudFront and with an Angular templateUrl?
For people coming from google, a bit more
Turns out Amazon actually does support CORS via SSL when the CORS settings are on an S3 bucket. The bad part comes in when cloudfront caches the headers for the CORS response. If you're fetching from an origin that could be mixed http & https you'll run into the case where the allowed origin from CloudFront will say http but you want https. That of course causes the browser to blow up. To make matters worse, CloudFront will cache slightly differing versions if you accept compressed content. Thus if you try to debug this with curl, you'll think all is well then find it isn't in the browser (try passing --compressed to curl).
One, admittedly frustrating, solution is just ditch the entire CloudFront thing and serve directly from the S3 bucket.
It looks like Amazon does not currently support SSL and CORS on CloudFront or S3, which is the crux of the problem. Other CDNs like Limelight or Akamai allow you to add your SSL cert to a CNAME which circumvents the problem, but Amazon does not allow that either and other CDNs are cost prohibitive. The best alternative seems to be serving the html from your own server on your domain. Here is a solution for Angular and Rails: https://stackoverflow.com/a/12180837/256066
I'm trying to embed an Amazon "Recommended Product" widget into a website. We use SSL across all pages on the site.
Unfortunately, the Amazon widget by default is embedded using a simple IFrame and although the source for the IFrame can be https://, the images and links within the IFrame are always http://
IFrame sample code
<iframe src="https://rcm-uk.amazon.co.uk/e/cm?t=june2k&o=2&p=16&l=st1&mode=books-uk&search=potter&f=ifr&f=ifr"
width="468"
height="336"
border="0"
frameborder="0"
style="border:none"
marginwidth="0"
marginheight="0"
scrolling="no"></iframe>
Needless to say this results in "insecure content" warnings, broken padlocks, etc.
So far the only solution I've been able to come up with is to get the contents of the IFrame using the server, parse it and re-write all the image links to point at a local handler which in turn proxies the images. It seems like a fragile approach with a lot of processing overhead. It's just nasty.
Does anyone have any experience with this? Is there a method here that I'm missing? Can I get Amazon to return valid https:// urls?
If I change the image urls from http to https in-situ, I get a certificate mis-match error - it seems the images are served from the Akamai CDN and the common name for the certificate isn't the hostname used to serve the images.
I'm finding it hard to believe that an e-commerce company as large as Amazon is incapable of serving a secure page.
Any help greatly appreciated.
After a lot of digging, I found a version of the widget on the Amazon site which ran in SSL mode without errors.
After looking at the IFrame src, the URL has an additional parameter internal=1. I haven't seen this documented anywhere but it seems to tell the widget to serve the images from Amazon's network instead of Akamai's, and SSL is supported.
The url should look like this:
https://rcm-uk.amazon.co.uk/e/cm?t=june2k&o=2&p=16&l=st1&mode=books-uk&search=potter&f=ifr&f=ifr&internal=1