Loading Times For Pop Traffic: The Go-Faster Cheatsheet (30)

STM Loading Times For Pops Cheatsheet

If you're running pops you'll hear people banging on and on about loading times and how important they are.

For good reason - loading times affect pop performance a lot, more than any other traffic source.

But how do you achieve those lightning-fast loads?

Here's our handy cheatsheet to answer that.



Loading Times: The Basics

• DO optimise your images. Image optimisation is usually the biggest improvement you can make to a slow page. I find https://imageoptim.com/mozjpeg/ produces the best results for JPGs, but others swear by http://www.kraken.io for ease of use.
• DON'T use all-image landers. Using a lander made of a single image is fine for a quick test, but having it properly coded will make it load much faster AND look much sharper.
• DON'T run Wordpress for your landers. Even highly-optimised Wordpress run by experts is still several times slower than a straight HTML page. A Worpdress install you haven't spent days tweaking is likely to be MUCH slower than that.
• DO remove tracking once you have optimised the campaign. Tracking redirects add 300ms or more to loading times. That's significant. Unless you're using a non-redirect-based tracker, removing tracking on an optimised campaign is likely to give an ROI boost.
• DO use the right type of image. PNGs for text and drawings, JPGs for photos. They'll compress better and look better too.
  

• DO Test your load times. Often. For a very simple test, http://fpt.pingdom.com is easy and fast. However...
• DO test your load times from the geo you're actually running. If you're targeting Malaysia, for example, testing load times from the US is close to useless. https://www.dotcom-tools.com/website-speed-test.aspx provides a decent overview of speeds from around the world.
• DO run RUM testing if you can. RUM - Real User Monitoring - is a much more accurate and effective way of testing the loading speeds that real users are seeing. You should test load speeds the simple way first to spot obvious problems, but running RUM is definitely something you should do when you start running your campaign. Here's a guide to that
• If you're using a VPS, DO stress-test your server too. It doesn't matter if your lander loads fast when only one person's loading it - it matters that it ALWAYS loads fast. Make sure to stress-test any servers you rely on.
  

• DO split-test a VPS against a CDN. Oddly enough, CDNs are not always faster. If you can get a VPS close to your target geo, it's definitely worth split-testing loading times from that vs from a CDN.
• DO choose the right CDN CDNs vary wildly in exactly how fast they are. Ask around on STM for the best one, and check tools like Cedexis Radar to get benchmarks.
• DO use libraries hosted by Google. If you've gotta use a Javascript library like JQuery, it's far better to reference the one hosted by Google - there's a very good chance that users already have it loaded, saving you significant loading time.
• DON'T stress too much about your web server software. Nginx vs Apache vs Litespeed vs Node vs whatever doesn't make a huge difference to loading times- in the order of single milliseconds. It CAN make a difference to the volume of traffic your server can handle, but a well-configured instance of any of the above server software will do fine.
• DON'T use a lot of dependencies from other sites. If your server's faster than Usain Bolt on a caffeine high, but your lander requires Javscript and CSS from 15 other sites before it renders, it's still going to load as slow as all crap. Avoid external dependencies as much as possible.
  

• DON'T use PHP where Javascript will do. If you can manage to serve pure HTML and Javascript rather than requiring server-side code, you can use much more minimal server setups, as well as CDNs, generally meaning much faster pages. (If you use a lot of Javascript rendering time can be a problem, though, so watch out for that!)
• DO be careful about web fonts. Web Fonts look pretty but they can really slow your page down. Try to avoid them - see my tutorial on typography.
• DON'T add JQuery unless you really need it. You usually don't need JQuery. Sure, it makes coding in Javascript neater and easier, but almost anything you want to do with it can be done using much smaller libraries or just native Javascript. And it's pretty big - around 50kb, which makes a difference.
• DON'T use Bootstrap for mobile sites (usually). It's easy to use and makes designing quite pretty responsive sites fast, but it's also BIG. Try to use either a much smaller framework or no framework at all.
• DO use Prefetch, Prerender, etc. Offer page loading times matter too. Prefetch large assets on the offer page, preconnect to your tracker, your aff network and the eventual domain, and if you don't mind screwing your stats up a bit, prerender the entire thing.
  

