Thanks for those examples, it makes your question much clearer.
In short my answer is to use (in order) stock Typst, packages on Typst Universe, then images. If one can’t fulfill your need, use the next. If you have a giant document that takes too long to compile try to find the reason for the slowdown and make improvements then. There are a few posts on the forum about this exact topic.
First Example - PDF book
Quickly looking through it I see these things that “graphics”. For each of them I give a suggestion of how it makes sense to me to include them in your document
- Tip/Info/Warning boxes which can be provided by a few packages on Typst Universe. I don’t see a good way to use SVG or image files for this. Native Typst seems like the clear choice
- Diagrams can also be done by Universe packages with diagram source in its own file (or directly in the Typst file). Pre-computed SVG or images could be used here but depending on the type of diagram it would be extremely easy to switch between using a diagram package or a static image
- Pictures would be image files. If you are include a lot of images, it can be useful to also have an option to compile the document with placeholders - blank rectangles the same size of the image (related question)
- Software screenshots would also be image files. Though there are a couple packages that simulate the look of chat software - messeji and ourchat
- Code blocks can easily be done with stock Typst or packages like codly or zebraw
- Tables of CSV data can easily be displayed with stock Typst
Second Example - Online book
Maybe the printed version has some but I couldn’t find any images in the 10 or so pages I checked. I’m not sure this example relates to your question since the answer would be to simply use Typst for the entire thing.
One aspect that isn’t directly related to including images and graphics in a document but does affect speed is how you structure your chapters, sections, data, images, appendices, bibliographies, etc. In the case that the entire document compiles too slowly to be considered realtime, then you could work only on a file for a single section which will be much faster. Then you would compile everything much less often so the time is less critical.
One example of how to structure your project is here: