KingPin

Iš asmeninių faebook užrašų:
 
Kaip pastebėjote, vakar nagrinėjau geriausius e-commerce sprendimus šiai dienai.
Po dienos skaitinėjimų ir bandymų, paaiškėjo labai super dalykas... darysim su tuo, su kuo ir darėm anksčiau (presta) :D ir jei produktas populiarus, dar nereiškia, jog jis geras. šiandien reikės parašyti straipsnelį apie e-shop'ų open source varikliukų pasirinkimus ir kiekvieno pliusus ir minusus :) Dabar patiekiu tik abstrakčią apžvalgą šia tema.
benaršydamas aptikau įdomesnį projektą, kuris, manau, turėtų puikiai tikti mažoms parduotuvėlėms, kurios nori būti visur ir visada - http://www.ecwid.com/ projektas sudomino, nes shopas gali būti lengvai paverčiamas mobilaus telefono aps'u, begalinės integravimo galimybės, "perpardavinėjimas", kai žmogus susikuria e-shopą, realiai savo prekių neturi (arba gali ir turėti :D) ir parduoda kitų žmonių prekes pas save už tam tikrą procentą. kažkas labai panašaus į apsikeitimą banneriais ar ad-words :) idėja tikrai nebloga, ypač jei pradedi nuo nulio :)
 
 
Wordpress - kaip visada labai lanksti sistema, kuri senai išaugo savo bloginimo platformos rūbus, tik visi e-commerce moduliai - fail. nepatogus prekių atvaizdavimas back end'e, daugumoje kvailokai įgyvendintas ir prekių suvedimas, import/export trūkumai ir kitos negandos... sunku nupasakoti, bet visi e-commerce sprendimai wordpressui nelabai suprantu kam išvis skirti ir kuo jie skiriasi nuo paprastų post'ų :) vienas geresnių sprendimų - wp e-commerce pluginas, kuris yra vienas populiariausių, BET pluginas nemokamas tik su mažu paketu funkcijų, jo kodas parašytas specialiai labai painiai, jog būtų perkami "updeitai", o dėl tų mažų updeitų mokėti 100 baksų - atsiprašau, bet tai vagystė :) laužto plugino jūs nepanaudosite, nes reikalingas api, kuris galioja tik vienam saitui.
 
 
magento - lėtas griozdas, reikalaujantis specifinio php.ini konfigo. Turi vieną didžiausių ir labiausia sustabarėjusią community tarp OS e-commerce sprendimų. Mėgsta klaidas, kurios neišvedamos vartotojui, tiesiog reloadinamas peidžas ir nepasakoma nieko :). Tuomet eini skaityti apatiškos community postų, kur 80% suteiktos pagalbos yra total crap arba problema išsprendžiama ne iki galo :) neįsivaizduoju kodėl šis produktas toks populiarus, galbūt dėl tam tikrų blog'ų, ypač užsenietiškų, kurie turi labai gerą reputaciją pataikavimo šiai sistemai, galbūt dėl kitų priežasčių, nežinau, bet šios sistemos rinktis nepatariu.
 
 
Joomla + virtuemart. Lėtokas, ganėtinai nemažai resursų reikalaujantis sprendimas. Kvailai sugalvotas theme'ingas. Gamintojai kai kurių bug'ų nesugeba išspręsti jau trejus ar net ketverius metus (bugai - tikrai ne kokios smulkmenos). Admin dalis sugeba persipinti su viešąja(WTF???), kvailai parašyti pluginai, kurie suteikia galvos skausmo su suderinamumu ir kodo validavimu. Nemažai problemų rūpinantis SEO reikalais. Mane labai nervuojantis dalykas - atsidarius prekės teksto editorių, tekstas jame ne visada užsikrauna (nesvarbu ar tai būtų wysiwyg editorius ar tiesiog atvaizduojamas visas kodas) :D
Tiesa, turi ir savų pliusų. Ganėtinai nemažai modulių, nemažas community, ganėtinai patogus ir organizuotas prekių administravimas backende. Nujaučiu, jog sistema po truputį užleis vietas kitoms.
 
 
Prestashop - labai patogus backend'as, nėra labai sudėtingas theme'ingas, puikiai optimizuota, didelis funkcijų ir modulių pasirinkimas, puikiai galima sudraugauti su SEO, nemažas community, bug'ai, jeigu jų ir yra - išspręsti / išsprendžiami oficialiame forume. Griežtai apibrėžta sistema, galimi keli vartotojų tipai, puikus suderinamumas su dauguma atsiskaitymo galimybių, lengvas lojalumo ir nuolaidų administravimas... Tiesą sakant tai, mano manymu, pats geriausias open source e-commerce sprendimas šiuo metu. IR JIS NEMOKAMAS :) Tiesa sakant, teko vartyti savo localhoste ne vieną eshop tvs ar modulį, kurie kainuoja 2-3k žalio ir jie toli atsiliko nuo šio nemokamo produkto. Tad, kur gi bajeris? Juk nebūna visko nemokamai ir idealaus. Kodėl prestashopas nėra toks populiarus? Kur čia šuo pakastas?
Viskas paprasta.
Didelis community, bet didžiausia jos dalis - prancūzai. Prancūzai dideli nacionalistai ir dažniausia kilus klausimams ar iššokus spuogui (bug'ui), teks pasitelkti google translator ir skaityti prancūzišką tekstą... :) merginoms tai turbūt pasirodys labai romantiška, ar ne ? :) Kiek neoptimizuotas (vietos atžvilgiu, nes reikia pastoviai daug scrollinti) backendas, bet geresnio - neteko matyti (dabar kaip tik kilo idėja sukurti theme'ą admin daliai...) :), daug pluginų, BET didžioji dalis - mokami. Netgi didžiuosiuose WAREZ saituose nerasite šablonų/plug-in'ų šiai sistemai(na, tiesą pasakius rasite, bet jų bus keli...), tad teks pakratyti piniginę arba žaisti lego patiems :) mano spėjimu, ši sistema todėl ir nepaplito taip plačiai, būtent dėl warezinių / nemokamų temų / plugin'ų nebuvimo (arba mažo buvimo :)), kurias tokios šalys kaip Lietuva ypač myli. Vertimus galite rasti, bet jie bus daliniai, tad teks pasėdėti ir paversti, kol pasidarysite final versiją.
www.gudriosgalvos.lt
 
 
Tai tiek. Jei turite pastebėjimų - rašykite :)

Šaltinis: http://www.gdgroup.lt/blog/naudingi-wordpress-pluginai/
 
Kol kas pateiksiu greitą, virš 60 naudingų wordpress pluginų sąrašą.
 
Pluginus atrinkau dirbdamas su wordpress sistema, stengiausi atsižvelgti į pluginų “gerumą” pagal jų programinę dalį, lengvą themeing’ą ir puikų savo darbo atlikimą.
 
Na ką, pradedam!
WordPress SEO by Yoast
Nuoroda: http://wordpress.org/extend/plugins/wordpress-seo/
Vienas iš geresnių seo optimizacijai skirtų pluginų. Leidžia redaguoti postų title ir meta description reikšmes, yra pilnai kanonizuotas, turi integruotus breadcrumb‘us, gali sudaryti xml sitemapus, rss patobulinimus ir keletą kitų funkcijų. Tai toks seo pluginas, kuris atlieka daug veiksmų, jei reikia būtent tokio ir dėl tam tikrų priežasčių negalite naudoti specializuotų pluginų – šis bus pats tas.
 
Booking Calendar
Nuoroda: http://wordpress.org/extend/plugins/booking/
Booking calendar Jums labai pravers, jei užsiimate nuoma ar kita sritimi, kuriai reiktų įskiepio „Booking calendar“.
Lankytojai, šio plugin‘o pagalba, galės tikrinti objektų prieinamumą tam tikru metu, vartotojai galės vykdyti rezervaciją. Klientai gali registruotis vyksiantiems renginiams. Taipogi, galima įdiegti papildomą atsiskaitymo modulį ir leisti vartotojams susimokėti iškart.
Įskiepis ganėtinai lankstus ir jį galima pritaikyti kitoms reikmėms.
Demonstraciją rasite čia: http://onlinebookingcalendar.com/demo/
Galimybės:
Rezervacija, pasirenkant norimą datą
Priminimai el. paštu, tiek administratoriui, tiek vartotojams.
Patogi vartotojo sąsaja.
Kalendoriaus widget‘as.
Palaiko kelias kalbas.
Ir t.t.
 
WP Minify
Nuoroda: http://wordpress.org/extend/plugins/wp-minify/
Įskiepis integruoja „Minify“ varikliuką, kuris optimizuoja JS ir CSS failų krovimo laikus puslapyje.
Puikiai tinka tiems, kurie kaunasi dėl optimizacijos.
Turi klaidų taisymo įrankius ir keletą konfigūracijos pasirinkimų.
 
Widget Logic
Nuoroda: http://wordpress.org/extend/plugins/widget-logic/
Įskiepis suteiks galimybę valdyti widget‘us, tiksliau jų logiką. Prie widgeto atsiras papildomas laukas, kuriame galima bus nustatyti, kuriame puslapyje jis gali atsirasti.
 
WPtouch
Nuoroda: http://wordpress.org/extend/plugins/wptouch/
Šis įskiepis padės optimizuoti Jūsų tinklalapį mobiliesiems įrenginiams.
 
WP-Cumulus
Nuoroda: http://wordpress.org/extend/plugins/wp-cumulus/
Teko matyti gražius tag cloud‘us kitose svetainėse, kur žodžiai sukasi 3d aplinkoje? Būtent šis pluginas ir atlieka šį darbą.
 
Social Slider
Nuoroda: http://wordpress.org/extend/plugins/social-slider-2/
Įskiepis atvaizduoja „išsiskleidžiantį“ box‘ą, kuriame pateikiami Jūsų socialinių tinklų profiliai ar nuorodos.
Pluginas tikrai atrodo neprastai ir su kai kuriais dizaino sprendimais, gali būti tikras išsigelbėjimas.
Įskiepio demonstracija: http://social-slider.com/demo/full.html
Palaikomi soc. Tinklai:
 RSS
 Newsletter
 Facebook
 Google+ (Google Plus)
 Twitter
 Blip
 Flaker
 Soup.io
 Buzz
 Sledzik
 Tumblr
 Spinacz
 GoldenLine
 LinkedIn
 Nasza Klasa
 NetworkedBlogs
 MySpace
 Orkut
 Grono
 FriendConnect
 FriendFeed
 Digg
 Wykop
 Kciuk
 Picasa
 Flickr
 Panoramio
 DeviantArt
 YouTube
 Vimeo
 IMDb
 Last.fm
 iSing
 Blip.fm
 Delicious
 Unifyer
 
Broken Link Checker
Nuoroda: http://wordpress.org/extend/plugins/broken-link-checker/
Kaip ir matosi iš pavadinimo – įskiepis skirtas stebėti „broken links“ svetainėje.
Stebi broken linkus į postus, puslapius, comentarus ir custom field‘us.
Aptinka neveikiančias nuorodas į paveikslėlius ir kitą media.
Perspėja Jus dashboard‘e ir emaliu.
Neleidžia paieškos varikliams followint broken linkų.
Įskiepis leidžia redaguoti nuorodas iškart, t.y. nereikia klaidžioti iki tam tikros vietos ir ieškoti broken linko.
 
TinyMCE Advanced
Nuoroda: http://wordpress.org/extend/plugins/tinymce-advanced/
Šis įskiepis, prideda 16 papildomų funkcijų į standartinį tinymce editorių.
Advanced HR, Advanced image, Advanced link, kontekstiniai meniu, šypsenėlės, laikas ir data, IESpell, sluoksniai, spausdinimas, search and replace funkcija, stailinimas, lentelės, matematikos formulių palaikymas ir t.t.
O prie viso šio gėrio – spellcheckas.
 
BackWPup
Nuoroda: http://wordpress.org/extend/plugins/backwpup/
Galimybės:
Duomenų bazės backupai
Wordpresso xml exportas
Duomanų bazės optimizacija
Duombazės patikra / taisymas
Failų backupas
Backupų archyvavimas
Backupų talpinimas įvairiuose šaltiniuose.
Multisite support‘as
 
WordPress Popular Posts
 
http://wordpress.org/extend/plugins/wordpress-popular-posts/
 
Plačiai konfigūruojamas plugin‘as, skirtas populiariausių post‘ų atvaizdavimui. Galima naudoti ir kaip šablono tag‘ą.
Galima nepriskirti kategorijų, palaiko shortcode‘us, template tag‘us, automatiškas atsinaujinimas.
 
wp-Typography
Nuoroda: http://wordpress.org/extend/plugins/wp-typography/
Super dalykas tiems, kas nori turėti dailią ir TAISYKLINGĄ tipografiją savo tinklalapyje.
 
CMS Tree Page View
Nuoroda: http://wordpress.org/extend/plugins/cms-tree-page-view/
Plugin‘as skirtas tiems, kurie pripratę prie klasikinių turinio valdymo sistemų atvaizdavimo.
Atvaizduoja jūsų tinklalapį hierarchiniu būdu, bei turi keletą papildomų funkcijų.
 
WP-Optimize
Nuoroda: http://wordpress.org/extend/plugins/wp-optimize/
Tai Duomenų bazės optimizacijos ir valymo įrankis.
Leidžia panaikinti postų revizijas, nepatvirtintus arba „šlamšto“ komentarus ir t.t.
Taipogi, leidžia pervardinti wordpress vartotojus.
Palaiko daugiakalbiškumą.
 
Sidebar Login
Nuoroda: http://wordpress.org/extend/plugins/sidebar-login/
Suteikia galimybę išvesti wordpress loginą per shorttag‘ą arba widget‘ą.
 
Contact Form 7
Nuoroda: http://wordpress.org/extend/plugins/contact-form-7/
Leidžia sudarinėti norimas formas.
Palaiko captcha, akismet, ajax ir t.t.
 
Fluency Admin
Nuoroda: http://wordpress.org/extend/plugins/fluency-admin/
Patobulinimas administratoriaus vartotojo sąsajai. Tab‘ai atskiriami skirtinga spalva, įvairios spalvų schemos, galima pridėti savo logotipą ir hotkey palaikymas norint prieiti atitinkamas sekcijas.
 
WP-PostRatings
Norite įdiegti post‘ų vertinimą į savo wordpress svetainę? Prašau 
Yra ajax palaikymas.
 
WordPress Content Slide
Nuoroda: http://wordpress.org/extend/plugins/content-slide/
Šaunus įskiepis, kuris leidžia Jums sudaryti content slaiderius su efektais. Turi begalę opcijų.
Pavyzdys: http://wptuts.info/wp-content-slide/
 
GD Star Rating
Nuoroda: http://www.gdstarrating.com/
Dar vienas, ypač galingas, postų, komentarų ir puslapių reitingavimo pluginas. Multilanguage palaikymas, suderinamumas su kešo pluginais, turi begalę tinkinimo galimybių.
 
WP No Category Base
Nuoroda: http://wordpress.org/extend/plugins/wp-no-category-base/
Greitai ir paprastai nuima /category/ nuo Jūsų postų.
 
WP-Paginate
Nuoroda: http://wordpress.org/extend/plugins/wp-paginate/
Atlieka paprastą funkciją – puslapiuoja ir tai atlieka gerai 
 
SexyBookmarks | email, bookmark, and share buttons
Nuoroda: http://wordpress.org/extend/plugins/add-to-any/
Populiarus ir dailiai atrodantis pluginas, skirtas Sharingui/Bookmarikinimui. Garantuoju, jog jį jau matėte.
 
