Its been quite OK for a long while to work with the document. At runtime in the browser, all runs very fast.
Now, suddenly opening, exporting goes very slow.
It has 18 scenes.
0 font data
654 KB SVG files (103 files)
664 KB SVG files (33 files)
211 KB PNG files (18 files)
( In total: 154 graphic files, 1.5 MB. )
About 100 small javascripts, 5-20 lines of code.
The _hype_generated_script.js
becomes 3.1 MB.
The -restorable.plist
becomes 2.8 MB
Is there anyway — except for splitting the document into several documents — that would speed up opening the document, exporting, perhaps reduce the Hype document file size?
Have I feeling the kept history of all edits makes the document big. Can that be true? (For the ‘revert/browse all versions’-feature.)
One important thing to keep in mind is that when people actually visit your website, if they are downloading a gzipped version of your .js file, the file size can be reduced enormously. To test the gzipped size, you can do this:
You can see if Gzip is on for your server by looking at the network tab in a browser’s developer tools (Safari + Chrome provide this).
Versions won’t affect the amount of time it takes to open your document, and shouldn’t have an effect on performance. We’d be happy to take a look at your document to see what might be slowing things down.
This is not true - version history is not stored in the document and definitely not exported. The macOS autosave mechanism (which Hype makes use of) generally stores items at the root level of your volume in a hidden /.DocumentRevisions-V100/ folder.
Splitting up into different documents is generally the right strategy - if you have lots of elements, scenes, and animations, this will all add a lot of complexity and size. You're free to share your document for more specific pointers since sometimes these things are case dependent.
Won’t have time in this project to split the document.
Something to think of for future, more complex works.
I thought the concept of dividing into several documents was more related to the amount of image and sound data linked to the project — and not so much to scene complexity and the amount of javascripts.
If you turn preloading off, then the image/sound complexity isn’t generally a factor on how you split it up, because the work to the browser is the same. However when you have a lot of elements/symbols/scenes/animations that can definitely incur a cost. Of course, there’s some work that can be done in Hype to keep this smaller that I’d like to improve, too.
