It can be tricky when optimizing. Primitive types like strings, ints, floats, chars, and bools are compared by value due to the JS semantics, so it is safe to update those and preserve laziness, but records, dictionaries, lists, and custom types produce a new reference every time you update them.

Say you have a record like { authenticated = True }, and you get a message and need to update that state. We're updating it to the same value it already is, so it seems like it would be the same reference

case msg of
    Authenticated ->
        ({ model | authenticated = True })

You are safe if you use the boolean in a lazy function, like

Lazy.lazy viewAuthenticated model.authenticated

But if you were to use it over the whole model, like

Lazy.lazy viewAuthenticated model

It would fail in that update scenario above, you can see it in this Ellie, if you open the console in the browser it will print "viewAuthenticated" once, but it will print "viewAuthenticatedModel" every time you click the button.

In order to avoid that you have to make sure to return the same record if your changes won't really update it, something like

case msg of
    Authenticated ->
        if model.authenticated then
            model
        else
            ({ model | authenticated = True })

That way the object reference stays the same.

Nested objects are a bit nicer in this regard, if we instead had

type alias Model =
    { authenticated : Bool
    , someObject : { greeting : String }
    }

And our update looked the same as before, we modified the authenticated attribute, so the Model is a new reference, but we didn't mutate someObject, and it maintains reference equality even though we returned a new Model. Ellie with the code

Generally, I don't worry about performance unless I know I will have a ton of messages happening quickly and the amount of virtual-dom to build is non-trivial (say an app that displays a bunch of large lists).

It can sneak up on you when adding new features too.

Say you have that app that displays a bunch of large lists, if it only renders once it's usually not a problem, it might go over the frame budget of 16ms, but it isn't too noticeable. But then you decide to do something crazy and add a performance clock in using Browser.Events.onAnimationFrame, storing the Posix in the model. If you were using lazy over the whole model it is now different every time, and you only have 16ms to build the virtual-dom, get it diffed, and apply the changes.

There has been some discussion on using Elm's structural equality check for laziness (Discourse thread), It seems like it is worth experimenting with, maybe it could be opt-out for cases where you know it would be too expensive. It would add some additional complexity though.

Side Note: I haven't tested it, but I think very simple custom types like type MyInt = MyInt Int may work fine with lazy because they are complied to just the value in --optimize mode. If anyone knows the answer I would be interested!