Reduce server traffic with HTML frames

The question of whether or not to use a framework has diverged in the field of web development, and most people have no hesitation in opposing it. Web developers don't like the web framework for several reasons, one of which is that the framework causes addressing (navigation) to be particularly troublesome, and some older browsers do not support them. Another reason is that some web addresses have in the past forced the framework (framesets) to connect to the contents of other addresses.


Although these issues are not groundless, I still think that using the framework is the right direction, the framework is useful, especially in reducing server traffic. I'll briefly explain how to use the various frameworks and see how they reduce server traffic.

Type of frame
The first frame is about frames. It divides the browser window into several child windows. Each child window displays a different HTML file, which is where the developer updates the selected child window rather than the entire page. When the user clicks the "Back" button on the browser, the problem is addressed, but this solves the problem by adding Window.history.forward (1) to the JavaScript statement in each child window to invalidate the back button.

An example of such a framework is given below:
<frameset rows= "50%,*"
<frame src= "page1.asp" name= "Bob" >
<frame src= "page2.asp" name= "Paul" >
</frameset>

The above example gives the main framework two separate frames named Bob and Paul. Although the frame Bob's document.location is Page1.asp and Paul is page2.asp, the two pages can interact and communicate with each other. For example, JavaScript statement top.Paul.readyState allows the Bob framework to detect whether the Paul framework is loaded completely.

The second type is an inline frame (inline frame or iframe). It has been introduced by Microsoft Internet Explorer version 3.0. It embeds an inline frame in an HTML document, just like an HTML document embedding a picture. The inline framework allows developers to embed an HTML document into another HTML document. This is the syntax for embedding inline frames:
<iframe name= "Nan" src= "page3.asp" width=90 height=50></iframe>

On the surface, the role of the inline framework is the same as that of Commodore VIC-20 in today's business environment. However, the inline framework does have some usefulness. We will discuss one of its possible uses in the middle of an article.

Use an implied frame (hidden frame) to reduce traffic
Now imagine a frame of zero size. This framework is implicit to the user. That sounds like no use. However, when you try to reduce server traffic, the implied framework is much more important.

One effect of the implied framework is to save the information needed for later processing. For example, I have established a web-based technology application system for an insurance company. The system allows Internet users to submit applications that require system support. There are approximately more than 10 types of applications, ranging from "Running the Blur report" to "accepting input files, translating it into network format, and then loading the security (insured) database."

Depending on the application, the customer needs to fill out one or several pages of information. I then used the data to be staged in a table in the implied framework of the client, rather than immediately sending them from the client to the server and storing them with a set of variables. When the user uses the Back button, the previous page he browses to is recovered from the implied framework of the client, not the server. This reduces the traffic on the server. When the user fills out and clicks the "Submit" button, the information stored by the implied framework is submitted to the server.

As in most cases, the technology can be further promoted. I've seen a network developer use up to 50 implied frameworks that contain all the objects that are likely to be used by the program. These objects include types such as Drop-down lists, images, Swing applets, and so on. When the initial load is complete, the program runs quickly-because, for example, it does not need to create a drop-down list containing the product name, but simply copy the Drop-down list from the implied list. I think this is the most brilliant idea I have ever seen. But there are still some problems to be solved.

Imagine that if you load 50 Dynamic Web pages at the same time, most of them will also need to access the database, the rest of which contains large images or simply big Java Swing applets. I can say for sure that if you load it at once, the program will run very quickly, but on Ethernet, the load process takes 5 minutes. If it's 56K (modem), I can't imagine how much time it will take. Although using the technology (saving downloaded objects with an implied framework) leaves some problems, the technique is good.

Intelligent framework
None of the tools--including the framework--is not good or bad in this province. Most of the problems that developers encounter with it stem from the misuse framework. As we can see, if used properly, the HTML framework provides a way to mitigate server traffic. In my other article, I will provide a practical approach-it does not take 5 minutes to download the objects required by the implied framework.