Mūsu lietotāju vajadzības aug un tiek pilnveidotas, īpaši pateicoties divām lietām - pirmajai ieviešanas gaitai kopš Gmail parādīšanās un tās asinhronās slodzes un tās attīstības šajā jomā, kur tā lietojumprogrammām ir piešķīrusi funkcionalitāti. arvien progresīvāks; Otrais faktors ir mobilo ierīču izmantošana, tagad lietotājs savās mobilajās vietnēs vēlas redzēt, ka ierīcēs darbojas bez problēmām, piemēram, viņi nevēlas veikt pieejas vai atrast komponentus, kas nedarbojas.
Kas tad notiek?
Kaut kas ļoti vienkāršs, koncentrējoties uz visu šo funkciju piešķiršanu mūsu lietojumprogrammām, mēs bieži aizmirstam, ka veiktspējai ir jāpievieno arī mūsu priekšlikums, viena no izplatītākajām kļūdām ir tā, ka, pabeidzot visu attīstību, mēs neapzināmies, ka jūsu Veiktspēja ir ļoti slikta, un mēs pamanām, ka problēma pastāv tikai pēc tam, kad produktu esam palaiduši ražošanā.
Atsaucīgs dizains
Atsaucīga dizaina tendence ir palielinājusies un ir atzīta par kaut ko vērā ņemamu, tostarp Google ir nedaudz mainījis savu meklēšanas algoritmu, lai rezultātu prezentācijā piešķirtu prioritāti lapām, kurām ir piemērotas versijas mobilie tālruņi
Problēma rodas tāpēc, ka, lai arī mēs saprotam, kādam vajadzētu būt rezultātam, daudzas reizes mēs ignorējam labākos procesa veidus, kā to sasniegt, viena no klasiskajām kļūdām ir tā, ka mums nav ierīcei atbilstošu attēlu.
Izplatīta kļūda
Šī pēdējā mūsu pieminētā kļūda liek mums sākt ielādēt attēlus pat 3 reizes lielākus, nekā nepieciešams, protams, super asu attēla redzēšanas skaistums liek mums kļūdaini domāt, ka klients rezultāta dēļ pieņems nedaudz mazāk veiktspējas. Mēs īsti nesaprotam, ka, ja lapa mobilajā ierīcē vai planšetdatorā netiek ielādēta 5 sekundēs , visticamāk, sliktas pārlūkošanas pieredzes dēļ mēs pārcelsimies uz citu vietu.
Vēl viena problēma rodas, piekļūstot no mobilā tālruņa, mēs ielādējam vairāk elementu, piemēram, stila lapas, papildu JavaScript un pat papildu attēlus. Tas padara mūsu lietojumprogrammas versiju, kurai vajadzētu būt gaišākai, kas kļūst par smagāku briesmoni nekā darbvirsmas versija.
Vislabāk ir vispirms uzzināt, kāda veida mobilo attīstību mēs vēlamies veikt, jo ir vairākas attīstības alternatīvas un stratēģijas.
Sākotnējie testi Kā tos izdarīt?
Izstrādājot, gandrīz vienmēr ir vietēja vide, kurā sākotnēji pārbaudām savu kodu, un šī prakse nav slikta šim mērķim, redzot, kā mūsu kods veidojas un dod mums apmierinošus rezultātus.
Bet vienmēr notiek tā, ka, tiklīdz mums būs pienācīga versija lietotāju pieredzei, mēs saviem funkcionāliem analītiķiem, klientiem vai priekšniekiem parādīsim to pašu vidi, un acīmredzot, ja nebūsim savienoti ar internetu vai nebūsim iekšējais serveris, veiktspēja šķitīs pārsteidzoša. Tas liek mums maldīties, jo, norādīto iemeslu dēļ neredzot veiktspējas problēmas, mēs uzskatīsim, ka mūsu tīmekļa lietojumprogramma ir ārkārtīgi optimāla ātruma ziņā.
Ražošanas kļūdas
Veicot ieviešanu ražošanā, starp citām kļūdām mēs sākam redzēt pirmās neveiksmes, komponentus, kuri netiek ielādēti pareizi, procesus, kas neizdodas, jo sistēma prasa daudz laika, lietotāji ir neapmierināti, jo tīmeklis ir ļoti lēns un pārāk ilgi jāgaida.
Šeit mums jāredz reālā testa vide, protams, ir jābūt attīstības videi, kurā tiek pārbaudīta koda funkcionalitāte, taču mums ir jāveido kvalitatīva vide, kurā mēs pārbaudām lietotāja pieredzi un veiktspēju, šo vidi var pārvaldīt produktam, kas tiks izlaists, ir atšķirīgs domēns, taču tam ir jābūt kaut kam īpašam, un tam ir jāatrodas internetā, ja iespējams, tajā pašā mitināšanas pakalpojumu sniedzējā vai tajā pašā komandā kā mūsu gala produkts.
Pēdējam, kuru mēs izskaidrojam, ir modelēts iemesls, kas ir tuvu tiešajai ražošanas videi, tāpēc, ja mūsu pieteikšanās ir lēna, mēs to redzēsim, kad mēs parādīsim darbu tiem, kas ir kopīgi atbildīgi par projektu, un tur mēs redzēsim, cik efektīvi mēs darbojāmies. Dariet kaut ko tādu, kas dod rezultātu.
Vispirms mobilais
Viena no pirmajām darbībām, kas mums jāņem vērā, ir mobilās ierīces pirmais dizains, tas ir, mums jāsāk, sākotnēji izveidojot versiju, kas paredzēta mobilajiem tālruņiem, un pēc tam pārejot uz lielākām versijām ( planšetdatori, phableti utt.), līdz sasniegsit galīgo darbvirsmas versiju, tas neļaus mums pievienot jaunus elementus, lai pielāgotu darbvirsmu mobilajai versijai.
Bet ne tikai lai izvairītos no elementu iekraušanas, papildinājumi ir priekšrocība, ko mums sniedz šī metodika, mēs arī pirms tam varam sākt mobilās veiktspējas testus, kas dod mums priekšrocības brīdī, kad tiek atklāti iespējamie sastrēgumi, jo tas versijai vajadzētu būt daudz ātrākai par citām. $config[ads_text5] not found
Kas ir tīmekļa veiktspēja?
Tīmekļa veiktspēja ir laika mērīšana starp vietnes apmeklējumu un tiek parādīta kopumā, lai varētu to izmantot.
Šis vienkāršais jēdziens slēpj vairākas malas aiz muguras, pirmais - lai arī starp apmeklējuma sākumu un parādīto būs laiks, nav nepieciešams, lai sākumā viss izskatās ideāli, mēs varam pakāpeniski parādīt sadaļas, kuras lietotājs var redzēt Tiek parādīts avanss, piemēram, strukturēts saturs, un visbeidzot tiek ielādēti attēli un pēc tam JavaScript funkcijas.
Tomēr mērīšana notiks tad, kad viss būs pieejams apmeklētāja vai lietotāja lietošanai.
Rādītāji, kas jāņem vērā
Ir vairāki rādītāji, kas mums jāņem vērā, lai varētu novērtēt mūsu vietnes veiktspēju. Tie ir šādi:
Kvantitatīvs
Šajā rādītāju kategorijā mums ir faktori vai parametri, kurus mēs varam izmērīt pēc formulas, skaitļiem vai noteiktām metodēm, kuras nevar pakļaut subjektīvai interpretācijai.
Kvalitatīvs
Šī kategorija ir pretēja iepriekšējai, jo faktorus, kurus mēs ņemam vērā, nevar izmērīt ar skaitli vai formulu, un tie galvenokārt ir subjektīvi skaidrojumi, lai arī daudzas reizes viņi var paļauties uz kvantitatīvajiem rādītājiem, lai atbalstītu dažus no tiem skaidrojumi
Tā kā mēs zinām divas plašās kategorijas, aplūkosim dažus īpašus rādītājus, kurus mēs varam sākt atcerēties, kad sākam mērīt mūsu tīmekļa lietojumprogrammu veiktspēju.
Lapas ielādes laiks
Šis kvantitatīvais indikators ļauj mums iegūt skaitli, kas izsaka sekundes, kas vajadzīgas lietojumprogrammas vai tīmekļa lapas pilnīgai ielādēšanai, parasti izteiktas sekundēs, un tam jābūt mazākam par 2 cipariem, tas ir, mazāk nekā 10 sekundes .
Lapas lielums
Tā ir visu to komponentu svara summa, kas veido mūsu lietojumprogrammu, tas ir, tas ir kopējais pārsūtīšanas svars, kas notiek no brīža, kad mēs apmeklējam mūsu lapu, līdz tā tiek parādīta.
HTTP pieprasījumu skaits
Tie ir savienojumu skaits, ko mūsu lietojumprogramma izveido, ielādējot. Šie pieprasījumi var būt pieprasījumi ielādēt css failus, js, attēlus un zvanus uz citām bibliotēkām vai pakalpojumiem.
Lapas atveidošanas laiks
Laiks, kas paiet starp resursu ielādēšanu un lapas vai lietojumprogrammas pareizu parādīšanu.
Rīki
Tā kā mēs zinām, ka mums ir jāmeklē un jāmēra, mums jāzina, kurus rīkus izmantot, mums šobrīd ir daudz iespēju, sākot ar tīmekļa rīkiem, kas veic tiešsaistes analīzi, līdz pat pašreizējo pārlūkprogrammu papildinājumiem, kas palīdz mums izprast procesu, kamēr mēs esam. dzīvo reālā laikā
GTmetrix$config[ads_text5] not found
Tīmekļa vietne gtmetrix.com piedāvā ļoti interesantu pakalpojumu, tas sniedz mums statistiku par mūsu lapas ielādi, balstoties uz diviem ļoti ievērotiem algoritmiem tīmekļa veiktspējas līmenī, viens ir lapas ātrums, bet otrs ir ySlow, un mēs piedāvājam arī ieteikumus, kā to uzlabot.
Šajā attēlā mēs redzam vietnes ar lielu trafiku analīzi, piemēram, Facebook, lai mēs redzētu, ka varam atrast.
Mēs atzīmējam, ka viņi mums saka, kur atrodas viņu izmērītais komponents, un prioritāti, lai uzlabotu veiktspēju. Tas mums ļoti palīdz, kad sākam, jo ātri uzbrūkam bāzes problēmām. $config[ads_text6] not found
Chrome izstrādātāja konsole
Google Chrome ir kļuvis par visuresošu pārlūku, un ir pareizi, ka tas ir viens no visbiežāk izmantotajiem, un tajā ir arī liels rīku komplekts izstrādātājiem, starp tiem mums ir tīkla konsole, šeit mēs varam redzēt resursu, pieprasījumu un laiks, kas nepieciešams iekraušanai.
Tas ir ideāli, ja mēs esam apguvuši GTmetrix, lai uzbruktu veiktspējas problēmai no šejienes, jo mēs varam sīkāk redzēt lietas, kas mūs ietekmē.
Nākamajā attēlā redzēsim, kā šī konsole izskatās, atkārtoti analizējot Facebook :
Mēs pamanām, kā norāda laiks un resurss, kas tiek izsaukts lapas ielādes laikā. Tas ir ļoti noderīgi, ja mums ir problēmas ar veiktspēju un mēs nezinām, kā viņiem uzbrukt. Šeit grafiski mēs redzam visu mūsu lapas procesu.
Ar šo mēs esam pabeiguši šo apmācību, mēs uzzinājām, kas ir veiktspēja, kā tā tiek mērīta un daži rīki, lai sasniegtu mērķi to uzlabot. Ir acīmredzams, ka tā nav tēma, kas tiek apgūta, tikai lasot apmācību, ir daudz mainīgo, un labākais veids, kā sasniegt labu rezultātu, ir prakse un nepārtraukta analīze.
Pants