Decreasing load times and optimizing performance: Preparing a Large project in Hype

Tumult Hype is built for producing animations as a part of other websites, but we have also seen projects that take the form of entire websites. While building and launching large Tumult Hype projects with many scenes is possible, there are a few things you should keep in mind to ensure that your website loads quickly, works well on mobile devices, and is easy to maintain:

Defer loading of images

Images added to your document will need to be downloaded when your visitor first visits your site, unless you explicitly turn off 'Preload' in the Resource Library. Images with 'Preload' checked will be downloaded before your Tumult Hype document can appear. The image below will be downloaded only when its scene is loaded:

Split up large projects

Separate large projects into multiple parts. As the number of elements used in your projects increases, the memory requirements of your document also increase. This can cause memory and performance issues on mobile devices. A good upper limit on the number of scenes is 15. This ensures that the elements and images loaded into the browser’s memory is low. A good way of testing this upper limit is to create a scene with the approximate number of elements, and to duplicate it 15 or more times (select a scene, right click on it, then click ‘Duplicate Scene.’) Loading this document on a device will give you an estimate of its performance and alert you to memory issues.

A typical structure of Hype document to make up a single website would look like this:

  • Index (Links to separate parts of the site)
  • Gallery (This contains links to different portfolios, but does not contain a portfolio)
  • Portfolio 1
  • Portfolio 2
  • Contact Page
  • About

To link these different documents together, you would use each documents URL in the ‘Mouse Action’ area. If you were in the ‘Index’ document and you want to link to the ‘Contact’ page, you would use the name of its .html file: http://site.com/contact.html. Naming your .hype documents simple one-word names is useful when linking between them since the name of the exported document defaults to the filename. Here is a technique to link to a specific scene using a snippet of Javascript :

Consider mobile devices:

Please read more about Mobile Device support in our documentation.

Identifying large resources

The more images, animations, and content you have, the longer it will take to load your Tumult Hype document. There are a number of ways to decrease loading times: First, determine what's taking so long
First, open up the Resource Library and sort by filesize. Uncheck 'Preload' for large images. Another way to check what is taking long is to load your site from the web with the Safari web inspector turned on. This can show a timeline of what resources are holding up the load. Here's instructions to see this:

  1. In Safari, go to the Advanced preferences and check "Show Develop menu in men bar"
  2. Choose 'Safari > Empty Cache...' and empty
  3. Quit and relaunch Safari
  4. Load your page
  5. Choose the new 'Develop > Show Web Inspector' menu item
  6. Click on the Resources tab
    This will give a timeline of how long it took each resource to load, and should make it easy to identify if you have any large resources that are holding up the load time. There are some more detailed instructions here.

Please note that Tumult Hype will preload all image resources, so if you have particularly large images that can hold up the initial load time. Videos will not slow down the initial loading time.

Optimizing Images:

On your Mac

If you have already added images to your project and you wish to optimize them, download Imageoptim and drag your exported Resources folder onto the application. (Please make a backup of your document first in case there are any issues).

Please note that Hype will downscale your images when appropriate and also generate @2x images for retina device support. Using Imageoptim will optimize all images.

Other ideas

Delete Unused Keyframes
When you create animations, keyframes define the starting and end point. If you don't animate between keyframes, Tumult Hype still saves those keyframes into the generated JS file. You can remove unused keyframes (these appear as red diamonds unconnected to other keyframes) by clicking and dragging over them, then hitting the delete key.

Tell your user what's happening

If you're finding that you can't get your website to load quickly enough, it's a smart idea to enable the 'Loading Indicator' for your site. Open the Inspector, and go to the 'Document Inspector' tab. Select 'Show Loading Indicator' and your users will see a loading bar as the site downloads. It's nice to know the gears are turning. IF you want to create your own loading indicator, please see our guide on creating a custom preloader.

Use a CDN, & Leverage Hype's CDN

Host your site files on a CDN-enabled host like Vercel or Amazon Cloudfront, or sign up with Cloudflare to get files to your users faster (they have a free plan).

Using Advanced Export, you can use Hype's CDN for the entire runtime. This will ensure that any runtime files will never be downloaded twice if you have multiple Hype documents at multiple URLs.

Enable Gzip your Server

This post explains how to make sure your server is serving compressed content over the Internet. this has a large effect on JavaScript files which can give you a speed boost.

Caching elements for Offline applications

For a quick tutorial on how to get your site assets to work with a persistent 'Application Cache' read this guide on cache.manifest.

While this will not increase the time it takes for your document to load, it may increase the speed on subsequent loading on your site. It places image content into your browsers cache so they will not be downloaded unless the filename has changed, or you have re-exported your document. Cache manifest files are versioned.

Further Reading

12 Likes

Great resource, Daniel!

If I to create a full site in Hype, I’d like to:

  1. Be able to combine all Hype common resources ( “HYPE-458.full.min.js”, “HYPE-458.thin.min.js”, etc.) in the same folder. Otherwise 40-page site will end up with 40 copies of .hyperresources. I know, I can edit page HTML later on, but if I alter any thing in Hype, I’ll have to do it al over again.

It’d certainly be better to be able to create Hype project and Hype file.

  1. Use local links instead of absolute URLs. This is possible if in Go to URL one uses “/page.html”

  2. Use of external CSSs. Ability to link to external CSS in the project level. Sorry, if I miss it, but how would I add a class to Hype element?

1 Like

