Uncompressed site - Google traffic doubled

[Stereo Steve]

I read a thread on here the other day about compression and I think it was Malc who suggested there was a reason why G liked uncompressed sites but couldn't remember why. So I think around the 25th I decided to uncompress and upload as a trial. By the 1st, traffic from G organic search had doubled to an all time high and the amount of pages in the main index quadrupled almost overnight. Plus total indexed pages went up 25%. There has been an impressive increase in sales as well.

May all be co-incidental but I thought I'd mention it. Would be interested in anyone else's experience of this. If your site is compressed, why not give uncompressed a go and watch analytics for a couple weeks?

[completerookie]

google, like other search engines will read your web pages one line at a time, trying to de-cypher them.
If it encounters an error on the line, it ignores the "line" and moves on to the next one.

when you run compressed output, all the html is effectively put on "one line" (all the irrelevent spaces and carriage returns are removed)
the net result of this, is that if google encounters and error partway through reading the "single compressed line", it ignores the remaining, moves on and effectively finishes the page.

if you do not compress, every line is individual, any error and only that small line is ignored and the remaining lines are hopefully interpreted,

It would be great if actinic could give us a "semi compressed" output whereby each line is preserved but all redundant carriage-returns are removed and any empty "white spaces" (tabs and spaces) are removed at the beginning of any line.

[Stereo Steve]

So, is it worth going through your layouts and removing all the blank lines?

[completerookie]

do not confuse google analysing your web site with the physical size of the html page. google doesn't really worry about extra line feeds, its just that when it encounters the error, it ignores the rest of the line, and gets on with the next, if all your page is "one line", then you don't get a second bite of the cherry if you've got an error early on in the line.

removing lines and spaces is all about the size of the page being served, each extra character you can remove, is one less to serve, one less to download, and potentially a quicker displaying of the web page.

I peronally think that actinic should do this job. its not a difficult process,
the problem is that actinic, for instance, generates a blank line for each condition (and end of condition), so if you have 40 conditions that are not met, then you end up with 80 extra blank lines (one for the start, one for the end)
internally, within the html file, you end up with 1 character for a "carriage return" and one character for the "line feed" - (depending if its on windows or unix) - net result is that you end up with potentially 160 extra characters that you download each time - and thats just the unused actinic conditions.

when you start to play with the tabs and spaces we are all guilty of using, the extra characters mount up. Having said that, for readability, maintainability, I always use tabs (thats one character) instead of spaces, I also use CrLf's (carriage return/line feeds) so I can at least read the darned code.

There is no easy way to have actinic run a semi-compressed code generator, you could run external html compressors, but of course, actinic generates and uploads in one in one hit.

there's lots of other ways to speed up the display of your web pages, but this thread is more about "uncompressed pages" rather than "speed of displaying your pages"

[RuralWeb]

thanks for the mention Steve as it was me who posted about it. At least it shows that some of us know what we are talking about and are not seo scam merchants.

[Mike Hughes]

Crikey. Nice one Malc. I hadn't even thought of this before but can see how it could cause problems. I've now changed one of my sites and will be watching to see what happens.

Steve, one thing you might find is that Google is seeing all the changes as an indication of freshness. It'll be interesting to see if any boost to the rankings is permanent or tails off after a few days.

Mike

[RuralWeb]

There are lots of similar tricks you can do with actinic which is one of the reasons I still use it.;)

[dave_finlayson]

Think it was me who asked that question!

We run our site uncompressed now and have seen a definate rise in visits since we did it. Unless you are on all but the crappest bandwidth limits then I really don't see the need to run compressed these days anyway.

[Stereo Steve]

Tonight, 10 more pages come out of supplemental and into the main index. Maybe a temporary thing. I should say that we recently went from Executive to Hotshot about a month ago but it looks pretty similar in terms of code.

The only other big thing we changed was to move the best sellers to the right margin (one reason for going to hotshot) also about a month ago. We felt that having identical content on the left margin on every page was not good for SEO. Having it on the right means google still picks up the links and we get the marketing benefits but it sees the content first.

So, either of those could be partially or full responsible as well. It's just the timing, it's almost a direct reaction!

[RuralWeb]

There is a very good reason why best sellers etc should be on the right. Think about how g reads the page and you will understand.

[Stereo Steve]

Just edited my post to explain the reason for the move and then saw yours after it.;)

[Stereo Steve]

I note that Actinic Express sites are uncompressed by default. Isn't it time Actinic defaulted the main software to uncompressed and left this as an option?

[gabrielcrowe]

<twopence>
google, like other search engines will read your web pages one line at a time, trying to de-cypher them.
If it encounters an error on the line, it ignores the "line" and moves on to the next one.

sorry, but i dont think this is strictly true.

Google uses regular expressions to evaluate the code within tags. their text extraction algo is based on good code, and not the lines its on. html has no real need for whitespace, and so linebreaks and such are treat no different than flowing single line code. Google uses python, that reads by the byte, not by the line.

The reason your code comes up higher is more likely to be the 'humanisation' of it. The big G likes human created pages, and not generated pages, and by 'compression' of the page, you're removing the human element of readability.

The Actinic compression algo. is not as configurable as we want it to be. In light of this discovery, I SERIOUSLY suggest that the following options be implemented in the compress html methods (that i have suggested before btw):

- remove/keep comments
- remove keep whitespace
- remove/keep linebreaks
- strip double line breaks (similar to outlook, trimming extra linebreaks)
- keep conditional headers and strip all other comments
- force all tags to lower case
- enable disable nested tag checking (move to this standard dialogue from options)
- run/dont run all code through htmltidy (http://tidy.sourceforge.net/)
- compress (http://www.webreference.com/internet/software/servers/http/compression/) and or encrypt (http://www.protware.com/) html

...are some of the things i feel would benefit EVERYONE looking for better natural SEO (apart from compression and encryption, obviously).

</twopence>

[toystoyou]

Sorry to sound a bit 'thick' but how do you uncompress your Actinic site?
Do you have to manually remove all the spaces in the html code or is there a button you can press that'll do it all in one go?
Julie
www.toys-to-you.co.uk
Affordable ethical and Fairtrade childrens toys

[Mark H]

Version 7:

Design Options / Miscellaneous / Generation Options, untick "Compact HTML/CGI".

Version 8/9:

Design Options / Generation, untick "Compact HTML/CGI".

:)

[toystoyou]

:D
Thank you.
Julie
www.toys-to-you.co.uk
Affordable ethical and Fairtrade childrens toys

[Buzby]

I uncompressed my site and expected to see my upload time increase above the three hours it usually takes.

Instead the site only took 2 hours and seemed to upload each page a lot faster than usual. I can only assume that Actinic compresses on the fly and this time is added in to the upload.

My site usually takes 80 minutes to do all pre upload checks and then 100 minutes to upload. The prechecks still took 80 minutes but the upload only took 40 minutes.

Has anyone else experienced this same effect?

Kind regards

Jason

[Stereo Steve]

I can't say I've noticed any change in upload speed but then I do have actinic running on a quad core 8GB x64 monster so it's pretty quick anyway.

I think the next step for us is as Gabe says, to spend some time tidying the code we have as it's been bastardised over the years and there are loads of comments (<!--FFS don't delete this--> etc. which we are now obsolete I expect.

[Mark H]

Can anyone think of a reason why uncompacting a site could actually damage SERPS or links from other sites?

[jont]

There should be no effect at all .... the vast majority of websites function with plain multiple lines of code.

[leehack]

I think the whitespace added could become an issue because if you use a lot of blockifs, the whitespace on your site really is huge. I've seen one site with the whitespace 5-6 times longer than the site code itself. I can't imagine that doing any good, especially as we are led to believe the higher up the code, the better the result returned.

[dave_finlayson]

Actinic really should sort out this whitespace issue. Apart from what you have just mentioned Lee, it makes it a right pain in the ass to troubleshoot incorrect code (or it does for me anyway). I went through and sorted it all out on our new site but not sure I have the patience or will to do it on the other one.

[Mike Hughes]

I tried uncompacting my site to see what happens and saw very little difference. There was a slight boost in the number of visitors from google after a couple of days but this dropped off a few days later which suggests it was just the usual fresh content boost that doesn't last very long.

I would guess you could see an improvement if you have some code that Google can't read, but as long as your site is OK I don't think there's any real benefit to doing this.

As my webpages load faster with compacting enabled I'll be compacting my pages the next time around.

Mike

[jont]

I think the whitespace added could become an issue

The amount of whitespace left is a nuisance (not sure if it is an issue unless shed loads is left behind and Google thinks the end of the page is reached) but can be overcome by judicious editing of the layouts involved.

I raised this issue during v8 Alpha testing with the desire to potentially use display:none if the code is empty.

[leehack]

Personally, I think the main point here would be that incorrect code littered with errors could see an improvement, whereas a compressed, correctly coded site with no errors would see little or no change.

Not sure what you are suggesting though Jonty, how do suggest reducing whitespace when it is mainly the blockifs causing it? I understand we can compress the code on our layouts, but that is the area where we want it laid out as uncompressed the most.

There is one thing you can pretty much guarantee (IMO) with Google, if traffic suddenly goes through the roof for whatever reason, within a week it will have stopped.

[jont]

The largest generator of white space are lists within blockifs .... these tend to be laid out for reading easily in the design tab but cause far too much white space. Once the layout is working I go back through and modify to reduce white space.

Don't forget you can also test a blockif for content / conditions and incorporate some css to remove the whitespace accordingly

[jont]

There is one thing you can pretty much guarantee (IMO) with Google, if traffic suddenly goes through the roof for whatever reason, within a week it will have stopped.

Aye - this is why it is best to run a couple of sites alongside each other or leave it for a while to get a more balanced view - leaving for a few days provides no insight at all.

[leehack]

Don't forget you can also test a blockif for content / conditions and incorporate some css to remove the whitespace accordingly
Introduce code to reduce whitespace, you are not getting away with that one young man!

[jont]

LOL - you know I like to keep a tidy house.

[RuralWeb]

Hmmm - I not really had any problems with excessive white space TBH but then I dont use many blockifs

[jont]

Mal - look at *link deleted* example and after the product images ... there are 13 lines of whitespace before the closing </p>

These can be if also boughts are empty, other info boxes not used, etc, etc ... they come from everywhere :eek:

[leehack]

Jonty for 10K before the end of the day?

[RuralWeb]

13 lines of whitespace
I dont think that much will cause problems TBH - I thought you were talking about hundreds of lines as Ive seen in some sites which when you look at them they have little bits of code everywhere

[Steve G Griggs]

Hi All.
I don't know about Google yet, but I can say that uncompressing the site seems to cut about an hour off of a site refresh. The process of checking the pages and HTML seems a lot quicker, as did the upload.

We will see if it brings any increase in orders over the weekend.

Does not seem to have affected the speed the pages load at either.

[Buzby]

With my site compressed I only had 430 out of 1974 pages listed on Google. After 2 to 3 weeks of running an uncompressed site this has now risen to 1490 as well as shaving an hour off my upload time.

A big thanks to Stereo Steve for the tip.

Kind regards

Jason

[Stereo Steve]

Seem remarkably similar to my experience. I should add that we are still getting more and more pages indexed on a weekly basis since the switch. Does seem to be something in it. Always difficult to tell with these things though.