What does it cost to run Travelfish?

Start a website! It’s free!


I came across a post a week or so ago that detailed what it cost an “online company” to remain online. I found it to be astoundingly high, but it did make me wonder just how much it costs us to keep the hamster-wheel at Travelfish spinning. How much do all those $5 monthly charges add up to in the end?

Here’s what I put together. Obviously, the tech side is a small portion of our expenses — the vast bulk of our earnings goes to our writers — but I’ve kept it technology focused. I also haven’t included Upwork costs, which are related to when I occasionally use a contractor to assist with a server management task or programming/inputting drudgework.

As a couple of the charges are traffic based (Mapbox, Amazon S3) and as our traffic is somewhat seasonal, there is a little bit of variance month to month. I’ve also included services that are free for the level of use we use them at, but which have paying tiers.

Lastly, I’ve included a brief on each after the list, explaining why we use each item and if whether I’d recommend them.

Essential to keep the site up
Server hosting with Server Beach (now Cogeco Peer) $274 per month
Amazon S3 $160 per month
Mapbox $215 per month
Google site search $750 (annual) 150k queries, lasts almost a year
SSL Cert $99 annual

Chartbeat $9.95 per month
Google Analytics Free
Google Webmaster Tools Free

Security & making my life easier
Sucuri $89.99 annual
Akismet $50 per month
Bugsnag Free
Mailchimp $30 per month
Dropbox Pro $100 per year

Aweber $149 per month

Moz $99 per month

Payment processing

Productivity/management etc
Asana Free
Toggl Free

Pinboard $11 annual

Prefer all the above in a chart? Here you go.

Cheque please!

A few more thoughts

Server hosting
We signed up for a dedicated server with ServerBeach years ago and have been through probably a half dozen servers with them over the years. No complaints. Very proactive support with a decent turn around on support queries and hardware failures. Have had one significant stretch of downtime in the last decade.

Amazon S3
We use S3 for image hosting and other storage needs and desires. There is a significant performance uptick in doing this rather than hosting the images locally. Would recommend it for any website with a lot of images.

We use Mapbox throughout the site and in the PDF travel guides. Very comprehensive documentation for their API and we’re a big fan — though the costs do add up. A free alternative is Google Maps, but we vastly prefer Mapbox.

Google Sitesearch
Having a 40,000-page website means you’ll be needing a search tool. We pay Google in order to be able to use their search tool free of ads. We buy it in chunks of 150,000 search queries, which lasts us almost a year, give or take.

SSL Cert
Essential if you’re running a https:// site. There are cheaper means to this and we’ll probably stop using Comodo next year.

Site analytics with a social tilt and with a site uptime side service. We were put onto Chartbeat by a friend at a newspaper who gets a lot of social traffic. As social isn’t a large traffic source for us, this isn’t so much fun and I keep meaning to cancel it. Maybe this month. If you do have a significant amount of social traffic, Chartbeat is worth a look.

Google Analytics
Essential if you want to keep on top of what is happening on your website.

Google Webmaster Tools
An imperfect tool for keeping an eye on the overall health of a site from Google’s perspective.

This is a WordPress monitoring service which we use for the sole remaining WordPress install on the site. If you use WordPress, this is well worth considering.

While you can use a single Akismet API key for free, we upgraded when we were using a bunch of WordPress installs. Now they’re all gone I could probably reduce this to the one-off fee ($5 per month from memory) as we still use the API for spam control on the forum, but Akismet is a great product and we’re happy to keep supporting its efforts to keep comment spam under control.

Handy tool for monitoring the site for PHP and other coding errors. Free for up to 250 errors a day.

We use these guys for transactional email delivery (password resets etc). Every month when I get the invoice my teeth grate as we previously used their associated service (Mandrill) but then it got rolled into Mailchimp and you were forced to pay another $10 for a mailing list you don’t want. Penny pinching or what? We went to switch to another company but they refused service because we are in Indonesia – never ceases to amaze me when companies thumb their noses at a country home to the fourth largest population on the planet.

We use Dropbox Pro (not business) for image management between us and the writers and while we pay for their licenses too, we’re just listing the one account for the purposes of this piece. Avoid their enterprise product.