A must-read for ANYONE running pop traffic! Thanks caurmen!

For other good threads on page load times - see this thread under "Try decreasing your page load speed!":

http://stmforum.com/forum/showthread...-AM-FAQ-Thread!



Amy

Thanks for this guide Caurmen!

Originally Posted by caurmen

[size=6][*]DO remove tracking once you have optimised the campaign. Tracking redirects add 300ms or more to loading times. That's significant. Unless you're using a non-redirect-based tracker, removing tracking on an optimised campaign is likely to give an ROI boost.

<a href="http://xxxxx.voluumtrk.com/click">
to this:
<a href="offer link from affiliate network">

Originally Posted by caurmen

[size=6][*]DO use Prefetch, Prerender, etc. Offer page loading times matter too. Prefetch large assets on the offer page, preconnect to your tracker, your aff network and the eventual domain, and if you don't mind screwing your stats up a bit, prerender the entire thing.

<meta content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=0" name="viewport">
<meta name="viewport" content="width=device-width">
<meta http-equiv="cleartype" content="on">
<link rel="icon" href="images/win-favicon.png" type="image/png" sizes="16x16">
<title>Hello</title>
<link rel="prerender" href="http://xxxxx.voluumtrk.com/click">
<link rel="preconnect" href="http://xxxx.voluumtrk.com/click">
<link rel="prefetch" href="http://xxxxxx/data/cache/f85074076965e7489255bed59a97d177.css">
<link rel="prefetch" href="http://xxxxxx/data/cache/1072c5018251e8d34d7ec4fff1554c72.js">
<link rel="prefetch" href="http://xxxxxx/media/02e298a9d42e06b5da3057df91d8a47cd124.jpg">
<link rel="prefetch" href="http://xxxxxx/assets/fonts/myriad-pro/MyriadPro-Bold.woff">
<link rel="prefetch" href="http://xxxxxx/assets/fonts/myriad-pro/MyriadPro-Semibold.woff">
<link rel="prefetch" href="http://xxxxxx/assets/campaigns/iphone6s/devices/silver-right.png">
<link rel="prefetch" href="http://xxxxxx/favicon.ico">
<link rel="prefetch" href="http://xxxxxx/assets/campaigns/iphone6s/devices/gold-left.png">
<link rel="prefetch" href="http://xxxxxx/assets/campaigns/iphone6s/devices/gold-right.png">
<link rel="prefetch" href="http://xxxxxx/assets/campaigns/iphone6s/devices/rose-gold-left.png">
<link rel="prefetch" href="http://xxxxxx/assets/campaigns/iphone6s/devices/rose-gold-right.png">

Hmm, that's strange - prefetch is by design non-blocking and works after all assets on the lander have loaded. I've certainly independently tested prerender and verified it loaded assets after the main page.

