Load JARs lazily JavaFX applications jars are downloaded eagerly by default using Java Network Launching Protocol (JNLP). This is fine for smaller applications. However, when you have several large JARs that are part of your application's manifest, this can cause a delay in startup time. You can change this behavior and download JAR files lazily as needed. Update your JNLP file with:

<jnlp>
...
<resources>
<jar href="demo-util.jar" download="lazy"/>
...
</resources>
</jnlp>

Index your classes one way to improve startup performance is through the use of JAR class indexing. Traditionally, the class loader will traverse each JAR to look for a classes to load. This can be a performance killer at startup to wait for JARs to download and classes to be loaded. Indexing is used to by the class loader to find classes quickly that are embedded in the JARs. To index your classes, use the jar command line tool with the -i option followed by a list of JAR files to be indexed (as shown next). The index information is saved as a text file embedded inside the first JAR file listed in the command.

jar -i main-app.jar \
jar-module-1.jar \
jar-module-2.jar \
jar-module-3.jar \
...
jar-module-N.jar

Compress JARs with Pack200 it goes without saying that the size of your JAR files will impact startup time. You can further squeeze the size of your JAR files with the pack200 option when packaging your application with the javafxpacakger, using the -pack200 flag as follows:

javafxpackager -src src \
-appClass draggable.demo.Main \
-appName demo-app \
-pack200

Provide ample memory avoid application death caused by 'out of memory' exceptions. This is a nasty situation which can damage the reputation of your app as being broken. The good news is, it can be easily prevented by setting the heap size of your app in the JNLP file

<jnlp> ...
<resources>
<j2se version="1.6+" max-heap-size="256m" />
...
</resources>
</jnlp>

Avoid excessive JAR update checks JavaFX applets and Web Start applications will automatically check for updates for the JAR files included in your application upon startup. You can either turn that off (if you don't plan on having updates), or do the update in the background by specifying it in your JNLP file as follows:

<jnlp>
...
<update check="background"/>
</jnlp>

JAR versioning if you decide to have your JARs be updated automatically (see previous bullet point) you can use JNLP's JAR-versioning mechanism. It uses this mechanism to update JAR files when version number changes, instead of checking for updates for all JARs. To take advantage of this, name your JARs using this format {jar-name}_V{version-number}.jar, for example demo-util_V1.0.jar. Then, set the jnlp.versionEnabled attribute in the JNLP file as shown:

<jnlp>
...
<resources>
<jar href="demo-app.jar" main="true"/>
<jar href="demo-util.jar" version="1.0"/>
<property name="jnlp.versionEnabled" value="true"/>
<resources>
</jnlp>

Avoid signing your application while a properly signed application can establish a certain level of trust, signing, however, can introduce new dialogue boxes that force users to confirm their trust in the application issuer. So, unless you absolutely need signing, avoid it. An unsigned application causes a security dialogue to appear only when the application attempts to execute privileged code. Furthermore, users can opt to trust the the unsigned application and no longer be presented with future security warnings.