You do get our newsletter right? Aweber isn’t free and it isn’t perfect, but it works. We have more than 10,000 subscribers and the inertia involved in moving to another service (which would never, ever be Mailchimp – see above) keeps us here.

I want to love Moz but I don’t and having been with them for a year will cancel this month. The product is good, especially the initial period when you first sign up and the site audit was very useful for fixing glaring errors, but as time goes on, at least in our case, we’ve logged in less and less. We don’t take a particularly competitive SEO position — we follow the rules and concentrate on content — so some of this was definitely a bit of information overload for us.

If you’re into SEO and particularly if you want to get into competitor analysis, then this is worth the money, but if you essentially just want to check you’re not doing anything especially stupid, then perhaps use it for a month or two then cancel, or pass on it and just follow the founder on Twitter, as he links out to a lot of very interesting stuff and his “Whiteboard Fridays” are reliably interesting.

We use this for payment processing for Travelfish premium members and for travel planning consultancy. Stripe is awesome and better than Paypal in pretty much every single way imaginable. Their fee base is percentage based per transaction.

I wrote about Asana when we first started using it way back when here. The more they added features the less I used it, to the point now where I don’t understand what is going on anymore. Sometimes simplicity is an asset. We don’t use it anymore.

This is a personal time manager which I can sync from laptop to phone. I love it. Very simple to use. If you want to get on top of what you spend time on, in a very simple format, this is great.

What we don’t use and what we do instead
Any kind of social networking management accounts (Hootsuite etc etc etc and etc). We do it old school — though I am taking a break from all of them for now.

We don’t use Slack for team collaboration and communication (I find Slack infernally confusing and counter-intuitive to use), instead using a private Facebook group and email and Skype.

No accounting or budgeting software. Instead budgets, GST, accounting, payments etc are all in a single excel sheet which we send to the accountant annually.

Oh, I almost forgot Pinboard
I signed up for Pinboard solely because the guy who runs it is one of the funniest tech people I follow on Twitter!

Switching Travelfish to https: A quick walkthru

We recently switched the Travelfish website over from http to https and it appears to have run very smoothly (touch wood!). As Chris at TravelHappy asked, here is a quick wrap on what I did and a few heads up to potential issues.

Primarily because of moronic telecom companies here in Indonesia (Hello Telkomsel!) who hijack sites which do not use https to inject their own ads and popups into the website. I have written about this previously here – it is an absolutely bottom-feeding parasitical practise, but, currently, is not illegal in Indonesia.

The site
Travelfish is a travel content site of give or take about 25,000 pages. These pages are served via 100 templates (again give or take) and serve around a couple of million impressions per month. It runs off of PHP and MySQL. Pretty bog standard stuff.

While we have a handful of WordPress installations tacked on the side, the vast majority of the CMS is custom.

Some are hosted on the server but most are on S3 with Amazon Cloudfront.

Embedded content
We use Mapbox for almost all of our mapping, and Vimeo for nearly all videos (which are primarily on just the one page). Otherwise there were a few Youtube embeds and so on scattered around the joint.

We don’t run any third party served ads (Google Adsense for example). This made the whole task considerably easier.

The process
I’m not going to bother covering getting an SSL certificate and setting that up, as there are a bazillion tutorials already online about that. In our case it was already set up as we were already using it for login stuff.

Going through the templates
The main headache is “mixed content” where you have a https page that is calling an item (say an image or icon) from a non https source. This mixed content causes browser warnings and, in some cases the page won’t load.

What this meant was that we had to change every single link in the site that pointed to http://www.travelfish.org/ to https://www.travelfish.org. So, there’s no shortcut route here, we needed to go through every template and check that every url was https.

That was a fun day.

At the same time, we had to check that all our support files (javascript, css, icon files, font files etc) were both hosted on https and called by their https address. Same went for third party content like mapping. Not complicated to fix – just tedious.

This was another fun day.

As we make heavy use of templates and PHP functions to generate chunks of standard content, the above was a lot less painful than if it was all vanilla HTML, but, well, your mileage will vary. It all needs to be changed — every bleeding line.

Aside from the tedium, there are a couple of things to watch out that are worth mentioning.

Hardcoded http in 3rd party files
http:// addresses that are hardcoded into Javascript and css files are a hassle. In one notable case, if you’re using Google Sitesearch as we do, there is a problem as the search JS script is hosted with Google (at //www.google.com/afsonline/show_afs_search.js), but the JS file contains a hardcoded http:// reference which creates a mixed content warning

