Hraði er nothæfi.
Til að segja það nákvæmara er vefsíðan hraði mikilvægur hluti notagildi. Mest leiðandi tengillinn sem alltaf hefur verið skapaður af huga mannsins, gerir þig ekki gott ef notandinn er laus við þann tíma sem hann hleður.
Það er það. Greinin er gerð ... Allt í lagi, það er í raun mikið meira að segja, en sú fyrsta setning er um helmingur af því sem þú þarft að vita. Við verðum að gera vefsíður okkar hratt.
Ég gæti notað mikið af frábærum tjáningum eins og "flassandi hratt" eða "mjög hratt" eða jafnvel "hraðar en hraðakstur" en þeir myndu vera ófullnægjandi. Það er einfaldara að segja að það sé ekki eins og "of hratt".
Við þurfum að taka eina mínútu til að tala um hvers konar hraða ég er að vísa til. Í stuttu máli, allt hraða. Nánar tiltekið, þrjár tegundir af hraða:
Þetta væri sá tími sem það tekur fyrir allar upplýsingar að hlaða niður á tæki notenda. Þetta hefur fyrst og fremst áhrif á hraða nettengingarinnar og raunveruleg stærð skráanna.
Þú getur ekki gert mikið um tenginguna, en þú getur gert mikið um skráarstærð.
Eftir að skrárnar þínar hafa verið hlaðið niður verða þær að vera unnar og gefnar af vafranum. Öll þessi vinnsla og flutningur hefur áhrif á hversu vel kóðinn þinn var skrifaður og allt annað sem gerist á símanum notanda, töflu eða fartölvu / skrifborð.
Það eina sem þú getur stjórnað er eigin kóði, en það skiptir miklu máli.
Og þá er sálfræðileg þáttur. Hratt vefsíður geta líkt og líkt og þeir eru að fara hægt. Hægt er að gera hægar vefsíður til að líta örlítið betur með dómstólum á sumum bragðarefur.
Þessi hluti snýst allt um að læra notandann og láta þá vita hvað er að gerast þegar þeir hafa samskipti við vefsvæðið þitt eða app.
Þú þarft að fylgjast með öllum þremur þáttum hraða vefsíðunnar til að láta síðuna þína líða eins og það gengur hratt. Og því stærri sem vefsvæðið er, því meira sem það er að hámarka.
Við skulum byrja, þá.
Margir sinnum, sérstaklega á þeim minni, tilraunaverkefnum sem ég elska svo mikið, finnst mér ég eyða meiri tíma í CSS en allir aðrir hluti kóðans. Oft er líka meira CSS skrifað en HTML eða JavaScript. Þannig að það er vísbending um hversu mikið CSS þín getur haft áhrif á skráarstærð.
Þá er auðvitað málið um hversu hratt vefsvæðið þitt muni reka á skjáborðinu, fartölvu, töflu eða sími notanda. Mikið af raunverulegu "starfi" eða flutningur á vefsíðu er gert af hugbúnaðinum, með smá hjálp frá GPU.
Það gæti hlaða hratt, en flettu hægt. Leiðin sem CSS þín er skrifuð hefur bein áhrif á hve hratt tiltekið tæki er í raun hægt að birta vefsíðu þegar skrárnar hafa verið hlaðið niður.
Þegar hagræðing á vefsíðu til að keyra hraðar er CSS venjulega góð staður til að byrja.
CSS sem situr í stílblaðinu þínu og gerir ekki neitt gerir skrárnar þínar óþörfu stærri. Allt í lagi, þannig að þetta gæti verið eins og ekki-brainer; en það gerist samt sem áður best.
Þú tekur út efni og gleymir að eyða gamla CSS. Þú breytir flokki eða auðkenni í gámagrein og gleymir að eyða gamla CSS. Þú skrifar nokkrar CSS, átta sig á því að það er betri leið, og gleymdu ... þú færð það.
Kasta mörgum framhliðshönnuðum í blandaðan og þú hefur fengið uppskrift að ómeðhöndluðum, óviðráðanlegum stílsíðu eða safni þeirra ef þú ert ekki varkár. Ónotaður kóða hægir á síðu hleðslu í krafti mjög tilveru hans sem gögn. Það hægir á þróun vegna þess að það getur ruglað fólki að lesa stíllinn.
Það getur líka þýtt hægari flutningstíma, því það er bara meira CSS fyrir vafrann að líta í gegnum meðan það passar öllum CSS við viðeigandi HTML þætti þess.
Hvort sem þú skoðar og eyðir öllum gömlum CSS handvirkt, notaðu sjálfvirkar verkfæri til að hjálpa þér að finna ónotaðar CSS valsmenn eða bara eyða hlutum af handahófi þar til eitthvað brýtur (gerðu það ekki), þú þarft að taka þessa gamla kóða út.
Talandi um hvernig vafrinn passar við CSS með viðeigandi HTML, það er kominn tími til að líta á CSS selectors. Mikið hefur verið skrifað um hvaða seljendur gera hraðast, hverjir eru hægir, hvort sem þú ættir að trufla hægfara þá yfirleitt og svo framvegis.
Vandamálið er að mikið af þessum upplýsingum er gamalt. Aftur á árinu 2000 skrifaði Dave Hyatt (verktaki sem starfar á Safari, og virkur meðlimur CSS vinnuhóps W3C) þetta:
Dásamleg sannleikur um CSS3 vali er að þeir ættu ekki að nota í raun ef þú ert annt um árangur á síðunni.
Ef þú skoðar skjalið Þessi vitneskja kom frá, þú munt sjá að hann var að tala um valmenn eins og : fyrsta barn og aðrar gervi-valarar. Og hann var rétt.
Hann er ennþá; en á síðustu fimmtán árum hafa tölvur þróað svolítið. Nú á dögum þarf að auka viðhöfnina sem krafist er af tölvunni til að láta þessi CSS ekki sjást af einhverjum nema þeim sem nota ódýrasta ódýran farsíma.
Það er áhyggjuefni í sjálfu sér, svo reyndar mun það ráðast á verkefnið sem er, hnitmiðun þín og svo framvegis. Einfaldlega settu, notaðu bestu dómgreind þína, og kannski ekki fara um borð í gerviskóða.
Að öðrum kosti, nema síðurnar nái bókalengd, þá skulu valdirnir sem þú notar mjög hafa lítil áhrif á árangur vefsvæðis þíns. Enn, kíkið á skjalið sem tengist hér að ofan og kynnst því hvað gerir festa og hvað gerir það ekki. Þú getur samt fundið upplýsingarnar gagnlegar.
Þú getur líka séð Þessi grein frá CSS-Bragðarefur fyrir aðeins meira nýlegt að taka á viðfangsefnið.
Auðvitað eru CSS eiginleikar sem taka lengri tíma en aðrir. Klassískir eiginleikar eins og breidd, hæð og litur er enn festa. Þeir sem hafa tilhneigingu til að taka smá tíma (og geta verið breytilegir frá vafra í vafra) hafa tilhneigingu til að vera CSS3 eiginleikar eins og kassaskuggi.
Aðferðin við að bæta dropaskugga við frumefni er flókið, að því er varðar flutning á vefsíðum. Það sem áhugavert er að hafa í huga er það, eins og bent var á HTML5 Rocks , vinnsluorkan sem krafist er getur verið mjög mismunandi eftir sérstökum stærðum dropaskugga.
Þessi grein gefur til kynna að það sama gildir um aðrar eignir eins og radíus radíus og umbreytingu.
Aftur, þetta myndi hafa lítil áhrif á flutning á síðu á meðaltali skrifborð eða fartölvu. Hreyfanlegur tæki gæti þó tekið stærri högg, en reynslan gæti orðið fyrir því. Allir hata hræðilega rolla.
Enn þarf að vega það gegn kostnaði við að nota myndir til að framleiða sömu áhrif. Einhver man eftir því sem við gerðum til að fá hringlaga horn, einu sinni í einu?
Farðu bara ekki um borð, og stíll þín ætti að gera nógu hratt.
Nú erum við að komast inn á annað landsvæði. CSS hreyfimyndir geta verið blazingly fljótur, eða þeir geta hægja á vafranum að því marki að gaming rigs eiga erfitt með að halda uppi.
Þetta er að hluta til vegna þess að ekki er allt hreyfimynd aflað jafnt. Nokkur þungur lyfting er gerð af vélbúnaði, en aðrar gerðir hreyfimynda verða að vera gerðar eingöngu af eiginleikum vafrans. Þetta er sérstaklega dýrt á farsímum.
Í annar grein Á HTML5 Rocks eru CSS eiginleikarnir sem eru festa til að hreyfa sig, staðsetning , mælikvarði , snúningur og ógagnsæi.
Skoðaðu greinina til að fá nánari yfirsýn yfir hvað hægt er að hreyfimynda en halda kostnaðinum lágt.
Hér er þar sem ég býður þér hagnýt ráð sem ég, höfundur, getur gefið þér. Notaðu CSS preprocessors eins og LESS, SASS og Stylus. Jú, ef þú notar þær rangt, getur þú búið til stærri stíllblöð en þú ætlaðir; en hugsanleg ávinningur er þess virði.
Til dæmis, ef þú vilt draga úr fjölda HTTP beiðna sem gerðar eru á netþjóninum (alltaf góð hugmynd), innihalda allar endurstillingar, ramma, í eina LESS / SASS skrá. Þegar það saman verður allt í einu stíll. Auk þess bjóða flestir preprocessors kost á að framleiða öll CSS í fullgilt formi.
Þannig geturðu notað eins marga mismunandi skrár og þú þarft til að skipuleggja kóða án þess að hafa óhóflega áhrif á skráarstærðina.
JavaScript getur verið mjög hægur. Til að vera nákvæmari getur JavaScript haft miklu meiri bein áhrif á "vinnslu" hluta hraðajöfnu en CSS. Verra, JS getur orðið veldisvísari þyngri hvað varðar skráarstærð til þess að ná tilviljun léttvægum hlutum.
Það er tvöfalt whammy af sársaukafullum seiglu og notendur okkar eru oft fórnarlömb, sérstaklega þá sem eru í farsímaflettum. Þetta er þó ekki galli tungumálsins. Hvernig ruglað upp JS fær okkar er oft í beinu hlutfalli við fáfræði okkar um forritun almennt.
Ég er ekki verktaki. Ég hef oft notað bókasöfn eins og jQuery eða einstaklingsbundin JS-viðbætur til að fá efni gert. Því meira sem ég þarf að gera, því fleiri viðbætur sem ég þarf til að gera það allt að verkum. Þessar viðbætur og rammar koma með auka valkosti og eiginleikum sem ég kann aldrei að nota.
Það er bandbreidd-stela uppblásna, þarna.
Að auki gætu viðbætur ekki gengið vel saman. Þeir gætu hægt á hvort annað, eða maður gæti stöðvað aðra frá því að vinna að öllu leyti.
Það er sóun á vinnsluafli, þarna.
Ef þú vilt virkilega að flýta fyrir vefsíðuna þína, hrista millisekúndur (eða heilar sekúndur, í sumum tilfellum) hér er það sem þú þarft að gera:
Eins og CSS, það er best að halda JS í utanaðkomandi skrám, og tengjast HTML þínum. Þú gætir ekki held að það sé svo stórt mál ef þú hefur ekki mikið JS kóða, og það bætir við HTTP beiðni, en hér er hlutur: Ytri CSS og JS skrár eru afritaðar af vafranum.
Svo þegar sömu síðu er beðið um aftur eða aðrar síður á vefsvæðinu þínu, sem nota sömu CSS eða JS, fáðu beðið, verða þau afrituð utanaðkomandi skrá notuð í stað þess að vera sótt aftur. Það er hraðari síða hleðsla sinnum og örlítið hraðar vinnsla. Það er þess virði að auka símtalið á netþjóninn núna og aftur.
Í grundvallaratriðum fer kenningin svona út: vafrinn gerir hvað sem er efst á frumkóðanum á síðu fyrst. Þess vegna eru hlutir eins og merkið nálægt toppnum.
JavaScript-skrár geta þó hægjað allt niður með því að stöðva vafrann frá því að flytja HTML þína þar til þau eru hlaðin. Þar sem flestar almennar notaðar JS-áhrif og viðbætur þurfa aðeins að virka eftir að restin af síðunni er á skjánum, er þetta minna en hugsjón.
Bættu reynslu notandans og dregið úr áhorfandi hleðslutíma með því að tengja við ytri skrár neðst á síðunni, rétt fyrir merkið.
Þegar notandi fær um að hafa samskipti við allt sem krefst JS, ætti það að vera tilbúið til að fara.
Ef þú ert að hanna fullnægjandi app, þá getur þú og kannski hafnað þessum kafla. Gott, sveigjanlegt og létt ramma getur gefið verktaki mikla brún. Fyrir lítil og meðalstórum vefsíðum getur hins vegar verið overkill með JavaScript ramma. Á þessum vefsíðum verður JS að mestu notað í bakgrunni CMS til að stjórna efni. Á framhliðinni gæti verið að þú hafir myndrennari eða múrsteinn eða tvö. Ef þú ert virkilega ímyndað gætirðu sjálfkrafa lokið á leitarreitnum.
Flest efni þarf ekki að vera fancied upp og líflegur eins og þetta. JavaScript ætti, eins mikið og mögulegt er, að vera frátekið til að bæta reynslu notenda. Reiða sig á það að einfaldlega fallega upp á síðuna getur leitt til hægur, hægur staður, sérstaklega á farsímum.
Á þann hátt eru öll kóða ramma öll þau sömu, hvort sem það er JavaScript, PHP, Python, HTML eða CSS: Sérhver eiginleiki er fullt af kóða. Þegar þú velur ramma eða tappi fyrir vinnu, spyrðu sjálfan þig hvort þú ætlar að nota alla eiginleika sem það býður upp á, eða jafnvel flestir þeirra.
Ef ekki, er ramma mát? Getur þú valið og valið aðeins hlutina sem þú þarft í raun? Ef svo er, og þú trúir því að skráarstærðin sé vel þess virði, þá að öllu leyti að fara fyrir það! Annars er besta leiðin til að sjá hvað þú getur tekið út meira en það sem þú getur búið til.
Ekki varanlega! Hugsaðu um það með þessum hætti, er eitthvað efni eða virkni á síðuna þína falin í burtu með JS? Getur fólk aðgang að því án þess að hafa JS virkt í vafra sínum?
Ef svo er þá þá frábært. Hins vegar, ef fólk getur ekki séð mikilvægar upplýsingar, hafðu samband við þig eða flettu rétt án JavaScript, þá hefur þú vandamál. Jú, þú getur treyst á að flestir sem enn hafa það virkt, en þú hefur alltaf fengið þá brún
Hvernig tengist þetta vefsíðan hraða? Ímyndaðu þér hversu hægur beit er að fá ef hluti af vefsvæðinu þínu skyndilega virkar ekki.
Nei alvarlega, ef þú ert ekki verktaki, og þú hefur fjárhagsáætlun fyrir einn, farðu með einn, jafnvel fyrir lítil, einföld störf. Það er ódýrara til lengri tíma litið að ráða einhvern sem hefur reynslu af því að gera það rétt, einu sinni.
Ef hlutirnir fara svolítið úrskeiðis (og við erum að tala um tölvur hérna, svo eitthvað mun fara úrskeiðis), munu þeir finna út hvað fór úrskeiðis hraðar. Þeir munu hafa reynslu af að finna þær tegundir af vandamálum og leysa þau. Ef ekkert annað, þá verður það betra að fara á þessar tilteknu málefni.
Mikilvægast er, þeir munu vita hvernig á að gera það sem þarf að gera með minna kóða. Minni kóða (venjulega) keyrir hraðar og (alltaf) niðurhal hraðar. Það er einfaldasta ráðin sem ég get hugsanlega gefið.
(Ef þú ert verktaki eða er að læra, hef ég safnað saman lista yfir námskeið sem liggja fyrir neðan þessa grein. Meðal þessara leiðbeinanda er að lesa JavaScript sem keyrir hratt.)
Þegar þú tekur myndskeið úr jöfnunni er stærsta hlutinn á hvaða efni sem er ekið á vefsíðum myndirnar. Myndir hafa tilhneigingu til að vera stór, fyrirferðarmikill og hægur eins og helvíti þegar þær eru ekki bjartsýni.
Nú, með útbreiðslu sjónhimnuskjáanna þvingar okkur til að nota stærri myndir ef við viljum að hlutirnir líti vel út í hverju tæki, þá er vandamálið ekki að verða auðveldara að leysa. Og verra, það er mál sem auðvelt er að gleyma því að þú ert að eyða meira en ætlað er á bandbreidd.
Þegar hvert bæti telur, getum við ekki efni á að gleyma.
Góðu fréttirnar eru að þetta er ekki nýtt vandamál með neinum hætti. Afhverju er þetta gott? Það þýðir að það eru tonn af hugsanlegum lausnum sem hægt er að velja úr, og þú getur notað fleiri en einn af þeim í einu. Í raun er það almennt góð hugmynd.
Svo þar til ISP og hýsingarfyrirtæki byrja að gefa okkur allt ótakmarkaðan ókeypis bandbreidd (ekki haltu andanum), hér eru nokkur atriði sem þú getur gert:
Einfaldlega settu, gerðu eins mikið og þú getur, sjónrænt séð, með CSS og JavaScript áður en þú snýr að myndum. Kóði verður alltaf ódýrari að flytja en myndir, svo halda fast við það eins mikið og þú getur. Þrátt fyrir vinnsluorku sem notuð er af CSS-undirstöðu dropaskuggum, stigum og þess háttar, íhuga viðskiptin.
Hafðu líka í huga að SVG myndir telja, í þessu tilfelli, sem "kóða", vegna þess að það er allt sem þeir eru: XML kóða sem er myndað sem mynd. Þannig ætti að nota þau þegar þú þarft eitthvað sem tengist vektor.
Nú, hvað gerum við við þá aftur til fyrrnefndra sjónhimnuskjáa? Hvernig sparaum við á bandbreidd þar?
Þetta er þar sem við snúum til frumefnisins og myndasettarinnar. Þau eru tiltölulega ný og ekki að fullu studd, en þeir leyfa vafra að velja viðeigandi myndastærð fyrir tækið sem notað er.
Svo á meðan þetta mun ekki spara þér bandbreidd fyrir þá sem skoða síðuna þína í iMac þeirra, er það ekki eins stórt í samningi vegna þess að þeir hafa líklega fengið breiðband. Einhver á símanum, á meðan, fær minni útgáfu af sömu myndinni og heldur þeim að bíða of lengi.
Margir myndastærðarsveitir verða fastir þegar þú lærir hvaða myndsnið sem er að nota í hvaða ástandi sem er. Ég gæti farið um tilteknar myndsnið, hvernig þjöppunin virkar og svo framvegis, en þú þarft aðeins að muna nokkra hluti:
Það er allt í lagi. Ef þú gerir þetta og spilar með hagræðingarstillingar þegar þú vistar myndirnar getur þú oft fengið frekar viðeigandi gæði í tiltölulega litlum skráagerðum.
Hins vegar er nýtt snið út sem heitir WebP, sem styður sjálfkrafa Chrome og Opera. Google kröfur þessi WebP skrár eru 26% minni en PNG og 25-34% minni eftir nokkra þætti.
Þetta er frábært fréttir, nema fyrir tvennt: Firefox og IE. Nú, ef þú dont 'hugur að nota fallbacks og auka handrit, getur þú notað WebP sniðið núna, í dag. Bara hlaða niður WebPJS , og þú ert góður að fara.
WebPJS notar JavaScript og smá Flash ( andvar ... en það er aðeins fyrir IE) til að gera það að verkum, en það virkar. Þú gætir hugsað það ef þú þarft að þjóna mikið og mikið af stærri myndum hratt, en gallinn er að það muni ekki virka án JS.
Það eru tvær tegundir af þjöppun sem þú getur notað á myndunum þínum. Í fyrsta lagi höfum við loðnuþjöppun . Þetta er notað á tapy snið eins og JPEG. Það gerir þér kleift að þjappa hvaða mynd sem er eins mikið og þú vilt með skilninginn á því að gæðiin verði versnað og verri og verri. Hlutirnir munu fá pixelated og missa skilgreiningu.
Lossless samþjöppun er notuð á sniðum eins og PNG, og getur dregið úr stærð þeirra að einhverju leyti. Hins vegar hefur það takmarkanir. Það kemur alltaf á stað þar sem það er ómögulegt að gera mynd minni án þess að tapa gæðum.
Ef þú ert með Photoshop eða svipuð háþróaður myndvinnsluforrit er oft best að nota þá til að þjappa myndunum þínum svo að þú sérð hvaða framleiðsla mun líta út þegar þú ert búinn.
(Sjálfvirk verkfæri, einkum á netinu tækjum, reyni að þjappa saman hlutina, kannski aðeins of langt. En ég mun skrá yfir bestu samþjöppunarverkfæri sem ég hef fundið í tengillanum hér að neðan.)
Ef þú notar CMS eins og WordPress mun það sjálfkrafa breyta stærð myndarinnar sem er of stór. Það er líka auðvelt að finna viðbætur sem þjappa sjálfkrafa þeim fyrir þig.
Hugsaðu þér, ég mæli með sjálfvirkri samþjöppun þegar þú veist að þú ert að hlaða upp hellingum og margar myndir af svipuðum gæðum í sama tilgangi. Myndblogg er eitt dæmi.
Ef þú ert að keyra á síðuna þar sem notendur eru að hlaða upp eigin myndum sínum, vel ... sjálfvirk breyting og samþjöppun er alger mælikvarði, og þess vegna gerir hvert félagslegt net það.
Hér eru nokkrar bita ráð sem passaði ekki í neinum af þessum þremur flokkum hér að ofan.
"Minnkun" kóðann þinn þýðir bara að öll viðbótarrými og línuskil séu tekin út. Þetta getur dregið úr skráarstærð frekar verulega.
Það gæti hljómað eins og mikið af vinnu, en það eru verkfæri þarna úti til að minnka CSS og JS sjálfkrafa og halda hreinsaðar skrár aðskilin fyrir skrárnar þínar, fyrir nokkuð augljósar ástæður.
Eins og áður hefur verið getið, geta ýmsir CSS preprocessors framleiðsla allra kóðana í hreinsuðu formi í fyrsta lagi.
Að því gefnu að netþjónninn sé stilltur réttur, getur allur kóðinn þinn verið sendur í vafrann í þjappaðri sniði. Textaskrár þjappa mjög vel og draga úr stærð skráanna sem sendar eru verulega.
Nú þarf þjónninn þinn að taka augnablik eða tvo til að þjappa þeim skrám sem hann sendir, og vafrinn notandi þarf að pakka þeim niður, en þetta er venjulega þess virði að gera bandbreiddarviðskipti.
Fyrir fullt útskýringu á því hvernig þetta virkar, sjá Hvernig á að hagræða vefsvæðinu þínu með GZIP samþjöppun .
Flettitæki er sjálfkrafa að einhverju leyti takk fyrir nútíma vafra. Vafrinn fer á síðuna og geymir tímabundið myndirnar og aðrar upplýsingar sem hann finnur þar.
Þannig, ef sama notandinn skilar innan tiltekins tíma, þarf vafrinn ekki að biðja um sömu myndirnar aftur og aftur. Það hleður bara þeim sem það hefur þegar, og óskar eftir nýjum myndum sem það gæti ekki haft.
Það er hins vegar eitthvað sem þú getur gert til að segja vafra hvað á að skynda og hversu lengi, eins og sést í Þessi handbók .
Og þá er miðlara flýtiminni. Server flýtiminni tekur í grundvallaratriðum bara á síðuna þína og setur eins konar "afrit" af því milli notenda og raunverulegan miðlara. Afhverju myndir þú trufla?
Jæja, það er sérstaklega gagnlegt fyrir fólk sem notar efnisstjórnunarkerfi í stórum stíl. Ef notendur hafa aðgang að tímabundinni afriti af vefsvæðinu þínu í staðinn fyrir raunverulegan hlut, dregur úr fjölda símtala í gagnagrunninn. Upplýsingar verða birtar og hlaðnir hraðar vegna þess að það þarf ekki að endurnýjast á hverjum tíma.
Það fer eftir því hvernig það er sett upp, þjöppun miðlara getur einnig dregið úr bandbreiddarkostnaði almennt. Í grundvallaratriðum, því stærri sem vefsvæðið þitt er, því meiri ástæða sem þú þarft að líta á að flokka það.
Og nú er hlutinn sem þú hefur verið að bíða eftir: Listi yfir tengla! Við höfum fengið námskeið og handbækur, að mestu leyti, og nokkrar myndþjöppunarverkfæri til að mæla með.
Yahoo! Ekki má vera eins stór samningur eins og það var einu sinni, en verktaki net þeirra hefur mikið af góðum hlutum á það. Þetta felur í sér þeirra Best Practices til að flýta fyrir vefsíðuna þína , sem nær yfir nokkrar af helstu hlutum sem þú getur gert. Sumt af því nær yfir sömu grundvöll og þessi grein, en það er meira að auki.
Í inngangi, nefndi ég skynja síðuna hraða, einnig þekktur sem skynja perfomance. Ef þú vilt lesa meira um það skaltu skrá sig út Leiðbeiningar um byrjendur að skynja árangur: 4 leiðir til að gera farsímaþjónustuna þína eins og innfæddur app .
Effeckt.css er sett af fjörum sem eru byggðar á CSS sem eru hönnuð til að gera hratt, sama hvaða vettvangur notandinn er á.
Þetta er leiðarvísir til að ganga úr skugga um að CSS þín verði sótt og unnin eins fljótt og auðið er af vafranum.
Þegar þú ert bara að byrja út, læra að kóða rétt getur verið eins mikil aukning í hraða eins og handahófi ráð um bragðarefur sem þú gætir lært. Bad kóða kostar meira með tilliti til vinnslutíma, svo að læra að gera hlutina á réttan hátt.
Hér er a undirstöðu fylgja sem leggur áherslu á að skrifa JavaScript sem keyrir hratt.
Rétt eins og titillinn segir, þetta er allt ráð beint til JavaScript V8.
Og stundum muntu líklega endar með því að nota jQuery. Ef þú ert að fara að gera það, þá ættir þú að vita hvernig á að skrifa jQuery selectors sem mun ekki hægja á þér. Og hér er þar Sitepoint hefur verið fjallað um þig .
Lestu þetta Nánari upplýsingar um myndasnið á vefnum. Upplýsingarnar eru svolítið gömul, en enn í gildi og gott að vita.
Þetta er tæknilegari leiðarvísir fyrir myndatöku sem Google þróunarnetið býður upp á.
Compressor.io er einn af þeim áhrifamikillustu verkfærum sem ég hef upplifað persónulega. Það er netforrit, svo þú verður að hlaða upp öllum skrám sem þú vilt þjappa, en það getur gert kraftaverk fyrir JPG. Það býður upp á bæði lausa og lossless þjöppunarmöguleika, hvert með fallegu ótrúlegu árangri, og það getur líka gert lotuvinnslu.
Trimage sérhæfir sig í lossless samþjöppun, en það er hægt að setja upp á eigin tölvu, á Windows, Mac eða Linux. Þar sem það er sett upp í tölvuna þína (og já, kemur með mismunandi skipanalínu valkosti og GUI) getur það auðveldlega verið keyrt sjálfkrafa sem hluti af þróunarvinnu.
Eins og alltaf, það er miklu meira að læra. En vopnaður við þær upplýsingar sem við höfum veitt og auðlindirnar sem við höfum tengt við, verður þú á leiðinni til að byggja upp vefsvæði og forrit sem ekki ónýta helvíti út af notendum þínum.
Og það er fyrsta skrefið í átt að hrifningu þeirra.