Zvláštní: Lidé neumějí nakonfigurovat webserver

Napsal vdusek;627563

Bez znalosti souvislostí nelze vydávat jednoznačné závěry a doporučení.

S něčím s tebou lze souhlasit, ale vůbec se mi nelíbí se způsob, jakým to prezentuješ

Zákazníka nezajímají souvislosti. Návštěvníka webu nezajímají souvislosti. Google nezajímají souvislosti.Pomalý web má horší návštěvnost, horší konverze a Google jej penalizuje.A od vývojářů i administrátorů slyšíme samé výmluvy

Napsal petrx;627576

Zákazníka nezajímají souvislosti. Návštěvníka webu nezajímají souvislosti. Google nezajímají souvislosti.

Pomalý web má horší návštěvnost, horší konverze a Google jej penalizuje.

A od vývojářů i administrátorů slyšíme samé výmluvy

podle vyse zminenych ukazatelu by byl nas firemni web tele3 bezici na serveru s centralizovanym uzivatelskym systemem docela v pr..., protoze mame ve score spoustu "F"docela se usmivam pokud i nase adminy povazujes za lamy nebo neschopnepricemz Google vse co lze analyzovat hodnoti kladne - coz asi verejne nedokazu, ani nechciale vysledek z alexy si muze prohlidnout kdokoliv:http://www.alexa.com/siteinfo/tele3.cz#Average Load Time for Tele3.czVery Fast (0.376 Seconds), 96% of sites are slower.Note: Slow sites may be penalized by search engines. ---takze tady delas machra, protoze jsi precetl par tipu na zlepsenipripomina mi to potazmo vysledky na seo-servis.cz kde "domaci seo-odbornici" prohlasuji, jak dulezite je mit 100% score

Soudruh +1Lépe bych to nenapsal1/ Návštěvníka zajímají informace, je ochoten si i počkat2/ webmastera zajímá spolehlivost, zálohování, komfort služby3/ Správce serveru zajímá výkon, fungování služby4/ Google penalizuje pomalost, ale rozhoduje bod 1/

Napsal petrx;627576

A od vývojářů i administrátorů slyšíme samé výmluvy

delat rychle weby lze i bez komprimace, cache a dalsich optimalizaci, kolikrat je horsi pouzit treba preplacany OS s komprimaci a cache nez vlastni rychly system bez komprimace a cache, nikdy jsem se temito optimalizacemi nijak vyrazne nezabyval a asi ani zabyvat nebudu, delam rychle systemy co jsou rychle bez tehle veci, pokud to nekdo spravne nastavi na serveru, je to jen dobre, ale i bez toho to frci a o to prece jde

Napsal vdusek;627626

1/ Návštěvníka zajímají informace, je ochoten si i počkat

O serverech toho moc nevím, ale tady nesouhlasím. Návštěvník nechce čekat, i když ho zajímají informace. On totiž NEMŮŽE předem vědět, že u tebe najde relevantní informace.

Napsal soudruh;627608

podle vyse zminenych ukazatelu by byl nas firemni web tele3 bezici na serveru s centralizovanym uzivatelskym systemem docela v pr..., protoze mame ve score spoustu "F"

docela se usmivam pokud i nase adminy povazujes za lamy nebo neschopne

pricemz Google vse co lze analyzovat hodnoti kladne - coz asi verejne nedokazu, ani nechci

ale vysledek z alexy si muze prohlidnout kdokoliv:

http://www.alexa.com/siteinfo/tele3.cz#

Average Load Time for Tele3.cz

Very Fast (0.376 Seconds), 96% of sites are slower.

Note: Slow sites may be penalized by search engines.

---

takze tady delas machra, protoze jsi precetl par tipu na zlepseni

pripomina mi to potazmo vysledky na seo-servis.cz kde "domaci seo-odbornici" prohlasuji, jak dulezite je mit 100% score