PHP Code Widget
Turbūt dažnas iš mūsų pasigedo galimybės rašyti php kodą widgete. Šis pluginas suteiks šią galimybę.
 
Relevanssi – A Better Search
Nuoroda: http://wordpress.org/extend/plugins/relevanssi/
Praplečia standartinę wordpress sistemos paiešką.
Paieškos rezultatai patiekiami pagal didžiausią sutapimą, ne pagal datą.
Ieškoma „žodžio dalies“ sutapimų.
Pažymimi paieškos žodžiai rezultatuose.
Ir kitos funkcijos.
 
Twitter Widget Pro
Nuoroda: http://wordpress.org/extend/plugins/twitter-widget-pro/
Turbūt populiariausias Twitter widgetas wordpressui.
 
WassUp
Nuoroda: http://wordpress.org/extend/plugins/wassup/
Nebloga, google analytics alternatyva ir kas svarbiausia – real time trackingas.
 
Sharebar
Nuoroda: http://wordpress.org/extend/plugins/sharebar/
Pavadinimas daug pasako. Vienas iš geresnių savo srityje.
 
Search Everything
Nuoroda: http://wordpress.org/extend/plugins/search-everything/
Paieškos patobulinimas wordpress sistemai.
Paieškos rezultatų paryškinimas, ieško kiekviename puslapyje, tag‘e, taxonomijose, kategorijose, komentare, draftuose, excerptuose, atachmentuose, custom field‘uose, taipogi suteikiama galimybė neleisti prieiti paieškai prie tam tikrų resursų.
 
Role Scoper
Nuoroda: http://wordpress.org/extend/plugins/role-scoper/
Labai šaunus wordpress pluginas, skirtas vartotojų teisėms sistemoje redaguoti.
 
Wordbooker
Nuoroda: http://wordpress.org/extend/plugins/wordbooker/
Pats geriausias ir lengviausiai konfigūruojamas pluginas, skirtas tam, jog Jūsų blogo įrašai atsirastų ir facebook erdvėje.
 
Disqus Comment System
Nuoroda: http://wordpress.org/extend/plugins/disqus-comment-system/
Viena geriausių alternatyvų standartinei wordpress komentavimo sistemai.
 
Really Simple CAPTCHA
Nuoroda: http://wordpress.org/extend/plugins/really-simple-captcha/
Pavadinimas – daug pasako. Gal ir ne pats saugiausias, tačiau labai paprastai valdomas captcha pluginas.
 
Secure WordPress
Nuoroda: http://wordpress.org/extend/plugins/secure-wordpress/
Didelis saugumo paketas wordpress turinio valdymo sistemai.
Trumpai: nepateikia error informacijos prisijungimo lange, prideda index.php failą pluginų direktorijoje, neatvaizduoja wp versijos ir dalies kitos, naudingos įsilaužėliui informacijos, blokuoja „blogas“ užklausas, kurios gali pakenkti wordpress sistemai.
 
BulletProof Security
Nuoroda: http://wordpress.org/extend/plugins/bulletproof-security/
Dar vienas „must have“ saugumo pataisymas wordpress sistemai. Apsaugo nuo xss, csrf, base64_encode, sql injekcijų ir kitų „laužimo“ būdų. Apsaugo wp-config.php, bb-config.php, php.ini, php5.ini, install.php ir readme.html su .htaccess failus, bei begalės kitų pataisymų.
 
Dynamic Content Gallery
Nuoroda: http://wordpress.org/extend/plugins/dynamic-content-gallery-plugin/
Šaunus pluginas, leidžiantis išburti slaiderį, su paskutiniais ir featured postais.
 
WP to Twitter
Nuoroda: http://wordpress.org/extend/plugins/wp-to-twitter/
Šio plugino Jums prireiks, jei norėsite wordpress įrašus postinti ir twitteryje.
 
Ajax Event Calendar
Nuoroda: http://wordpress.org/extend/plugins/ajax-event-calendar/screenshots/
Ajax technologija besiremiantis kalendorius, su begale funkcijų. Plačiau – gamintojo puslapyje.
 
SEO Friendly Images
Turite daug paveikslėlių, bet ne visiems priskyrėte title ir alt žymes? Nepergyvenkite, šis pluginas Jums padės tai sutvarkyti.
Tiek kodas tampa validus, tiek puslapis tampa daugiau „seo friendly“
 
Link Library
Nuoroda: http://wordpress.org/extend/plugins/link-library/
Tiems, kas „stato“ didelius nuorodų sąrašus, šis pluginas tikrai bus naudingas.
 
After the Deadline
Nuoroda: http://wordpress.org/extend/plugins/after-the-deadline/
Spellcheckeris wordpressui. Įdomu dar ir tai, jog naudoja AI rašybai tikrinti.
 
WP Security Scan
Nuoroda: http://wordpress.org/extend/plugins/wp-security-scan/
Tikrina Jūsų wordpress svetainės saugumą. Pateikia pažeidžiamumus ir galimus pataisymus.
Tikrina: slaptažodžius, failų permissionus, duombazės saugumą, versijos slėpimą, wordpress admin dalį ir t.t.
 
Shortcode Exec PHP
Nuoroda: http://wordpress.org/extend/plugins/shortcode-exec-php/
Leis vykdyti php kodą postuose, puslapiuose ir t.t. naudojant shortcodus. Turi įdiegtą sintaksės spalvinimą. Prisibijant dėl saugumo, tai shortcodus galės naudoti tik administratoriai.
 
Easing Slider
Nuoroda: http://wordpress.org/extend/plugins/easing-slider/
Tikria gražus slaideris, su puikiu css3 apipavidalinimu.
 
AdRotate
Nuoroda: http://wordpress.org/extend/plugins/adrotate/
Patogiausias ir turbūt geriausias pluginas reklamai administruoti Jūsų wordpress svetainėje. Patogus, lankstus, paprastas ir galingas. Ko daugiau reikia?
Turi integruotą šiokią tokią statistiką, palaiko shortcodus, turi reklamos „pasibaigimo terminą“ ir begalę kitų galimybių.
 
Exploit Scanner
Nuoroda: http://wordpress.org/extend/plugins/exploit-scanner/
Ieško blogų gyventojų Jūsų wordpress svetainėje  Pats nieko netrina, tiesiog informuoja administratorių apie galimas grėsmes.
Ieškomi neįprasti pluginai, duombazės įrašai, failų vardai ir t.t.
 
WordPress Video Plugin
Nuoroda: http://wordpress.org/extend/plugins/wordpress-video-plugin/
Leidžia paprastai embeddinti video medžiagą į wordpress svetainę.
Palaiko labai daug šaltinių.
 
Facebook likes you!
Nuoroda: http://wordpress.org/extend/plugins/facebook-likes-you/
lengvai ir greitai diegiamas like/share mygtukas wordpress‘ui.
 
Configure SMTP
Sukonfigūruoja smtp nustatymus wordpressui. Be šios konfigūracijos kai kurie pluginai gali veikti nekorektiškai (dažniausia tai būna email notificationai ir newsletter pluginai)
 
Facebook Comments for WordPress
Nurooda: http://wordpress.org/extend/plugins/facebook-comments-for-wordpress/
Lengvai integruojami ir konfigūruojami facebook tipo komentarai wordpress sistemai. Galimybė sinchronizuoti wordpress ir facebook komentarus.
 
Newsletter
Nuoroda: http://wordpress.org/extend/plugins/newsletter/
Naujienlaiškis. Nemokamai ir paprastai.
 
WP-Cufon
Nuoroda: http://wordpress.org/extend/plugins/wp-cufon/screenshots/
Patyrusiems temų developeriams šio plugino tikrai neprireiks, bet tiems, kurie yra mažiau pažengę – šis pluginas tikrai pravers. Pasirinkite ir lengvai embeddinkite bent kokį šriftą iš cufon kolekcijos.
 
All In One Favicon
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-favicon/
Vėlgi – truputį patyrusiems vartotojams šio plugino tikrai neprireiks, tačiau, jei esate naujokas ir nenorite lysti į sistemos vidurius, bet norite pakeisti favicon arba suteikti galimybę paprastam vartotojui ją pasikeisti be Jūsų pagalbos, šis pluginas Jums pravers.
 
Quick Adsense
Nuoroda: http://wordpress.org/extend/plugins/quick-adsense/
Greitas ir lengvas ad sense reklamos administravimas Jūsų puslapyje. Random atvaizdavimas ir kitos funkcijos tikrai palengvins Jūsų gyvenimą ir papildys piniginę.
 
Blog Protector – Protect Your Content
Nuoroda: http://wordpress.org/extend/plugins/blog-protector/
Nors aš manau, jog internete turinys turi būti atviras, tačiau tiems, kurie savo turinį nori apsaugoti – pateikiame blog protector.
Pluginas atjungia tokias funkcijas kaip teksto žymėjimas ir antras pelės mygtuko apspaudimas.
 
WordPress Portfolio Plugin (WP Portfolio)
Nuoroda: http://wordpress.org/extend/plugins/wp-portfolio/
Lengvas portfolio administravimas.
 
WordPress Importer
Nuoroda: http://wordpress.org/extend/plugins/wordpress-importer/
Importuoja postus, puslapius, komentarus, custom , meta fieldus, kategorijas, tagus, taksonomijas ir autorius iš kito wordpress blogo.
 
WP-Polls
Nuoroda: http://wordpress.org/extend/plugins/wp-polls/
Norite surengti apklausą savo wordpress svetainėje? Šis pluginas Jums padės! Paprastas ir greitas.
 
WordPress Mobile Pack
Nuoroda: http://wordpress.org/extend/plugins/wordpress-mobile-pack/
Leis Jūsų svetainei atrodyti geriau mobiliuosiuose prietaisuose.
Galimybės:
Switchas tarp desktop ir mobile svetainės versijų.
Standartinė tema mob. Įrenginiams.
Didelės pritaikomumo galimybės.
Mobiliems įrenginiams pritaikyta admin panelė.
Barcode widgetas
Mobilie adsense widgetas
Ir t.t.
 
NextGen gallery
Nuoroda: http://wordpress.org/extend/plugins/nextgen-gallery/
Pats geriausias albumų / galerijų pluginas wordpressui. Draugauja su begale pluginų, yra pastoviai atnaujinamas, palaiko multilanguage, turi nemažai papildomų praplėtimų ir t.t.
 
Viper’s Video Quicktags
Nuoroda: http://wordpress.org/extend/plugins/vipers-video-quicktags/
Įkeliant video, tag‘us šis pluginas supildys pats, automatiškai.
Palaiko:
 YouTube (including playlists)
 Google Video
 DailyMotion
 Vimeo
 Veoh
 Viddler
 Metacafe
 Blip.tv
 VideoPress aka WordPress.com Video NEW!
 Flickr videos
 Spike.com/IFILM
 MySpaceTV
 
WordPress Related Posts Yet Another Related Posts Plugin
Nuoroda: http://wordpress.org/extend/plugins/yet-another-related-posts-plugin/
Atvaizduoja susijusius postus.
Universalus ir konfigūruojamas algoritmas, kuris peržvelgia postų antraštes, tagus ir kategorijas, bei pagal YARPP apskaičiuoja sutapimo „rezultatą“.
Pluginas draugauja su kešu, bei turi keletą kitų gerų savybių.
 
Autolink URI
Nuoroda: http://wordpress.org/extend/plugins/sem-autolink-uri/
Paverčia tekstą, kuris turi pradžią http:// į nuorodą automatiškai.
 
WordPress Firewall 2
Nuoroda: http://wordpress.org/extend/plugins/wordpress-firewall-2/
Stebi užklausas ir apsaugo sistemą nuo atakų.
 
Zemanta
Nuoroda: http://wordpress.org/extend/plugins/zemanta/
Rašant wordpresse, zemanta siūlo paveiksliukus, video, nuorodas ir seo optimizuotus tag‘us su Jūsų susijusiu turiniu.
Tikrai labai patogus content sugestion engine‘as, padedantis tiems, kurie daug rašo ir nori rašyti kokybiškai.
Plačiau: gamintojo saite ir http://en.wikipedia.org/wiki/Zemanta
 
All in One SEO Pack
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-seo-pack/
Pats geriausias seo pluginas wordpress sistemai. Palaiko custom post type, kanonines nuorodas, turi palaikyma e-commerce pluginams, meta tagų automatinis generavimas ir begalės kitų funkcijų.
 
Qtranslate
Nuoroda: http://wordpress.org/extend/plugins/qtranslate/
Tiesiog, pats geriausias sprendimas tada, kai reikia svetainės keliomis kalbomis. Draugauja su begale pluginų.
 
FancyBox for WordPress
Nuoroda: http://wordpress.org/extend/plugins/fancybox-for-wordpress/
Lengvesnis nei lightbox, bet toks pat gražus.

Šaltinis: http://www.gdgroup.lt/blog/naudingi-wordpress-pluginai/
 
Kol kas pateiksiu greitą, virš 60 naudingų wordpress pluginų sąrašą.
 
Pluginus atrinkau dirbdamas su wordpress sistema, stengiausi atsižvelgti į pluginų “gerumą” pagal jų programinę dalį, lengvą themeing’ą ir puikų savo darbo atlikimą.
 
Na ką, pradedam!
WordPress SEO by Yoast
Nuoroda: http://wordpress.org/extend/plugins/wordpress-seo/
Vienas iš geresnių seo optimizacijai skirtų pluginų. Leidžia redaguoti postų title ir meta description reikšmes, yra pilnai kanonizuotas, turi integruotus breadcrumb‘us, gali sudaryti xml sitemapus, rss patobulinimus ir keletą kitų funkcijų. Tai toks seo pluginas, kuris atlieka daug veiksmų, jei reikia būtent tokio ir dėl tam tikrų priežasčių negalite naudoti specializuotų pluginų – šis bus pats tas.
 
Booking Calendar
Nuoroda: http://wordpress.org/extend/plugins/booking/
Booking calendar Jums labai pravers, jei užsiimate nuoma ar kita sritimi, kuriai reiktų įskiepio „Booking calendar“.
Lankytojai, šio plugin‘o pagalba, galės tikrinti objektų prieinamumą tam tikru metu, vartotojai galės vykdyti rezervaciją. Klientai gali registruotis vyksiantiems renginiams. Taipogi, galima įdiegti papildomą atsiskaitymo modulį ir leisti vartotojams susimokėti iškart.
Įskiepis ganėtinai lankstus ir jį galima pritaikyti kitoms reikmėms.
Demonstraciją rasite čia: http://onlinebookingcalendar.com/demo/
Galimybės:
Rezervacija, pasirenkant norimą datą
Priminimai el. paštu, tiek administratoriui, tiek vartotojams.
Patogi vartotojo sąsaja.
Kalendoriaus widget‘as.
Palaiko kelias kalbas.
Ir t.t.
 
WP Minify
Nuoroda: http://wordpress.org/extend/plugins/wp-minify/
Įskiepis integruoja „Minify“ varikliuką, kuris optimizuoja JS ir CSS failų krovimo laikus puslapyje.
Puikiai tinka tiems, kurie kaunasi dėl optimizacijos.
Turi klaidų taisymo įrankius ir keletą konfigūracijos pasirinkimų.
 
Widget Logic
Nuoroda: http://wordpress.org/extend/plugins/widget-logic/
Įskiepis suteiks galimybę valdyti widget‘us, tiksliau jų logiką. Prie widgeto atsiras papildomas laukas, kuriame galima bus nustatyti, kuriame puslapyje jis gali atsirasti.
 
