eValid™ -- The WebSite Quality Authority Browser-Based Client-Side WebSite Mapping & Analysis, Functional Testing and Validation, Server Loading, Page Timing/Tuning, and Quality Monitoring. © Copyright 2000-2011 by Software Research, Inc.

Purpose
This page documents some common facts about eValid site analysis capabilities. A secondary goal is to help set aside some common misconceptions.

• Client Side Operation: Permissions Not Needed
  eValid is a 100% client side engine and does NOT need ANY permissions to examine any website that it can see.

  Implication: You can scan any website you can browse to. The thinking of eValid is, "if the website is public then it's fair game to scan it [if you want to]."

• What HTML is Processed?
  eValid process whatever is sent "over the wire" and what resides, fully composed and rendered, in the eValid browser. The string of data eValid analyzes is what is in the DOM (Document Object Model) for that page.

  Implication: The HTML is seen "post-processed" so all of the artifacts about how the page was assembled, what the file composition was, is no available. Only what the USER sees is what is scanned and processed.

• Original File Structure Is Invisible
  Because the HTML is post-browser content, you don't have any details about how the page was assembled.

  Implication: It may be difficult, if an error is found in a page, to reflect that error back into a specific source file on the server. Use of "View Source" is the best approach if you can't see the files on the server.

• Invisible Links
  If a link is somehow rendered invisible on the rendered page but it still part of the live HTML then eValid will see the URL reference, check it and confirm if it is reachable or not.

  Implication: This often leads to a "broken link" that the user cannot see. "Better to point it out than to try to hide the fact," is the eValid way of looking at this.

• Orphan Files
  eValid can't detect orphan files on your website because, if they ARE orphans, they cannot ever be reached by the user.

  Implication: The only way eValid can identify orphan files is to look for files on the server side that have NOT been accessed recently (as they would have been if an eValid scan had just been run).

• Whitespace and Line Breaks are Gone
  There are no line breaks in the post-processed fully rendered HTML that eValid scans. Don't look for them.

  Implication: Strings within a page element have lengths that do NOT include any newline or carriage-return/line-feed sequences, and this can lead to some confusion when you try to match a string that is seen on the page as "wrapped". The visual wrapping of lines is a browser rendering function, not an HTML function.

• Oops! Pages Have To Be Programmed
  If you server provides "Oops! Pages" that are sent to the browser in place of sending a 404 error message, then eValid detects these, but you have to program eValid to look for the right phrase or clause.

  Implication: Every website that serves an Oops! Page seems to do it a little bit differently, and you have to sometimes look closely to identify the correct phrase to search for.

• Scanning Big Sites Takes Time [and RAM]
  If you try to scan a large site -- e.g. 5,000 pages or more -- you may have to wait a while. eValid has to actually download every page -- while it pretends to be a real-world user -- and fully render the page. Also, if the link count is large -- e.g. 100,000 links or more -- or if the average link length is large, the amount of RAM used in the intermediate link table can grow substantially.

  Implication: Run large scans on a fast machine, with high-speed access, and make sure there is plenty of RAM.

• Running a Regular Expression Scan Can Be Slow
  A lot of extra computing goes into the process when you have the string filter set to search the HTML for a regular expression -- even more so when the regular expression is a complex one.

  Implication: Make sure you allow enough time, and make sure you have enough CPU power, so you don't wait too long!