What is the problem with frames?
Some people do not want to use frames as they have heard that frames are bad. This is a very uninformed position as frames have very specific advantages and many areas rely heavily on them.
Firstly, frames DO NOT break Accessibility Guidelines - provided each frame has a meaningful title attribute. ComWeb does this for a Content Manager automatically and transparently.
Reduced file sizes:
ComWeb can use frames to dedicate one area of the screen to site navigation and another to page content. Each frame may then contain separate HTML files and operate as 2 independent windows - much like the layout of Windows Explorer, Outlook, PowerPoint, etc.
If frames were not used, both the site navigation code and page content code would need to reside physically in the same HTML file.
Typically site navigation code is at least the same size (in characters) as the page content code. Therefore by moving this code from each page to a dedicated site navigation file, all HTML pages through the entire site would reduce by approximately 50% in size!
ComWeb dynamic site deployment:
From a ComWeb in Defence perspective, the main advantage of using frames is not file size, but rather performance.
Using frames the site menu is processed only once per site. This means, processed once on the server, transmitted once over typically very limited bandwidth to the client, then rendered once by the client's browser.
On the ComWeb web and database servers (both low-end 1 GHz Celeron machines on the DRN to late 2005), the first time a site was visited it took up to 4 seconds to process, transmit and display. This was made up with a site menu at 2-3 seconds and page content at up to a second. In this framed mode, subsequent navigation to other pages of the same site displayed within a second as the menu did not have to be reprocessed for each page.
Compared to framed operation (where the combined site menu and page content would be required for each page), savings were therefore:
- 75% less demand on the web server
- 75% less demand on the database server
- 75% less impact on the network infrastructure, and
- 75% less demand on the client browser processing and rendering.
Extrapolate these savings through the 75% of all Defence DRN web sites in ComWeb with collectively nearly 100 million hits to ComWeb pages in 2005 (advised by ISD using web traffic analysis software), and all would have to agree that framed operation was properly justified.
ComWeb static site deployment:
The advantages of framed operation in a static deployment is similar to the above, though concentrates on one aspect of the overall delivery, namely reduced bandwidth.
Deployed forces in various theatres of operation seek to obtain every available byte from limited bandwidth. Not only is the 50% reduced file sizes (see above) a major consideration in these cases, the bandwidth savings in synchronising changes to web sites could easily be 50:1!
| eg: |
Consider a site with 50 pages. If the site menu is embedded in each page (non framed) then the addition of a new page will result in one new file (due to page content) though the change to the site menu (resident in every file) means that every page changes and needs to be uploaded to the destination server. In a framed mode, only two files (the new page and the new site menu), need to be uploaded. |
In some cases bandwidth is so much at a premium that pages are also prioritised by importance and menu depth so that deployment decisions can be made as to which files are downloaded and which are delayed or not downloaded!
| V4.2 SP1 |
With this service pack, the ComWeb Static Site Publisher (SSP) can now post-process a stripped site and restructure it such that the html files including the site menu are renamed to Active Server Pages (ASP) and the common site menu code saved as a file which is included in each page at run time. |
Contact CompuCraft for further details.