Taking A Landing Page from 2 Seconds' Loading Time To 34 Milliseonds Loading Time (40)
Taking A Landing Page from 2 Seconds' Loading Time To 34 Milliseonds Loading Time
No, that's not a typo. It's really possible to get your LPs in front of the user in sub-100ms times - which research shows can skyrocket your CTR (and here are the results of Stack That Money's own testing to prove it!)
I'm using an old landing page of mine for this tutorial, back from when I was starting out with POF. It's actually based on one of the landers Stackman gave away a while ago - but I assure you, all the mistakes made in the initial design of the lander are mine alone 
The First Draft
Here's what the first version of the landing page looked like, and here's its loading speed from the USA according to Pingdom:
1.70 seconds - not too bad, right? Actually, yeah, that's pretty bad. I know from the research I'm probably dropping conversions at that speed, and all it'll take is one slow connection for it to go over the magic 2 second mark and users to start clicking away in droves.
The raw HTML for that original version of the page (minus some key features like my tracking domain) is attached in a zip file at the bottom, if you want to follow along!
Confused?
I'm assuming a basic knowledge of HTML and Cascading Style Sheets in this tutorial. However, I want it to be useful for everyone!
I've tried to avoid jargon, but if there is anything you don't understand in here, please do hit "reply" and ask WTF I mean. I'll answer and update the case study to make it clearer!
Too Long? Didn't Read?
This is a pretty big case study. If you just want the key bullet points without the details, here's a quick summary:
- Put all your styles in the main landing page, not in separate files.
- Watch out for web design programs adding CSS or Javascript you don't need - take it out.
- Load Javascript just before the </body> tag if you possibly can. Avoid Javascript in the <head> unless it's vital.
- Photoshop Image Slicing produces very inefficient web pages. It's better to export as a single image, and even better to just export images you need and place them with CSS Positioning.
- If you possibly can, text on your LP should be HTML, not an image. It looks better and speeds up your page at the same time.
- Finally, better-optimised servers can shave up to half a second off your LP's loading time, even when they're not under load, and having a server in the same country as your offer can shave even more time.
UPDATE - I've attached the source of the final lander with images, in case it's useful!
good stuff... ya page load speed is critical. easy way: get a coding ninja to code it. I have 2 coders, their code is super clean and lightning fast.
Stage 1: Remove Unnecessary Javascript and Stylesheets
Opening up the HTML for the page, I noticed something straight away: I had both some Javascript and a stylesheet loading in the <HEAD> portion of the document.
<head> <title>Chat To Girls Looking For Heavier Guys Now!</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <script src="scripts/jquery.min.js" type="text/javascript"></script> <LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen> </head>
Most Web speed guides will tell you to put your stylesheet in a separate file, but that's actually a bad idea for a simple affiliate marketing campaign. The reason to put the stylesheet in a separate file is so that the browser caches it - it slows down the loading time on the first page a bit, but subsequently speeds up later loads on the same site. However, we're not really expecting our visitors to come back to visit our LP again later, so it's just a slowdown for us.
I pulled the script loading line out and copied the stylesheet into the landing page - it turned out it was only one line of code anyway! My <head> now looked like this:
<head>
<title>Chat To Girls Looking For Heavier Guys Now!</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
.wrapper {style="width:902; margin: 0 auto; border: thin #124760 solid; border-top: none; border-bottom: none}
</style>
</head>
Stage 2: Revert To Single Image And Optimise
Looking at the code of my landing page, it was obvious that I'd exported it straight from Photoshop using the Slice tool to cut it up into a bunch of images. 1999 had called, and it wanted its web design techniques back:
<tr> <td colspan="2" rowspan="5"> <img src="images/ChatLander2_02.jpg" width="268" height="353" alt=""></td> <td colspan="2"> <img src="images/ChatLander2_03.jpg" width="323" height="86" alt=""></td> <td colspan="4" rowspan="2"> <img src="images/ChatLander2_04.jpg" width="309" height="270" alt=""></td> <td> <img src="images/spacer.gif" width="1" height="86" alt=""></td> </tr>
Photoshop places its exported images using HTML tables. That table code also bloats the HTML of our page, and it makes rendering more complicated for our user's browser. You might not think that's a concern, but speaking as the guy who back in 2000 managed to author a web design which would crash many browsers just because of the pile of nested tables in its code, I can assure you it does have an impact!
(We didn't realise our site did that for about six months. The day we discovered that little fact was not a fun day in the office.)
So, to make our lander faster, it's time for the nuke-the-site-from-orbit approach. I went back to the original Photoshop document, cut out the Call To Action layer as a separate image, and then removed all my slices and exported the whole thing as a single image. Then, I placed the button back where it was originally using the following bit of CSS:
.button {position: absolute; top: 477px; left: 555px; }
A quick Pingdom check showed that the loading speed had gone up slightly to 1.2 seconds, but the number of separate elements I was loading had gone down from well over 20 to 3 before the page was loaded. In addition, my HTML was now far simpler. In real terms, that was almost certainly a speed increase.
But it was still too damn slow. So I did the simplest thing that I (and most people) forget to do: I optimized the image size.
Going into Photoshop's "Save For Web" dialog, I tested GIF, PNG and JPG, looking for the lowest possible quality setting at which point I couldn't see any difference in the image. In Photoshop, there's a handy preview, but any image editing program should be able to move JPEG quality up or down when you're saving an image.
Most people, I've noticed, tend to save their images around the 80-90 quality mark in a JPEG. That's actually a huge waste for most Web images: I've found you can set some images as low as quality 20 without a noticable difference.
In this case, I set my image to Quality 30, Progressive (which chopped a few more k off), and no blur. Then I took the produced image and ran it through Smush.it, which is horrendously slow but removes some additional unnecessary data.
In the end, I'd reduced the image size from 200k to 70k.
I saved the button as an 8-bit PNG, chopping a third off its image size too.
Stage 3: Actually Use Some HTML
It's very tempting to use Photoshop for all our text - and I've seen plenty of LPs that do - but that's actually a bad idea.
For starters, it bloats our images: a picture of the words "We Have TOO MANY WOMEN!" takes up a lot more download time than the same words in text.
But the more important reason is that it doesn't look as good. For various reasons to do with the hundreds of millions of dollars that have been sunk into display technology over the years, text in HTML will almost always look crisper and easier to read than text in an image. I've tested this, and have actually seen a 3-4% boost in CTR just by switching a lander from text-in-image to HTML text.
So, I go back to my lander in Photoshop, and export each of the sub-images (the header, the picture of the girl at the left, and the two grids of "profile" images) separately, then line the lander up as three CSS floating columns. (I'm skimming a bit here - comment below if you'd like more detail on how to do this.)
This takes a little while, but I end up with an HTML body like this:
<body bgcolor="#FFFFFF" leftmargin="0" topmargin="0" marginwidth="0" marginheight="0">
<div class="wrapper">
<img src="topbar.gif">
<div class="left"><img src="leftpic.jpg"></div>
<div class="midbar"><h2>Guys 25-45 Needed! Join Free</h2>
<h3>Mate1.com is overwhelmed with more women then men for each session</h3><img src="mid.jpg"><p>Currently FREE for Men In {state:}</div>
<div class="right"><h2>Find ONLY Girls Who Like Husky Guys</h2>
<img src="right.jpg"><p><a href="HC-Stack-Rot.php"><img src="button.png"></a></div>
<div class="button"><img src="Arrow.png"></div>
</div>
At the same time, by doing this the size of the page goes down even more, from 70k of images to 42k of images.
Initially, it appears that we haven't chopped much loading time off the page:
That's disappointing. But then I notice that wheras before, the element taking the longest to load was the background image:
after this stage, the last element to load is Prosper's tracking script:
That's EXTREMELY good, because the tracking script actually loads after the rest of the page is already visible - so from the user's point of view, the page is loading in more like 500ms!
Stage 4: Move To An Optimised Server In The Right Country
At this point, I've optimised my actual page about as far as I can push it - but this code is still running on my old server, which is in the UK, running fairly unoptimized Apache as its web server.
So I copy the entire thing to a VPS I'm running on Linode in the USA, using the web server Nginx and the memory caching software Varnish:
WTF? It's gotten slower? What the hell?
But then, I look at the loading time graph, and understanding dawns:
I've still got my old tracking code on there, and that's calling back to the UK. But that's not a problem, because Prosper's coded in a smart way: all of the landing page tracking happens invisibly after the page has loaded. Pingdom just isn't clever enough to realise that by the time we start loading the tracking code, everything else is already done.
Of course, having my tracking server in another country's still going to be a pain in the ass later, because it'll slow down my redirects from my lander to my offer page. But I'm going to say redirect speed is Future Caurmen's Problem (and possibly a future case study too!).
For the time being, we need to know how fast the LP appears to load to the user - so I temporarily remove the LP's tracking code.
And here's the result:
Now THAT is a fast lander.
Postscript: Do You REALLY Need Servers In Every Country?
I really hate to recommend getting yourself a server on every continent, or even in every country, that you're running offers. I know, it's expensive, it's a pain in the ass, and it gives you all kinds of exciting tracking problems.
I certainly don't run servers on every continent myself. But based on the research I've been doing recently, I'm starting to consider at least getting a server in the countries where I'm running significant volume.
Some of you will be saying "ah, yes, but you ALSO moved to a better-optimised server. That's true - but there's an easy way to check whether it was the server or the location that had a bigger effect, by running a Pingdom check on the new server from the old server's location - Northern Europe:
Clearly, the better-optimised server has a pretty significant effect, to the tune of about 300ms. (I'm going to do some server optimisation tutorials next week.). But so does moving country - a 400ms improvement.
Overall, it's clear that you can massively improve your page speeds before you need to think about moving to a server on a different continent. Using a CDN (Content Delivery Network) would speed that load time up even more. But if you want the absolute best response time, it's clear that the geographical location of your servers does make a difference.
-Aaron
Hey Caurmen, great guide! Any chance you can upload the final source?
Great case study! I would think that with mobile traffic the load speed of your website makes a much bigger difference as well. If anyone knows any coders who can go through my landers and optimize the speed on them please point me in the right direction.
Holy fuck. Brilliant write up.
Take a bow son.
Great guide
Good tips, may I suggest Google Hosted Libraries google hosting for the jquery, most people have that cached already so no need to re-download it.
Amazon Cloudfront for static assets such as css and images.
Thanks, everyone! Glad it was useful!
@matthewk - thanks! I forgot to mention that - good catch. Downloads of Jquery from the google hosts are usually close to instant even if the browser doesn't have it cached - last time I benched them it was around a 42 ms load.
@thomasbhm - sure thing! It's attached below.
What also helps a lot if you have many images like this lander is if you make a css sprite from the image, there are generators that do all this work for you, like this one: http://draeton.github.com/stitches/
You put the generated css directly in the lander like Caurmen said, and on top of that you could use Amazon Cloudfront or a similar CDN and host the image there, trick there is to create a subdomain on your lander and add the ip of your CDN bucket as cname to your domains DNS so your css would look something like this:
.sprite {
background:url(http://subdomain.mylander.com/imgs/mysprite.png) no-repeat;
}
.sprite-ad-png {
width:16px;
height:11px;
display:table-cell;
background-position:-378px -132px;
}
Or: <img src="http://subdomain.mylander.com/imgs/myimage.png"> if you use single images, if you do use single images it can be a very good idea to use multiple cname subdomains to serve them. I once had a wordpress movie site, the category pages consisted of 50 images (movie posters) and the database had I think 500K movies in it with tags and the whole shebang. Using 8 cnames to deliver javascript, css and images helped me bring down loading speed of that site to 600 ms. Which is really fast for a wordpress site of that size (Of course db queries were highly optimized too).
PS: If you use subdomains to serve your images, do not have scripts on those domains that set cookies. That would increase the loading time, so simply have your amazon cloudfront bucket and add it's ip as cname to your subdomain (or multiple subdomains) and you're good to go.
I do a lot of the same things and had considered doing a similar write up at some point. Only thing I'd add is you can use css gradients for your buttons instead of images.
I don't think you need varnish for your everyday landing page. It's mainly for sites that connect to a database to retrieve content, eg wordpress sites.
Sprites are good, but they make creating new variations time consuming. I'd save that for when you've got a decent LP first.
The thing that sucks is no matter how fast your LP loads, the weakest link is often the advertisers page crammed full of javascript. I've seen advertisers with mobile landers with jquery up the wazoo totaling 500k, and dozens of requests in some instances.
So pretty much I just do try a reasonable job of following best practices to keep page size and requests down, and worry about heavy optimization later once things are going well.
I'm going to have to look into amazon cloudfront though as that's the bulk of my page load time on pingdom. Looks pretty damn cheap if you keep your assets small.
Shit you don't stop son! Implementing a few of these tips today.
One other thing to use: gzip! it compresses html, css, and javascript a lot. In my case a 80kb javascript file got reduced to 20 something kb. If you have a managed host this is probably already enabled, but you can check your headers @ http://web-sniffer.net/ to see it's working. It should show under 'Accept-Encoding'.
As far as CDNs, I setup Amazon Cloudfront for all my images and javascript but didn't notice much of any difference between that and just using Coudflare, which also acts as a CDN. I researched CDN performance but it seems like the fastest ones cost hundreds per month.
Caurman, you're an absolute beast haha, will put this all on test tomorrow!
This sort of shit can add so much to your bottom line when you're running volume!
@szmudo - I tend to find that making a CSS sprite is marginally useful with 4-5 images, but I agree, if you have 20 or more images, USE SPRITE TECHNIQUES. I recall dropping the loading speed on one of my better known sites like a stone when I first discovered this technique. It's a PITA to implement, but worth it for lots of images.
Also, good tips on using multiple domains to host image-heavy pages. I may actually do a separate tutorial on long-form landers at some point - different techiques required. If you're going to use a bunch of domains, I'd recommend setting up an Nginx server to serve the images from them if you're not going the full CDN route - Nginx is a beast at serving static files.
@thedudeabides - I haven't tested Varnish vs no Varnish with this LP, but I'd be inclined to agree with you - particularly if your server uses SSDs.
In this case, I already had it set up on the server so it would have been harder to NOT use it! gzip is excellent if you're running a longer lander. I probably should have put it into this one just for completeness, but given how small the text was, it barely reduced the load time at all. However, if you're using a long Javascript, CSS or HTML file, god yes - great tip. (I shall be mentioning gzip again in the near future...)
@Maynzie - Thanks! Yeah, it's definitely something to look into once you know you've got an offer that works. It's just unreal how much peoples' perception of a page changes based on their speed!
@MrGreen - cool! As always, interested to hear how well things work, and if you hit any problems!
Instead of servers all over optimize your images then drop them on a CDN with gzip turned on. Coupled with an nginx box with varnish and you are golden. If you don't want to paste your css in the header you can load the file externally from a CDN too.
All the pain of doing all these steps manually all the time, will be over... soon ;o)
If you want to use css for your button rather than an image, check out http://www.cssbuttongenerator.com/.
For sites that use a high number of images its also good practice to parallel load your images. Browsers only run 2 concurrent connections per domain, you can get around this by using multiple subdomains for your images. Ex.. image1.site.com image2.site.com Downloading all of them at the same time decreases the amount of bandwidth available for any individual image but will maximize the overall bandwidth usage leading to faster load times. This can also help with those large JS files that you just cant avoid putting in the head or high in the body.
To make up for the lost bandwidth per image and really capitalize I convert all of my images to png and use http://tinypng.org/ to shrink them down as small as possible without giving up image quality.
With modern browsers it appears the default number of simultaneous connections is closer to 6 - http://www.browserscope.org/?category=network
In any case if the site is data heavy then designing it to use sprites/CDNs/async or deferred javascript loading and of course optimising images is probably a bigger issue to deal with.
Yup, most modern browsers will run 6 simultaneous connections.
If you're going to use multiple domains (which can be a useful technique in some circumstances, although I wouldn't recommend it all the time), do bear in mind there's an additional time cost for performing the lookup on that new server, and for connecting to it. Sometimes that can be worth it, sometimes not - test and see!
Originally Posted by caurmen
Go to tools.pingdom.com and type in your URL, then hit "Start Test". Those results will come up at the top of the page.
Caurmen, my man -- I am starting to love you (no homo)!!
Advice here is golden and actually -- when I implement it -- expect to boost my bottom line.
Yeah man, Caurmen is on point with this stuff. My server located in Central US, I have been running some tests on my end for a while, and in general I am seeing about 300 ms avg load time difference between US and Europe. Makes me wonder, how much money I am leaving on the table when I'm running Mobile offers in Europe, or elsewhere with my server location in the US. I would venture to guess that 300 ms delay is probably equal to about 5-6 % leak in overall ROI.
Wow! So many excellent tips! Thanks for sharing
@testosterone - glad it helps!
@vp5005 - I'd guess at least that, yes. Maybe even more. Mobile is pretty sensitive to load speed.
Thanks Caurman, Got my lander down from 800+ ms to 195 ms
Originally Posted by kidooo
The only similar option i see is this, but not sure which option to choose
Apache 2.0 and newer allow you to compress content before sending it to the visitor’s browser. The types of content to be compressed are specified by MIME type. This feature requires Apache’s mod_deflate to function correctly.
Disabled
Compress all content
Compress the specified MIME types
Originally Posted by dconstrukt
Thanks
Dconstrukt is referring to hiring a coder, probably from odesk or similar.
Hi, i'm feeling a bit sluggish at DNS & SSL & connect.. can anyone recommend me what to do?
what factor is defining DNS? is it hosting? smaller size? or html/script itself?
(i'm already combining css to html, javascript at before /body tag, using starter package beyondhosting btw)
i know SSL oftenly make slower, is it any benefit using SSL?
Great tips! I used to got mental with landing page speed optimization and then started getting into more popunder traffic. I assume for popunders specifically, load time is much less of a factor because it loads under the current page. Is that a safe assumption?
Originally Posted by caurmen
Opening up the HTML for the page, I noticed something straight away: I had both some Javascript and a stylesheet loading in the <HEAD> portion of the document.
<head> <title>Chat To Girls Looking For Heavier Guys Now!</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <script src="scripts/jquery.min.js" type="text/javascript"></script> <LINK REL=StyleSheet HREF="style.css" TYPE="text/css" MEDIA=screen> </head>
Most Web speed guides will tell you to put your stylesheet in a separate file, but that's actually a bad idea for a simple affiliate marketing campaign. The reason to put the stylesheet in a separate file is so that the browser caches it - it slows down the loading time on the first page a bit, but subsequently speeds up later loads on the same site. However, we're not really expecting our visitors to come back to visit our LP again later, so it's just a slowdown for us.
I pulled the script loading line out and copied the stylesheet into the landing page - it turned out it was only one line of code anyway! My <head> now looked like this:
<head>
<title>Chat To Girls Looking For Heavier Guys Now!</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style>
.wrapper {style="width:902; margin: 0 auto; border: thin #124760 solid; border-top: none; border-bottom: none}
</style>
</head>
Stage 2: Revert To Single Image And Optimise
Looking at the code of my landing page, it was obvious that I'd exported it straight from Photoshop using the Slice tool to cut it up into a bunch of images. 1999 had called, and it wanted its web design techniques back:
<tr> <td colspan="2" rowspan="5"> <img src="images/ChatLander2_02.jpg" width="268" height="353" alt=""></td> <td colspan="2"> <img src="images/ChatLander2_03.jpg" width="323" height="86" alt=""></td> <td colspan="4" rowspan="2"> <img src="images/ChatLander2_04.jpg" width="309" height="270" alt=""></td> <td> <img src="images/spacer.gif" width="1" height="86" alt=""></td> </tr>
Photoshop places its exported images using HTML tables. That table code also bloats the HTML of our page, and it makes rendering more complicated for our user's browser. You might not think that's a concern, but speaking as the guy who back in 2000 managed to author a web design which would crash many browsers just because of the pile of nested tables in its code, I can assure you it does have an impact!
(We didn't realise our site did that for about six months. The day we discovered that little fact was not a fun day in the office.)
So, to make our lander faster, it's time for the nuke-the-site-from-orbit approach. I went back to the original Photoshop document, cut out the Call To Action layer as a separate image, and then removed all my slices and exported the whole thing as a single image. Then, I placed the button back where it was originally using the following bit of CSS:
.button {position: absolute; top: 477px; left: 555px; }
A quick Pingdom check showed that the loading speed had gone up slightly to 1.2 seconds, but the number of separate elements I was loading had gone down from well over 20 to 3 before the page was loaded. In addition, my HTML was now far simpler. In real terms, that was almost certainly a speed increase.
But it was still too damn slow. So I did the simplest thing that I (and most people) forget to do: I optimized the image size.
Going into Photoshop's "Save For Web" dialog, I tested GIF, PNG and JPG, looking for the lowest possible quality setting at which point I couldn't see any difference in the image. In Photoshop, there's a handy preview, but any image editing program should be able to move JPEG quality up or down when you're saving an image.
Most people, I've noticed, tend to save their images around the 80-90 quality mark in a JPEG. That's actually a huge waste for most Web images: I've found you can set some images as low as quality 20 without a noticable difference.
In this case, I set my image to Quality 30, Progressive (which chopped a few more k off), and no blur. Then I took the produced image and ran it through Smush.it, which is horrendously slow but removes some additional unnecessary data.
In the end, I'd reduced the image size from 200k to 70k.
I saved the button as an 8-bit PNG, chopping a third off its image size too.
This thread helped me a lot. Was optimizing most of the day yesterday and achieved huge improvements, especially for bigger pages (mobile advertorials).
Since they were ripped I've found lots and lots of javascripts and css that actually weren't used. Not to mention images weren't optimized and so on.
Smush.it didn't work at all for me (waited 2 hours for it to compress 10kb image, lol), so I've found something much better - http://sapegin.ru/projects/picturebeaver
It's almost instantaneous (compressed 50 images in few seconds) and the compression is quite good - shaved 52kb from 50 images from total of 350 to 298kb.
@duck_noodle - get DnsMadeEasy it's very effective.
Thanks for sharing. Is this still relevant? Whenever I hire a developer to optimize the speed, the fastest has been 2.5+sec. can't wait to hand this info over to a dev if this still works...
Almost everything is still relevant.
What is not relevant anymore:
1) put JS script at the bottom before </body>. You can now put them in the head with a 'defer' parameter. It does not block rendering the DOM, but the JS is downloaded while the browser is rendering the DOM.
2) use sprites and/or subdomains to serve images / js / css. With HTTP/1.1, browsers had a limitation to 6 concurrent downloadings. Most browsers now support HTTP/2, which does not have this limitation. Furthermore, browsers now support lazy loading, so focus should be on serving images visible when the page appears (above the fold). The rest is loaded while the user starts to interact, or is not loaded if he does not (less GB transferred for pop traffic).
Home > Technical & Creative Skills > Programming, Servers & Scripts