Building a CDN on Amazon s3 to host CSS and Javascript for Pardot Landing Pages.
We’ve been working with a client for a good few months and they’ve just moved to Pardot. During the pre-Pardot era, we naturally built many emails and landing pages. The landing pages used Javascript, Custom Fonts and had various other cool things like support for retina display.
As we were making the move to Pardot we wanted to:
a) keep our awesome, modern and beautifully coded landing pages
b) host our landing pages on Pardot (so we could do cool stuff like multivariate testing)
and c) achieve lightning speed load times.
My post originally said this:
As you may be aware — you can’t host scripts on Pardot. Thus the idea of the s3/CloudFront CDN came into play. Please see note at the end of the article.
In the interest of making sense, I’m going to start at the end.
This is a Pardot Layout Template.
You will see it links to two CSS Style Sheets (highlighted).
Static.Kimble.Digital is our s3 bucket with Cloudfront Support (eg the CDN)
where we can host static client files — like CSS and javascript.
The second image (above) shows we’re also hosting images on the CDN — with retina support functionality (2x). These images could of course be hosted on Pardot itself, but in for a penny…
Incidentally, the main stylesheet references a custom font family (Greycliff) which is also hosted in our S3 bucket.
This is the result: https://go.pardot.com/l/532242/2018-04-05/2rmcl4r
You will note :
- The above is a Pardot landing page with an embedded Pardot Form
- There are 251 lines of code in the source (There are actually only 80 lines of code in the layout template — the pardot form values add a lot of lines).
- The page is built in HTML5 / CSS3 — the latest standard in web development
- The page uses a Custom Font
- The page has full Retina support
- The load time is 1.03 seconds (to put things into perspective that’s faster than Pardot’s and Salesforce’s simple demo pages).
So now you know the WHY, let’s look at the HOW.
Setting Up your s3 bucket
A bucket is a logical unit of storage in Amazon Web Services (AWS) where you host files. To set one up you will need to log into AWS. If you don’t already have an account, set one up on aws.amazon.com. once you get through to the console, Type S3 in the search box select the top option.
Set up a bucket on the next screen and then use these settings:
We’ve disabled website hosting because that will be managed through CloudFront.
Setting up your Custom Domain on Route53
You now need to setup a domain for your bucket to use. Go back to the AWS Management Console and search for Route53 — this is Amazon’s DNS and domain registration console.
We registered a new domain (kimble.digital) but you can also transfer existing domains to the AWS service.
Once you have registered or transferred your domain, AWS will set up something called a Hosted Zone where you can manage DNS settings.
In the Hosted Zone settings we link our domain directly to our s3 bucket by clicking ‘Create Record Set’
You’ll notice we set up three CNAMES linking to kimble.digital, www.kimble.digital and static.kimble.digital. The value on the right of the screen is the ‘s3 bucket end point’. Click here for info.
At this point you should be able to upload a basic ‘hello world’ HTML file…
To your s3 bucket (index.html) …
Which should hopefully work like this:
Setting up your SSL
We of course want our style sheets and files to be secure. SSL is free on Amazon! Go to the main dashboard and search for ‘AWS Certificate’ and you will happen upon this...
Click ‘Get started’ on Provision Certificates and walk through the steps. We got our certificate set up in about 10 minutes — it’s extremely easy if you purchased the domain through Route53.
Setting up your CDN (CloudFront)
Go back to the AWS Management Console and search for Cloudfront— this is Amazons Content Delivery Network. Click through and select ‘Create Distribution’
On the next page you can select your s3 bucket. These are the settings we used. That’s it really on the CDN front — Amazon will configure this automatically.
You now need to go back to Route53 and configure your Cloud Front CNAME’s. More info on that here.
Using your new s3 bucket and CDN.
We prefer to upload and change files in our bucket through an FTP client called Transmit by Panic by you view and upload files directly through the AWS Management Console by clicking on your bucket name…
You should be all set up now — but do read the two tips below!
Versioning and Flushing
The very nature of a CDN (Content Delivery Network) is to use multiple servers across geographic locations to deliver content. Global content requests automatically get routed to the closest servers, speeding up page loads, maximising bandwidth and providing identical content. When you a view a web page or access a file like an image or stylesheet, the local server which services you all the information caches all of the files.
This means that when you update code or images on the server, it’s highly unlikely you will see the changes take place on your landing page — because the landing page is loading the cached version.
You have two options — versioning or flushing.
Versioning
The idea of versioning is pretty simple. Eg — You make an update to the main.css file. You upload the main.css to your server -replacing the older version. You refresh the webpage and alas see no changes (because the old main.css file has been cached by servers around the world).
So instead of doing that… you rename the file as mainV1.css and upload that to the server. You then change the layout template to reference mainV1.css instead of main.css. Reload the page and will now see the changes.
This is versioning in action:
With the above example, let’s say we’re now happy with indexv23.html
What we do now is delete all the other versions (you may want to make a copy first) and rename indexv23.html to index.html.
Now you want to flush the CDN — to essentially reset all the geographic servers, so they have to come and pull the file again — which naturally contains the correct code.
Flushing (Invalidations)
In Cloudfront, Cache Flushes are know as Invalidations. At the point you want to flush you will need to go to the AWS Management Console and search for Cloudfront.
Once there you click on your CDN ID, hit the Invalidations tab and select Create Invalidation. A simple /* will flush the whole server, or you can specify a path or multiple paths if you wish.
You could of course do this every time you update a file but that’s is quite time consuming and there is also a limit on the amount of ‘free’ invalidations you can execute each month on AWS (c1000).
That brings us nicely on to costs…
S3 Bucket — Free ( 50 GB Data Transfer Out and 2,000,000 HTTP and HTTPS Requests each month for one year).
SSL — Free
Cloud Front — $0.085 for first 10 TB / month
Domain — Various depending on TDL. We paid $29 for .digital (.com is $12)
Summary
At Kimble Digital we love to share the wonderful (if a little geeky) things that can be achieved with Pardot and in this case AWS. This guide is in no way bullet proof and it’s purpose is to demonstrate what can be achieved.
We hope you found it useful and good luck if you’re going to give it a whirl.
A big thanks to @KnowlesJames for inspiring this project (and helping us with the CORS issues — which we may write about another day).
Correction:
Having done further testing (22.05.18) following a chat with Zach Bailey, it transpires that you can host your scripts and main CSS on Pardot. I however believe there is still a case for s3 if you want to work at speed through an SFTP client.