This meant I had to pull down the script, change the http: to https: and host it on our server (as obv I can’t change the code Google is hosting). The downside of this is of course is if Google changes something the script breaks — so far so good 😉

Images at S3
This was one of the main reasons we had delayed the switch to https because of the complexity is getting a SSL certificate that would cover all the images there. To be honest, I still don’t really understand all this, but this explainer at the aptly named Delicious Brains (their blog has lots of interesting stuff too), worked a dream and made all of our images and other stuff secure with a minimum of effort (and zero cost).

Once all the images and all the support files had had their references updated, we moved on to the content.

The database
Plenty of our content in the database (accommodation reviews etc) has links hardcoded into it. Rather than doing search and replace through the database to fix this, we took the more gradual approach of:

a) On the public template pages we replaced the old url with the correct ones as a part of the process of querying the database and formatting the output with PHP.

b) We adjusted our CMS to do the same, so any time we open a record in the CMS any baked in links are updated permanently when the record is saved. Over time, all the records will be updated.

The forum
One issue here was members being able to post images that were hosted elsewhere. The problem was that people may not always post images from a https source so we’d end up with a mixed content warning. We dealt with this by forcing the image to https (again by replacing the url with the PHP str_replace function as in (a) above). What this did was if the image wasn’t hosted on https the image broke — but no mixed content warning. That was preferable result to our mind.

As an aside, if you’re built on WordPress, you’ll want to avail yourself of the following plug-ins to make your life easier. Both should be self explanatory.

Search and replace
SSL Insecure Content Fixer

WordPress’ new image handing with srcset can be an added complicating factor. The easiest approach is to just disable srcset by adding the following to your functions.php file:

function disable_srcset( $sources ) {
return false;
add_filter( ‘wp_calculate_image_srcset’, ‘disable_srcset’ );

Once all this was done, mix yourself a major gin and tonic then:

1) Upload all the files
2) Add a sitewide 301 redirect in the .htaccess file sending all traffic from the http:// to the https:// (this should catch any hardcoded links I missed plus deals with all inbound traffic)

And see what happens.

In our case (SO FAR) it ran smoothly. No noticeable traffic budge (in either direction) and no Webmaster Tools freak out warnings. Note you will need to register the new domain in Webmaster Tools if you want to busy yourself with their beyond pointless 404 reports.

And, that’s a wrap.

Adblocking: down the track in travel

I’m not going to go to deep into the pros and cons of actually using an adblocker, other than to say I don’t agree with their use — especially if a publisher makes it clear they don’t want you to use one. Instead I wanted to write about what the results of adblocker use by a large majority of readers might look like down the track, within the travel writing sphere.

There are three main aspects to this. How advertisers and ad networks will respond, how publishers will be affected and how readers will be affected. What will happen to the reader’s experience is the most important to my mind, but I’m treating it last as the other two are inter-related and contribute (obviously) to the reader experience.

How advertisers and ad networks will respond
Two primary arguments are raised by the pro-adblocker camp: Ads are annoying and detract from the reading experience and adtracking is loathsome. Currently, most adblockers block third party Javascript, which is used to load both ads and tracking cookies, removing both issues.

The most straightforward way to address the first part of this (the ugly annoying ads) is to load them server side. Plenty of sites already do this, so those ads are (generally) not blocked; expect to see more of this. Adblockers can block on creative size — for example, they can block all images that are IAB unit sizes — but there will be a considerable amount of collateral damage to this approach (as not all 300*250 images are ads, for instance).

Getting around the tracking block is more difficult but not impossible. Assigning unique IDs to readers and then identifying characteristics like referrer (where available!) and other user-agent/platform stuff, plus plenty of site specific stuff (such as time on site and pages viewed) is relatively straightforward. This information could then be baked into the querystring and passed to an adserver on click (because the ads are now being served server-side). Some publishers would probably agree to bake that into their entire site navigation for enough $$. Sure, it’s not as comprehensive as current tracking, but it is a start. Take a look at ANY Online Travel Agent querystring once you’ve surfed around a bit to see what I’m talking about.

