• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 454
  • Last Modified:

is there such a thing as too many include files

Hi, I am building the file structure for our ap.  I would like to place everything into include files as to eliminate redundancies.  We have a java ap and are interfacing with jsp pages.  Most of our includes are jsp, js, and css files.

I am nervous about placing too many include files in the structure as, the way I understand it, that causes a http request for each file and can have an effect on performance.  What is the most efficient way to call these include files and should I worry about having too many?

I have searched this out on the net and am only finding references between dynamic include calls vs static.  Nothing about how it affects performance and what it's capacities are.
Shaye Larsen
Shaye Larsen
3 Solutions
>causes a http request for each file and can have an effect on performance.  
Includes don't make a request. They are actions at the server and only  add output to the response. Requests are made by the browser for js and css files. So the number of includes won't effect the number of requests.
The only problem that you might encounter is in using <%@ include.....%>  It includes everything at compile-time. JSP has a limitation of 64k for the size of the servlet that is generated. If your code is that large then you need to use <jsp:include.....> to break up your logic, so that each JSP is generated into one servlet, and then the contents is all put together at run-time, not compile-time.  But chances are that you don't have to worry about that.  The use of includes will not effect perfomance. Hopefully some experts will add their wisdom here.
Performance does take a slight hit. Can you "merge" include file code into fewer larger files? I heard once you would not want more than about 4 included files, so I don't.
Shaye LarsenAuthor Commented:
Thank you for responding. Two totally different opinions is not what I was hoping for.  Nanharbison, can you back up your advise?  I did verify that JSP has a 64k size limit for servlets, but that is per instance and has little to no effect on performance.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

No I can't, I was told that by a "pro" in the company where I used to work, and I have always organized my web pages according to that rule.  I may be wrong!
>JSP has a limitation of 64k for the size of the servlet that is generated.  
I copied that from another expert. But now I think that it not exactly right.  
>I did verify that JSP has a 64k size limit for servlets  
Could you post the link ?
I now think the correct statement is
"The JVM limits the amount of code to 65536 bytes per Java method"
from  http://www.deakin.edu.au/its/dba/oracle-doco/  
The code that is put into all the scriptlets and all template text on a page   is put into one method the _jspService method. So that is the limitation.  

How many includes are you thinking about using in one page ?  What type ?  static or dynamic ?  


If I may add my practice, I also put all my javascripts into client side "includes" and my common asp codes in includes. I don't do jsp but I would believe they are the same. So far, no problems about hitting any limit and performance wise, I cannot feel any difference between pages with and without includes.

However, I advise that you use includes wisely and balance against code readability and re-usability. Having many include files makes your code very difficult to read and debug. It will surely affect the development time and can result in a programmer having a hard time trying to figure out what the whole code picture is. Another bad point is that it isn't easy to find out where each include page is used.

My rule of thumb, which my team and I mostly follow, is if the code is reusable in more than 2 pages, it should be coded as reusable codes placed as an include file.

I agree with NicksonKoh -- those are good practices for Web site architecture.

We also don't see any performance hit with JSP includes of the type:
<%@ include file="/includes/myinclude.txt" %>
This is an include done at compile time in the jsp page, and the compile is only done once for all time until you change the code itself.  As mentioned by other experts here, the client browser doesn't know anything about this kind of include, and does not make any requests based on it.  It is server-side only.

Statements like this in HTML will result in a request for the file to the Web server, but generally only once in a session, or until the datetime stamp on the css or js file on the server has changed:
<link href="/myapp.css" rel="stylesheet" type="text/css" />

Using link href for css and js files is good coding practice, and Web servers and browsers strive hard to optimize performance around them.

If your servlet makes a redirect for every jsp page, then that will result in another request from the client browser to the server.  Sometimes it's the only way to handle the request.  However, in general it's good practice to either make your links to JSP pages, or to servlets which forward to JSP for display.  Don't make a request to a servlet, then redirect to a JSP to display the results, if you can avoid it -- if you think you are in a situation like that, then look again at your design -- it's likely that the design does not make the best use of Web server architecture.

I especially agree with NicksonKoh that it's important to make the Web software readable so that programmers can fix and enhance it in a reasonable amount of time.  It's unlikely that many include files of small amounts of code are necessary for the site architecture, and they reduce the readability of the code.

All of these suggestions are dwarfed, however, by the common performance problem of making too many database connections to create a page display.  Just FYI.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now