It’s a question asked by virtually every web design client ever: “When will we be among the top spots in the search results?” Serious web designers will give a reserved reply, while the common SEO will say “tomorrow.” But how long does it really take?
This article from Noupe aims to give a realistic answer.
2020Media.com is happy to announce a new partnership with CloudFlare, the web’s easiest performance and security solution. As a CloudFlare Optimised Partner, we deliver their simple and effective solution to help protect and accelerate your website. Once your website joins the CloudFlare community, it loads twice as fast and is protected from a range of online threats.
We are delighted to offer this great service to you and help make your website faster and safer.
As a CloudFlare Optimized Partner, we are delighted to offer the CloudFlare Railgun™ technology to all our customers as an upgrade option. Railgun is CloudFlare’s latest performance optimization technology that gives you significant improvements in site load times.
Railgun ensures that the connection between our network and the CloudFlare network is as fast as possible. Railgun achieves a 99.6% compression ratio for previously uncacheable web objects by using techniques similar to those used in the compression of high-quality video. The average website can expect a 1.43x performance increase.
Although the dynamic web is not cacheable, it is also not changing quickly. That means that from moment to moment there’s only a small change between versions of a page. CloudFlare Railgun uses this fact to achieve very high rates of compression. This is very similar to how video compression looks for changes from frame to frame; Railgun looks for changes on a page from download to download.
This is a guest post from 2020Media customer Andy C. He writes:
The other morning I had an automated email from 2020media advising I was nearing my bandwidth quota. So I went over to google analytics to see if there had been a sudden surge of interest in the site. There was no real change so I knew I’d need to investigate further.
I also had a look at my spam numbers as spammers had previously been a bandwidth cause. However, there were only a handful of comments needing approval and the numbers that had been sent directly to spam were quite small too.
Rex from 2020media recommended looking at the webalizer web stats provided by the site, these are driven directly from the Apache server and are used by the bandwidth monitor. The numbers here are hence a more accurate reflection of bandwidth use. I logged into the FTP server and downloaded the logs to analyse off-line.
The monthly summary did not give any clues so I drilled into the details for March. The problem was highlighted both in the form of the graph and big numbers that had been pulled in over the weekend of 11th and 12th.
Looking further down the report I could see that the big numbers were for the home page (not much of a surprise) and for the comment subscription page which is the landing page when people save a comment.
Further down the report I could see the culprits, a couple of IP addresses that were pulling a lot of Kbytes.
I’ve added those to my blacklist so that should keep them at bay. I’ll also be pro-actively monitoring my Bandwidth Gem to make sure they’ve not come back.