Content-wise, what should we expect to see? A massive growth in native content — this is basically advertorial, renamed to make is remotely more socially acceptable. Brands pay the publisher to have their editorial staff prepare stuff related (sometimes vaguely, sometimes very specifically) to the brand, whittling down the editorial/advertising Chinese wall. As Medium founder Evan Williams says, “Native ads are the only thing that can work. Other stuff hasn’t been a win-win especially for users. It’s on its last legs.” I’d never categorise native advertising as a win-win, but Williams’ sentiment is a common one.

Responsible publishers clearly disclose native content — phrases like “Partner content”, “In conjunction with” and “Sponsored by” are all code for advertorial. Of course, clearly disclosing native content to your readers means you’re also clearly disclosing it to adblockers. So expect adblockers to increasingly block this material as well.

Therefore the next step will be for brands to require undisclosed native content blended in as closely as possible to editorial content. This will be far more difficult for adblockers to detect correctly and remove. It will also be extremely difficult for readers to realise what they are reading is actually an ad.

This last step is a double win for the advertiser — unblocked content that readers don’t realise is advertorial. It isn’t so much a great thing for publisher trust because when readers realise they’ve been tricked into reading an ad, they’re generally not very happy.

So the ads and much of the tracking are gone — yay! They’ve been replaced by material that is advertorial and indistinguishable from editorial — not so much yay!

What will happen to small-scale publishers?
At, say, a 75% percent block rate, many independent smaller scale publishers (ie too small to have dedicated ad and tech teams) will stop publishing. Aside from lawyers, bankers, cocaine dealers and politicians I can’t think of many occupations who work with a 75% profit margin; take away three-quarters of any business’s income and it will struggle. Non-professional hobby sites will undoubtably continue, but maybe they’ll just pull in enough for a slab of beer annually rather than monthly.

Obviously a wise approach as a professional publisher is to not have all your eggs in one basket — being totally reliant on advertising has never been the best idea. Travel-themed affiliate marketing and ebooks are two obvious and relatively easy candidates to help in this regard. But these revenue streams too may well be blocked in the future by adblockers because of the zeal of people who simply think information should be free (never mind the cost of compiling the information).

In travel publishing, we’ll see a vast growth in advertorial (sorry, I mean native content) — not that it wasn’t already a massive reader problem in travel. Expect more luxury hotel insider pieces paid for by luxury hotels, adventure travel experiences paid for by adventure travel companies, local food pieces written by local food tour providers, PR companies paying for guidebook writers to visit certain properties and so on. The travel vertical is already awash in native stuff. Expect to see plenty more from publishers willing to do it and less and less of it to be disclosed to the reader.

The reader experience
As an adblocking reader, you’ll be tracked less and see fewer ads. You’ll also be presented with far more content that, well, is probably actually an ad. You didn’t realise? That’s the idea. And if you don’t use an adblocker? Well, you’ll still face reading crappier content online as well as some publishers bend to the new regime.

For some readers, this is a reasonable trade off. But it is worth considering that the most likely result to your “hating ads” and so blocking them, will be getting to read ads without realising they’re actually ads.

And whatever you do, don’t worry about all the tracking that is going on while you browse the web logged in to Facebook. (That was sarcasm.)

On Travelfish
Advertising is a minor but important part of our revenue stream. If 75% of our readers blocked ads, we wouldn’t be very happy about it, but we wouldn’t go out of business. You’ll never read native content on Travelfish. We’d shut the site down before it came to that.

We will continue to run ads, as we currently do, primarily through Google Adsense which remains, by far, the most cost-effective way for a small publisher to monetise their website. To the full extent that the Adsense platform permits, we disallow advertiser practices that present a poor user experience or enable excessive tracking. For example, we block third party and interest-based ads as well as more than 2,000 “Google-certified ad networks”. There is definitely a revenue cost for us associated with blocking these “services”. Does this matter to adblocking software? No. An ad is an ad is an ad.

If the adblock rate gets high enough, we’ll paywall adblockers. Don’t want to pay and don’t want to turn your adblocker off? Take your entitlement over to Wikivoyage please. (This is not meant as a slight to Wikivoyage – they’re a solid site – but rather highlighting a non-commercial site providing similar information to Travelfish.)

