-
-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
打开设置页面卡顿[Bug] #2516
Comments
不只是设置页,整个lobe都卡卡的,切换对话,卡片的时候,经常要刷新页面。 |
Not only the settings page, but also the entire Lebo is stuck. When switching conversations or cards, I often have to refresh the page. |
@Cp0204 你确定最新版本还有这个问题吗 |
@Cp0204 Are you sure the latest version still has this problem? |
|
是的,最新版。lobe请求资源太频繁,首次打开,就有200+个请求,切换对话,也会请求,部署在远程的体验很不好。 |
These resources will be requested every time you switch conversations, which is actually unnecessary. I don’t know if the author deployed it locally and used a very high-configuration computer (or is it the difference between mac and windows?), because I tried to search for solutions under the issue and found that many people have reported the lag problem. The author doesn't seem to feel strongly about it. In fact, the lag is very obvious. I also suspected a network problem and tried deploying a domestic server. There was a slight improvement, but there was no qualitative difference. |
确实很卡 |
Really stuck |
+1 |
求求你把ssr,server component去掉💔 |
Please remove ssr, server component💔 |
是因为这个请求卡顿吗? |
Is it because of this request? |
这些资源应该都在 service worker 缓存了的。你说的卡应该和这个没关系 我日常用的是MBP 20年 M1 的 13寸,并没有很卡。另外之前已经做了非常多轮的性能优化,应该比以前好很多了。目前剩余已知的是会话页面的切换和助手的切换是还存在一定延迟的问题,下个月应该能根治掉了。 |
These resources should be cached in the service worker. The card you mentioned should have nothing to do with this. I use the 13-inch MBP 20-year-old M1 on a daily basis, and it’s not very stuck. In addition, many rounds of performance optimization have been done before, and it should be much better than before. What is currently known is that there is still a certain delay in switching session pages and assistants, which should be resolved next month. |
反正没有NextChat丝滑 |
Not as smooth as NextChat anyway |
有缓存的情况下体验还过得去,首次访问的加载速度是真的慢,PC端要1分多钟才渲染完毕。我对比过ChatGPT-Next-Web和chatgpt-web-midjourney-proxy,PC端浏览器他们只需要三四秒,移动端lobe也至少比他们慢一倍,包括PWA应用。推荐给朋友都不好意思,用户体验堪忧呀,希望能多多测试优化一下。 测试用户端:Windows11 Chrome浏览器 1716173717854-1716173266494-20240520_104413.mp4 |
service worker 也撐不住資源多啊,一個幾十毫秒,時間都量變引起質變了。再加上服務器的請求…… 😂 |
The service worker cannot support the large number of resources. Every tens of milliseconds, the time changes quantitatively and qualitatively. Plus server requests... 😂 |
@BruceLee569 preview 站点的访问也有这么慢么?另外我拿我的电脑打开你的站点很快啊,没缓存的情况也基本上秒开。你确定不是你的网络问题么? default.mp4 |
@BruceLee569 Is access to the preview site also so slow? In addition, when I open your site on my computer, it is very fast. Even if there is no cache, it can be opened in almost a second. Are you sure it's not a problem with your network? default.mp4 |
@arvinxx 网络没问题的,直接进这个聊天页面会很卡:https://ai.jdz-ceramic.com/chat 像你这样先进主页,再点立即开始速度就还好。 另外提个建议:感觉主页没必要单独显示一个欢迎界面,没啥作用,直接显示对话框用户体验会更好吧,主流的工具默认都是一个对话框,功能够用能用就好,拖慢性能的实现可以考虑放一放。 |
首次访问的请求数😂,虽然有绝大一部分是UI出来,可以边用变加载的。但是1000+个请求,也真是不太优雅。 |
Number of requests for first visit😂 |
2024-05-20.2.35.28.movMacBook Pro 15 mid 2014 16GB |
😂 跟我一样,没有对比就没有伤害。。 |
@ShinChven 如果是这个配置,使用 LobeChat 会卡的话,我个人还是建议你使用 NextChat 吧。 我并不打算为这么老的设备做什么优化,抱歉 🤷♂️ |
@ShinChven If LobeChat is stuck in this configuration, I personally recommend you to use NextChat. I don’t intend to do any optimization for such an old device, sorry 🤷♂️ |
我主力机 M1 Max 64GB 进 Settings 也卡…… |
My main machine, M1 Max 64GB, is stuck in Settings... |
@ShinChven 那能否录个屏看下具体怎么卡呢? |
@ShinChven Can you record the screen and see how it gets stuck? |
我用了这么久,都安利给几个朋友了。谁也不会去留意首页的跳转路由啊,所以我说缓存之后再用速度还可以,但进设置页还是会卡,我对前端不太熟悉,但我觉得点击后路由跳转到 即使将它优化到秒进,让请求在后台成功后再更新数据,但我只是进一个首页,后台在那里默默发送超过1000个请求(绝大部分都是不知道有什么用处的 js 文件),然后点一下设置,又在那里发送超过500个请求,说实话用这耗电量都大好多。 大部分用户都是普通人,第一次打开的时候也确实很卡(人们分享的时候也不会留意链接是首页还是聊天页),我试了你的 vercel 链接也是一样卡,跟 cdn 没关系,请在Windows端测试一下。 1716204996711-20240520_191121.mp4找到bug点了,3秒请求之后,在页面处随便点击一下,UI就渲染出来了。(虽然后台还是会默默依次发送近1000个js请求。。) 20240520_191324.mp4 |
这个似乎是 SSR 水合问题… 就是客户端和服务端的语种没有匹配上,导致首次水合失败,然后会一直 fallback 到静态 html 的样子。只有用户做了点击操作后,才会重新在 client 端进行渲染。但第二次及以后,客户端的主题/语种都会在 cookie 中记录下来,这样水合就能顺利完成。 我理解这个应该也就是第一次会出现,而且用户不做任何操作的概率也比较低,所以一直没当回事 😅 我看看后续怎么修复下吧。
这个我理解应该是 pwa 的特性吧?浏览器会在空闲的时候预先将整个网站都缓存下来,这样在未来打开网站的速度会加快。这不算一个 feature 么… |
This seems to be an SSR hydration problem... that is, the language of the client and server do not match, causing the first hydration to fail, and then it will fall back to static html. Only after the user clicks, it will be rendered again on the client side. But the second time and later, the client's theme/language will be recorded in the cookie, so that the hydration can be completed smoothly. I understand that this should only appear for the first time, and the probability of users not doing anything is relatively low, so I haven’t taken it seriously 😅 I'll see how to fix it later.
I understand this should be a feature of pwa, right? The browser will cache the entire website in advance when it is idle, so that the speed of opening the website in the future will be faster. Isn’t this a feature?… |
你说的发给 |
You said to send it to |
嗯嗯 感谢回复 现在好很多了 设置项每次点完还是需要等待渲染,不能秒开,操作速度一快UI也容易反应不过来,给人感觉卡卡的。首次缓存后再次点击,大部分UI都不用等待渲染了。但是关闭窗口之后再进入又会慢一点,PWA应用杀后台再进又会更慢一点。 后续能够注意优化就更好啦 👏 |
问题是本质不是加载慢,而是操作的时候UI卡顿,比如点任意一个按钮,都要等2秒才响应,正常的网页应该是点击后在0.1秒内响应,超过0.3秒就会明显感受到卡顿 |
The problem is not that loading is slow, but that the UI freezes during operation. For example, when you click on any button, you have to wait for 2 seconds to respond. A normal web page should respond within 0.1 seconds after clicking it. If it exceeds 0.3 seconds, you will notice it. to katon |
@kele527 你说的没错,操作延迟的问题是存在的,还需要做更多的优化 |
@kele527 You are right, the problem of operation delay exists, and more optimization needs to be done |
你是不是整了什么 SSR ?纯SPA应该不会这么卡 |
Did you fix some SSR? A pure SPA should not be so stuck |
跟SSR没啥关系。 Next 默认的路由体系是 MPA (多页应用),理论上是会比SPA的慢 |
It has nothing to do with SSR. Next The default routing system is MPA (Multi-page Application), which is theoretically slower than SPA. |
我部署在新加坡的服务器上,有缓存的情况下访问应该还行,2S左右,但是切换操作的不是很流畅,有卡顿,另外我将代码拉到本地,启动巨慢,是超级慢,点一个页面都得好2、3分钟...... 配置:i9Mac 64G内存 |
I deployed it on a server in Singapore. With cache, the access should be fine, about 2 seconds. However, the switching operation is not very smooth and there are lags. In addition, I pulled the code locally and the startup was extremely slow. It was super slow. Click Each page takes 2 or 3 minutes... Configuration: i9Mac 64G memory |
要不要用 Vite + React Router 重构一下, 非常丝滑的。挂在 Express 的 middleware 上一样可以搞 MPA 。 https://github.com/ShinChven/druid/blob/main/app/src/views/index.ts |
@ShinChven 不计划 ,next 比 rr 好多了 |
@ShinChven not planning |
This issue is closed, If you have any questions, you can comment and reply. |
💻 系统环境
Windows
📦 部署环境
Official Preview
🌐 浏览器
Chrome
🐛 问题描述
每次打开设置都会向服务器发送请求,导致设置页面显示卡顿,没请求必要时能否先显示?
🚦 期望结果
No response
📷 复现步骤
No response
📝 补充信息
No response
The text was updated successfully, but these errors were encountered: