【正文】 The period of caching dynamic Web pages generated by a JSP engine is limited due to the dynamic nature of the content. When the cached content of a Web page generated by a JSP engine is updated, the entire JSP page must be executed again on the application server, even though the change of the Web page might be small. Since frequent updates of cached Web pages increase the load on an application server, it is reasonable to split a JSP page into fragments and set different caching periods for the Web page fragments obtained by executing the JSP fragments. Of course, the Web page fragments must be merged into a final Web page correctly. The Dynacache technology of IBM WebSphere Application Server allows Web page fragments to have different caching periods. Cache tag libraries provided by the Apache Jakarta Project also support different caching periods for the JSP fragments. In addition, ESI (Edge Side Includes) technology provides a mechanism to cache Web page fragments with different caching periods, and to merge them into a final Web page on an edge server. The application offload technology of IBM WebSphere Edge Server is another approach to improve the execution performance of JSP pages. This technology allows one or more JSP fragments to be cached and executed on edge servers. The remaining JSP fragments are deployed on the application server and are called by the JSP fragments executed on the edge server. Thus, some of the execution of a JSP page is offloaded to the edge server. Splitting a JSP page facilitates the reuse of JSP fragments. When a Web application consists of many JSP pages, the same portions tend to exist in many JSP pages. Examples are the frames, the banners, the headers, and etc. When a JSP page is split into fragments, the total execution result of all of the fragments must be the same as the JSP page before it was split. In addition, when the fragments of a JSP page are executed in different servers, each fragment needs to be executed without the other fragments. In order to satisfy these conditions, we propose JSP splitting, which is the method of splitting a JSP page into fragments described in this paper. Since it is very difficult to automatically find the best way to split a JSP page into fragments for some particular purpose, we assume that the developers will select the portions that they want to split into fragments. In order to execute all of the divided JSP pages correctly, JSP splitting automatically detects any portions that must be moved or copied into a fragment with the selected portions. The detection is done based on the analysis of the data and control dependences existing in a JSP page. JSP splitting is similar to the program slicing technique that slices a program based on the data and the control dependences. However, the program slicing technique does not take into account that the sliced programs are executed independently and that the total execution result of the sliced programs must be the same as the program before the division. In addition, since data is passed to the JSP engine during the execution of JSP pages, the source program of the JSP engine, such as Apache Tomcat, is required in order to analyze the data dependences correctly. This is impractical, because the source program of the JSP engine is very large and plex. JSP splitting avoids the analysis of the JSP engine by utilizing the characteristics of JSP. The rest of the paper is anized as follows. Section 2 explains the difficulty of splitting a JSP page into fragments. Section 3 gives details of the algorithmto split a JSP page. Section 4 describes the JSP splitting tool that is an implementation of JSP splitting and demonstrates how a sample JSP page is split by the tool. Section 5 shows the experimental results obtained by executing the split JSP fragments with different caching periods on the IBM WebSphere Application Server. Section 6 discusses previous work in relation to our contributions. Our conclusions form the final section. 2. Difficulty of Splitting a JSP Page In this paper, splitting a JSP page means that some portions of the JSP page are cut from the JSP page and saved as new JSP pages. Such newly created JSP pages are included in the original JSP page by using some mechanism such as the jsp: include tag. We call the included JSP page the JSP fragment, and call the JSP page that invokes the JSP fragments the master JSP page. A master JSP page invokes JSP fragments and receives Web page fragments obtained by executing them. Then the master JSP page merges its own Web page fragment with the Web page fragments received from the JSP fragments, and creates a final Web page. JSP fragments are not always executed in the same server or at the same time. The application offload technology allows a master JSP page and JSP fragments to be executed in different servers. When the ESI mechanism is used, esi: include tags are put into a Web page fragment obtained by executing a master JSP page and interpreted in an edge server that supports the ESI mechanism. In this case, the edge server checks whether or not the Web page fragments specified by esi:include tags exist in its cache. If the contents of Web page fragments are not cached or have expired, the JSP fragments are invoked from the edge server, and executed in one or more application servers. If different caching periods can be given to the Web page fragments obtained by executing the JSP fragments, each JSP fragment is executed only when the cached content has expired. The Dynacache technology, the ESI mechanism, and the cache tag libraries can support different caching periods for Web page fragments. When a JSP page is split into fragments, the following two conditions must be satisfied even if the master JSP page and the JSP fragments