geekhack
geekhack Community => Other Geeky Stuff => Topic started by: Alline Cliff on Fri, 21 October 2016, 04:21:09
-
What constitutes high website latency? It’s a fact that most of the consumers expect a website to load in two seconds or less, and 40 percent of consumers will abandon a website that takes more than three seconds to load. Any ideas on what is the benchmark that I should aim to keep my website’s page load speeds? How do you reduce website latency issues?
-
too fast to be a dos attack..... mabye slow connection? What browser computer and network card do you have? Wifi or ethernet? what speed is the router rated? or are you on a phone?
-
Most web site loading latency is due to page display in the browser being dependent on elements loaded from other servers.
- Reduce the number of servers that the web client has to contact to load.
- Use image width and height attributes.
- Set expiration times correctly. Static content should never expire.
Next is slow server processing:
- Reduce number of database queries
- Optimize database and/or queries.
Most web site interaction latency is because of slow Javascript.
- Reduce the use of Javascript to when it provides a tangible benefit over not having it.
- Write code that is not crap.
- Don't load Javascript libraries when not needed. If you can do it in Vanilla JS (http://vanilla-js.com/) then do it in Vanilla JS and don't load jquery.
Next, it is because of images being large than necessary and scaled down to manageable sizes by the browser.
-
The simplest way: Go to https://gtmetrix.com/ (https://gtmetrix.com/) and test your website. Now don't look at the speed measurements! They will fluctuate randomly depending on server load, network congestion, etc., and you will not learn anything actionable from them. Instead, look at the YSlow (created by Yahoo!) and Page Speed (created by Google) scores.
You should aim to get an A on both, and the report will even tell you exactly which performance best practices you need to work on. Findecanor mentioned several of the typical ones, but the gtmetrix report will tell you exactly what bottlenecks your site has (on the front end -- the scanner can't see your server side code, so gtmetrix can't give you tips about database queries etc., but you should absolutely still go over your backend code once your frontend is tuned).
If you want to go deeper down the rabbithole of Web Performance Optimization tricks, follow Steve Souders (http://www.stevesouders.com/blog/), Stoyan Stefanov (http://www.phpied.com/) and Ilya Grigorik (https://www.igvita.com/). They are the best in the business and Steve Souders in particular lead both the Yahoo! team that built YSlow and the Google team that creeated Page Speed.
And read up on Accelerated Mobile Pages (https://www.ampproject.org/).
For small personal web sites, getting performance scores in the 90s is absolutely doable with fairly simple tweaks. For larger/business sites, it will take a bit more effort. And for large community/social network sites with users in the hundreds of thousands, you're going to want to hire a dedicated specialist full time, who will spend months analyzing your architecture's bottlenecks, most likely rewriting your frontend stack dramatically, improving caching in every step, optimizing or eliminating critical API endpoints, rebuilding your static asset server(s), and training your developers in performance best practices.
(Full disclosure: I am that kind of specialist)
But for anything like a personal site or a hobby project, or even a small business site, just use the gtmetrix scanner (or the standalone YSlow and Page Speed browser extensions) and follow the advice one best practice at a time.
And have fun with it! :)
-
I like 60-90ms. Wouldn't a simple ping and traceroute give you some decent information? I have no idea what you host or how you host it but as a user, I know that I am a bit uncomfortable with any connection slower than 90ms.
-
Ping time / network latency is not actually a performance bottleneck on 99.9% of web sites, since network latency only accounts for a tiny percentage of the time it takes for a web site to load.
Most of the time when I've optimized web sites, I've aimed to reduce average page load times (time until interactive / time until perceived content ready) by something like 4-8 seconds. To achieve these kinds of optimizations, optimizing network latency by maybe 200ms is not a main concern.
Yahoo!s Exceptional Performance Group did a large scale experiment some years back and found that not only was the network not a significant source of site slowdowns, the entire backend was largely irrelevant, since only around 5-10% (http://yuiblog.com/blog/2006/11/28/performance-research-part-1/) (with a few notable exceptions) of the time is spent between the initial request and the completed download of the HTML.
So while network latency is paramount when it comes to game servers, it is not what you should be looking at when optimizing web pages.
-
What equipment are you using to gauge page load timing? Most of the pages I visit stream media so I guess that is mostly why I said 90ms.
Would you go so far as to reduce the colors on a page? I did that back in 2003 - but that seems like less of a problem these days. Although, switching to vector graphics will definitely improve page loads.
-
Color reduction will do nothing, and vector graphics are only relevant for the 'vectorizable' subset of graphics (icons, charts, cartoony images..) and not the high-res photos that make up 90% of the image weight on a normal web site, so the total benefit is very limited.
Where you'll usually get the most bang for your buck (See the HTTP Archive stats page (http://httparchive.org/interesting.php#renderStart) for specifics):
- Reduce the number of requests (less relevant with HTTP/2 but still worth addressing)
- Reduce the amount of CSS and synchronous JS in the 'critical render path'
- Concatenate all the external CSS and JS into as few files as possible
- Make sure all JS loads asynchronously
- Set far-future cache headers on all resources (JS, CSS, images)
- Reduce the total payload size - gzip and minify JS and CSS, use image sprites, smush/compress images, lazyload heavy images/videos, and never serve a full size image file where a downscaled one would do
- Use custom fonts if you must, but sparingly!
- And don't use a 40KB jQuery plugin when 600 bytes of properly written JS (or CSS) can solve your problem. Specifically, websites need to STOP shoving jQuery UI (30KB of CSS and 250KB of JS!!!) down my throat when all they need is the bleeping Tabs menu
There's lots more you can do of course, but those recommendations will catch 90% of the worst performance offenders with 10% of the effort. Don't spend any time optimizing SQL queries or configuring nginx or benchmarking whether for loops are faster than while loops (or whether a React SPA is faster than a Backbone one, or Angular or Vue.js or vanilla JS), or trying to achieve BigPipe-level concurrency until you've done all of the above. There's just no sense in chasing single-digit milliseconds when there are exponentially greater gains in each of the above.
-
To address csmertx' comments, if I was optimizing a streaming protocol, a realtime data processing library or a multiplayer game engine, I would go about it exactly the way you mention. In those cases, you are trying to shave your payloads down basically a single bit at a time, since you are fighting extremely tight budgets in terms of bandwidth, framerate or memory consumption. There, you need to get everything done by the next tick or you lose the frame.
Loading of websites don't work like that, for a few reasons:
- The average web site is making ~100 separate TCP requests over the network in order to construct a single page (rather than streaming through a socket), and each of these requests comes with its own unpredictable overhead.
- Web pages are fundamentally different from streaming content because of the many different requests in the critical rendering path, which plays a demonic game of dodgeball with the network stack, loading some resources in parallel and others in a totally blocking fashion, eventually constructing and re-constructing the DOM potentially thousands of times while the page resources are arriving. If streaming a Youtube clip is like singing a song without missing a beat, then loading a web page is like freestyling a rap from words scribbled on bricks that are being launched at you at high speed.
- Different browsers use different engines for JS, DOM rendering, etc., and different versions make it even more complicated. Imagine if League of Legends had to support 28 different clients (on hundreds of different devices from Blackberries to Mac Pros), all built by different teams across the world, all interpreting the APIs a little bit differently. You'd be lucky to get 2 FPS
- And finally, in the challenges mentioned before (protocol, realtime, game engine) you have control over all the tech at code level, so you can actually change things like color palettes, compression algorithms, protocol headers, bit packing schemes etc., which can lead to sometimes very significant wins. On the web however, you only have the protocols and image formats supported by all major browsers; navigating inside these boundaries is a big part of optimizing page load times. I'd love to choose my own scripting language and have it run *natively* in the browser, and choose my own protocol for AJAX requests, and better compression algorithms and image formats; but that's just not possible in a world of IEs and Safari Mobiles and Android Browsers and old installs of Firefox ;)
-
Maybe the OP has it figured out. He or she didn't provide a lot of details. I mean, if you're selling designer handbags there's no way you would optimise for 56k connections.
I think I understand some of what you're saying Scarpia. The server would have to decide which website would work best with which device and many other nuances all simultaneously. Hosting my own is completely out of the question - I probably could learn how but I want the burden of security left in more capable hands.
-
Chrome has a nice Audit panel in the Dev Tools that highlights things you can do by examining your page construction:
[attachimg=1]
Much of this is originally from the Yahoo page optimization list from back in the day.
-
What constitutes high website latency? It’s a fact that most of the consumers expect a website to load in two seconds or less, and 40 percent of consumers will abandon a website that takes more than three seconds to load. Any ideas on what is the benchmark that I should aim to keep my website’s page load speeds? How do you reduce website latency issues?
There are several causes of latency or slow speed. Though latency has a greater effect on your lag than speed. I think, you have to sort out the causes first and if it is really a big issue, there are a number of possible solutions to be done and to be able to work your way through these solutions, you may ask help already from a reliable service provider.