1) Alexa měří stažení čistého kódu HTML, podobnou hodnotu měří i WebPageTest.org: http://www.webpagetest.org/result/110220_BT_14AB/1/details/ (HTML by se stahovalo ještě rychleji, kdyby někdo z hlouposti nevypnul HTTP kompresi) 2) Pro zobrazení stránky se však musejí načíst i CSS, JavaScripty a obrázky. CSS a JavaScripty se opět načítají zbytečně pomalu a bez komprese (kterou správce z hlouposti vypnul). 3) CSS , JavaScript i obrázky se tahají z jediného hostname a nikoli paralelně => další zpomalení. Takže homepage se načítá např. 5 sekund: http://www.webpagetest.org/result/110220_BT_14AB/1/details/ a stránka s více obrázky i déle: http://www.webpagetest.org/result/110220_Z7_14A9/1/details/ 4) Kvůli špatně nastavenému cachování statického obsahu dochází ke zbytečným HTTP requestům i při opakovaném načtení stránek: http://www.webpagetest.org/result/110220_BT_14AB/1/details/cached/ http://www.webpagetest.org/result/110220_Z7_14A9/1/details/cached/ 5) Google má rád stránky, které se načítají do 1,5 sekundy, což by bylo na webu www.tele3.cz dosažitelné, ale nikoli v této konfiguraci. 6) Jsou tedy správci www.tele3.cz lamy, jak žertuješ? Asi ano, pokud neumějí administrovat webserver. Ale určitě je lama ten, kdo si neumí přečíst měřící protokol a vyhodnotit data. 7) Zkus se schválně podívat v Google Webmaster Tools do sekce Diagnostika -> Statistika procházení (tam uvidíš optimistický údaj jako v Alexe). A pak se podívej v Google Webmaster Tools do sekce Laboratoř Google -> Výkon webu. Tam uvidíš data, který od skutečných uživatelů reportuje Google Toolbar ---------- Příspěvek doplněn 20.02.2011 v 21:17 ----------

Napsal baryman;627632

O serverech toho moc nevím, ale tady nesouhlasím. Návštěvník nechce čekat, i když ho zajímají informace. On totiž NEMŮŽE předem vědět, že u tebe najde relevantní informace.

Říkají to i skutečná data ze skutečného světa: http://www.webperformancetoday.com/2011/02/15/slow-website-performance-customer-satisfaction/ http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/ ---------- Příspěvek doplněn 20.02.2011 v 21:20 ----------

Napsal Aleš Jiříček;627630

delat rychle weby lze i bez komprimace, cache a dalsich optimalizaci, kolikrat je horsi pouzit treba preplacany OS s komprimaci a cache nez vlastni rychly system bez komprimace a cache, nikdy jsem se temito optimalizacemi nijak vyrazne nezabyval a asi ani zabyvat nebudu, delam rychle systemy co jsou rychle bez tehle veci, pokud to nekdo spravne nastavi na serveru, je to jen dobre, ale i bez toho to frci a o to prece jde

Důležitá jsou data, nikoli něčí přání:

http://www.webperformancetoday.com/2010/06/15/everything-you-wanted-to-know-about-web-performance/

ser behavior and expectations about web performance

In 2006, the average online shopper expected a web page to load in 4 seconds. Today, that same shopper expects your page to load in 2 seconds or less.

Web site performance is second only to security in user expectations.

56% of online bankers and brokers expect web pages to load in 2 seconds or less.

Poor website performance leads to dissatisfaction more often than any other factor. Sixty-four percent of online US bankers and brokers have had a dissatisfying experience when servicing their accounts. Web performance is far and away the biggest reason for this dissatisfaction.

As online tasks get more urgent or complex, online users are less likely to try later and more likely to move to more expensive channels to complete the transactions. Fifty-six percent of online bankers would move to offline channels to ask a general account question; 54% of online brokers would move to offline channels to trade investments if the website was unavailable or slow to respond.

48% of online bankers and brokers said that poor performance had an impact or significant impact on their likeliness to recommend a firm’s services to a friend or family member.

Users who experience a 2-second site slowdown make almost 2% fewer queries, click 3.75% less often, and report being significantly less satisfied with their overall experience.

57% of online consumers will abandon a site after waiting 3 seconds for a page to load.

8 out of 10 people will not return to a site after a disappointing experience.

Of these, 3 will go on to tell others about their experience.

A user who has to endure an 8-second download delay spends only 1% of her total viewing time looking at the featured promotional space on a landing page. In contrast, a user who receives instantaneous page rendering spends 20% of viewing time within the promotional area.

Nearly one-third (32 percent) of consumers will start abandoning slow sites between one and five seconds.

39% say speed is more important than functionality for most websites, while only one in five rank greater site functionality as more important.

