首先，您异步发送您的印象，以避免妨碍性能。
不是请求的数量，而是同步请求的数量。
第二，你分批处理你的跟踪请求，以避免向mixpanel端点发送几乎没有填满的tcp-ip包。不确定mixpanel的sdk是否本机允许这样做。Firebase肯定允许。
第三，您限制字段的数量、事件的数量、字符串的长度，只是为了将更多的跟踪事件装入批处理的tcp数据包。
第四，你考虑改变你跟踪印象的方式。有几种不同的，不那么直接的方法来跟踪它们。例如，如果页面上的产品对每个访问它的用户都是一样的，您不需要为每个用户发送相同的印象，您可以假设每次访问此页面时都会自动获得所有这些印象。您甚至可以将数据从mixpanel ETL到一个更合适的事件存储中，并单独用补充印象填充表。
最后，即使你不做这些优化，只确保分析是非阻塞的，你真的看到了有和没有分析的性能差异吗？也许你生成印象事件负载的方式在某种程度上损害了CPU？衡量损害你的确切点。分析是前端的一个明显的原因，但它很少是性能问题的真正原因。