We don’t think we’ll be the only publisher to do this — others who get that icky feeling about native content may well do the same. If you buy an adblocker, consider that down the track you may also have to buy access to a site in lieu of seeing their ads. Some people are cool with that; if so, everyone is happy.

One thing I’ll give adblockers: blocking comments on blogposts was a great idea. But what about the perfect adblocker?

Does social matter?

If you have a travel-related website, perhaps not.

A big fat NOTE up front here, I pulled together this information from SimilarWeb which delivers estimated stats on desktop traffic and I couldn’t see any way to split the stats out by device. One would imagine the stats would be somewhat different on mobile.

Anyway, I gathered the site stats on ten travel websites (Lonely Planet, Rough Guides, Fodors, Frommers, Travelfish (my site), Tripadvisor, Moon, Wikitravel, Travellerspoint and Gogobot) and then gathered the same information for ten news websites (NYT, Guardian, The Atlantic, New Yorker, SMH, BangkokPost, FT, The Australian, LA Times and the Independent). I then plonked them all into a spreadsheet and made the following four simple charts.

Get a magnifying glass for social.

Get a magnifying glass for social.

Social traffic
This is FAR more important to news websites than travel. Rough Guides derives the largest proportion of its traffic from social, but it is still below 5% of overall traffic – the average across the ten travel publishers was just 2.09%. Compare this to the Independent in the UK who gets 36.68% of traffic from social, with an average across the ten publishers of 22.03%.

Search traffic
This is the bread and butter to travel publishers, with an average of 73.62% across the ten. News by comparison is just 30.66% across the ten. Similarweb doesn’t break out results from news.google.com so I’m assuming it is wrapped into the overall Google figure. I’m kinda surprised it is this low, but, to be honest, I can’t remember the last time I looked at Google News – Twitter is now my newsfeed.

A closer look at social for travel websites. The “big three” are Facebook (52%), Twitter (16%) and Reddit (16%), but there are very big fish in a tiny pond. Taking Rough Guide for example, their largest social source of traffic is 41.43%, but that is 41.43% of 4.48% of their overall traffic – ie Facebook represents 1.85% of their traffic.

One point eight five percent.

This all makes sense I guess, breaking news is far more “share-worthy” than a profile of the guesthouse that you stayed in last night, so maybe give that some thought before you slather social sharing buttons all over your website.

Traffic data is here.

Managing travel photos – is this possible?

A common problem we have at Travelfish is managing photos. Managing author submissions is no major issue – we use Dropbox for that – they share a folder on their laptop/desktop with us via Dropbox and we see the pics, then we pull them off and into local folders so we can use as needed.

We struggle more though with our home setup. Basically there are two Macbooks – Sam and mine – they’re not networked. Each has their own distinct photo library local to that laptop. These two libraries are organised differently — mine by location, Sam’s by a different method. This is ok when we are in range of each other’s laptops, but when one of is is away and needs a pic from the other’s machine, it is a hassle.

An ideal solution would be to mirror the image organisation system onto the two machines, and introduce a third machine, which would automatically sync with my and Sam’s machines, making a central copy of everything, plus copying images from Sam’s to mines and mine to Sam’s to fill any blanks, update with new images and so on. Essentially they’d then be three collections of the same image library, so if one of us were away, they’d still have a copy of everything the other had — at least up to the moment we went away.

We don’t want to use Dropbox or some other Cloud solution as we’re often where internet is poor and the combined gallery is about 50,000 pics.

Is the ideal situation I describe above possible? Or is there a better way?

Any suggestions much appreciated!

Indonesia to offer visa free entry for Australia, China, Japan, Russia and South Korea

TTGAsia has the scoop that “sometime” in 2015, Indonesia is to offer tourist visa free entry for tourists from Australia, China, Japan, Russia and South Korea.

While there are lots of details still to be announced (and I assume to be negotiated), this is quite a big deal.

“Part of the Ministry of Tourism’s quick-win programmes to boost arrivals to Indonesia and achieve 20 million arrivals by 2019, tourism minister Arief Yahya is expecting 500,000 arrivals from the five target markets alone as a result of the visa-free facility.”

According to Bali Discovery, in 2013, Bali arrivals were around 750,000 Australians, 360,000 Chinese, 190,000 Japanese, 70,000 Russia and 120,000 South Koreans to Bali, so even taking into account that the Bali Discovery numbers are just for Bali, the Tourism Minister is either expecting a boatload of Australians to take advantage of the new conditions, or some pretty staggering increases from some of the other markets.