WPtouch
Nuoroda: http://wordpress.org/extend/plugins/wptouch/
Šis įskiepis padės optimizuoti Jūsų tinklalapį mobiliesiems įrenginiams.
 
WP-Cumulus
Nuoroda: http://wordpress.org/extend/plugins/wp-cumulus/
Teko matyti gražius tag cloud‘us kitose svetainėse, kur žodžiai sukasi 3d aplinkoje? Būtent šis pluginas ir atlieka šį darbą.
 
Social Slider
Nuoroda: http://wordpress.org/extend/plugins/social-slider-2/
Įskiepis atvaizduoja „išsiskleidžiantį“ box‘ą, kuriame pateikiami Jūsų socialinių tinklų profiliai ar nuorodos.
Pluginas tikrai atrodo neprastai ir su kai kuriais dizaino sprendimais, gali būti tikras išsigelbėjimas.
Įskiepio demonstracija: http://social-slider.com/demo/full.html
Palaikomi soc. Tinklai:
 RSS
 Newsletter
 Facebook
 Google+ (Google Plus)
 Twitter
 Blip
 Flaker
 Soup.io
 Buzz
 Sledzik
 Tumblr
 Spinacz
 GoldenLine
 LinkedIn
 Nasza Klasa
 NetworkedBlogs
 MySpace
 Orkut
 Grono
 FriendConnect
 FriendFeed
 Digg
 Wykop
 Kciuk
 Picasa
 Flickr
 Panoramio
 DeviantArt
 YouTube
 Vimeo
 IMDb
 Last.fm
 iSing
 Blip.fm
 Delicious
 Unifyer
 
Broken Link Checker
Nuoroda: http://wordpress.org/extend/plugins/broken-link-checker/
Kaip ir matosi iš pavadinimo – įskiepis skirtas stebėti „broken links“ svetainėje.
Stebi broken linkus į postus, puslapius, comentarus ir custom field‘us.
Aptinka neveikiančias nuorodas į paveikslėlius ir kitą media.
Perspėja Jus dashboard‘e ir emaliu.
Neleidžia paieškos varikliams followint broken linkų.
Įskiepis leidžia redaguoti nuorodas iškart, t.y. nereikia klaidžioti iki tam tikros vietos ir ieškoti broken linko.
 
TinyMCE Advanced
Nuoroda: http://wordpress.org/extend/plugins/tinymce-advanced/
Šis įskiepis, prideda 16 papildomų funkcijų į standartinį tinymce editorių.
Advanced HR, Advanced image, Advanced link, kontekstiniai meniu, šypsenėlės, laikas ir data, IESpell, sluoksniai, spausdinimas, search and replace funkcija, stailinimas, lentelės, matematikos formulių palaikymas ir t.t.
O prie viso šio gėrio – spellcheckas.
 
BackWPup
Nuoroda: http://wordpress.org/extend/plugins/backwpup/
Galimybės:
Duomenų bazės backupai
Wordpresso xml exportas
Duomanų bazės optimizacija
Duombazės patikra / taisymas
Failų backupas
Backupų archyvavimas
Backupų talpinimas įvairiuose šaltiniuose.
Multisite support‘as
 
WordPress Popular Posts
 
http://wordpress.org/extend/plugins/wordpress-popular-posts/
 
Plačiai konfigūruojamas plugin‘as, skirtas populiariausių post‘ų atvaizdavimui. Galima naudoti ir kaip šablono tag‘ą.
Galima nepriskirti kategorijų, palaiko shortcode‘us, template tag‘us, automatiškas atsinaujinimas.
 
wp-Typography
Nuoroda: http://wordpress.org/extend/plugins/wp-typography/
Super dalykas tiems, kas nori turėti dailią ir TAISYKLINGĄ tipografiją savo tinklalapyje.
 
CMS Tree Page View
Nuoroda: http://wordpress.org/extend/plugins/cms-tree-page-view/
Plugin‘as skirtas tiems, kurie pripratę prie klasikinių turinio valdymo sistemų atvaizdavimo.
Atvaizduoja jūsų tinklalapį hierarchiniu būdu, bei turi keletą papildomų funkcijų.
 
WP-Optimize
Nuoroda: http://wordpress.org/extend/plugins/wp-optimize/
Tai Duomenų bazės optimizacijos ir valymo įrankis.
Leidžia panaikinti postų revizijas, nepatvirtintus arba „šlamšto“ komentarus ir t.t.
Taipogi, leidžia pervardinti wordpress vartotojus.
Palaiko daugiakalbiškumą.
 
Sidebar Login
Nuoroda: http://wordpress.org/extend/plugins/sidebar-login/
Suteikia galimybę išvesti wordpress loginą per shorttag‘ą arba widget‘ą.
 
Contact Form 7
Nuoroda: http://wordpress.org/extend/plugins/contact-form-7/
Leidžia sudarinėti norimas formas.
Palaiko captcha, akismet, ajax ir t.t.
 
Fluency Admin
Nuoroda: http://wordpress.org/extend/plugins/fluency-admin/
Patobulinimas administratoriaus vartotojo sąsajai. Tab‘ai atskiriami skirtinga spalva, įvairios spalvų schemos, galima pridėti savo logotipą ir hotkey palaikymas norint prieiti atitinkamas sekcijas.
 
WP-PostRatings
Norite įdiegti post‘ų vertinimą į savo wordpress svetainę? Prašau 
Yra ajax palaikymas.
 
WordPress Content Slide
Nuoroda: http://wordpress.org/extend/plugins/content-slide/
Šaunus įskiepis, kuris leidžia Jums sudaryti content slaiderius su efektais. Turi begalę opcijų.
Pavyzdys: http://wptuts.info/wp-content-slide/
 
GD Star Rating
Nuoroda: http://www.gdstarrating.com/
Dar vienas, ypač galingas, postų, komentarų ir puslapių reitingavimo pluginas. Multilanguage palaikymas, suderinamumas su kešo pluginais, turi begalę tinkinimo galimybių.
 
WP No Category Base
Nuoroda: http://wordpress.org/extend/plugins/wp-no-category-base/
Greitai ir paprastai nuima /category/ nuo Jūsų postų.
 
WP-Paginate
Nuoroda: http://wordpress.org/extend/plugins/wp-paginate/
Atlieka paprastą funkciją – puslapiuoja ir tai atlieka gerai 
 
SexyBookmarks | email, bookmark, and share buttons
Nuoroda: http://wordpress.org/extend/plugins/add-to-any/
Populiarus ir dailiai atrodantis pluginas, skirtas Sharingui/Bookmarikinimui. Garantuoju, jog jį jau matėte.
 
PHP Code Widget
Turbūt dažnas iš mūsų pasigedo galimybės rašyti php kodą widgete. Šis pluginas suteiks šią galimybę.
 
Relevanssi – A Better Search
Nuoroda: http://wordpress.org/extend/plugins/relevanssi/
Praplečia standartinę wordpress sistemos paiešką.
Paieškos rezultatai patiekiami pagal didžiausią sutapimą, ne pagal datą.
Ieškoma „žodžio dalies“ sutapimų.
Pažymimi paieškos žodžiai rezultatuose.
Ir kitos funkcijos.
 
Twitter Widget Pro
Nuoroda: http://wordpress.org/extend/plugins/twitter-widget-pro/
Turbūt populiariausias Twitter widgetas wordpressui.
 
WassUp
Nuoroda: http://wordpress.org/extend/plugins/wassup/
Nebloga, google analytics alternatyva ir kas svarbiausia – real time trackingas.
 
Sharebar
Nuoroda: http://wordpress.org/extend/plugins/sharebar/
Pavadinimas daug pasako. Vienas iš geresnių savo srityje.
 
Search Everything
Nuoroda: http://wordpress.org/extend/plugins/search-everything/
Paieškos patobulinimas wordpress sistemai.
Paieškos rezultatų paryškinimas, ieško kiekviename puslapyje, tag‘e, taxonomijose, kategorijose, komentare, draftuose, excerptuose, atachmentuose, custom field‘uose, taipogi suteikiama galimybė neleisti prieiti paieškai prie tam tikrų resursų.
 
Role Scoper
Nuoroda: http://wordpress.org/extend/plugins/role-scoper/
Labai šaunus wordpress pluginas, skirtas vartotojų teisėms sistemoje redaguoti.
 
Wordbooker
Nuoroda: http://wordpress.org/extend/plugins/wordbooker/
Pats geriausias ir lengviausiai konfigūruojamas pluginas, skirtas tam, jog Jūsų blogo įrašai atsirastų ir facebook erdvėje.
 
Disqus Comment System
Nuoroda: http://wordpress.org/extend/plugins/disqus-comment-system/
Viena geriausių alternatyvų standartinei wordpress komentavimo sistemai.
 
Really Simple CAPTCHA
Nuoroda: http://wordpress.org/extend/plugins/really-simple-captcha/
Pavadinimas – daug pasako. Gal ir ne pats saugiausias, tačiau labai paprastai valdomas captcha pluginas.
 
Secure WordPress
Nuoroda: http://wordpress.org/extend/plugins/secure-wordpress/
Didelis saugumo paketas wordpress turinio valdymo sistemai.
Trumpai: nepateikia error informacijos prisijungimo lange, prideda index.php failą pluginų direktorijoje, neatvaizduoja wp versijos ir dalies kitos, naudingos įsilaužėliui informacijos, blokuoja „blogas“ užklausas, kurios gali pakenkti wordpress sistemai.
 
BulletProof Security
Nuoroda: http://wordpress.org/extend/plugins/bulletproof-security/
Dar vienas „must have“ saugumo pataisymas wordpress sistemai. Apsaugo nuo xss, csrf, base64_encode, sql injekcijų ir kitų „laužimo“ būdų. Apsaugo wp-config.php, bb-config.php, php.ini, php5.ini, install.php ir readme.html su .htaccess failus, bei begalės kitų pataisymų.
 
Dynamic Content Gallery
Nuoroda: http://wordpress.org/extend/plugins/dynamic-content-gallery-plugin/
Šaunus pluginas, leidžiantis išburti slaiderį, su paskutiniais ir featured postais.
 
WP to Twitter
Nuoroda: http://wordpress.org/extend/plugins/wp-to-twitter/
Šio plugino Jums prireiks, jei norėsite wordpress įrašus postinti ir twitteryje.
 
Ajax Event Calendar
Nuoroda: http://wordpress.org/extend/plugins/ajax-event-calendar/screenshots/
Ajax technologija besiremiantis kalendorius, su begale funkcijų. Plačiau – gamintojo puslapyje.
 
SEO Friendly Images
Turite daug paveikslėlių, bet ne visiems priskyrėte title ir alt žymes? Nepergyvenkite, šis pluginas Jums padės tai sutvarkyti.
Tiek kodas tampa validus, tiek puslapis tampa daugiau „seo friendly“
 
Link Library
Nuoroda: http://wordpress.org/extend/plugins/link-library/
Tiems, kas „stato“ didelius nuorodų sąrašus, šis pluginas tikrai bus naudingas.
 
After the Deadline
Nuoroda: http://wordpress.org/extend/plugins/after-the-deadline/
Spellcheckeris wordpressui. Įdomu dar ir tai, jog naudoja AI rašybai tikrinti.
 
WP Security Scan
Nuoroda: http://wordpress.org/extend/plugins/wp-security-scan/
Tikrina Jūsų wordpress svetainės saugumą. Pateikia pažeidžiamumus ir galimus pataisymus.
Tikrina: slaptažodžius, failų permissionus, duombazės saugumą, versijos slėpimą, wordpress admin dalį ir t.t.
 
Shortcode Exec PHP
Nuoroda: http://wordpress.org/extend/plugins/shortcode-exec-php/
Leis vykdyti php kodą postuose, puslapiuose ir t.t. naudojant shortcodus. Turi įdiegtą sintaksės spalvinimą. Prisibijant dėl saugumo, tai shortcodus galės naudoti tik administratoriai.
 
Easing Slider
Nuoroda: http://wordpress.org/extend/plugins/easing-slider/
Tikria gražus slaideris, su puikiu css3 apipavidalinimu.
 
AdRotate
Nuoroda: http://wordpress.org/extend/plugins/adrotate/
Patogiausias ir turbūt geriausias pluginas reklamai administruoti Jūsų wordpress svetainėje. Patogus, lankstus, paprastas ir galingas. Ko daugiau reikia?
Turi integruotą šiokią tokią statistiką, palaiko shortcodus, turi reklamos „pasibaigimo terminą“ ir begalę kitų galimybių.
 
Exploit Scanner
Nuoroda: http://wordpress.org/extend/plugins/exploit-scanner/
Ieško blogų gyventojų Jūsų wordpress svetainėje  Pats nieko netrina, tiesiog informuoja administratorių apie galimas grėsmes.
Ieškomi neįprasti pluginai, duombazės įrašai, failų vardai ir t.t.
 
WordPress Video Plugin
Nuoroda: http://wordpress.org/extend/plugins/wordpress-video-plugin/
Leidžia paprastai embeddinti video medžiagą į wordpress svetainę.
Palaiko labai daug šaltinių.
 
Facebook likes you!
Nuoroda: http://wordpress.org/extend/plugins/facebook-likes-you/
lengvai ir greitai diegiamas like/share mygtukas wordpress‘ui.
 
Configure SMTP
Sukonfigūruoja smtp nustatymus wordpressui. Be šios konfigūracijos kai kurie pluginai gali veikti nekorektiškai (dažniausia tai būna email notificationai ir newsletter pluginai)
 
Facebook Comments for WordPress
Nurooda: http://wordpress.org/extend/plugins/facebook-comments-for-wordpress/
Lengvai integruojami ir konfigūruojami facebook tipo komentarai wordpress sistemai. Galimybė sinchronizuoti wordpress ir facebook komentarus.
 
Newsletter
Nuoroda: http://wordpress.org/extend/plugins/newsletter/
Naujienlaiškis. Nemokamai ir paprastai.
 
WP-Cufon
Nuoroda: http://wordpress.org/extend/plugins/wp-cufon/screenshots/
Patyrusiems temų developeriams šio plugino tikrai neprireiks, bet tiems, kurie yra mažiau pažengę – šis pluginas tikrai pravers. Pasirinkite ir lengvai embeddinkite bent kokį šriftą iš cufon kolekcijos.
 
All In One Favicon
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-favicon/
Vėlgi – truputį patyrusiems vartotojams šio plugino tikrai neprireiks, tačiau, jei esate naujokas ir nenorite lysti į sistemos vidurius, bet norite pakeisti favicon arba suteikti galimybę paprastam vartotojui ją pasikeisti be Jūsų pagalbos, šis pluginas Jums pravers.
 
Quick Adsense
Nuoroda: http://wordpress.org/extend/plugins/quick-adsense/
Greitas ir lengvas ad sense reklamos administravimas Jūsų puslapyje. Random atvaizdavimas ir kitos funkcijos tikrai palengvins Jūsų gyvenimą ir papildys piniginę.
 
Blog Protector – Protect Your Content
Nuoroda: http://wordpress.org/extend/plugins/blog-protector/
Nors aš manau, jog internete turinys turi būti atviras, tačiau tiems, kurie savo turinį nori apsaugoti – pateikiame blog protector.
Pluginas atjungia tokias funkcijas kaip teksto žymėjimas ir antras pelės mygtuko apspaudimas.
 
WordPress Portfolio Plugin (WP Portfolio)
Nuoroda: http://wordpress.org/extend/plugins/wp-portfolio/
Lengvas portfolio administravimas.
 
