江苏龙网

  1. 首页 > 生活 > >

论坛网站和社区网站怎样做网站加速( 五 )



■网友
想让自己的网站提高速度，可以使用百度云加速，详情可以咨询QQ840364317 或者淘宝店铺百度云加速CDN百度CDN网站CDN网站加速一年【官网合作伙伴】-淘宝网
■网友
如果是IIS服务器的话，可以考虑一启快网站加速器，软件的。没备案的也能用。
■网友
以下是前facebook工程师Justin Mitchell,现pave合伙人说的，不代表个人观点。Everyone here is giving a bunch of good suggestions, but they\u0026#39;re missing the most important step.Instrumentation.Before you start to fix things, figure out what\u0026#39;s broken. If your application server is taking 5 seconds to generate a page, fronting your static resources with a CDN won\u0026#39;t help much. If you\u0026#39;re downloading 10 MB of images on every page view, adding memcache to your back-end architecture won\u0026#39;t fix the problem.Did you know you can open up Chrome and see network traffic and volume when loading a page? Here\u0026#39;s some data about a reload of Google论坛网站和社区网站怎样做网站加速

One tool I highly recommend for many things, but also for performance monitoring is New Relic. It tracks both server and client performance, and breaks it down by what\u0026#39;s the biggest bottleneck. For example, this is pave.com\u0026#39;s graph for browser load time:论坛网站和社区网站怎样做网站加速

In this case, you can see the vast majority of our time is spent in DOM processing and page rendering. When trying to improve performance, this is the first place to look - see what the problem is before wasting time on potentially complicated solutions to problems you don\u0026#39;t have.Before getting into page-specific performance issues, see where the biggest impact is to be had. You can look at what the user is spending the most time on (this is basically for each page). For Pave, having the largest impact would involve optimizing the home page. It doesn\u0026#39;t matter how fast a page loads if no one uses it.For someone starting a new website.You probably don\u0026#39;t need to worry about every possible optimization mentioned here. There are a few which will make life easier from the start, or which are easy enough that it\u0026#39;d be foolish to avoid. Specifically:Instrument your site. This is most important. Long term, it\u0026#39;s the only way to know how you\u0026#39;re doing.Understand the split between server time, network time, and browser time. Critically, you need to understand that optimizing one will have almost no impact on the other. If your server is slow, it doesn\u0026#39;t matter how fast you make the browser, and vice versa. There\u0026#39;s less you can do about network time (until you\u0026#39;re mega-scale) other than using a CDN.Put CSS at the top of the page, and scripts at the bottom. This requires literally zero extra effort on your part. It helps because the browser will start to render the page (the user will perceive it being loaded) even before all scripts are run.Avoid inlining CSS / JS. Browsers will cache these external resources, reducing your load time on subsequent page views. Note that this won\u0026#39;t help (and might hurt) if your site\u0026#39;s bounce rate is 100%. But then you probably have bigger issues.Most of the "don\u0026#39;t" items in Best Practices for Speeding Up Your Web Site. If you never start, you won\u0026#39;t need to remove later. This goes for CSS expressions, minimizing iframes, using \u0026lt;link\u0026gt; over @import, avoiding scaling images in HTML, redirects, etc...Optimize images/use CSS sprites. Use the best image format for the job (PNGs for icons, JPGs for photos), and choose a quality setting for JPGs that strikes the right balance between quality and size. Using CSS sprites means instead of making multiple requests to download icons, you could download one image and use background-position: in CSS to display the correct section.Some easy-ish stuff you should probably do early on:CDNs. Cloudfront is pretty trivial to set up, and works well for Pave. I only left it off the initial list because it probably isn\u0026#39;t something you literally need when prototyping or showing initial friends. It\u0026#39;s also pretty easy to add on later.Packaging/minifying JS/CSS. At Pave, we use LESS and RequireJS for this. It means we\u0026#39;re both sending fewer bytes over the wire, and that most pageviews do only 2-4 static resource requests even though, as a developer, I think of it as many smaller files.GZIP components. Assuming you have control over your webserver, this is probably just a configuration flag. If you don\u0026#39;t have control over your webserver, it\u0026#39;s likely this is already set for you.Optimize server-side data fetching. This is pretty abstract because the strategies are completely different depending on your data store. But something I\u0026#39;ve seen over and over again is people with really really inefficient data access patterns. New Relic can help you track how much time you\u0026#39;re spending fetching data. Broadly speaking, the three strategies you could employ are: fronting with a cache, batching data access, and reducing over-fetching.Monitor external service perf. One API we formerly used at Pave was taking ~1000ms per query, resulting in a really bad user experience. Also, try whenever possible to call external APIs either asynchronously or at least after the response is flushed to the browser. For example, we do this for all metric reporting so it really doesn\u0026#39;t matter whether Mixpanel\u0026#39;s API is slow or how much data we send.Anyway, eventually you should take on everything Steve Souders recommends, and keep working to ensure you minimize server time as well. Fancy things like flushing early, progressive loading, and the like may not be the best use of time when prototyping; but can provide immense performance boosts long term.


推荐阅读


上一篇：葛优代言拉手网成被告了，名人代言在互联网公司发展中能够起到多大的作用

下一篇：##今年小麦长势属正常偏好