---
title: Optimizer | Tutorial
contributors:
  - manucorporat
  - adamdbradley
  - mhevery
  - mrhoodz
updated_at: '2023-06-25T19:43:33Z'
created_at: '2022-08-02T12:07:45Z'
---

For the application to be resumable it needs to have lots of entry points. For example, clicking on button `A` is a different entry point than clicking on button `B`. When we implement an application we don't usually think about entry points and so we typically end up with just one entry point or the `main()` function.

The Optimizer does its job by looking for functions that end in `$` character. For example, the Optimizer will transform a call to [`component$()`](/docs/(qwik)/core/overview/index.mdx#component) into an entry point. Notice that the name of the function doesn't matter only that it ends with the `$`.

Every time you see `$` you should think, there is a lazy-loaded boundary here. The implication is that the lazy-loaded content may require lazy-loading and hence can't be accessed synchronously.

While the Optimizer can serialize any data that Qwik can serialize, it has special handling for closures. Closures are functions that are created inside of other functions and that may capture variables in the lexical scope. The ability to serialize closures is a key property that makes Qwik resumable. Without closure serialization, it would be difficult to have resumable applications.

### Example

In this example notice that we have two lazy-loaded chunks because we have two `$` in our code.

Open the `Symbols` tab and notice how Optimizer turned the `onClick$` function into an entry point. Specifically, notice that the `onClick$` entry point does not import the `@qwik.dev/core` module.

Now change the `onClick$` callback to `store.count++`.

Open the `Symbols` tab again and notice that this time the Optimizer imported `@qwik.dev/core` and inserted `useLexicalScope()` call to restore the captured state of the event handler. Restoring the captured state of the function is what makes Qwik resumable.
