Home > Technical & Creative Skills > Programming, Servers & Scripts

---

Improving offer loading speed (12)

---

Hi there. It really depends on what your flow is.

If you're redirecting instantly, it's pretty hard to control what the offer loading speed will be or it's actual speed
since you don't control the offer, server, provider.

If you are referring about your LP then there are a few things you can do:
- inline css / javascript ( a must ) - it can be done on the fly if you request your LP via a PHP file that
puts everything in the LP then save that output to the CDN ( basically you save the HTML ) - http://subdomain.yourdomain.com/lp1.html
- inline images inside css ( data-url )
- try to use the lite versions of js libraries if you're using the big thing
- minify the js / css in the first step
- run your images through a compressor ( png - TinyPNG.org, jpg, gif etc on their own services )

This way you will have only 1 network call compared to 9 you have right now, thus removing
unnecessary connections and TTFB wait lines

Your inline JS shouldn't be more than 10-15kb and the overall page more than 25-30kb
( this if you're running pops - but still a good practice to have it small if possible - and usually it is )

Cheerios

---

Glad it was useful!

Slightly hard to debug this without more information on what we're seeing in those waterfalls.

What's your funnel, and what traffic source are you using? Do users go to a lander first or straight to the offer?

---

First make sure pre-render is enabled on your browser http://prerender-test.appspot.com

Next thing is to be careful with prerender. Depending on the network/offer and how they inspect traffic there is an aspect of cookie stuffing going on whenever you prerender an affiliate link/url so an actual pre-render could cause you to get banned.

Also it's better to prerender the final page and not the redirect link that leads to the page.

Prerendering is still messy on the edge cases etc, so the less work the browser has to do to figure out how to correctly prerender the better.

Discussions on the chrome dev channels indicate that they plan to disable prerender (currently it's disable in some of the recent test builds)

So in addition to prerender you also want to check out dns prefetch

---

Glad you enjoyed the speech! It was fun to give.

MrBaffoe is very much the man on this sort of thing, so definitely listen to all his advice, above.

In addition to what MrBaffoe says, above - it looks like the waterfall may be a bit misleading here. The numbers and the placements on the waterfall graph don't add up: my suspicion is that the "time" listing for each of the assets is the time it took to load, whether or not that time was whilst you were looking at the lander. (Having a quick look at the detailed docs for Chrome dev tools seems to imply that's the case.)

Note that if you add up the time to load your initial lander and the time to load the Voluum redirect, they add up to 1.84s + 2.11s = 3.95s. Total content load time is 4.28s. So that implies your actual offer page is, in real terms, loading in 0.33s, which sounds a little sluggish for a prerendered page but in the right ballpark. (The rest of the time will be actual browser render time, which we can't do anything about.)

The placements of loading bars on the waterfall indicate that your biggest visible-to-the-user slowdown by far is the Voluum redirect. I'd talk to Voluum support about that - may be misreading the chart, or there may be things they could do.

What's your experience as a user when going through the funnel through your VPN? Does the offer page seem to load very quickly? Try preparing two funnels with and without prerender, and comparing them (remember to clear your cache first!)

P.S. - Obvious thing I forgot: are you loading the lander, then waiting a few seconds, then clicking through? Prerender uses the time whilst you're reading the lander to load the next page - so if you click through instantly it doesn't get any time to load!

---

Thank you @Mr Baffoe and @caurmen, very insightful answers.

Mr Baffoe: Indeed, the first thing that I checked is probably the best and simplest explanation: prerender was disabled as default in Chrome. I'll try to implement dns prefetch instead and see how it goes.

caurmen: Voluum redirects are indeed really slowing the whole thing down, my experience as a user going through the funnel through a VPN was horrible, especially the redirect to the offer (Voluum click redirect + offer loading time). And yes I did wait at least 10 seconds to make sure it'd have enough time to prerender in the background.

I did test with and without prerender but as Mr Baffoe pointed out, prerender was disabled in my browser (and I didn't know that) so both looked similar in terms of speed.

I'll definitely try DNS prefetching and see how it affects my funnel's speed.

---

Interesting stuff!

Yeah, browser support for prerender is pretty limited. Prefetch, preconnect and DNS prefetch are much more widely supported, or were last time I looked.

Here's a good overview of the different options: https://css-tricks.com/prefetching-p...g-prebrowsing/

In 2017 it's also worth keeping an eye on a new option, Preload: it's a forced option like prefetch but with no failure chance. Currently only supported in a few browsers, but it looks to be coming in generally: http://caniuse.com/link-rel-preload

---

Preconnect seems the most interesting to me right now all things considered. Does it impact the loading time of the current page/lander though, or does the preconnect by default accur after the lander is fully loaded?

---

In addition, you can use https://www.npmjs.com/package/uncss to remove unused CSS, combine them together and place.
There are also some nodejs package that extracts out css to reduce render blocking.
In terms of JS to really optimise it remove things you don't need and parse it through google's closure compiler.

I was able to create a wordpress to static HTML (fake CDN) that downloads the html from a wordpress page and parses it to remove unecessary CSS, whitespace html, optimise a lot of the images and delivery it with Google Pagespeed module.

I like google pagespeed module because it auto audjust and modify the page to best practices. it converts and optimises the images on the fly, optimise delivery of all assets, add lazy load of images without you coding or modifying the html any further.
there are still a few limitation as it does not parse through the background-image: css , so that loads up heavy.

---

@bramburn - good tips, but (unless I'm misunderstanding, in which case do tell me more) more applicable to sites / landers that you control, rather than offer pages which are usually controlled by a 3rd party.

However, that's still a useful tip - I've been looking for an unused-css remover for a while.

---

I'll post my workflow later.
It is only for pages you can control but you could always parse and deliver the offer page on your server and any links or form submission would still go to the offers server.

It takes roughly 1-3 seconds to process the page first time.

It's similar to you guys ripping and editing the landing page of someone but I do it internally and parse my own edits automatically.

The script I had could also upload the files automatically to s3, but I've found that running my own sever locally is much better than s3.
Also you need nginx or apache to run google page speed module.

I'll also post my landing pages.

I've got an amp parser that I'm working in the backend to convert pages including landing page to amp friendly landing pages.
That means near instant page load.

---

Cool - will be interested to see that.

Particularly interested to hear about AMP landing pages - those are on my to-experiment-with list.

---

I spoke to a few people who deals with PPC on adwords and they recommended doing the AMP LP as it would bump up your QS. But those pages are not easy to build if you have forms, etc...

---

Home > Technical & Creative Skills > Programming, Servers & Scripts