WordPress Importer
Nuoroda: http://wordpress.org/extend/plugins/wordpress-importer/
Importuoja postus, puslapius, komentarus, custom , meta fieldus, kategorijas, tagus, taksonomijas ir autorius iš kito wordpress blogo.
 
WP-Polls
Nuoroda: http://wordpress.org/extend/plugins/wp-polls/
Norite surengti apklausą savo wordpress svetainėje? Šis pluginas Jums padės! Paprastas ir greitas.
 
WordPress Mobile Pack
Nuoroda: http://wordpress.org/extend/plugins/wordpress-mobile-pack/
Leis Jūsų svetainei atrodyti geriau mobiliuosiuose prietaisuose.
Galimybės:
Switchas tarp desktop ir mobile svetainės versijų.
Standartinė tema mob. Įrenginiams.
Didelės pritaikomumo galimybės.
Mobiliems įrenginiams pritaikyta admin panelė.
Barcode widgetas
Mobilie adsense widgetas
Ir t.t.
 
NextGen gallery
Nuoroda: http://wordpress.org/extend/plugins/nextgen-gallery/
Pats geriausias albumų / galerijų pluginas wordpressui. Draugauja su begale pluginų, yra pastoviai atnaujinamas, palaiko multilanguage, turi nemažai papildomų praplėtimų ir t.t.
 
Viper’s Video Quicktags
Nuoroda: http://wordpress.org/extend/plugins/vipers-video-quicktags/
Įkeliant video, tag‘us šis pluginas supildys pats, automatiškai.
Palaiko:
 YouTube (including playlists)
 Google Video
 DailyMotion
 Vimeo
 Veoh
 Viddler
 Metacafe
 Blip.tv
 VideoPress aka WordPress.com Video NEW!
 Flickr videos
 Spike.com/IFILM
 MySpaceTV
 
WordPress Related Posts Yet Another Related Posts Plugin
Nuoroda: http://wordpress.org/extend/plugins/yet-another-related-posts-plugin/
Atvaizduoja susijusius postus.
Universalus ir konfigūruojamas algoritmas, kuris peržvelgia postų antraštes, tagus ir kategorijas, bei pagal YARPP apskaičiuoja sutapimo „rezultatą“.
Pluginas draugauja su kešu, bei turi keletą kitų gerų savybių.
 
Autolink URI
Nuoroda: http://wordpress.org/extend/plugins/sem-autolink-uri/
Paverčia tekstą, kuris turi pradžią http:// į nuorodą automatiškai.
 
WordPress Firewall 2
Nuoroda: http://wordpress.org/extend/plugins/wordpress-firewall-2/
Stebi užklausas ir apsaugo sistemą nuo atakų.
 
Zemanta
Nuoroda: http://wordpress.org/extend/plugins/zemanta/
Rašant wordpresse, zemanta siūlo paveiksliukus, video, nuorodas ir seo optimizuotus tag‘us su Jūsų susijusiu turiniu.
Tikrai labai patogus content sugestion engine‘as, padedantis tiems, kurie daug rašo ir nori rašyti kokybiškai.
Plačiau: gamintojo saite ir http://en.wikipedia.org/wiki/Zemanta
 
All in One SEO Pack
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-seo-pack/
Pats geriausias seo pluginas wordpress sistemai. Palaiko custom post type, kanonines nuorodas, turi palaikyma e-commerce pluginams, meta tagų automatinis generavimas ir begalės kitų funkcijų.
 
Qtranslate
Nuoroda: http://wordpress.org/extend/plugins/qtranslate/
Tiesiog, pats geriausias sprendimas tada, kai reikia svetainės keliomis kalbomis. Draugauja su begale pluginų.
 
FancyBox for WordPress
Nuoroda: http://wordpress.org/extend/plugins/fancybox-for-wordpress/
Lengvesnis nei lightbox, bet toks pat gražus.

Iš asmeninių faebook užrašų:
 
Kaip pastebėjote, vakar nagrinėjau geriausius e-commerce sprendimus šiai dienai.
Po dienos skaitinėjimų ir bandymų, paaiškėjo labai super dalykas... darysim su tuo, su kuo ir darėm anksčiau (presta) :D ir jei produktas populiarus, dar nereiškia, jog jis geras. šiandien reikės parašyti straipsnelį apie e-shop'ų open source varikliukų pasirinkimus ir kiekvieno pliusus ir minusus :) Dabar patiekiu tik abstrakčią apžvalgą šia tema.
benaršydamas aptikau įdomesnį projektą, kuris, manau, turėtų puikiai tikti mažoms parduotuvėlėms, kurios nori būti visur ir visada - http://www.ecwid.com/ projektas sudomino, nes shopas gali būti lengvai paverčiamas mobilaus telefono aps'u, begalinės integravimo galimybės, "perpardavinėjimas", kai žmogus susikuria e-shopą, realiai savo prekių neturi (arba gali ir turėti :D) ir parduoda kitų žmonių prekes pas save už tam tikrą procentą. kažkas labai panašaus į apsikeitimą banneriais ar ad-words :) idėja tikrai nebloga, ypač jei pradedi nuo nulio :)
 
 
Wordpress - kaip visada labai lanksti sistema, kuri senai išaugo savo bloginimo platformos rūbus, tik visi e-commerce moduliai - fail. nepatogus prekių atvaizdavimas back end'e, daugumoje kvailokai įgyvendintas ir prekių suvedimas, import/export trūkumai ir kitos negandos... sunku nupasakoti, bet visi e-commerce sprendimai wordpressui nelabai suprantu kam išvis skirti ir kuo jie skiriasi nuo paprastų post'ų :) vienas geresnių sprendimų - wp e-commerce pluginas, kuris yra vienas populiariausių, BET pluginas nemokamas tik su mažu paketu funkcijų, jo kodas parašytas specialiai labai painiai, jog būtų perkami "updeitai", o dėl tų mažų updeitų mokėti 100 baksų - atsiprašau, bet tai vagystė :) laužto plugino jūs nepanaudosite, nes reikalingas api, kuris galioja tik vienam saitui.
 
 
magento - lėtas griozdas, reikalaujantis specifinio php.ini konfigo. Turi vieną didžiausių ir labiausia sustabarėjusią community tarp OS e-commerce sprendimų. Mėgsta klaidas, kurios neišvedamos vartotojui, tiesiog reloadinamas peidžas ir nepasakoma nieko :). Tuomet eini skaityti apatiškos community postų, kur 80% suteiktos pagalbos yra total crap arba problema išsprendžiama ne iki galo :) neįsivaizduoju kodėl šis produktas toks populiarus, galbūt dėl tam tikrų blog'ų, ypač užsenietiškų, kurie turi labai gerą reputaciją pataikavimo šiai sistemai, galbūt dėl kitų priežasčių, nežinau, bet šios sistemos rinktis nepatariu.
 
 
Joomla + virtuemart. Lėtokas, ganėtinai nemažai resursų reikalaujantis sprendimas. Kvailai sugalvotas theme'ingas. Gamintojai kai kurių bug'ų nesugeba išspręsti jau trejus ar net ketverius metus (bugai - tikrai ne kokios smulkmenos). Admin dalis sugeba persipinti su viešąja(WTF???), kvailai parašyti pluginai, kurie suteikia galvos skausmo su suderinamumu ir kodo validavimu. Nemažai problemų rūpinantis SEO reikalais. Mane labai nervuojantis dalykas - atsidarius prekės teksto editorių, tekstas jame ne visada užsikrauna (nesvarbu ar tai būtų wysiwyg editorius ar tiesiog atvaizduojamas visas kodas) :D
Tiesa, turi ir savų pliusų. Ganėtinai nemažai modulių, nemažas community, ganėtinai patogus ir organizuotas prekių administravimas backende. Nujaučiu, jog sistema po truputį užleis vietas kitoms.
 
 
Prestashop - labai patogus backend'as, nėra labai sudėtingas theme'ingas, puikiai optimizuota, didelis funkcijų ir modulių pasirinkimas, puikiai galima sudraugauti su SEO, nemažas community, bug'ai, jeigu jų ir yra - išspręsti / išsprendžiami oficialiame forume. Griežtai apibrėžta sistema, galimi keli vartotojų tipai, puikus suderinamumas su dauguma atsiskaitymo galimybių, lengvas lojalumo ir nuolaidų administravimas... Tiesą sakant tai, mano manymu, pats geriausias open source e-commerce sprendimas šiuo metu. IR JIS NEMOKAMAS :) Tiesa sakant, teko vartyti savo localhoste ne vieną eshop tvs ar modulį, kurie kainuoja 2-3k žalio ir jie toli atsiliko nuo šio nemokamo produkto. Tad, kur gi bajeris? Juk nebūna visko nemokamai ir idealaus. Kodėl prestashopas nėra toks populiarus? Kur čia šuo pakastas?
Viskas paprasta.
Didelis community, bet didžiausia jos dalis - prancūzai. Prancūzai dideli nacionalistai ir dažniausia kilus klausimams ar iššokus spuogui (bug'ui), teks pasitelkti google translator ir skaityti prancūzišką tekstą... :) merginoms tai turbūt pasirodys labai romantiška, ar ne ? :) Kiek neoptimizuotas (vietos atžvilgiu, nes reikia pastoviai daug scrollinti) backendas, bet geresnio - neteko matyti (dabar kaip tik kilo idėja sukurti theme'ą admin daliai...) :), daug pluginų, BET didžioji dalis - mokami. Netgi didžiuosiuose WAREZ saituose nerasite šablonų/plug-in'ų šiai sistemai(na, tiesą pasakius rasite, bet jų bus keli...), tad teks pakratyti piniginę arba žaisti lego patiems :) mano spėjimu, ši sistema todėl ir nepaplito taip plačiai, būtent dėl warezinių / nemokamų temų / plugin'ų nebuvimo (arba mažo buvimo :)), kurias tokios šalys kaip Lietuva ypač myli. Vertimus galite rasti, bet jie bus daliniai, tad teks pasėdėti ir paversti, kol pasidarysite final versiją.
www.gudriosgalvos.lt
 
 
Tai tiek. Jei turite pastebėjimų - rašykite :)

Sveiki, teko parašyti straipsnį anglų kalba, tačiau noriu juo pasidalinti ir su lietuvių Front-ender'ių community.
Originalu straipsnį rasite čia:
https://www.devbridge.com/articles/increasing-sass-compiling-performance-or-when-every-second-counts/
 
Ar daug yra sekundė? O dvi, trys? Dešimt? Tokie klausimai man kilo nuo tada, kai pradėjome naudoti CSS preprocesorių SASS.
Įrankis, kurio pagalba turėjome palengvinti ir pagreitinti savo darbą, kartais jį netgi prailgindavo, dėl savo compile’o greičio. Taip, įrankis mums leido suvienodinti savo kodą tarp kelių komandos narių, leido automatizuoti kodo rašymo, spritinimo ir kitus procesus, tačiau kelis mėnesius developinamas projektas, pasiekdavo 7-12 sec. ar net didesnes compile’o laiko ribas. Galbūt tai neatrodo daug, tačiau paskaičiuokime: tarkime, jog buildiname failą vieną kartą kas minutę, vidutinis build time 6-10sec = 8sec. Tai reiškia, jog nemaža dalis mūsų darbo laiko (1/7.5, kas yra 40/7.5 ~ 5.3 valandos) yra ne kas kita, kaip laukimas, kol SASS susicompilins. Tad ką mes galime padaryti?
SASS su steroidais
Logika čia gana artima automotibilių sportui - jei automobilis važiuoja labai lėtai, vadinasi kaltas jo variklis. Būtent tai mes ir padarysime, pakeisim variklį. SASS buildinimui panaudosime libsass, tai SASS port‘as C kalba. Libsass kūrėjai jau senai pastebėjo, jog Ruby tikai nėra gerai performinanti kalba ir SASS variklį reikia perkelti ant kalbos, kurią galėtum paleisti tiek įvairiose aplinkose ir kurios greitis tenkintų.
Tolumoje jau girdžiu žmones, kurie sako „Palauk, palauk, o kaip compass? Kaip native ruby funkcijų naudojimas libuose? Pamiršai?“.
 
Karalius mirė? Tegyvuoja karalius!
Taip, pasirinkus libsass aš turėjau atsisakyti dviejų visų mėgiamų sass frameworkų: „Compass“ ir grid‘o sistemos „Susy“. Jei susy atsirado dar visai nesenai, tai compass buvo labai didelė SASS populiarumo priežastis ir jo atsisakymas daug kam pasirodys neadekvatus, tačiau mes jį visai nesunkiai pakeisime. Susipažinkite – „Bourbon“.
Bourbon – tai tik SASS paremta mixinų biblioteka, kuri yra beveik identiška „Compass“, tačiau „Bourbon“, mano nuomone turi didesnį išpildymą, nepriklausomumą, greitį ir dokumentaciją.
Pavyzdiniame projekte, pakeitus „Compass“ į „Bourbon“, su kiekvienu importo pakeitimu compile time sumažėdavo 0,6~ sekundės (visas compile time apie 10sec).
Tad ką mes laimėjome ir ką praradome iškeitę „Compass“ į „Bourbon“?
Laimėta:
a) Greitis (build time, net nepakeitus buildinimo engine tapo greitesnis)
b) Didesnis išpildymas – papildomai gausite tikrai kokybišką grido sistemą - „Neat“, ir ne tokią svarbią componentų ir add’ons bibliotekas.
c) Dokumentacijos stilius yra pesonalinis dalykas, tačiau „Bourbon“ dokumentacija man žymiai aiškesnė.
d) Bourbon yra „pure“ SASS, jį galima naudoti tiek su libsass tiek su ruby sass compileriu.
f) Jau integruotas CSS animacijų paketas (keyframes, animation ir t.t.)
g) Compass iš esmės stengiasi padaryti viską, bet kaip žinoma, įrankiai skirti viskam, dažniausia nėra tinkami geriausiems ir sparčiausiems sprendimams. Netgi visų mėgstamas spritinimo helperis compasse nėra optimaliai parašytas, nes sprite’ai yra pertikrinami kas kiekvieną sass failo modifikaciją, kai tuo tarpu, logiška būtų juos tikrinti tik tuomet, jei grafiniai failai buvo pridėti į sprite.
h) Compass labiau mėgsta įsibrauti į jūsų sistemą ir turi kelis erzinančius dependencies.
 
Prarasta:
a) Compass Inline-image funkcija, kuri buvo patogi, tačiau galima gyventi ir be jos.
b) Sprite‘ų generavimas (kaip mes tai pakeisime – apie tai, vėliau)
 