Between 37 to 49% of users who experience performance issues when completing a transaction will either abandon the site or switch to a competitor. Of these, 77% will share their experiences with others.

Users have faulty perceptions of time. For example, the average person will perceive the amount of time it takes a page to load as being about 15% slower than the actual load time. And later, in recalling their memory of how long it took for the page to load, they will remember it took about 35% longer than it actually did.

Site speed and its impact on ecommerce metrics: Revenue, conversions, page views and downloads

Issues with application performance are affecting overall business revenues by up to 9%.

A 1-second delay in page load time equals 11% fewer page views, a 16% decrease in customer satisfaction, and 7% loss in conversions. (In dollar terms, this means that if your site typically earns $100,000 a day, this year you could lose $2.5 million in sales.)

A site that loads in 3 seconds experiences 22% fewer page views and a 50% higher bounce rate than a site that loads in 1 second. Impact on conversions: -22%.

A site that loads in 5 seconds experiences 35% fewer page views and a 105% higher bounce rate. Impact on conversions: -38%.

A site that loads in 10 seconds experiences 46% fewer page views and a 135% higher bounce rate. Impact on conversions: -42%.

Shopzilla sped up its average page load time from 6 seconds to 1.2 seconds and experienced a 12% increase in revenue and a 25% increase in page views. It also doubled the number of sessions from search engine marketing and cut the number of required servers in half.

Amazon found that it increased revenue by 1% for every 100 milliseconds of improvement.

Mozilla shaved 2.2 seconds off their landing pages, thereby increasing download conversions by 15.4%, which they estimate will result in 60 million more Firefox downloads per year.

Performance optimization improved conversion rate by 16.07% and cart size by 5.51%.

Yahoo increased traffic by 9% for every 400 milliseconds of improvement.

Visitors in the top ten percentile of site speed viewed 50% more pages than visitors in the bottom ten percentile.

Speed and the mobile web

“Sixteen percent of consumers have shopped via mobile phones or smartphones, but 27% of them report that it is dissatisfying due to the mobile shopping experience being too slow. One-third of consumers report wanting to shop via their smartphones in the future, with 5% indicating that this will be an important aspect of their loyalty to online retailers.

More than half of mobile device users say that they expect sites to download as quickly on their mobile devices as they do on their home computers.

60% of mobile web users have had a problem when accessing a website in the past year.

Slow load time was the number one issue faced by almost three quarters of them.

Three out of 5 say that poor performance will make them less likely to return to the site.

40% said they’d likely visit a competitor’s site next.

The majority of study participants said they expect to be able complete simple transactions like checking their bank balance in a minute or less, or they will abandon the site.

From Nov. 1-15, the average response time for 14 industry-leading mobile retail sites was 4.73 seconds. Amazon led with a response time of 2.85 seconds.

---------- Příspěvek doplněn 20.02.2011 v 21:22 ----------Ale na druhou stranu chápu, že pro líného nebo hloupého člověka může být pohodlnější žít v iluzi a sebeuspokojení

Napsal petrx;627633

Ale na druhou stranu chápu, že pro líného nebo hloupého člověka může být pohodlnější žít v iluzi a sebeuspokojení

Ano, žiješ v iluzi, že tyhle mikrooptimalizace spasí svět, vydělají miliony a dostanou tě v googlu na první místo. Přitom realita je u většiny webů taková, že to nemá smysl výrazně řešit.