Regardless of the actual tourism increases, this is a great first step in the right direction for Indonesian tourism.

The key questions are of course, how long will the allowed stay be (currently 30 days for a visa on arrival), will multiple stays be allowed (visa on arrivals can be used back to back) and when will it be expanded to other countries?

The second step should be the creation of a longer-stay tourism visa — ideally in two flavours of 90 days and 180 days. There could each attract a modest fee — say $30 and $50 respectively.

It won’t be until a longer stay tourist visa is available that Indonesia will go anywhere close to sustainably realising the target of 20 million arrivals. The current month visa on arrival allows one to cover the highlights of say Java, Bali and Lombok at a moderate pace, but realistically for tourists to explore other regions — say Sumatra, Sulawesi, Flores or Sumbawa — one or two months simply is not sufficient.

These longer stay travellers will see more tourist rupiah being deposited into the hands of small scale, family-run businesses across the archipelago — rather than short stay tourists padding the bank balance of the development tycoons who are busy paving over South Bali.

This is a great first step.

And of course these new regulations should be 100% reciprocal. Fat chance of that with the current Australian Government.

Why is Indonesian telcom firm Telkomsel hijacking websites?

Update, added a couple of links below with previous coverage on this scabby behaviour.

Indonesian telcom firm Telkomsel have for a while been injecting crappy little banners above websites without the website owner’s permission. This happens if you’re using their prepaid 3G simcards. This has for years been regarded as a particularly crappy parasitical practice, but Telkomsel take it to an extra level by coding it so badly that the sites they are injecting the ads onto (including mine) get broken.

Here are some screenshots:

Travelfish homepage
This is a “best case” usage as the injected ad (the “weplay” leaderboard up top) doesn’t actually break the site.

Example 1

Example 1

Travelfish forum page
This is a “bad case” usage, where, because their crappily coded stylesheet uses the same element names we do, it breaks the form on this page (it overly widens it) making it impossible to read the screen.

Example 2

Example 2

Agoda booking form
This is a “worst case” usage, where the crappy Telkomsel code makes the Agoda page unusable. I’d imagine Agoda and Priceline’s legal departments would find this of considerable interest.

Example 3

Example 3

Here’s the code Telkomsel are using to inject the ads — they are clearly hosting it. I’ve wrapped it for legibility and bolded a couple of the ad serving URLs.

For websites that are transactional, like Agoda, there is a clear revenue affect here where the ad code Telkomsel is inserting is making Agoda’s website unusable. For other sites, like ours, it is just a PITA.

&lt;meta http-equiv="refresh"content="0;
<link href="http://ads.telkomsel.com:8004/COMMON/css/ibn.css" rel="stylesheet" type="text/css">
<script type="text/javascript" src="http://ads.telkomsel.com/ads-request?t=3&amp;i=174559005&amp;j=2&amp;
<script type="text/javascript" id="placeholder-script"

<meta content="minimum-scale=1.0, width=device-width,
maximum-scale=0.6667, user-scalable=yes" name="viewport">
<meta content="yes" name="apple-mobile-web-app-capable">
<title>What's the most famous attraction in Hong Kong? :
Travelfish Hong Kong travel forum</title>
<script type="text/javascript"