Grido sistema gali kelti performance bėdų? Really?
Mano atveju, teko keisti ir grid sistemą. Naudotas susy, jau pusę metų neišsprendžia savo bėdų performance srityje https://github.com/ericam/susy/issues/325, taip pat, jis priklauso nuo ruby, tad teko jo atsisakyti.
Žinoma, skaitydami šias eilutes, galvojate, jog vėl sutaupysime vidutiniškai puę sekundės, tačiau, norėčiau atkreipti Jūsų dėmesį į šį grid‘o sistemų palyginimą: http://jeffreydegraaf.nl/2014/07/04/performance-of-sass-grid-systems/
Kaip matote, Neat ir Susy performance skirtumas yra gana didelis (0.3~1,2 sec versus 7~8sec.). Gana įspūdinga?
Būtent todėl ir pasirinkau „Neat“, nes jis panašus į „Susy“, LABAI greitas, nepriklausomas nuo Ruby ir labai gerai dokumentuotas.
Užteks kalbėti, rodyk skaičius.
Gerai, tad tarkime, jog turime seną projektą, kiek mes galime sutaupyti?
Generation of average project file (240KB size)
Compass + susy + sprites – empty cache: 16-17s.
Compass + susy + cache + sprites: 10-12sec.
Libsass + neat + bourbon + sprites + grunt-watch: 1.6 sec.
Libsass + neat + bourbon + sprites + grunt watch with (spawn:false): 0.6 sec.
Kaip matote, skirtumas yra milžiniškas.
 
 
Įtikinai, tik kaip visa tai efektyviai sujungti? Ir kaip dėl sprite’ų?
Turbūt ne paslaptis, jog didelė dalis front-end developerių laikosi įsikandę compass tik dėl sprite’ų generavimo.
Libsass ir automatizuotas spritinimas? Taip, tai įmanoma, kaip ir minėjau, sprite‘ų automatizavimo atsisakyti nereikės, tačiau tam, jog viskas veiktų, reikės grunt arba gulp. Jei dar nesate susipažinę su šiuo įrankiu, tai pasiskaitykite čia (asmeniškai, pirmenybę teikiu Grunt, todėl instrukcijas pateiksiu tik jam): http://gruntjs.com/
Jums eikės:
Node naujausios versijos:
http://nodejs.org/download/
Parsisiųskite sample libsass projektą: https://github.com/devbridge/Front-End-Toolkit/tree/master/starter-template-libsass
kai susiinstaliuosite Node, įsijunkite node command line ir nueikite į projekto direktoriją:
įveskite komandą: npm install
Ir viskas, galite pradėti dirbti :)
 
Pirmam paleidimui duokite komandą „grunt“, bus sugeneruoti pradiniai failai, sprite‘ai. Dirbant naudokite task‘ą grunt watch, jis stebės scss failus ir img failus ir jiem pakitus, atitinkamai reaguos.
 
Jei kažkas nepavyko – rašykite komentaruose, pabandysiu pagelbėti.
 
Faster!
Tam, jog taupyti laiką ir tik atsinaujinus CSS failui, vaizdas būtų perpieštas, esu pasirašęs mažą chrome extensioną, galbūt pravers ir Jums:
https://chrome.google.com/webstore/detail/prototool-css-auto-refres/kobijmefblkndpicohiondpdnpojebjd
 
Final thoughts
Tiesą sakant, šis research‘as davė man labai daug patirties apie tai, kaip aš ateityje rinksiuosi įrankius. Tai padėjo man suvokti, jog sass plugins‘ai, extension‘ai negali savyje turėti kitos kalbos panaudojimo kaip SASS. Tai leidžia vėliau išvengti suderinamumo ir palaikomumo problemų ir esant dideliems pokyčiams, leidžia greitai daryti pakeitimus esant poreikiui.
Taip pat, developinant didelius projektus, kritiškai svarbu atsižvelgti į įrankio spartą.
Tikiuosi mano postas Jums padės atsikratyti beverčio laukimo ir leis atsilaisvinusį laiką panaudoti geresniems tikslams.
Galbūt turite įdėjų kaip visa tai dar labiau pagreitinti, o gal turite pastabų ar pastebėjimų? Rašykite komentarų skiltyje! Ačiū!

Sveiki,
Jei atsibodo spaudyti refreshą ant css edit'o ar projektas loadinasi ilgiau, nei trunka css/sass pakeitimas, o gal klientas nori "pixel perfect" dizaino? Parašiau custom chrome extension'ą, kuris turėtų padėti evelopinant frontend'ą.
Pagrindinės savybės:
1. auto css refresh ant edit'o
2. pixel perfect mode'as, kur galit pasidaryti svetainės overlay su tikru dizainu ig lengvai jį įjungti - išjungti.
3. Difference mode'as
Linkas: https://chrome.google.com/webstore/detail/proto-tool/kobijmefblkndpicohiondpdnpojebjd
Paskaitykite description'ą prieš naudojant ir sėkmės :)
Jei turite klausimų ar pasiūlymų - rašykite čia.
Ačiū!

Šaltinis: http://www.gdgroup.lt/blog/naudingi-wordpress-pluginai/
 
Kol kas pateiksiu greitą, virš 60 naudingų wordpress pluginų sąrašą.
 
Pluginus atrinkau dirbdamas su wordpress sistema, stengiausi atsižvelgti į pluginų “gerumą” pagal jų programinę dalį, lengvą themeing’ą ir puikų savo darbo atlikimą.
 
Na ką, pradedam!
WordPress SEO by Yoast
Nuoroda: http://wordpress.org/extend/plugins/wordpress-seo/
Vienas iš geresnių seo optimizacijai skirtų pluginų. Leidžia redaguoti postų title ir meta description reikšmes, yra pilnai kanonizuotas, turi integruotus breadcrumb‘us, gali sudaryti xml sitemapus, rss patobulinimus ir keletą kitų funkcijų. Tai toks seo pluginas, kuris atlieka daug veiksmų, jei reikia būtent tokio ir dėl tam tikrų priežasčių negalite naudoti specializuotų pluginų – šis bus pats tas.
 
Booking Calendar
Nuoroda: http://wordpress.org/extend/plugins/booking/
Booking calendar Jums labai pravers, jei užsiimate nuoma ar kita sritimi, kuriai reiktų įskiepio „Booking calendar“.
Lankytojai, šio plugin‘o pagalba, galės tikrinti objektų prieinamumą tam tikru metu, vartotojai galės vykdyti rezervaciją. Klientai gali registruotis vyksiantiems renginiams. Taipogi, galima įdiegti papildomą atsiskaitymo modulį ir leisti vartotojams susimokėti iškart.
Įskiepis ganėtinai lankstus ir jį galima pritaikyti kitoms reikmėms.
Demonstraciją rasite čia: http://onlinebookingcalendar.com/demo/
Galimybės:
Rezervacija, pasirenkant norimą datą
Priminimai el. paštu, tiek administratoriui, tiek vartotojams.
Patogi vartotojo sąsaja.
Kalendoriaus widget‘as.
Palaiko kelias kalbas.
Ir t.t.
 
WP Minify
Nuoroda: http://wordpress.org/extend/plugins/wp-minify/
Įskiepis integruoja „Minify“ varikliuką, kuris optimizuoja JS ir CSS failų krovimo laikus puslapyje.
Puikiai tinka tiems, kurie kaunasi dėl optimizacijos.
Turi klaidų taisymo įrankius ir keletą konfigūracijos pasirinkimų.
 
Widget Logic
Nuoroda: http://wordpress.org/extend/plugins/widget-logic/
Įskiepis suteiks galimybę valdyti widget‘us, tiksliau jų logiką. Prie widgeto atsiras papildomas laukas, kuriame galima bus nustatyti, kuriame puslapyje jis gali atsirasti.
 
WPtouch
Nuoroda: http://wordpress.org/extend/plugins/wptouch/
Šis įskiepis padės optimizuoti Jūsų tinklalapį mobiliesiems įrenginiams.
 
WP-Cumulus
Nuoroda: http://wordpress.org/extend/plugins/wp-cumulus/
Teko matyti gražius tag cloud‘us kitose svetainėse, kur žodžiai sukasi 3d aplinkoje? Būtent šis pluginas ir atlieka šį darbą.
 
Social Slider
Nuoroda: http://wordpress.org/extend/plugins/social-slider-2/
Įskiepis atvaizduoja „išsiskleidžiantį“ box‘ą, kuriame pateikiami Jūsų socialinių tinklų profiliai ar nuorodos.
Pluginas tikrai atrodo neprastai ir su kai kuriais dizaino sprendimais, gali būti tikras išsigelbėjimas.
Įskiepio demonstracija: http://social-slider.com/demo/full.html
Palaikomi soc. Tinklai:
 RSS
 Newsletter
 Facebook
 Google+ (Google Plus)
 Twitter
 Blip
 Flaker
 Soup.io
 Buzz
 Sledzik
 Tumblr
 Spinacz
 GoldenLine
 LinkedIn
 Nasza Klasa
 NetworkedBlogs
 MySpace
 Orkut
 Grono
 FriendConnect
 FriendFeed
 Digg
 Wykop
 Kciuk
 Picasa
 Flickr
 Panoramio
 DeviantArt
 YouTube
 Vimeo
 IMDb
 Last.fm
 iSing
 Blip.fm
 Delicious
 Unifyer
 
Broken Link Checker
Nuoroda: http://wordpress.org/extend/plugins/broken-link-checker/
Kaip ir matosi iš pavadinimo – įskiepis skirtas stebėti „broken links“ svetainėje.
Stebi broken linkus į postus, puslapius, comentarus ir custom field‘us.
Aptinka neveikiančias nuorodas į paveikslėlius ir kitą media.
Perspėja Jus dashboard‘e ir emaliu.
Neleidžia paieškos varikliams followint broken linkų.
Įskiepis leidžia redaguoti nuorodas iškart, t.y. nereikia klaidžioti iki tam tikros vietos ir ieškoti broken linko.
 
TinyMCE Advanced
Nuoroda: http://wordpress.org/extend/plugins/tinymce-advanced/
Šis įskiepis, prideda 16 papildomų funkcijų į standartinį tinymce editorių.
Advanced HR, Advanced image, Advanced link, kontekstiniai meniu, šypsenėlės, laikas ir data, IESpell, sluoksniai, spausdinimas, search and replace funkcija, stailinimas, lentelės, matematikos formulių palaikymas ir t.t.
O prie viso šio gėrio – spellcheckas.
 
BackWPup
Nuoroda: http://wordpress.org/extend/plugins/backwpup/
Galimybės:
Duomenų bazės backupai
Wordpresso xml exportas
Duomanų bazės optimizacija
Duombazės patikra / taisymas
Failų backupas
Backupų archyvavimas
Backupų talpinimas įvairiuose šaltiniuose.
Multisite support‘as
 
WordPress Popular Posts
 
http://wordpress.org/extend/plugins/wordpress-popular-posts/
 
Plačiai konfigūruojamas plugin‘as, skirtas populiariausių post‘ų atvaizdavimui. Galima naudoti ir kaip šablono tag‘ą.
Galima nepriskirti kategorijų, palaiko shortcode‘us, template tag‘us, automatiškas atsinaujinimas.
 
wp-Typography
Nuoroda: http://wordpress.org/extend/plugins/wp-typography/
Super dalykas tiems, kas nori turėti dailią ir TAISYKLINGĄ tipografiją savo tinklalapyje.
 
CMS Tree Page View
Nuoroda: http://wordpress.org/extend/plugins/cms-tree-page-view/
Plugin‘as skirtas tiems, kurie pripratę prie klasikinių turinio valdymo sistemų atvaizdavimo.
Atvaizduoja jūsų tinklalapį hierarchiniu būdu, bei turi keletą papildomų funkcijų.
 
WP-Optimize
Nuoroda: http://wordpress.org/extend/plugins/wp-optimize/
Tai Duomenų bazės optimizacijos ir valymo įrankis.
Leidžia panaikinti postų revizijas, nepatvirtintus arba „šlamšto“ komentarus ir t.t.
Taipogi, leidžia pervardinti wordpress vartotojus.
Palaiko daugiakalbiškumą.
 
Sidebar Login
Nuoroda: http://wordpress.org/extend/plugins/sidebar-login/
Suteikia galimybę išvesti wordpress loginą per shorttag‘ą arba widget‘ą.
 
Contact Form 7
Nuoroda: http://wordpress.org/extend/plugins/contact-form-7/
Leidžia sudarinėti norimas formas.
Palaiko captcha, akismet, ajax ir t.t.
 
Fluency Admin
Nuoroda: http://wordpress.org/extend/plugins/fluency-admin/
Patobulinimas administratoriaus vartotojo sąsajai. Tab‘ai atskiriami skirtinga spalva, įvairios spalvų schemos, galima pridėti savo logotipą ir hotkey palaikymas norint prieiti atitinkamas sekcijas.
 
WP-PostRatings
Norite įdiegti post‘ų vertinimą į savo wordpress svetainę? Prašau 
Yra ajax palaikymas.
 
WordPress Content Slide
Nuoroda: http://wordpress.org/extend/plugins/content-slide/
Šaunus įskiepis, kuris leidžia Jums sudaryti content slaiderius su efektais. Turi begalę opcijų.
Pavyzdys: http://wptuts.info/wp-content-slide/
 
GD Star Rating
Nuoroda: http://www.gdstarrating.com/
Dar vienas, ypač galingas, postų, komentarų ir puslapių reitingavimo pluginas. Multilanguage palaikymas, suderinamumas su kešo pluginais, turi begalę tinkinimo galimybių.
 
WP No Category Base
Nuoroda: http://wordpress.org/extend/plugins/wp-no-category-base/
Greitai ir paprastai nuima /category/ nuo Jūsų postų.
 
WP-Paginate
Nuoroda: http://wordpress.org/extend/plugins/wp-paginate/
Atlieka paprastą funkciją – puslapiuoja ir tai atlieka gerai 
 
SexyBookmarks | email, bookmark, and share buttons
Nuoroda: http://wordpress.org/extend/plugins/add-to-any/
Populiarus ir dailiai atrodantis pluginas, skirtas Sharingui/Bookmarikinimui. Garantuoju, jog jį jau matėte.
 
PHP Code Widget
Turbūt dažnas iš mūsų pasigedo galimybės rašyti php kodą widgete. Šis pluginas suteiks šią galimybę.
 
Relevanssi – A Better Search
Nuoroda: http://wordpress.org/extend/plugins/relevanssi/
Praplečia standartinę wordpress sistemos paiešką.
Paieškos rezultatai patiekiami pagal didžiausią sutapimą, ne pagal datą.
Ieškoma „žodžio dalies“ sutapimų.
Pažymimi paieškos žodžiai rezultatuose.
Ir kitos funkcijos.
 
Twitter Widget Pro
Nuoroda: http://wordpress.org/extend/plugins/twitter-widget-pro/
Turbūt populiariausias Twitter widgetas wordpressui.
 
WassUp
Nuoroda: http://wordpress.org/extend/plugins/wassup/
Nebloga, google analytics alternatyva ir kas svarbiausia – real time trackingas.
 
Sharebar
Nuoroda: http://wordpress.org/extend/plugins/sharebar/
Pavadinimas daug pasako. Vienas iš geresnių savo srityje.
 
Search Everything
Nuoroda: http://wordpress.org/extend/plugins/search-everything/
Paieškos patobulinimas wordpress sistemai.
Paieškos rezultatų paryškinimas, ieško kiekviename puslapyje, tag‘e, taxonomijose, kategorijose, komentare, draftuose, excerptuose, atachmentuose, custom field‘uose, taipogi suteikiama galimybė neleisti prieiti paieškai prie tam tikrų resursų.
 
Role Scoper
Nuoroda: http://wordpress.org/extend/plugins/role-scoper/
Labai šaunus wordpress pluginas, skirtas vartotojų teisėms sistemoje redaguoti.
 
Wordbooker
Nuoroda: http://wordpress.org/extend/plugins/wordbooker/
Pats geriausias ir lengviausiai konfigūruojamas pluginas, skirtas tam, jog Jūsų blogo įrašai atsirastų ir facebook erdvėje.
 
Disqus Comment System
Nuoroda: http://wordpress.org/extend/plugins/disqus-comment-system/
Viena geriausių alternatyvų standartinei wordpress komentavimo sistemai.
 