Figured out how to add external CSS class to an element: in innerHTML.

I tried Imageoptim, it is really useful if export resources folder, but what about if the project is export by OAM widget? anyway to optimize those images either?

Thanks.

Alex

Couple ways to do this:

Each time you export as OAM: You could break open the OAM widget by renaming it as a zip file, unzipping it, then optimizing those images, and then re-zipping it and changing the extension to OAM.

Or, one time, based on the current export state: When Hype exports images it will scale them down based on how your using the image in your document. So you would export to a folder on your desktop, optimize those files, and then go into the exported resource folder and manually replace every image. You would then need to turn off ‘automatically optimize when exporting’ – this would require that you add both the 1x and @2x version of each image back in. The first option is probably best :slight_smile:

Yes, it is. I did not know OAM could be unzipped. Thanks.

Alex

1 Like

there is a dead link of Here

Alex

1 Like

8 posts were split to a new topic: Optimizing an OAM file after Export with Imageoptim

Hi,
the last post here ist 2 years old but I hope I can get help here anyway.

I have a large hype project with several scenes that I exported separately and distributed on several subdomains. I have severe loading problems and pagespeed insights says (on most of them):

  • Avoid enormous network payloads
  • Serve static assets with an efficient cache policy
  • Minimize critical request depth
  • Minimize main thread work
  • Reduce JavaScript execution time
  • Avoid an excessive DOM size

... I know this sounds really bad and I'm not a programmer, have no clue about JS programming stuff and that is maybe one of the problems.

However, I searched for help in the forum for days and tried the following:

What I tried until now:

  • I converted all pictures to jpeg2000 (cause page speed insights told me to)
  • I unchecked the "automatically optimize" button in the resources tab (there were layout problems...)
  • I unchecked the preload button in the tab

What I tried but didn't work very well:
I read in the forum that most of the problems could be solved by a htaccess file that manages compression and caching. I tried these

and this

and this

I created the file, uploaded it to the folder xyz.hyperressources and renamed it to .htaccess.
The compression code doesn't have any effect on the loading time, also in page speed insights the same problems are displayed.
Uploading the caching code causes the page to turn blank with error 500 or 404.

What I will try in the future but need more information:

  • Using a CDN like Amazon CloudFront.

Can anybody help me?
Have I missed something?
Is there another possibility to decrease the load times?
Have I done something wrong?
And are there any tips for this CDN thing? Do I have to have privacy concerns using this (I live in Germany...)

Thanks guys, really appreciate that you kept reading till the end.

Ultimately when doing anything performance related, the most important step is to measure. While the page speed insights might provide an overview of algorithmic ideas on what may be wrong, it lacks fine-grained measurements and sensibility as to the purpose of your content. I'd also make sure that you can reproduce performance problems - relying on a tool to tell you about them doesn't necessarily make them true.

Proper measurements provides two most critical bits of information:

  1. What is slow (and by extension generally the source of the slowness)
  2. If your changes improved the situation

Further, the strategy should always be to tackle the slowest part first, and work your way down the list as each issue is resolved. Working in the wrong order is ultimately a wasteful pursuit and can also make higher priority improvements harder to make as well.

You'll need to fire up the web developer tools and take a look. There's plenty of informatin around the web on how to go about performance work; here are two links from Google on using Chrome to do so:

https://developers.google.com/web/tools/chrome-devtools/network/resource-loading
https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/timeline-tool

So there's no way to specifically answer performance questions as any tips on what to do with your document may not apply or may even be harmful!

There are a few comments that I can at least bring some illumination to:

Those items are too ambiguous to specifically state if they create natural problems. For example, if your content has complex animation, then there's a lot to do. So "Minimize main thread work" could be akin to saying "reduce animations" when your whole goal is to have a lot of animations!

I don't really get this advice unless this table is wrong! Regardless jpeg2000 does have better compression, but comes with many other tradeoffs. Typically just making sure your image is in "the most optimal" format is going to be a bigger win. For example depending on the image content, you may be able to use a 20kb SVG instead of a 2MB JPEG2000. You really need to look at content, sizing, and compression individually.

If you are using Flexible Layout, then automatically optimize shouldn't do anything. Otherwise it will look at image usage and generally always produce smaller images -- that's the point of this checkbox!

gzip compression only applies to text-based files. Further, it will only help with the download time. Usually the heaviest bits in a document are not the text-based files, but images. Images are either not served with compression or would not benefit (as formats like jpeg are already compressed!). So this is only helpful specifically when there's a problem with the download time for a lot of text content. If you have a lot of text content, there could be other problems, like the parse time, memory usage, etc.

It could also be that the server is also already configured to use compression, or is configured to not work with those settings!

CDNs can be extremely helpful when network load time is a problem specifically because of geography or slow servers. Otherwise they won't really help.

You can serve Hype's runtime from a CDN via the Advanced Export panel. This will allow different documents to use the same source - which then also means it will likely be cached by the browser. But the Hype runtime itself is only one network request and pretty small, so it is unlikely this is a top-level performance issue in the first place.

So I'm sorry there's not specific advice; this is just the result of the many variables (document, content, formats, servers, browsers) etc. There's no panacea or shortcuts. Just look at the performance graphs and work your way down the list to improve!

1 Like

Thank you for your reply.
I will do my very best.

1 Like

This no longer seems to work when using it with the Wordpress plugin it does not up load :frowning:

Worked it out I was zip back up the whole folder instead of just the assets and config files