<div id="container">
<div id="top-banner">
<div id="offdeck-ads-div"
style="height: 69px; padding-top: 2px; padding-bottom: 0px;
margin: 0px auto; background-color: rgb(221, 221, 221);
position: relative; box-shadow: rgb(0, 0, 0) 0px 2px 3px;
-webkit-box-shadow: rgb(0, 0, 0) 0px 2px 3px; z-index: 50;
clear: both; background-position: initial initial;
background-repeat: initial initial;">
<div id="ads" style="width:100%;text-align:center;">
<div align="center">
<a href="http://telkomselprod.amobee.com/upsteed/actionpage?as=15353&amp;t=1411104155737
&amp;acc=4040581&amp;monitor=0&amp;n=http%3A%2F%2F&amp;a=85733636&amp;data=" accesskey="">
<img src="http://telkomselprod.amobee.com/content/4040581/85733630/85733629.gif" alt=""></a>
<img src="http://telkomselprod.amobee.com/upsteed/notification?event=3
height="1" width="1" alt="" style="display:none">
<hr style="margin-top:2px; padding-top:0px; padding-bottom:0; margin-bottom:1px;">
<div id="toolbar" style="width:100%; text-align: center;">
<div style="width:300px; margin: 0px auto;">
<div style="text-align:right; width: 295px; display:inline-block; height:12px; vertical-align: top;">
<img id="btn-hide" class="ibn-ads-button" src="http://ads.telkomsel.com:8004/COMMON/images/hide.jpg"
style="cursor: pointer; height:10px; width: 50px; vertical-align: top;">&nbsp;
<img id="btn-close" class="ibn-ads-button" src="http://ads.telkomsel.com:8004/COMMON/images/close.jpg"
style="cursor: pointer; height:10px; width: 50px; vertical-align: top;">
<div id="middle">
<div id="left-banner">

<div id="content">
<iframe id="main-frame" scrolling="no"
height="5015" style="height: 5015px;">

<div id="right-banner">

<div id="bottom-banner">

<script type="text/javascript">
p={'t':'3', 'i':'174559005'};
<script type="text/javascript">
var b=location;
if(typeof window.iframe=='undefined'){
<script src="http://ads.telkomsel.com:8004/COMMON/js/if_20140604.min.js"></script>
<script src="http://ads.telkomsel.com:8004/COMMON/js/ibn_20140223.min.js"></script>

<div id="showbutton" class="sh-div sh-div-top-bottom sh-div-top " style="display: none;">
<span class="showbar">
<a id="btn-show" href="javascript:void(0)" style="padding: 5px; font-size: 10px; font-family:
verdana; color: black; text-align: center; font-weight: bold; text-decoration: none;">show ad</a>

So Telkomsel, could you stop doing this please?


Update 20 September 2014, seems I’m very late to the party on this issue. Here’s some others who are equally displeased with the situation.

On similar practises by another Indonesian Telco, XL, Batista Harahap says: “I can’t agree with these kind of practices. Period.”

Aulia Masna in October last year for Daily Social: “There is a concern that XL’s employees or anyone with access to this practice will be able to capture people’s login details for various websites.

I liked your post so much I didn’t read it

Last week, as a part of our “giving back in Southeast Asia” series we published a piece profiling the Soi Dog Foundation. They’re a group in Thailand doing great work helping stray dogs (and other animals) and are funded totally by donations. Nice work!

The charity pieces tend to get very few reads on Travelfish and this was no exception. But, as you can see from the screenshot below, the story got quite a few likes — 3,894 according to Facebook.

Likes all over the place!

Likes all over the place!

It wasn’t till the author of the piece let me know that the Soi Dog Foundation had shared the piece on their Facebook page, that this made more sense. Afterall, they have around half a million “fans” on Facebook. Sure enough, when I look at the piece on their Facebook page, there are the bulk of the likes — 3,580 of them.

How can you not like that dog?

How can you not like that dog?

I got all excited, expecting a tonne of (well 3.5 tonnes to be exact) readers on the story on our site. But, it seems I was barking up the wrong tree.

A bit of a dog.

A bit of a dog.

The above screenshot is from Google Analytics and shows ALL traffic to the story — not just from Facebook. The busiest day saw 313 reads.

What does this mean?

It means that one shouldn’t see Facebook likes as some kind of proxy for web traffic.

It indicates, that at least in this case, the vast majority of readers (90%) liked the post without reading it.

Perhaps most importantly, it means that a story displaying a badge saying it has x number of likes is largely meaningless. (We’re removing them in the redesign).

Lastly it means all stories you publish to Facebook should include a photo of a cute dog.

You can learn more about the great work the foundation is doing here.

How to speed up your website

The easiest way to speed up your website is to invest in a better server.

The second best way to speed up your website is to not have 3 meg GIFs of cats on the page.

But what about after that?

I took a typical Travelfish feature story page, with a standard Adload and went through a series of steps to see just how quickly I could get it to load. You’ll see that the problem of a lagging load are quickly taken out of your hands.

All results are via the smart cookies at Pingdom

Grade 77
Requests 107
Load time 2.43 seconds
Pagesize 1.2 meg

Step 1: Remove all social sharing buttons
Theoretically effects ability of readers to share content on other networks.
Grade 80
Requests 81
Load time 3.54 seconds
Pagesize 1.1 meg

Step 2: Switch Adsense ads to async
No downside I’m aware of. That the code wasn’t already async was my oversight.
Grade 79
Requests 89
Load time 3.53 seconds
Pagesize 1.0 meg

Step 3: Reduce Jpg images from 80% to 60%
Slight change to image quality. More noticeably on retina screens. This was the biggest single improvement.
Grade 79
Requests 91
Load time 2.05 seconds
Pagesize .915 meg

Step 4: Split images across four S3 subdomains
This would have more of an effect if I had say a dozen images as there could be more parallel downloading. In this case a bit of a non issue.
Grade 78
Requests 91
Load time 2.01 seconds
Pagesize .916 meg

Step 5: Remove GAM to basic Adsense code
Removes ability for me to set an artificial floor on the ads displayed. Immediately started seeing weightloss ads. This change would have a revenue implication.
Grade 80
Requests 84
Load time 1.79 seconds
Pagesize 1.0 meg

Step 6: Dump to a plain HTML page
Removes ability to serve dynamic content.
Grade 80
Requests 82
Load time 1.15 seconds
Pagesize .918 meg

Step 7: Remove all ads
Obvious revenue implication!
Grade 85
Requests 37
Load time 0.715 seconds
Pagesize .614 meg

Step 8: Remove Facebook like code
Ego/social proof buttons no longer shown – this should have gone in step 1 – I forgot.
Grade 92
Requests 26
Load time 0.647 seconds
Pagesize .466 meg

Step 9: Remove Google search suggestion from the search box
Readers lose search suggestion.
Grade 97
Requests 19
Load time .416 seconds
Pagesize .361 meg

Step 10: Remove Google Analytics
Obvious loss of traffic measurements.
Grade 98
Requests 17
Load time 0.357 seconds
Pagesize .345 meg

So in ten steps I’ve improved load time from 2.43 seconds to .357 seconds — not too shabby. In the process though, I’ve removed all sharing, tracking and revenue opportunities. This is not exactly a win win situation.

Off the top of my head takeaways.
1) Any changes while still serving Adsense are difficult to measure as Adsense can serve wildly varying ads that will impact the Pingdom results. On one load I saw an Adsense cumulative load of around 700meg!

