The API methods *reference* isn't supposed to explain what's already explained in a dedicated article on messaging: https://developer.chrome.com/extensions/messaging

In short, "connect" methods are for long-lived connections between two pages. The obvious advantages would be that 1) the message port doesn't need to be created for each message whereas one-time simple messaging creates a new temporary port internally, and 2) any two of the extension's own pages can exchange messages "privately" without broadcasting each message to all of its own pages such as open browserAction popups, option pages, devtools panels, etc.

See also the demo extensions:
https://developer.chrome.com/extensions/samples#search:connect

On the other hand, it might be a good idea to add a link to https://developer.chrome.com/extensions/messaging in each messaging-related method in the reference.

As I understand long-lived connection will work faster than the opening of port for every message?

But if I have an event page and popup page maybe it is not much sense to use long-lived connection because popup will be closed (killed) on next second and event page will die after few seconds?

The actual difference in performance is usually negligible unless you send hundreds of messages per second. Also, if it's between the popup and the background page, it might be better to access the background page directly via chrome.runtime.getBackgroundPage()

The event page will not unload until all visible views (for example, popup windows) are closed and all message ports are closed. In other words, no connection to the event page can outlive the event page itself. It's connected only while it runs.

Normally, long-lived port connections aren't really needed, but there are some cases when this is the only method (e.g. communicating with a content script that's loaded in a web iframe inside the background page), or when this is a preferred method for page-to-page communication (to avoid broadcasting into all open internal extension pages such as open popups, option pages, background page, etc.), or when you want to detect the moment the other connected context was unloaded (e.g. a content script can detect if the entire extension was reloaded on chrome://extensions page or upgraded/uninstalled).

Could anyone from extension team look in to this issue?

Thanks!

Seems it is out of scope from TE end, adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!