针对移动设备进行优化时，我应该瞄准什么样的页面重量/大小？
我希望使用出色的 jQuery mobile 来优化小型 Web 应用程序中的移动浏览器体验。
不用说，用户不想 DL 200k 数据，我只是想在使用外部 URL 和内部 URL 之间划清界限。是否有关于我应该拍摄哪种页面大小/加载时间的现有指南？我更愿意坚持使用内部 URL（从维护的角度来看，将移动界面有效地保持在一个地方），但我厌倦了让用户陷入大量他们无意查看的信息。
I'm looking to optimise the mobile browser experience in a small webapp, using the awesome jQuery mobile to do so.
It goes without saying that a user doesn't want to DL 200k of data, I'm just trying to draw the line between using external and internal URLs. Is there any existing guideline of what sort of page sizes / loading times I should be shooting for? I'd prefer to stick to internal URLs (keep the mobile interface effectively in one place from a maintenance point of view), but am weary of bogging the user down with lots of information that they have no intention of viewing.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
更重要的是服务器和客户端之间不要闲聊。延迟可能会很大，因此最好将比平时更多的东西打包在一起。每次按键后在服务器上进行验证会很痛苦。
Much more important is to not be chatty between server and client. The delay can be large, and makes it sensible to pack more together than you would do normally. Validating on the server after each keypress would be painfull.
需要注意的一件事是，例如 iPhone 不会缓存大于 25K 的组件。
还可以考虑缩小并压缩您的代码。 @jfar 做对了一件事。 HTTP 请求可能会对性能造成巨大影响，因此您可能还希望尽可能减少它们。
One thing to note is that e.g. iPhone won't cache components bigger than 25K.
Also consider minifing and gzipping your code. And @jfar got one thing right. HTTP requests can be a huge performance hit, so you may also want to reduce them as much as possible.
大小并不重要。下载时间确实如此。
在某些区域，移动速度每百英尺都会有所不同，因此 xxxk 的速度并不总是完美的。
追求“尽可能小”。
Size doesn't matter. Download times does.
Mobile speeds differ every hundred feet in some areas so its not like some xxxk amount is going to always be perfect.
Go for "as small as possible".
根据 W3C 移动网络最佳实践：
According to the W3C Mobile Web Best Practices:
我会说尝试将您的页面降低到 100kb，因为如果您设法这样做，则根据用户请求加载不同的页面可能可以忽略不计。
然而，一次加载大量内容并使用简单的 JavaScript 显示和隐藏，以几乎实时的方式显示内容可能也会给观众留下深刻的印象。
I would say try to lower your page as much to 100kb, because if u manage to do so loading different pages as per user request might be negligible.
However, loading the big pile of content at a time and using simple javascript show and hide, to display the content in almost realtime manner might impress the viewer too.
我建议您查看 HTML5 缓存清单规范，它允许您定义浏览器应保持离线状态的一组资源。它就像老式的浏览器缓存，但更好，因为它是可控的。
对于移动网站来说，大小确实很重要，但更重要的是浏览器必须执行的请求数量。尽可能多地将图像内联到 css 文件中，因为每个请求都需要时间（根据我的经验，最多需要 4000 毫秒 ping！） 将所有 javascript 合并到一个文件中，并发送所有经过 gzip 压缩的内容。
如果您想了解移动开发中的重要因素，请拿出计算器并计算加载时间。每个请求弥补 500ms，并考虑加载时间约 8-20 KiB/s。这不是最坏的情况，但也不是最好的情况。
I would recommend you to look into the HTML5 Cache Manifest specification, it allows you to define a set of resources the browser should keep offline. It's like the old fashioned Browser cache but better because it's controllable.
For mobile websites size does matter, but what matters much more are the number of requests the browser has to do. Inline as much of your images in the css files as you can, because every request takes time (in my experience up to 4000ms ping!) consolidate all javascript into one file and send all things gzip compressed.
If you want to get a feeling for what matters in mobile development take out your calculator and calculate the loading times. Make up 500ms for each request and take about 8-20 KiB/s for loading time into consideration. That's not the worst case but it's not the best case too.