Forum Moderators: open
I have a client that insists on having their reservation widget on every page. I've added it to my targeted landing pages, but I'm concerned about the impact the 128 bit encryption is having on my code:content ratio.
The page is as follows: Metas, a script call, THIS:
[snip - Removed code dump of 7,352 characters with spaces.]
and then my SEO content and some more script calls.
The source code is DOMINATED by the jibberish above. Is that killing my content pages? Should I recommend a lighter encryption for my pages, or to drop this from my pages all together and simply provide a link to it?
Thanks in advance.
[edited by: pageoneresults at 8:02 pm (utc) on July 1, 2004]
Here's a sample of the code that was snipped....
value="dDw3NDk4MDA4NzA7dDw7bDxpPDM+Oz47bDx0PDtsPGk8Mz47
The string of code goes on for a very long time before you get to any content.
<script type="text/javascript" src="widget.js"></script>The bots won't download the external script, and I'm guessing your widget and page won't work without javascript anyway.
Can you put it in an external JS file
I don't know if it works that way with 128bit encryption. That is an interesting theroy, and I'd love to hear if that would work!
Can you put it at the bottom of the page if the include doesn't work? (One good thing about the include is that the browser should only download the file once per session, which speeds the whole thing up)
The other alternative is to place the code at the end of the page and use CSS positioning to place it on the page. That would at least mean that your real content will appear first in the source code.
there ought to be no problems putting it in a called file like encyclo says ...
to be sure load it this way into an unlinked test page on your server in a robots.txt barred folder ...
see if it works ...
test all my ( cough ) dodgy (cough) stuff like this ..
I don't know if it works that way with 128bit encryption.
<script type="text/javascript" src="[b]https://www.domain.com/[/b]script/script.js">Use an absolute URI (not a relative one) with an HTTPS protocol call, and it should work fine.
Note, anytime that you call a secure item from an unsecure page or vice versa you could throw an error in the browser.
...you could throw an error in the browser.
Yeah... I'd thought about that. That's not an option as this is a very large worldwide company.
I'm going explore the call with their programmers in a call later today. If the test page kicks up browser alerts or doesn't work, I'll recommend placing the crap at the bottom of the page and doing a CSS placement.
BUT before I go spouting off without being 100% confident... here's a snip of the code.
<form name="index" method="post" action="index.aspx" id="index">
<input type="hidden" name="__VIEWSTATE" value="dDwtMzk4MjQ1MzE1O3Q8O2w8aTw1Pj ...[goes on for 7k+ characters]... V2vg==" />
Can anyone tell me what this is before I try to talk to the programmer about it? It's NOT on an HTTPS page...
THANKS!
Do you really even need it? You can generally remove that stuff until absolutely necessary.
[msdn.microsoft.com...]
It'll have adverse SEO affects as well.
The source code is DOMINATED by the jibberish above. Is that killing my content pages? Should I recommend a lighter encryption for my pages, or to drop this from my pages all together and simply provide a link to it?
I'm not 100% familiar with encrypted code. But, after running a few tests on pages where I have a similar situation this is what I've deducted...
Is that killing my content pages?
The encrypted code that is contained within that hidden input field does not appear to be indexed by a common spider routine. Based on two web page size tools that I utilize, both ignored the characters within that hidden input field.
Should I recommend a lighter encryption for my pages.
Anyway you can trim the fat is always a good idea.
What I typically do in the instances where I have a similar setup is utilize the code on the primary pages where it is required (section specific to the function). And then I'll provide a link to the main section (reservation widget) elsewhere.
Typically when you see encryption code like this, the form tag contains a URI with https...
<form action="https://www.example.com/" method="post">