Really Simple CAPTCHA
Nuoroda: http://wordpress.org/extend/plugins/really-simple-captcha/
Pavadinimas – daug pasako. Gal ir ne pats saugiausias, tačiau labai paprastai valdomas captcha pluginas.
 
Secure WordPress
Nuoroda: http://wordpress.org/extend/plugins/secure-wordpress/
Didelis saugumo paketas wordpress turinio valdymo sistemai.
Trumpai: nepateikia error informacijos prisijungimo lange, prideda index.php failą pluginų direktorijoje, neatvaizduoja wp versijos ir dalies kitos, naudingos įsilaužėliui informacijos, blokuoja „blogas“ užklausas, kurios gali pakenkti wordpress sistemai.
 
BulletProof Security
Nuoroda: http://wordpress.org/extend/plugins/bulletproof-security/
Dar vienas „must have“ saugumo pataisymas wordpress sistemai. Apsaugo nuo xss, csrf, base64_encode, sql injekcijų ir kitų „laužimo“ būdų. Apsaugo wp-config.php, bb-config.php, php.ini, php5.ini, install.php ir readme.html su .htaccess failus, bei begalės kitų pataisymų.
 
Dynamic Content Gallery
Nuoroda: http://wordpress.org/extend/plugins/dynamic-content-gallery-plugin/
Šaunus pluginas, leidžiantis išburti slaiderį, su paskutiniais ir featured postais.
 
WP to Twitter
Nuoroda: http://wordpress.org/extend/plugins/wp-to-twitter/
Šio plugino Jums prireiks, jei norėsite wordpress įrašus postinti ir twitteryje.
 
Ajax Event Calendar
Nuoroda: http://wordpress.org/extend/plugins/ajax-event-calendar/screenshots/
Ajax technologija besiremiantis kalendorius, su begale funkcijų. Plačiau – gamintojo puslapyje.
 
SEO Friendly Images
Turite daug paveikslėlių, bet ne visiems priskyrėte title ir alt žymes? Nepergyvenkite, šis pluginas Jums padės tai sutvarkyti.
Tiek kodas tampa validus, tiek puslapis tampa daugiau „seo friendly“
 
Link Library
Nuoroda: http://wordpress.org/extend/plugins/link-library/
Tiems, kas „stato“ didelius nuorodų sąrašus, šis pluginas tikrai bus naudingas.
 
After the Deadline
Nuoroda: http://wordpress.org/extend/plugins/after-the-deadline/
Spellcheckeris wordpressui. Įdomu dar ir tai, jog naudoja AI rašybai tikrinti.
 
WP Security Scan
Nuoroda: http://wordpress.org/extend/plugins/wp-security-scan/
Tikrina Jūsų wordpress svetainės saugumą. Pateikia pažeidžiamumus ir galimus pataisymus.
Tikrina: slaptažodžius, failų permissionus, duombazės saugumą, versijos slėpimą, wordpress admin dalį ir t.t.
 
Shortcode Exec PHP
Nuoroda: http://wordpress.org/extend/plugins/shortcode-exec-php/
Leis vykdyti php kodą postuose, puslapiuose ir t.t. naudojant shortcodus. Turi įdiegtą sintaksės spalvinimą. Prisibijant dėl saugumo, tai shortcodus galės naudoti tik administratoriai.
 
Easing Slider
Nuoroda: http://wordpress.org/extend/plugins/easing-slider/
Tikria gražus slaideris, su puikiu css3 apipavidalinimu.
 
AdRotate
Nuoroda: http://wordpress.org/extend/plugins/adrotate/
Patogiausias ir turbūt geriausias pluginas reklamai administruoti Jūsų wordpress svetainėje. Patogus, lankstus, paprastas ir galingas. Ko daugiau reikia?
Turi integruotą šiokią tokią statistiką, palaiko shortcodus, turi reklamos „pasibaigimo terminą“ ir begalę kitų galimybių.
 
Exploit Scanner
Nuoroda: http://wordpress.org/extend/plugins/exploit-scanner/
Ieško blogų gyventojų Jūsų wordpress svetainėje  Pats nieko netrina, tiesiog informuoja administratorių apie galimas grėsmes.
Ieškomi neįprasti pluginai, duombazės įrašai, failų vardai ir t.t.
 
WordPress Video Plugin
Nuoroda: http://wordpress.org/extend/plugins/wordpress-video-plugin/
Leidžia paprastai embeddinti video medžiagą į wordpress svetainę.
Palaiko labai daug šaltinių.
 
Facebook likes you!
Nuoroda: http://wordpress.org/extend/plugins/facebook-likes-you/
lengvai ir greitai diegiamas like/share mygtukas wordpress‘ui.
 
Configure SMTP
Sukonfigūruoja smtp nustatymus wordpressui. Be šios konfigūracijos kai kurie pluginai gali veikti nekorektiškai (dažniausia tai būna email notificationai ir newsletter pluginai)
 
Facebook Comments for WordPress
Nurooda: http://wordpress.org/extend/plugins/facebook-comments-for-wordpress/
Lengvai integruojami ir konfigūruojami facebook tipo komentarai wordpress sistemai. Galimybė sinchronizuoti wordpress ir facebook komentarus.
 
Newsletter
Nuoroda: http://wordpress.org/extend/plugins/newsletter/
Naujienlaiškis. Nemokamai ir paprastai.
 
WP-Cufon
Nuoroda: http://wordpress.org/extend/plugins/wp-cufon/screenshots/
Patyrusiems temų developeriams šio plugino tikrai neprireiks, bet tiems, kurie yra mažiau pažengę – šis pluginas tikrai pravers. Pasirinkite ir lengvai embeddinkite bent kokį šriftą iš cufon kolekcijos.
 
All In One Favicon
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-favicon/
Vėlgi – truputį patyrusiems vartotojams šio plugino tikrai neprireiks, tačiau, jei esate naujokas ir nenorite lysti į sistemos vidurius, bet norite pakeisti favicon arba suteikti galimybę paprastam vartotojui ją pasikeisti be Jūsų pagalbos, šis pluginas Jums pravers.
 
Quick Adsense
Nuoroda: http://wordpress.org/extend/plugins/quick-adsense/
Greitas ir lengvas ad sense reklamos administravimas Jūsų puslapyje. Random atvaizdavimas ir kitos funkcijos tikrai palengvins Jūsų gyvenimą ir papildys piniginę.
 
Blog Protector – Protect Your Content
Nuoroda: http://wordpress.org/extend/plugins/blog-protector/
Nors aš manau, jog internete turinys turi būti atviras, tačiau tiems, kurie savo turinį nori apsaugoti – pateikiame blog protector.
Pluginas atjungia tokias funkcijas kaip teksto žymėjimas ir antras pelės mygtuko apspaudimas.
 
WordPress Portfolio Plugin (WP Portfolio)
Nuoroda: http://wordpress.org/extend/plugins/wp-portfolio/
Lengvas portfolio administravimas.
 
WordPress Importer
Nuoroda: http://wordpress.org/extend/plugins/wordpress-importer/
Importuoja postus, puslapius, komentarus, custom , meta fieldus, kategorijas, tagus, taksonomijas ir autorius iš kito wordpress blogo.
 
WP-Polls
Nuoroda: http://wordpress.org/extend/plugins/wp-polls/
Norite surengti apklausą savo wordpress svetainėje? Šis pluginas Jums padės! Paprastas ir greitas.
 
WordPress Mobile Pack
Nuoroda: http://wordpress.org/extend/plugins/wordpress-mobile-pack/
Leis Jūsų svetainei atrodyti geriau mobiliuosiuose prietaisuose.
Galimybės:
Switchas tarp desktop ir mobile svetainės versijų.
Standartinė tema mob. Įrenginiams.
Didelės pritaikomumo galimybės.
Mobiliems įrenginiams pritaikyta admin panelė.
Barcode widgetas
Mobilie adsense widgetas
Ir t.t.
 
NextGen gallery
Nuoroda: http://wordpress.org/extend/plugins/nextgen-gallery/
Pats geriausias albumų / galerijų pluginas wordpressui. Draugauja su begale pluginų, yra pastoviai atnaujinamas, palaiko multilanguage, turi nemažai papildomų praplėtimų ir t.t.
 
Viper’s Video Quicktags
Nuoroda: http://wordpress.org/extend/plugins/vipers-video-quicktags/
Įkeliant video, tag‘us šis pluginas supildys pats, automatiškai.
Palaiko:
 YouTube (including playlists)
 Google Video
 DailyMotion
 Vimeo
 Veoh
 Viddler
 Metacafe
 Blip.tv
 VideoPress aka WordPress.com Video NEW!
 Flickr videos
 Spike.com/IFILM
 MySpaceTV
 
WordPress Related Posts Yet Another Related Posts Plugin
Nuoroda: http://wordpress.org/extend/plugins/yet-another-related-posts-plugin/
Atvaizduoja susijusius postus.
Universalus ir konfigūruojamas algoritmas, kuris peržvelgia postų antraštes, tagus ir kategorijas, bei pagal YARPP apskaičiuoja sutapimo „rezultatą“.
Pluginas draugauja su kešu, bei turi keletą kitų gerų savybių.
 
Autolink URI
Nuoroda: http://wordpress.org/extend/plugins/sem-autolink-uri/
Paverčia tekstą, kuris turi pradžią http:// į nuorodą automatiškai.
 
WordPress Firewall 2
Nuoroda: http://wordpress.org/extend/plugins/wordpress-firewall-2/
Stebi užklausas ir apsaugo sistemą nuo atakų.
 
Zemanta
Nuoroda: http://wordpress.org/extend/plugins/zemanta/
Rašant wordpresse, zemanta siūlo paveiksliukus, video, nuorodas ir seo optimizuotus tag‘us su Jūsų susijusiu turiniu.
Tikrai labai patogus content sugestion engine‘as, padedantis tiems, kurie daug rašo ir nori rašyti kokybiškai.
Plačiau: gamintojo saite ir http://en.wikipedia.org/wiki/Zemanta
 
All in One SEO Pack
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-seo-pack/
Pats geriausias seo pluginas wordpress sistemai. Palaiko custom post type, kanonines nuorodas, turi palaikyma e-commerce pluginams, meta tagų automatinis generavimas ir begalės kitų funkcijų.
 
Qtranslate
Nuoroda: http://wordpress.org/extend/plugins/qtranslate/
Tiesiog, pats geriausias sprendimas tada, kai reikia svetainės keliomis kalbomis. Draugauja su begale pluginų.
 
FancyBox for WordPress
Nuoroda: http://wordpress.org/extend/plugins/fancybox-for-wordpress/
Lengvesnis nei lightbox, bet toks pat gražus.

Šaltinis: http://www.gdgroup.lt/blog/naudingi-wordpress-pluginai/
 
Kol kas pateiksiu greitą, virš 60 naudingų wordpress pluginų sąrašą.
 
Pluginus atrinkau dirbdamas su wordpress sistema, stengiausi atsižvelgti į pluginų “gerumą” pagal jų programinę dalį, lengvą themeing’ą ir puikų savo darbo atlikimą.
 
Na ką, pradedam!
WordPress SEO by Yoast
Nuoroda: http://wordpress.org/extend/plugins/wordpress-seo/
Vienas iš geresnių seo optimizacijai skirtų pluginų. Leidžia redaguoti postų title ir meta description reikšmes, yra pilnai kanonizuotas, turi integruotus breadcrumb‘us, gali sudaryti xml sitemapus, rss patobulinimus ir keletą kitų funkcijų. Tai toks seo pluginas, kuris atlieka daug veiksmų, jei reikia būtent tokio ir dėl tam tikrų priežasčių negalite naudoti specializuotų pluginų – šis bus pats tas.
 
Booking Calendar
Nuoroda: http://wordpress.org/extend/plugins/booking/
Booking calendar Jums labai pravers, jei užsiimate nuoma ar kita sritimi, kuriai reiktų įskiepio „Booking calendar“.
Lankytojai, šio plugin‘o pagalba, galės tikrinti objektų prieinamumą tam tikru metu, vartotojai galės vykdyti rezervaciją. Klientai gali registruotis vyksiantiems renginiams. Taipogi, galima įdiegti papildomą atsiskaitymo modulį ir leisti vartotojams susimokėti iškart.
Įskiepis ganėtinai lankstus ir jį galima pritaikyti kitoms reikmėms.
Demonstraciją rasite čia: http://onlinebookingcalendar.com/demo/
Galimybės:
Rezervacija, pasirenkant norimą datą
Priminimai el. paštu, tiek administratoriui, tiek vartotojams.
Patogi vartotojo sąsaja.
Kalendoriaus widget‘as.
Palaiko kelias kalbas.
Ir t.t.
 
WP Minify
Nuoroda: http://wordpress.org/extend/plugins/wp-minify/
Įskiepis integruoja „Minify“ varikliuką, kuris optimizuoja JS ir CSS failų krovimo laikus puslapyje.
Puikiai tinka tiems, kurie kaunasi dėl optimizacijos.
Turi klaidų taisymo įrankius ir keletą konfigūracijos pasirinkimų.
 
Widget Logic
Nuoroda: http://wordpress.org/extend/plugins/widget-logic/
Įskiepis suteiks galimybę valdyti widget‘us, tiksliau jų logiką. Prie widgeto atsiras papildomas laukas, kuriame galima bus nustatyti, kuriame puslapyje jis gali atsirasti.
 
WPtouch
Nuoroda: http://wordpress.org/extend/plugins/wptouch/
Šis įskiepis padės optimizuoti Jūsų tinklalapį mobiliesiems įrenginiams.
 
WP-Cumulus
Nuoroda: http://wordpress.org/extend/plugins/wp-cumulus/
Teko matyti gražius tag cloud‘us kitose svetainėse, kur žodžiai sukasi 3d aplinkoje? Būtent šis pluginas ir atlieka šį darbą.
 
Social Slider
Nuoroda: http://wordpress.org/extend/plugins/social-slider-2/
Įskiepis atvaizduoja „išsiskleidžiantį“ box‘ą, kuriame pateikiami Jūsų socialinių tinklų profiliai ar nuorodos.
Pluginas tikrai atrodo neprastai ir su kai kuriais dizaino sprendimais, gali būti tikras išsigelbėjimas.
Įskiepio demonstracija: http://social-slider.com/demo/full.html
Palaikomi soc. Tinklai:
 RSS
 Newsletter
 Facebook
 Google+ (Google Plus)
 Twitter
 Blip
 Flaker
 Soup.io
 Buzz
 Sledzik
 Tumblr
 Spinacz
 GoldenLine
 LinkedIn
 Nasza Klasa
 NetworkedBlogs
 MySpace
 Orkut
 Grono
 FriendConnect
 FriendFeed
 Digg
 Wykop
 Kciuk
 Picasa
 Flickr
 Panoramio
 DeviantArt
 YouTube
 Vimeo
 IMDb
 Last.fm
 iSing
 Blip.fm
 Delicious
 Unifyer
 
Broken Link Checker
Nuoroda: http://wordpress.org/extend/plugins/broken-link-checker/
Kaip ir matosi iš pavadinimo – įskiepis skirtas stebėti „broken links“ svetainėje.
Stebi broken linkus į postus, puslapius, comentarus ir custom field‘us.
Aptinka neveikiančias nuorodas į paveikslėlius ir kitą media.
Perspėja Jus dashboard‘e ir emaliu.
Neleidžia paieškos varikliams followint broken linkų.
Įskiepis leidžia redaguoti nuorodas iškart, t.y. nereikia klaidžioti iki tam tikros vietos ir ieškoti broken linko.
 
