Back up regularly!
Neither the hardware nor software in your computer is perfect. Computers fail and software can crash. Back up your projects to protect yourself from losing work. It is essential to also maintain off-site backups. If all your backups are in the same computer or saved to disks all in the same building, catastrophic events like fire, floods, theft or simultaneous hardware failure can cause you to lose all your work and backups together.
Cloud Save is a good way to save your work where it is safe in case of disaster. However it is wise to keep secondary backups anyway, in case you lose access to your account, or the service has an outage or even shuts down. Construct can help you do this by automatically making backups. See the Save & backup section of the Settings dialog. Check Periodically back up active project, and choose the location and backup interval. For example you could set up an automatic save to the same location as the project every 10 minutes, or select a local backup folder (where supported by the browser) to save backups to.
The advice to back up regularly is not specific to Construct. It is vital to adopt this practice for any work on a computer which is important to you. Do not wait until you've lost work before starting to do this. People lose work regularly from having poor backup practices. Don't be one of them!
Test on multiple platforms, browsers and devices
It is essential to test your game works as intended in a range of different systems. While Construct 3 games are based on the HTML5 standard which in theory is implemented the same on all platforms, in practice there are variations between browsers and devices (e.g. in performance, features, text rendering, etc). You should install a range of browsers on every device you have available and test with them all to ensure your game will work well for everyone. Remote Preview Paid plans only can help with this, especially since you can get anyone in the world to help test with their devices. You may also need to make test exports to check how your project works as published, since app containers like Cordova (for Android and iOS) can have differences too.
Support touchscreen devices
Many users now browse the web with touchscreen devices. If at all possible, you should design your game to also support touch input. Often you can simply use the Touch plugin instead of the Mouse plugin.
Recommended file formats
You may wish to prepare artwork and audio in other software before importing to Construct. These are the formats we recommend.
Use 32-bit PNG (Portable Network Graphics) while preparing images. Be sure to select 32-bit if you are given a choice; the 8-bit or lower versions will degrade quality. 32-bit PNGs are lossless and fully support alpha-channel transparency. Note some images such as Microsoft Paint do not support PNG transparency. Use may need to use a different editor instead, such as Paint.NET on Windows.
You can choose different export formats like JPEG inside Construct to reduce the size of your finished project. However when importing you should still stick to 32-bit PNGs if possible, and leave Construct to recompress them when exporting. Construct does a lot of optimisation on export for you. It is unlikely that any third party tools or services will be able to beat Construct's existing lossless optimisations, unless they degrade the image quality. Remember there is no point optimising images before importing them to Construct since it stores them in projects as 32-bit PNGs with default compression settings; they are only optimised on export.
Use 16-bit PCM WAV while preparing audio. These are typically .wav files, but note that not all .wav files are 16-bit PCM. Importing a 16-bit PCM .wav file to Construct will automatically encode it to WebM Opus. PCM WAV files are lossless, ensuring there is no quality degradation while you prepare your audio files. Allowing Construct to perform the encoding ensures the encoding is only done once (so there is no unnecessary degradation), and that the correct format is used for support across a wide range of platforms.
Always test on the target device from the start, especially for mobile devices. Your computer could be several times faster than your mobile device, and something which runs fast on your computer may be unplayably slow on the mobile device. Testing regularly on such devices also allows you to quickly spot any changes which have a big performance impact and revise it to be faster. Don't fall in to the trap of making an entire game before running it on mobile, realising that it's slow, and then having a very difficult job working out why. It is far easier to test as you go along. There are many more best practices to avoid poor performance - for more information see the section on Performance Tips.
Some designers are tempted to design entire levels from lots of large image tiles. This method should be avoided since it is extremely wasteful with memory, and is not used by any professional game designers. The subject is discussed in detail in the blog post Remember not to waste your memory. See also the section on Memory usage.