It might be worth re-checking that yourself using Chrome developer tools (or FF's developer tools) and seeing if the resources are still loading like that. My guess is that it might not be running a full browser implementation and as such is getting a bit confused about the link syntax.

Alternatively, it may be that the bandwidth available is such that it's not blocking anyway. Try taking the prefetch commands out and seeing if the overall load time changes.

Do let me know the results on this one! Prefetch and similar calls are so new that there might well be hidden gotchas that we should be aware of.

Seperate response on removing tracking

Basically, tracking slows your loading speeds down because of all the database calls, redirects, new connections, and so on.

HOWEVER, of course that's a price worth paying whilst you're still optimising.

Once you have a solidly in-profit and stable campaign, though, and once you've exhausted all the ideas you can think of to improve it, there's no real reason to keep your tracking running - just compare costs against revenue each day to make sure it's still making money.

At that point, you can remove your tracking.

You can also do clever stuff with removing your tracking and continuing to track data using your webserver's log files - I've written about that in the past - but that's a pretty advanced approach. Worth doing if you're comfortable enough with it or have a sysadmin you can instruct to do it, though.

Wanted to ask if my tracking is hosted on VPS and my landers on CDN, will the fact that my target geo and VPS location is significantly different impact the load speed materially?

Cause I'm trying to weigh out the pros and cons of switching from a cloud based tracking like Voluum to self hosted solutions like funnel flux. Since I'm running pops mainly the speed is my biggest concern that is holding me back for the switch

@sushiparlour - you're right to be aware of that as a concern. If you're using a conventional redirect for tracking, the location of your VPS will almost definitely have an impact. I'd usually recommend trying to get a VPS with decent peering to your target geo. Doesn't have to literally be in the same country but you don't want to run an AU campaign from a UK tracker, for example.

Alternatively look at using the non-redirect tracking solution that a couple of the new breed trackers are coming out with.

Hey Sushiparlor,

I've just finished testing Funnelflux vs Voluum.

I believe your talking about redirect speeds.

I have a Mobile follow along right now where I was having some landing page speed issue. During my tests, I noticed my redirect speeds using Voluum weren't as fast so I switched over to a VPS (Vultr) and FunnelFlux.

I initially installed Funnelflux on a VPS in America but my target Geo was Australia. Taking this route, the redirect speeds were almost similar (sometimes slower) than Voluum. I then created a VPS in Australia where my target Geo was. I noticed a small increase in speeds over Voluum - but the CVR didn't change.

What I could see provide a better value (and something I'll be testing soon) is what Caurmen suggested:
"DO split-test a VPS against a CDN. Oddly enough, CDNs are not always faster. If you can get a VPS close to your target geo, it's definitely worth split-testing loading times from that vs from a CDN."

This might provide a noticeable difference (hosting your files on a VPS in your Geo) instead of hosting your tracker at the Geo.

Thanks all.

Not sure if this is a basic question since server side stuff is my weak point but is there a solution in which we could have multiple VPS in different geos but all integrate as one pooled tracking software? That way we mitigate the redirect speed issue but can still manage everything in one place?

@sushiparlour - there's no packaged solution for that right now but in theory it's doable. If you're operating at scale it's probably worth talking to the various tracker devs and seeing what enterprise solutions they have along those lines.

Originally Posted by caurmen

@sushiparlour - you're right to be aware of that as a concern. If you're using a conventional redirect for tracking, the location of your VPS will almost definitely have an impact. I'd usually recommend trying to get a VPS with decent peering to your target geo. Doesn't have to literally be in the same country but you don't want to run an AU campaign from a UK tracker, for example.

Alternatively look at using the non-redirect tracking solution that a couple of the new breed trackers are coming out with.

Originally Posted by sushiparlour

Thanks all.

Not sure if this is a basic question since server side stuff is my weak point but is there a solution in which we could have multiple VPS in different geos but all integrate as one pooled tracking software? That way we mitigate the redirect speed issue but can still manage everything in one place?

Originally Posted by Mr Baffoe

Prosper202 has had this option for as long as I can remember, and I know Thrive also launched this feature a week or two ago.

Not familiar enough with Voluum or FunnelFlux to know if they have this. I'm sure someone can comment on this.

Originally Posted by sushiparlour

Thanks all.

Not sure if this is a basic question since server side stuff is my weak point but is there a solution in which we could have multiple VPS in different geos but all integrate as one pooled tracking software? That way we mitigate the redirect speed issue but can still manage everything in one place?

Is it possible to see if the user already has Jquery cached and if not then load it inline? In my tests it seemed like loading it inline was faster, but I'm not 100% sure since the speed tests might not have it cached. Are you saying we should ALWAYS just import Jquery from Google's CDN?

@xxf8xx - there are very few reasons not to use the Google-cached versions, so yes, in practise you probably should unless you have a specific reason not to.

To the best of my knowledge there's no easy way to check if a browser has jquery cached. You might try some of the methods discussed here - http://stackoverflow.com/questions/7...ched-on-chrome - but they only work spottily with images, and the problem's harder with scripts.

@caurmen I remembered you mentioned software to monitor page changes (like in pingdom). This is used to monitor if the offer page has been changed. How would you do something like this when offers may redirect you based on GEO and Useragent?

@quantum27 - At that point you'd want a self-hosted equivalent software hosted in the appropriate geo. Useragent spoofing is comparatively simple so that shouldn't be a problem.

https://sourceforge.net/projects/phpservermon/ is pretty good.

So I have a dedicated cloud server at Beyong Hosting and their own CDN. Now you cant host the main html files on their CDN, but I use it for everything else. I guess I could create a html file on the server with just a redirect to the actual content on the CDN. Would it be worth it though? Another redirect vs the potential benefits of the CDN? How do the speed optimizers of STM handle it?

Also, how much JavaScript would you say is needed to warrant it's own file on the CDN?

hey

can anyone explain what prefetch and prerender is, or link any resources to explain this.

thnaks

Originally Posted by vincent9

hey

can anyone explain what prefetch and prerender is, or link any resources to explain this.

thnaks

Quick question. I read the part where I should remove tracking.. So you mean if ive maxed optimization.. I just direct link to the lander and that to offer? As in completely take Voluum out of the whole flow?

@vyapari - Yes, thats what is being suggested. The reason for that is because your tracking (Voluum or other solution) causes additional redirect times and slows your lander down by 200-300ms. So once you are optimized and profitable, remove the tracking part of your campaign and just monitor revenue and expenses to ensure you stay profitable.

Originally Posted by mrpayne

@vyapari - Yes, thats what is being suggested. The reason for that is because your tracking (Voluum or other solution) causes additional redirect times and slows your lander down by 200-300ms. So once you are optimized and profitable, remove the tracking part of your campaign and just monitor revenue and expenses to ensure you stay profitable.

Do you have any examples on non-redirect trackers? I read your thread on server log based tracking and thought it was really interesting, but a more off the shelf solution would be appreciated (all though I'm going to test that server log based one soon). Thanks!

@jessejames - I believe FunnelFlux and Thrive have that feature available. Keep in mind though that you are not able to use rules to redirect any of your traffic because you will be using your direct landing page url and it gets tracked once the lander is visited.

Yup, both of them now offer non-redirect tracking. Prosper also uses, or can use, non-redirect-based tracking, but I'd recommend one of the other options at the moment as they're more featureful.

It's worth noting that none of these options are using logfile-based tracking as I discussed in that article. They use Javascript-based tracking, which is a slightly different approach.

MrPayne's point on redirect rules is a very good one. You can get around it with clever scripting on the server end (nginx's redirects are probably the best way), but that adds development time.

Thanks. Are you using the server based tracking yourself? I'm thinking for high volume campaigns. I imagine the log files can be pretty large? Ant thought son automating the log file transfer to a tracking solution?


An appealing thought would be that amount of data + some sort of machine learning/big data approach to it (combined with data from CAKE) -- but that's above my level on "computer stuff".

do you guys see that on mobile pop traffic there is a big time delay between the click and the conversion? on desktop traffic this can go up to many days or even week (until the cookie duration runs out) but I have the feeling the time different click vs conversion is not so big in mobile. whats your experience?

@jessejames - Sometimes, depends on the traffic source. Often I'll still use something like FunnelFlux or my own internal tracker for simplicity.

The log files get large-ish: they're very compressable. Automated transfer to another system that does the processing is definitely the best way, though.

You are absolutely correct: these log files are definitely ideal candidates for machine learning analysis. You could use a tool like WEKA for that if you don't want to get into the coding (which as I mentioned at AWE is super-complicated).

Cool, I want to look into that. Amazon also have a machine learning thing on AWS, I haven't tested it though.

Too bad I didn't go to AWE hehe


Also for speed optimization, I typically make CSS sprites for larger-ish images and base-64 encode images that are small. Seems to help. Also moving any sounds or any javascript I can to the "footer" of the lander, so some of the page will render for the user.