TinyMCE Advanced
Nuoroda: http://wordpress.org/extend/plugins/tinymce-advanced/
Šis įskiepis, prideda 16 papildomų funkcijų į standartinį tinymce editorių.
Advanced HR, Advanced image, Advanced link, kontekstiniai meniu, šypsenėlės, laikas ir data, IESpell, sluoksniai, spausdinimas, search and replace funkcija, stailinimas, lentelės, matematikos formulių palaikymas ir t.t.
O prie viso šio gėrio – spellcheckas.
 
BackWPup
Nuoroda: http://wordpress.org/extend/plugins/backwpup/
Galimybės:
Duomenų bazės backupai
Wordpresso xml exportas
Duomanų bazės optimizacija
Duombazės patikra / taisymas
Failų backupas
Backupų archyvavimas
Backupų talpinimas įvairiuose šaltiniuose.
Multisite support‘as
 
WordPress Popular Posts
 
http://wordpress.org/extend/plugins/wordpress-popular-posts/
 
Plačiai konfigūruojamas plugin‘as, skirtas populiariausių post‘ų atvaizdavimui. Galima naudoti ir kaip šablono tag‘ą.
Galima nepriskirti kategorijų, palaiko shortcode‘us, template tag‘us, automatiškas atsinaujinimas.
 
wp-Typography
Nuoroda: http://wordpress.org/extend/plugins/wp-typography/
Super dalykas tiems, kas nori turėti dailią ir TAISYKLINGĄ tipografiją savo tinklalapyje.
 
CMS Tree Page View
Nuoroda: http://wordpress.org/extend/plugins/cms-tree-page-view/
Plugin‘as skirtas tiems, kurie pripratę prie klasikinių turinio valdymo sistemų atvaizdavimo.
Atvaizduoja jūsų tinklalapį hierarchiniu būdu, bei turi keletą papildomų funkcijų.
 
WP-Optimize
Nuoroda: http://wordpress.org/extend/plugins/wp-optimize/
Tai Duomenų bazės optimizacijos ir valymo įrankis.
Leidžia panaikinti postų revizijas, nepatvirtintus arba „šlamšto“ komentarus ir t.t.
Taipogi, leidžia pervardinti wordpress vartotojus.
Palaiko daugiakalbiškumą.
 
Sidebar Login
Nuoroda: http://wordpress.org/extend/plugins/sidebar-login/
Suteikia galimybę išvesti wordpress loginą per shorttag‘ą arba widget‘ą.
 
Contact Form 7
Nuoroda: http://wordpress.org/extend/plugins/contact-form-7/
Leidžia sudarinėti norimas formas.
Palaiko captcha, akismet, ajax ir t.t.
 
Fluency Admin
Nuoroda: http://wordpress.org/extend/plugins/fluency-admin/
Patobulinimas administratoriaus vartotojo sąsajai. Tab‘ai atskiriami skirtinga spalva, įvairios spalvų schemos, galima pridėti savo logotipą ir hotkey palaikymas norint prieiti atitinkamas sekcijas.
 
WP-PostRatings
Norite įdiegti post‘ų vertinimą į savo wordpress svetainę? Prašau 
Yra ajax palaikymas.
 
WordPress Content Slide
Nuoroda: http://wordpress.org/extend/plugins/content-slide/
Šaunus įskiepis, kuris leidžia Jums sudaryti content slaiderius su efektais. Turi begalę opcijų.
Pavyzdys: http://wptuts.info/wp-content-slide/
 
GD Star Rating
Nuoroda: http://www.gdstarrating.com/
Dar vienas, ypač galingas, postų, komentarų ir puslapių reitingavimo pluginas. Multilanguage palaikymas, suderinamumas su kešo pluginais, turi begalę tinkinimo galimybių.
 
WP No Category Base
Nuoroda: http://wordpress.org/extend/plugins/wp-no-category-base/
Greitai ir paprastai nuima /category/ nuo Jūsų postų.
 
WP-Paginate
Nuoroda: http://wordpress.org/extend/plugins/wp-paginate/
Atlieka paprastą funkciją – puslapiuoja ir tai atlieka gerai 
 
SexyBookmarks | email, bookmark, and share buttons
Nuoroda: http://wordpress.org/extend/plugins/add-to-any/
Populiarus ir dailiai atrodantis pluginas, skirtas Sharingui/Bookmarikinimui. Garantuoju, jog jį jau matėte.
 
PHP Code Widget
Turbūt dažnas iš mūsų pasigedo galimybės rašyti php kodą widgete. Šis pluginas suteiks šią galimybę.
 
Relevanssi – A Better Search
Nuoroda: http://wordpress.org/extend/plugins/relevanssi/
Praplečia standartinę wordpress sistemos paiešką.
Paieškos rezultatai patiekiami pagal didžiausią sutapimą, ne pagal datą.
Ieškoma „žodžio dalies“ sutapimų.
Pažymimi paieškos žodžiai rezultatuose.
Ir kitos funkcijos.
 
Twitter Widget Pro
Nuoroda: http://wordpress.org/extend/plugins/twitter-widget-pro/
Turbūt populiariausias Twitter widgetas wordpressui.
 
WassUp
Nuoroda: http://wordpress.org/extend/plugins/wassup/
Nebloga, google analytics alternatyva ir kas svarbiausia – real time trackingas.
 
Sharebar
Nuoroda: http://wordpress.org/extend/plugins/sharebar/
Pavadinimas daug pasako. Vienas iš geresnių savo srityje.
 
Search Everything
Nuoroda: http://wordpress.org/extend/plugins/search-everything/
Paieškos patobulinimas wordpress sistemai.
Paieškos rezultatų paryškinimas, ieško kiekviename puslapyje, tag‘e, taxonomijose, kategorijose, komentare, draftuose, excerptuose, atachmentuose, custom field‘uose, taipogi suteikiama galimybė neleisti prieiti paieškai prie tam tikrų resursų.
 
Role Scoper
Nuoroda: http://wordpress.org/extend/plugins/role-scoper/
Labai šaunus wordpress pluginas, skirtas vartotojų teisėms sistemoje redaguoti.
 
Wordbooker
Nuoroda: http://wordpress.org/extend/plugins/wordbooker/
Pats geriausias ir lengviausiai konfigūruojamas pluginas, skirtas tam, jog Jūsų blogo įrašai atsirastų ir facebook erdvėje.
 
Disqus Comment System
Nuoroda: http://wordpress.org/extend/plugins/disqus-comment-system/
Viena geriausių alternatyvų standartinei wordpress komentavimo sistemai.
 
Really Simple CAPTCHA
Nuoroda: http://wordpress.org/extend/plugins/really-simple-captcha/
Pavadinimas – daug pasako. Gal ir ne pats saugiausias, tačiau labai paprastai valdomas captcha pluginas.
 
Secure WordPress
Nuoroda: http://wordpress.org/extend/plugins/secure-wordpress/
Didelis saugumo paketas wordpress turinio valdymo sistemai.
Trumpai: nepateikia error informacijos prisijungimo lange, prideda index.php failą pluginų direktorijoje, neatvaizduoja wp versijos ir dalies kitos, naudingos įsilaužėliui informacijos, blokuoja „blogas“ užklausas, kurios gali pakenkti wordpress sistemai.
 
BulletProof Security
Nuoroda: http://wordpress.org/extend/plugins/bulletproof-security/
Dar vienas „must have“ saugumo pataisymas wordpress sistemai. Apsaugo nuo xss, csrf, base64_encode, sql injekcijų ir kitų „laužimo“ būdų. Apsaugo wp-config.php, bb-config.php, php.ini, php5.ini, install.php ir readme.html su .htaccess failus, bei begalės kitų pataisymų.
 
Dynamic Content Gallery
Nuoroda: http://wordpress.org/extend/plugins/dynamic-content-gallery-plugin/
Šaunus pluginas, leidžiantis išburti slaiderį, su paskutiniais ir featured postais.
 
WP to Twitter
Nuoroda: http://wordpress.org/extend/plugins/wp-to-twitter/
Šio plugino Jums prireiks, jei norėsite wordpress įrašus postinti ir twitteryje.
 
Ajax Event Calendar
Nuoroda: http://wordpress.org/extend/plugins/ajax-event-calendar/screenshots/
Ajax technologija besiremiantis kalendorius, su begale funkcijų. Plačiau – gamintojo puslapyje.
 
SEO Friendly Images
Turite daug paveikslėlių, bet ne visiems priskyrėte title ir alt žymes? Nepergyvenkite, šis pluginas Jums padės tai sutvarkyti.
Tiek kodas tampa validus, tiek puslapis tampa daugiau „seo friendly“
 
Link Library
Nuoroda: http://wordpress.org/extend/plugins/link-library/
Tiems, kas „stato“ didelius nuorodų sąrašus, šis pluginas tikrai bus naudingas.
 
After the Deadline
Nuoroda: http://wordpress.org/extend/plugins/after-the-deadline/
Spellcheckeris wordpressui. Įdomu dar ir tai, jog naudoja AI rašybai tikrinti.
 
WP Security Scan
Nuoroda: http://wordpress.org/extend/plugins/wp-security-scan/
Tikrina Jūsų wordpress svetainės saugumą. Pateikia pažeidžiamumus ir galimus pataisymus.
Tikrina: slaptažodžius, failų permissionus, duombazės saugumą, versijos slėpimą, wordpress admin dalį ir t.t.
 
Shortcode Exec PHP
Nuoroda: http://wordpress.org/extend/plugins/shortcode-exec-php/
Leis vykdyti php kodą postuose, puslapiuose ir t.t. naudojant shortcodus. Turi įdiegtą sintaksės spalvinimą. Prisibijant dėl saugumo, tai shortcodus galės naudoti tik administratoriai.
 
Easing Slider
Nuoroda: http://wordpress.org/extend/plugins/easing-slider/
Tikria gražus slaideris, su puikiu css3 apipavidalinimu.
 
AdRotate
Nuoroda: http://wordpress.org/extend/plugins/adrotate/
Patogiausias ir turbūt geriausias pluginas reklamai administruoti Jūsų wordpress svetainėje. Patogus, lankstus, paprastas ir galingas. Ko daugiau reikia?
Turi integruotą šiokią tokią statistiką, palaiko shortcodus, turi reklamos „pasibaigimo terminą“ ir begalę kitų galimybių.
 
Exploit Scanner
Nuoroda: http://wordpress.org/extend/plugins/exploit-scanner/
Ieško blogų gyventojų Jūsų wordpress svetainėje  Pats nieko netrina, tiesiog informuoja administratorių apie galimas grėsmes.
Ieškomi neįprasti pluginai, duombazės įrašai, failų vardai ir t.t.
 
WordPress Video Plugin
Nuoroda: http://wordpress.org/extend/plugins/wordpress-video-plugin/
Leidžia paprastai embeddinti video medžiagą į wordpress svetainę.
Palaiko labai daug šaltinių.
 
Facebook likes you!
Nuoroda: http://wordpress.org/extend/plugins/facebook-likes-you/
lengvai ir greitai diegiamas like/share mygtukas wordpress‘ui.
 
Configure SMTP
Sukonfigūruoja smtp nustatymus wordpressui. Be šios konfigūracijos kai kurie pluginai gali veikti nekorektiškai (dažniausia tai būna email notificationai ir newsletter pluginai)
 
Facebook Comments for WordPress
Nurooda: http://wordpress.org/extend/plugins/facebook-comments-for-wordpress/
Lengvai integruojami ir konfigūruojami facebook tipo komentarai wordpress sistemai. Galimybė sinchronizuoti wordpress ir facebook komentarus.
 
Newsletter
Nuoroda: http://wordpress.org/extend/plugins/newsletter/
Naujienlaiškis. Nemokamai ir paprastai.
 
WP-Cufon
Nuoroda: http://wordpress.org/extend/plugins/wp-cufon/screenshots/
Patyrusiems temų developeriams šio plugino tikrai neprireiks, bet tiems, kurie yra mažiau pažengę – šis pluginas tikrai pravers. Pasirinkite ir lengvai embeddinkite bent kokį šriftą iš cufon kolekcijos.
 
All In One Favicon
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-favicon/
Vėlgi – truputį patyrusiems vartotojams šio plugino tikrai neprireiks, tačiau, jei esate naujokas ir nenorite lysti į sistemos vidurius, bet norite pakeisti favicon arba suteikti galimybę paprastam vartotojui ją pasikeisti be Jūsų pagalbos, šis pluginas Jums pravers.
 
Quick Adsense
Nuoroda: http://wordpress.org/extend/plugins/quick-adsense/
Greitas ir lengvas ad sense reklamos administravimas Jūsų puslapyje. Random atvaizdavimas ir kitos funkcijos tikrai palengvins Jūsų gyvenimą ir papildys piniginę.
 
Blog Protector – Protect Your Content
Nuoroda: http://wordpress.org/extend/plugins/blog-protector/
Nors aš manau, jog internete turinys turi būti atviras, tačiau tiems, kurie savo turinį nori apsaugoti – pateikiame blog protector.
Pluginas atjungia tokias funkcijas kaip teksto žymėjimas ir antras pelės mygtuko apspaudimas.
 
WordPress Portfolio Plugin (WP Portfolio)
Nuoroda: http://wordpress.org/extend/plugins/wp-portfolio/
Lengvas portfolio administravimas.
 
WordPress Importer
Nuoroda: http://wordpress.org/extend/plugins/wordpress-importer/
Importuoja postus, puslapius, komentarus, custom , meta fieldus, kategorijas, tagus, taksonomijas ir autorius iš kito wordpress blogo.
 
WP-Polls
Nuoroda: http://wordpress.org/extend/plugins/wp-polls/
Norite surengti apklausą savo wordpress svetainėje? Šis pluginas Jums padės! Paprastas ir greitas.
 
WordPress Mobile Pack
Nuoroda: http://wordpress.org/extend/plugins/wordpress-mobile-pack/
Leis Jūsų svetainei atrodyti geriau mobiliuosiuose prietaisuose.
Galimybės:
Switchas tarp desktop ir mobile svetainės versijų.
Standartinė tema mob. Įrenginiams.
Didelės pritaikomumo galimybės.
Mobiliems įrenginiams pritaikyta admin panelė.
Barcode widgetas
Mobilie adsense widgetas
Ir t.t.
 
NextGen gallery
Nuoroda: http://wordpress.org/extend/plugins/nextgen-gallery/
Pats geriausias albumų / galerijų pluginas wordpressui. Draugauja su begale pluginų, yra pastoviai atnaujinamas, palaiko multilanguage, turi nemažai papildomų praplėtimų ir t.t.
 
Viper’s Video Quicktags
Nuoroda: http://wordpress.org/extend/plugins/vipers-video-quicktags/
Įkeliant video, tag‘us šis pluginas supildys pats, automatiškai.
Palaiko:
 YouTube (including playlists)
 Google Video
 DailyMotion
 Vimeo
 Veoh
 Viddler
 Metacafe
 Blip.tv
 VideoPress aka WordPress.com Video NEW!
 Flickr videos
 Spike.com/IFILM
 MySpaceTV
 
WordPress Related Posts Yet Another Related Posts Plugin
Nuoroda: http://wordpress.org/extend/plugins/yet-another-related-posts-plugin/
Atvaizduoja susijusius postus.
Universalus ir konfigūruojamas algoritmas, kuris peržvelgia postų antraštes, tagus ir kategorijas, bei pagal YARPP apskaičiuoja sutapimo „rezultatą“.
Pluginas draugauja su kešu, bei turi keletą kitų gerų savybių.
 
