Stellar (XLM) Freighter钱包通过技术升级将加载时间缩短63%
Freighter钱包的显著优化
Stellar (XLM) 的Freighter浏览器钱包通过积极的缓存策略、批量获取和更智能的资产图标加载,将初始加载时间缩短至1.27秒。
根据开发团队在2月23日发布的技术分析,Freighter浏览器扩展钱包经过数周的优化,启动时间减少了63%,现在仅需1.27秒即可完成加载。
用户体验痛点的解决
此次改进针对加密钱包用户长期以来的痛点:等待余额和交易历史显示。对于需要在波动市场中快速访问的交易者来说,每一秒都至关重要。
具体改动内容
Freighter团队发现外部API调用是主要瓶颈。此前,钱包在启动时会同时获取账户余额、交易历史、资产图标和多个数据流——这导致用户必须等待所有数据加载完成才能看到任何内容。
解决方案是首先仅加载账户余额,然后在后台获取其他数据。交易历史、资产列表和图标现在会在主界面渲染后异步加载。这些数据会被缓存,因此当用户导航到“历史”选项卡时,数据会从本地存储中提取,而不是触发新的API调用。
资产图标加载问题的优化
一个特别低效的过程涉及资产图标的加载。旧方法要求为每个资产进行三次独立的网络往返:首先从Horizon获取发行方账户,然后加载关联的TOML文件,最后抓取图标URL。这一过程会因用户钱包中的每个代币而重复。
新方法首先检查资产列表——因为流行的Stellar代币已经被编目——仅在必要时才回退到多步骤流程。即便如此,团队切换到Stellar RPC的账本条目端点,该端点可以在单次调用中返回多个资产发行方,而不是逐一迭代。
激进的缓存策略
钱包现在会缓存几乎所有内容,直到用户关闭它,并在三分钟的陈旧阈值触发自动刷新。显然会使缓存数据失效的操作(如发送付款、添加信任线)会立即触发重新获取,而不是等待计时器。
对于交易历史,团队实施了批量获取以避免冗余查找。用户经常多次与相同的Soroban合约交互;在第一次遇到时缓存合约数据可以消除处理后续交易时的重复API调用。
为什么这很重要
随着钱包选项的增多,浏览器扩展性能仍然是竞争差异化的关键。关于2026年扩展优化的研究强调,运行不必要代码的内容脚本直接影响感知速度——这正是Freighter通过推迟非关键加载所解决的问题。
1.27秒的目标使Freighter在浏览器扩展领域处于合理范围,尽管使用较慢连接或拥有广泛交易历史的用户可能仍会经历较长的等待时间。随着时间推移,缓存改进应通过更多本地存储的数据产生累积效应。
Stellar的原生代币XLM继续在全球市场条件下交易,钱包改进可能会减少活跃管理网络头寸用户的摩擦。