2) The “easiest” improvement was reducing the image quality. But there seems little point in doing this when Adsense can dump something massive in. The second easiest way is to remove ads. Great for readers — not so hot for the bottom line.

3) Google (and Facebook to a lesser extent) really need to consider adopting some of the “best practises” they keep advising everyone else to.

Request for link removal

A Saturday morning exchange with a Phuket villa operation that has been slammed by Google for dodgy link building aka spamming. Start from the bottom.


So what you’re trying to say is something along the lines of:

“We’re sorry for spamming Travelfish in a boneheaded attempt to try and game Google. To be honest, we’re not actually sorry at all, but, as Google caught us at it and busted our chops we’re feigning sorrow. You can tell we’re not actually sorry at all as we imply in the email that Travelfish added the link themselves rather than fessing up that it was our moronic link building actions that saw it there in the first place.”

When what you really should be saying is:

“We spammed Travelfish in order to try and game Google. Google caught us. Please remove our filthy spam and we’re truly sorry for any inconvenience this caused and it most certainly will not happen again.”

Let me know


On 3/22/14 5:43 AM, XXX wrote:
> Dear Webmaster,
> I am contacting you on behalf of XXX. We noticed that you
> have links to our website XXX on the following
> pages:
> While we appreciate the links, we are currently attempting to recover
> from penalization by Google Penguin. I am respectfully requesting that
> you remove these links to our website, as they are no longer in line
> with our Internet marketing goals.
> Please do not hesitate to contact me should you have any questions about
> removing these links.
> Thank You,
> XXX on behalf of XXX

Stuart McDonald

Travelfish — the website other travel writers use
email: stuartmcdonald@travelfish.org

Twitter: http://twitter.com/travelfish
Facebook: http://www.facebook.com/travelfish
Flickr: http://flickr.com/groups/travelfish/

We want travellers to love Southeast Asia as much as we do.