Autolink URI
Nuoroda: http://wordpress.org/extend/plugins/sem-autolink-uri/
Paverčia tekstą, kuris turi pradžią http:// į nuorodą automatiškai.
 
WordPress Firewall 2
Nuoroda: http://wordpress.org/extend/plugins/wordpress-firewall-2/
Stebi užklausas ir apsaugo sistemą nuo atakų.
 
Zemanta
Nuoroda: http://wordpress.org/extend/plugins/zemanta/
Rašant wordpresse, zemanta siūlo paveiksliukus, video, nuorodas ir seo optimizuotus tag‘us su Jūsų susijusiu turiniu.
Tikrai labai patogus content sugestion engine‘as, padedantis tiems, kurie daug rašo ir nori rašyti kokybiškai.
Plačiau: gamintojo saite ir http://en.wikipedia.org/wiki/Zemanta
 
All in One SEO Pack
Nuoroda: http://wordpress.org/extend/plugins/all-in-one-seo-pack/
Pats geriausias seo pluginas wordpress sistemai. Palaiko custom post type, kanonines nuorodas, turi palaikyma e-commerce pluginams, meta tagų automatinis generavimas ir begalės kitų funkcijų.
 
Qtranslate
Nuoroda: http://wordpress.org/extend/plugins/qtranslate/
Tiesiog, pats geriausias sprendimas tada, kai reikia svetainės keliomis kalbomis. Draugauja su begale pluginų.
 
FancyBox for WordPress
Nuoroda: http://wordpress.org/extend/plugins/fancybox-for-wordpress/
Lengvesnis nei lightbox, bet toks pat gražus.

apmaudu skaityti ir žiūrėti į tuos žmones, kurie šiuo parsidavėliu tiki...

koks klausimas, toks komentaras. nemanai?

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)

Sveiki,
Nesenai publikavau savo straisnį web optimizacijos tema, anglų kalba.
Manau, jog nuodėmė būtų nepasidalinti juo kartu su Jumis, juo labiau, jog turiu jo draft'ą lt kalba :)
Tikrojo straipsnio adresas: http://bit.ly/1mLtvj9
 
Visais laikais žmones žavėjo greitis. Greičiausia mašina, greičiausias bėgikas, greičiausias žveris, greičiausias procesorius... Greitis, tai magija, kuri iš pradžių atrodo vulgari ir paprasta, tačiau, kad taptum tikrai greitu, visose srityse turi įdėti nemažai darbo. Kaip ir vaikinas, laisvalaikiu paspardantis kamuolį su draugais futbolo stadione netaps profesionaliu futbolininku, uždirbančiu milijonus, taip ir Jūsų programinė įranga netaps ypatingai greita be tam tikrų optimizacijos procesų.
Jau tampa aišku, jog web technologijų srityje responsive dizainas yra „must have“. Ir ne be reikalo, nes mobiliųjų įrenginių skaičius, kurie naudojasi mobiliu internetu, pasaulyje jau pasiekė penktadalį visos populiacijos, tad web‘ui tenka taikytis prie įvairių įrenginių (šaltinis: http://www.dekh.com/blog/post/the-mobile-web-will-it-replace-desktop-use). Prisitaikymas kainuoja. Daugiausia kenčia našumas, kurį galėčiau išskirti į tris dalis: „loado“ (krovos), grafinį (rendering) ir nematomoji dalis – programavimo našumas (executing). Apie našumo svarbą verslui plačiau galite pasiskaityti čia: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ . Rezultatai gana įdomūs – 1 papildoma sekundė kainuos Jums 7% konversijų.
Šiame straipsnyje pabandysiu aptarti pagrindines klaidas ir duoti gerų patarimų, kaip svetainę padaryti greitesnę, tačiau prieš pradedant, norėčiau supažindinti su nerašytomis taisyklėmis, kada web aplikacija gali būti laikoma „greita“:
• Time To First Byte: 200ms - 350ms
• DOM Content Loaded: 1000ms - 2000ms
• JS Load Event Fired: 900ms - 2200ms
• Total Download Size: 1MB - 2MB
• DNS Lookup: 10ms - 20ms
• HTTP Requests per page: 50 - 75
Tad, pradedam:
 
Sulieknėk greitai arba kai reklama tampa realybe
Tikriausia esate matę tas reklamas, kuriose moteris numeta 15 kilogramų per tris dienas naudodama stebuklingus patarimus? Ši reklama gali būti teisinga web optimizacijos atveju. Jūs galite turėti didelę aplikaciją, su daug įvairiausio kodo, tačiau dažniausia turėsite bėdų su paveiksliukais, kurie kels krovos laiką, o jeigu naudosite dar ir transparent png – tai bus didelis galvos skausmas... iki tol, kol naudosite reikiamus įrankius ir mokėsite juos organizuoti.
• Visų pirma rekomenduočiau tinkamai paruošti paveiksliukus. Dažniausia girdžiu, jog png optimizuoti beprasmiška, nes labai kenčia kokybė, tačiau geresnio įrankio, nei daug kam nežinomas, kuklus ir nemokamas „Color quantizer“ (http://www.softpedia.com/get/Multimedia/Graphic/Graphic-Others/Color-quantizer.shtml) – neteko sutikti, o ir problemas jis sprendžia puikiai. Yra tekę matyti pavyzdžių, kai transparent png neoptimizavusios svetainės, turėjo vieną, riebų paveikslėlį, kurio dydis viršijo pusę megabaito. Su šiuo įrankiu tokį paveikslėlį nesunkiai sumažinsite bent kelis kartus, o kokybės skirtumas bus sunkiai įžvelgiamas. Tiesa, gradient paveikslėlių optimizuoti nepatariu.
Keletas PNG optimizacijos pavyzdžių:
1. http://www.htc.com/www/smartphones/ - atvaizduojama 12 telefonų paveiksliukų ir nuo kiekvieno vidutiniškai galima sutaupyti 20KB. 12 * 20KB = 140KB
2. Vienas iš awwwards nugalėtojų: http://epic.net/mmxiv/
Suoptimizavus titulinio puslapio png laimima ~75KB.
3. Neabejotinas nugalėtojas: http://www.olympicstory.com/ - 190KB loss nuo vieno paveiksliuko.
 
• Sprite‘ai – naudokite sprite‘us krauti paveikslėliams. Tai kardinaliai sumažins requestų skaičių, kas žymiai pagreitins bendrą svetainės krovimasi. Automatizuotam sprite‘ų generavimui mano kolega, Paul Gabronis yra parašęs SASS biblioteką (https://github.com/paulgabronis/Easy-Sprites ), kuri leis pilnai automatizuoti sprite‘ų generavimą ir pagreitins ne tik krovimosi laiką, bet kartu ir leis pagreitinti gamybos procesą.
Drąsiausieji gali pabandyti netgi SVG sprite‘us: http://css-tricks.com/svg-sprites-use-better-icon-fonts/
• Labai dideliems background images naudokite jpg progressive arba preloaderius, tai leis neturėti didelių pokyčių svetainėje ir neprivers vartotojo ilgai laukti.
• Jei dėl vienokių ar kitokių priežasčių negalite naudoti sprite paveiksliukų, galite naudoti inline base64 paveiksliukus. Sumažinsite request skaičių, tačiau patys paveiksliukai gali būti šiek tiek didesni, nei įprasto formato (prieš versdami į base64 formatą, patariu juos optimizuoti).
Jeigu naudojate SASS + Compass, tai padaryti galite labai lengvai:

.test-class { background:inline-image("test-image.png") no-repeat 0 0; }
Jeigu naudojate CSS ir koduojate su Visual Studio, Jums padės šis papildinys:
http://visualstudiogallery.msdn.microsoft.com/a56eddd3-d79b-48ac-8c8f-2db06ade77c3
CSS optimizacija
1. Magiškasis Transform:translateZ(0). Naršyklių kurėjai dažnai nesutaria įvairiausiais klausimais, tad nieko nuostabaus, jog nuomonės dėl gpu akseleracijos naršyklėse skirtingos stovyklose išsiskyrė. Jeigu FireFox kūrėjai akseleruoja viską, kas pasitaikė po ranka, webkit varikliuko kurėjai davė laisvę pasirinkti. Ir tai yra gana logiška, nes:
a) Suteikiama resursų skirstymo laisvė
b) Leidžia taupyti įrenginio bateriją
Būtent minėtasis translateZ(0) leis „paforsinti“ gpu akseleraciją elementui, tačiau būkite atsargūs, kadangi tai nėra galutinis sprendimas ir ateityje planuojama įvesti tam dedikuotą css property: „will-change“. Daugiau pasiskaityti galite čia: http://tabatkins.github.io/specs/css-will-change/ .
2. CSS animacijos/tranzicijos. Stenkitės kiek įmanoma daugiau javascript animacijų pakeisti css animacijomis/tranzicijomis, ypač kai Jūs turite animuoti kelis elementus vienu metu.
Paskaityti apie tai ir pajusti skirtumą galite čia: http://css3.bradshawenterprises.com/blog/jquery-vs-css3-transitions/
Tik nepamirškite, jog FireFox naršyklė sunkiai susitvarko su css animacijomis/tranzicijomis, kai vienu metu animuojama daugiau nei 150 elementų.
3. Stenkitės optimizuoti „brangius“ css properties. Tokie stiliai kaip box-shadow, gradient, border-radius, outline, opacity turi įdomių savybių renderinant ir gali žymiai sulėtinti Jūsų UI.
Keli pavyzdžiai, kaip renderinamas box shadow:
Imkime tris scenarijus (A, B ir C), kai:
A - elementas turi tik box shadow.
B - kai turi tik border radius
C - kai turi abu šiuos stilius.
 
Kaip pasikeis renderinimo laikas?
A renderinimo laikas 0,19ms
B renderinimo laikas – 0,16ms
C renderinimo laikas – 0,73ms
 
Dar vienas įdomus testas palyginimui, box-shadow reikšmės
box-shadow: 1px 1px = 0.28ms
box-shadow:1px 2px 3px red = 0.16ms
box-shadow: 1px 2px 3px 4px = 0.76ms
 
Tai jokiu būdų nereiškia, jog reikia atsisakyti šių stilių naudojimo, tačiau jei iškyla tam tikros bėdos su UI greičiu, šią informaciją svarbu žinoti.
Plačiau šia tema: http://nerds.airbnb.com/box-shadows-are-expensive-to-paint/
 
4. Naudokite automatizuotus testus, kad aptiktumėte blogiausiai performinančius selectorius. Vienas naudingesnių testų, kuris leis nustatyti blogiausiai peforminančias klases scrollinant:
http://andy.edinborough.org/CSS-Stress-Testing-and-Performance-Profiling
Keep things simple
• Kurkite gracefully degrading tinklalapius. Galbūt metas atsisakyti javascript select‘o librario, o checkbox‘us ir radio buttonus sustailinti su plain css‘u? Taikydamiesi prie mažumos browserių, tokių kaip ie8 ar žemiau, palaikydami 2 metų senumo opera naršykles Jūs tiesiog apsunkinate tiek savo darbą, tiek svetainės performance, o lopomos vietos vis sunkėja, kol tampa nebepakeliamos ir tampa visiškai nebenaudojamos. Taip, IE8 dar gana plačiai naudojamas, tačiau 1-5% vartotojų tikrai nenusimins, jog tam tikri elementai tiesiog turi defaultinį stilių, o tinkalapis veikia nepalyginamai greičiau.
Custom select: http://jsfiddle.net/TKE6g/
Custom checkbox and radio: http://jsfiddle.net/t7jCL/
• Nepersistenkite su Web font‘ų įvairove. Pasirinkite tik būtinus fontus ir jų variacijas ir nekraukite nenaudojamų, tai leis pastebimai sumažinti krovos laiką.
 
Optimization Essentials
Jeigu norite, jog web aplikacija veiktų greitai, Jūs tiesiog privalote:
1. Minifikuokite CSS failus ir sumažinkite jų kiekį iki minimumo.
2. Jokiu būdu nenaudokite @import css failuose, juo labiau, kai dabar galite lengvai failus importuoti SASS pagalba.
3. Javascript failus krauti tik prieš užsidarant body tag‘ui ir šios taisyklės galima nepaisyti tik labai išskirtiniais atvejais
4. Minifikuokite javascript failus ( Automatizuotam minifikavimui galite naudoti: https://www.npmjs.org/package/grunt-contrib-uglify )
5. Naudokite „up to date“ jquery versiją kartu su jquery migrate, tai leis sėkmingai palaikyti kodą, rašytą su senomis jquery versijomis, tačiau kartu veiks sparčiau ir pati biblioteka užims žymiai mažiau vietos.
6. Kraukite pakopinius stilius tik head dalyje ir kaip įmanoma anksčiau
7. Naudokite resursus iš CDN (Content Delivery Network). Jei naudojate require.js, cdn naudoti galite taip:

requirejs.config({ baseUrl: "Scripts", paths: { /* Load jquery from google cdn. On fail, load local file. */ 'jquery': ['//ajax.googleapis.com/ajax/libs/jquery/2.0.3/jquery.min', 'libs/jquery-min'], } });
8.
MISC optimizacija
• Dažnai socialinių tinklų ikonos tinklalapyje nugrūdamos į footer dalį. Ar jos tikrai vertos savo vietos po saule? Spręsti Jums, o perskaityti ką galite sutaupyti jų atsisakydami, galite čia:
http://zurb.com/article/883/small-painful-buttons-why-social-media-bu
http://lastdropofink.co.uk/market-places/the-true-cost-of-adding-social-buttons/
• Vietoje strandatinio „on resize” jquery event’o, naudokite šį: http://www.paulirish.com/2009/throttled-smartresize-jquery-event-handler/
Praktinis pavyzdys: http://jsfiddle.net/c9Dfm/
• Iframe – didelis galvos skausmas, jeigu jame pateikinėjate informaciją iš nutolusių šaltinių. Tokių iframe krovimas kaip youtube, vimeo, gali kardinaliai pakeisti Jūsų krovos laikus ir window loaded, bei js first event fire eventų gali tekti laukti labai ilgai. Pateiktas snippet‘as padės Jums išvengti šių bėdų:
 

<iframe width="780" height="440" data-src="//player.vimeo.com/video/54638896" frameborder="0" webkitallowfullscreen mozallowfullscreen allowfullscreen class="vimeo-video"></iframe> $(document).ready(function () { $('iframe').each(function() { $(this).attr('src', $(this).data('src')); }); });
• Tiems kam patinka skaičiai – neprošal perskaityti šį straipsnį: https://developers.google.com/speed/articles/web-metrics
 
Pabaigai – palyginimas
 
Pabaigai - tiesiog norėčiau palyginti dvi visiškai paprastas aplikcijas. Viena aplikacija bus be optimizacijos, kita – su ir palyginsime jų performance.
Parašius tik labai paprastutę aplikaciją ir pritaikius paprasčiausius optimizacijos veiksmus, mes gavome tokius rezultatus (testuota esant prisijungus prie mobilaus interneto ir išvestas vidurkis iš 10 kartų):
 
1. Neoptimizuota versija:
Užklausų skaičius: 88
Dom ready event fire: 2,24sec
Window loaded event: 8,21sec
Data transfered: 3,2MB
 
2. Minimaliai optimizuota versija
Užklausų skaičius: 74
Dom ready event fire: 1,07sec
Window loaded event: 6,63sec
Data transfered: 2,2MB
 
 
Tai tiek :) tikiuosi, jog patiko :)