5 sec. s nactenim indexoveho slide-show je myslim dost dobra hodnota, napr. na urovni IBM (dle tveho vyhodnocovace: http://www.webpagetest.org/result/110220_VJ_14E0/1/details/) (napis na IBM, ze jsou Lamy :))jde o to, ze first-view pro navstevnika je mnohem kratsi - to, ze se dotahuji nejake casti - zejmena onhoover obrazky, favicona nebo jquery neni zadne cekani uzivatele ani robotadale - je nekolik douvodu proc nevolit kompresi a cachovani - pro nektere online systemy muze byt cache nezaduci, pokud to server utahne je lepsi necachovat - ano, selektevni cache napr. loga, "paty", css apod. by moha byt vyhodou, uznavam - nicmene ad komprese obrazkuta by mela byt spise na strane uzivatele - pokud si nekdo neumi zoptimalizovat napr. obrazky, necht mu web leze jak z chlupate dekychapu, ze singl users na serveru si mohou hrat s cimkoliv, ale az budes mit par set hostingu per jeden server, budes se divit o kolik ti ruzne komprese vytizi CPU - a vinikem budou end-useri co si treba ve fronpage daji obrazky v BMP na web - nedej boze takovy web nekdo "proflakne v diskuzi" a zabije ti server s dalsi komercni klienteloupokud by clovek potreboval server opravdu "vytunit", nebude tak cinit na apache-base, ale vrhne se na webservery typu lighttpd, nginx apod.vazne se zde nechci hadat, mas spoustu relevantnich informaci - tj. hodne nastudovano - otazkou pro vsechny asi je, v jake praxi jsi to nasadil

Napsal toshi;627642

Ano, žiješ v iluzi, že tyhle mikrooptimalizace spasí svět, vydělají miliony a dostanou tě v googlu na první místo. Přitom realita je u většiny webů taková, že to nemá smysl výrazně řešit.

Přečti si ty statistiky---------- Příspěvek doplněn 20.02.2011 v 22:37 ----------

Napsal soudruh;627646

5 sec. s nactenim indexoveho slide-show je myslim dost dobra hodnota, napr. na urovni IBM (dle tveho vyhodnocovace: http://www.webpagetest.org/result/110220_VJ_14E0/1/details/) (napis na IBM, ze jsou Lamy :))

jde o to, ze first-view pro navstevnika je mnohem kratsi - to, ze se dotahuji nejake casti - zejmena onhoover obrazky, favicona nebo jquery neni zadne cekani uzivatele ani robota

dale - je nekolik douvodu proc nevolit kompresi a cachovani - pro nektere online systemy muze byt cache nezaduci, pokud to server utahne je lepsi necachovat - ano, selektevni cache napr. loga, "paty", css apod. by moha byt vyhodou, uznavam

- nicmene ad komprese obrazku

ta by mela byt spise na strane uzivatele - pokud si nekdo neumi zoptimalizovat napr. obrazky, necht mu web leze jak z chlupate deky

chapu, ze singl users na serveru si mohou hrat s cimkoliv, ale az budes mit par set hostingu per jeden server, budes se divit o kolik ti ruzne komprese vytizi CPU - a vinikem budou end-useri co si treba ve fronpage daji obrazky v BMP na web - nedej boze takovy web nekdo "proflakne v diskuzi" a zabije ti server s dalsi komercni klientelou

pokud by clovek potreboval server opravdu "vytunit", nebude tak cinit na apache-base, ale vrhne se na webservery typu lighttpd, nginx apod.

vazne se zde nechci hadat, mas spoustu relevantnich informaci - tj. hodne nastudovano - otazkou pro vsechny asi je, v jake praxi jsi to nasadil

1) No, asi jsou opravdu lamy, když na tak významném a navštěvovaném webu mají všechen obsah na jediném hostname (tedy jediný obrázek tahají bokem...), co s tím naděláme...2) A kdo má problém s onhover obrázky? I na tom diagramu vidíš okamžik, kdy je stránka načtena (vertikální modrá čára), pokud se nějaký obsah načítá později, je to pro uživatele i vyhledávače OK3) Spíše než náhrada Apache serverem lighttpd / nginx má smysl před Apache předsadit reverzní proxy cache, v ideálním případě včetně Edge Side Includes. Téměř ideální je reverzní proxy Varnish (místo skladování cachovaných HTTP objektů ve filesystému je skladuje v RAM, resp. ve virtuální paměti), nicméně Varnish neumí HTTP kompresi, proto se před ní nasazuje nginx v režimu reverzní proxy (bez cachování).V praxi to pak funguje takto:Apache / lightppd <-> Varnish <-> nginx <-> browserNapř. na www.posterous.comDalší možností je použít reverzní proxy cache v cloudu. Tj. Amazon CloudFront nebo CloudFlare.com (ta je k dispozici levně či zdarma, kromě cachování je výhodou anycast routing a "cenzura" patologických HTTP requestů od útočníků => určitá ochrana před hacknutím)4) V praxi (e-shop s množstvím obrázků na stránkách, kde bylo nutno počet fotografií výrobků ještě zvýšit...) se mi osvědčila takováto konfigurace:www.example.com -- stránky e-shopu, nastavena HTTP komprese a keep-alive pro případ zapomenutého obsahu na tomto hostnameexample2.com -- servisní doména, obsah distribuován zatím přes CloudFlare.com, výhledově přes Varnish + nginx*.example2.com -- alias pro www.example.comSoubory typu www.example.com/obrazek.jpg prestěhovány na URL typu jpg.example2.com/obrazek.jpg, soubory typu www.example.com/skript.js přestěhovány na js.example2.com. To samé s CSS, GIF, PNG apod. Web se okamžitě zrychlil.Aktivace Cloudflare.com pro *.example2.com => Odlehčilo se serveru www.example.comZvýšený počet produktů => pomocí hashování jejich ID byly jejich fotografiím přiděleny aliasy 0..9, a..f (prostě 1. číslice hexadecimální hashe) +.example2.com => další zrychlení pro URL typu 5.example2.com/produkt123.jpgTeď budeme s hostnames asi ještě čarovat (díky keep-alive je možno "recyklovat" spojení na hostnames typu css.example2.com, rovnou se využije již roztažené TCP okno, chce to takový trik)V další fázi uvažuji, že bychom CSS, JS a grafiku kromě fotografií produktů tahali jako nyní, do seznamu produktů s fotografiemi bychom nasypali nejprve průhledné GIFy a po načtení stránky nasypali fotografie pomocí JavaScriptu (=> opět rychlejší pro uživatele)Výhledově jsem si od adminů zažádal o Varnish + nginxA v ideálním případě bych po nich chtěl záplatu do jádra, aby TCP okno začínalo rovnou na velikosti 10 paketů jako u Google.Teoreticky tady vyzrazuji jakési know-how, ale mě už ty prasácky pomalé weby štvou, už se na to nemohu dívat. Dnes může mít člověk rychlou CDN i zadarmo (CloudFlare), takže už neexistuje výmluva, proč by weby měly být pomalé---------- Příspěvek doplněn 20.02.2011 v 23:00 ----------

Napsal toshi;627642

Ano, žiješ v iluzi, že tyhle mikrooptimalizace spasí svět, vydělají miliony a dostanou tě v googlu na první místo. Přitom realita je u většiny webů taková, že to nemá smysl výrazně řešit.

To ne, svět by spíš spasilo zkrocení vohnoutů a ichtylů

Stačilo říct, že se prostě nudíš.

Hlavně by mě potěšilo, kdybych se nemusel trápit s nekvalitními servery a nekvalitními administrátory. Zatím se s nimi opravdu nenudím

koukám, že ani můj administrátor neudělal vše, jak by mohl.. proberu to s ním - pro mě osobně je toto téma poučné.

Ja jen furt premyslim proc ma tolik "F" i hostgator.com, rackspace.com, wikipedia.org, aws.amazon.com, verisign.com dale pak godaddy Decko, facebook.com Cecka a Decka, twitter.com - Becko ...takze bud jsou vsude neschopny admini ... a nebo je to jako kdybys urcoval kvalitu auta pouze na zaklade toho jestli ma maximalni rychlost 210km/h nebo 240km/h---------- Post added 21.2.2011 at 0:23 ----------

Napsal petrx;627660

Apache / lightppd <-> Varnish <-> nginx <-> browser

Např. na www.posterous.com

posterous.com ma jeste horsi hodnoceni nez ja :D http://www.webpagetest.org/result/110220_F6_1504/ ... takze dle tohodle nastroje jim je cely to reseni o kterym pises k hovnu :D

Je třeba napodobovat to, co kdo dělá dobře a ne to, co kdo dělá špatně.Jedna věc je nastavení keep-alive, komprese, cachování atd.Jiná věc je infrastruktura.Takže nastavení keep-alive, komprese, cachování je možno v první fázi nastudovat na CloudFlare.comServírování obsahu z více hostnames je možno nastudovat na nějakém slušně zvládnutém zpravodajském webuInfrastrukturu je možno nastudovat na www.posterous.com atd.Jinde mají zase hezky zvládnuté CSS....Je nutno přistupovat k věcem pragmaticky, bez předsudků.Představujme si webserver jako černou skříňku, která má dobře servírovat obsah uživatelům

Prosím prozraď nám tvůj "e-shop s množstvím obrázků na stránkách...". Já chci nastudovat jak se to dělá nejlíp.