A JavaScript hatása a mobil webes teljesítményre kétszeres.
Az egyik, ez a második legnagyobb közreműködője a weboldal súlyának képek , Ezzel növelve a letöltési időt; És kettőt, miután letöltötték, a böngészőnek el kell futtatnia a szkriptet, ami késleltetheti az oldalon lévő (esetleg fontosabb) eszközök letöltését / megjelenítését.
A JavaScript (más néven szkriptek vagy JS) egyike azon technológiák triumvirátusának, amelyek weboldalakat (és webes alkalmazásokat) használnak. A HTML (Hypertext Markup Language) szabályozza a weboldal szerkezetét és tartalmát; A CSS (Cascade Styling Sheets) szabályozza, hogy a webhely hogyan néz ki különböző eszközökön; És a JavaScript még interaktívabbá és dinamikusabbá teszi az oldalt.
A parancsfájlok számos funkciót töltenek be weboldalakon, mint például a hirdetések betöltése, az A / B tesztelés, a címkekezelés (az oldal személyre szabása) vagy az inline video lejátszó megjelenítése.
Az elmúlt öt évben a mobileszközökre küldött oldalak teljes tömege Megnégyszereződött 2,2 MB-ra . A méret azért számít, mert általában több mobiltelefonos vagy rögzített hálózaton keresztül küldött adat hosszabb ideig fog futni. Több adat, több másodpercig egy üres mobil képernyőre bámulva.
Ez azt sugallja, hogy a képek – amelyek általában az egyes oldalak teljes kilobájtját (KB) vagy megabájtját (MB) növelik – a fő bűnösök. De ez nem mindig így van.
A JavaScript potenciálisan több hatással lehet az oldal teljesítményére, mint a képek. Mint Patrick Meenan, a webes teljesítménymérő webhely alapítója WebPageTest És a Google szoftverfejlesztője, kifejti:
“A szkriptek általában (nagyobb) problémát jelentenek, mivel a letöltési méret mellett a szkript végrehajtásához szükséges idő is eltelik, míg a képek tényleg csak a letöltési méret miatt számítanak. A mobileszközökön például néhány másodpercig eltarthat egy szkript futtatása még a letöltés után is. ”
Ez nem feltétlenül JavaScript, önmagában ez a probléma, de hogyan valósul meg: a szkriptek monopolizálhatják a böngésző tevékenységét, blokkolva más tartalmak letöltését és megjelenítését (megjelenítését).
“A problémák gyakran összetettek, ahol a szkript hivatkozik az oldalon. A tartalom egy “blokkoló” szkript után (az aszinkrikus szkripthez képest) nem létezik, a böngésző tekintetében, addig, amíg a szkript letöltött és végrehajtásra kerül. Amikor, ahogyan általában előfordul, hogy a szkriptek az oldal elejére kerülnek, ez azt jelenti, hogy az oldal teljesen üres lesz, amíg a szkriptek letöltöttek és végrehajtásra kerülnek. ”
Az alábbiakban a blokkolás, az inline, a szinkron (szinkron), az aszinkron (async) és a késleltetett szkriptek közötti különbséget tárgyaljuk, és hogyan oldjuk meg a JavaScript-problémákat, de először megnézzük a problémák feltérképezését.
JavaScript blokkolásának tesztelése
Ha weboldalainkat a Google PageSpeed ​​Insights (NBS) használatával próbálta meg rendszeresen Teszteld mobil weboldalakat Olyan eszközök használatával, mint a WebPageTest és a PageSpeed ​​Insights), valószínű, hogy látta a következő figyelmeztetést:

! Javítás:
Szüntesse meg a renderelt blokkoló JavaScriptet és a CSS-t a legördülő tartalomban
Az oldal 8 blokkoló szkript erőforrással és 7 blokkoló CSS ​​erőforrással rendelkezik. Ez késlelteti az oldal megjelenítését.
Az oldalon lévő fent említett tartalom egyetlen oldala sem jelenhet meg anélkül, hogy várni kellene a következő erőforrások betöltésére. Próbálja meg elhalasztani vagy aszinkron módon betölteni a blokkoló erőforrásokat, vagy az erőforrások kritikus részeit közvetlenül a HTML-ben beilleszteni.

A fenti szöveg és kép egy a A Mobile PageSpeed ​​Insights teszt a BBC.com-on 2017 februárjában.
A “felhordás feletti” megjegyzés csak a weboldal azon részére vonatkozik, amely látható a mobileszközön, görgetés nélkül, a Google nem elemez szkripteket az oldal többi részén.
A BBC a világ legnépszerűbb angol nyelvű híroldala Alexa , Hogy kontextusba helyezzük, a többi négyet is meg kell vizsgálnunk a négy legfontosabbban. Az eredmények szerint két másik kiadónak hasonló problémái vannak a JavaScript-szal. (A teszt kiemeli a CSS-problémákat is, de ez nem a cikk fókuszpontja):
BBC.com PageSpeed ​​teszt (8 blokkoló szkript, 7 blokkoló CSS ​​erőforrás)
NYTimes.com PageSpeed ​​teszt (0 blokkoló szkript)
ESPN.com PageSpeed ​​teszt (2 blokkoló szkript, 3 blokkoló CSS ​​erőforrás)
CNN.com PageSpeed ​​teszt (6 blokkoló szkript, 2 blokkoló CSS ​​erőforrás)
4x növekedés a JavaScript használatának öt év alatt
Az elmúlt öt évben az átlagos mobiloldalon használt JavaScript mennyisége majdnem megnégyszereződött 2012 februárjától 101 kB-ról 387 kB-ra 2017 februárjában. Kérdések száma (kérés: a böngészők száma, Tartalom vagy kód) a különböző JavaScript fájlok száma 8-ról 21-re nőtt.
Ezt jól szemlélteti az alábbi grafikon HTTP archívum . A HTTP archívum a havonta legfeljebb 1 millió webhelyet többször is teszteli WebPageTest , És közzéteszi azokat a trendeket és statisztikákat, amelyek alapvető teljesítményértékelést jelentenek webhelye teljesítményéhez.
A HTTP Archívum által felügyelt 1 millió webhely közül a JavaScript a 17,4% -os oldalsúlyt jelenti. A JavaScript az összes kérésből 21-ből áll (22,6%).
Egyes webhelyeknél, különösen a hírtérben, a JavaScriptnek sokkal nagyobb az oldala súlya, mint a norma.
Az alábbi kép összehasonlítja az átlagos webhely tartalomtípus szerinti lebontását A BBC.com a HTTP archívum által tesztelt (2017. február 15):
Az első dolog, amit meg kell jegyezned, hogy a BBC oldal mérete kicsi: 609KB v 2225KB.
A második dolog megjegyezni, hogy milyen kicsi a kombinált méret a BBC képek: 70KB v 1501KB.
A harmadik dolog, hogy arányosan nagy a scriptek: 458KB vagy 75,2% -a teljes oldalméret.
A negyedik megjegyzés (az alábbi ábrákon nem látható) az, hogy a BBC összes 88 kérésének 39 (44,3%) szkriptje.

Ha összehasonlítja a top négy angol nyelvű hírportál eredményeit, figyelemre méltó, hogy mennyire kisebb a BBC, mint a riválisai. Ez a méret egyharmada és felénél van, két-háromszor kevesebb JavaScriptet.
A BBC.com a HTTP archívum által tesztelt : Scripts 458KB (75,2%) 609KB az összes adat; 39 JS kéri (44,3%) 167 88 kérelmet.
NYTimes.com HTTP archív teszt : Forgatókönyvek 1511KB (51%) 2953KB az összes adat; 73 JS kéri (43,7%) 167 teljes kérelmet. (N.B. NY Times egy dedikált mobil webhely a mobile.nytimes.com webhelyen, amely nem szerepel a HTTP archívumban, ami különböző eredményeket adhat.)
ESPN.com HTTP archív teszt : Scripts 1183KB (65.7%) 1802 KB összes adat; 50 JS kérést (47,2%) 106 teljes kérelem közül.
CNN.com HTTP archív teszt : Forgatókönyvek 1484KB (68%) 2182 KB összes adat; 67 JS kéri (31,9%) 210 teljes kérelmet.
Mi a hatás a mobil oldal sebességére?
Tehát következik, hogy a karcsú BBC weboldal sokkal gyorsabban töltődik be, mint minden riválisa?
Err, nem. 2017. február 15-én a HTTP Archívum a következő terhelési időt rögzítette:
BBC.com : 18,3 másodperc
NYTimes.com : 27,4 másodperc
ESPN.com : 8,8 másodperc
CNN.com : 31,5 másodperc
Így a BBC gyorsabban terheli a mobilkészüléket, mint a CNN és ​​a New York Times, de lényegesen lassabb, mint a (nagyobb) ESPN.
Így néz ki a két webhely mobileszközön. (A filmszalag egyike a WebPageTest leglátványosabban legérzékenyebb funkcióinak, amelyet bármely nem techie könnyen érthet). Minden keret 1 másodpercet képvisel. A HTTP archiválási teszt során 9 másodpercig a BBC.com mobil látogatói nem láttak semmit, míg 4 másodpercig az ESPN látogatói nem láttak semmit.
Számos oka lehet annak, hogy egy weboldal gyorsabb lehet, mint például a szerver válaszideje, a tartalomszolgáltató hálózatok (CDN) használata, a hirdetési hálózatok hatása, a harmadik féltől származó adatok (gyakori hírek) vagy a A teszt ideje és helye (ebben az esetben Kalifornia, USA).
Azonban minden más dolog egyenlő, lehetséges, hogy a JavaScript is hozzájárulhat. (Bocsánatkérés a fogadások fedezésére). Amint fentebb megjegyeztük, a BBC.com több figyelmeztetést kapott arra, hogy blokkolja a szkripteket a fold felett, mint a többi híroldal.
A JavaScriptre való támaszkodás csökkentése
A JavaScriptet gyakran olyan feladatok elvégzésére használják, amelyek nem (egyszerűen) HTML vagy CSS segítségével végezhetők el. Mivel a W3C fokozatosan hozzáadja ezeket a funkciókat a HTML vagy CSS szabványokhoz, és ezeket böngészők hajtják végre, a JavaScript javításra már nincs szükség, mivel a HTML / CSS valószínűleg hatékonyabb lesz. Jó példa erre Érzékeny képek .
Alex Painter, az NCC Group webes tanácsadója:
“Általánosságban érdemes ragaszkodni a progresszív javítás elvehez – olyan webhelyet biztosítani, amely JavaScript nélkül működik, és csak olyan parancsfájlokat használ, amelyek más módon nem hajthatók végre.
“A JavaScript használatával a tartalom megjelenítésének költsége drága lehet – betölteni és végrehajtani. Így például ha HTML-t és CSS-t használhat ugyanazon eredmény eléréséhez, akkor általában gyorsabb lesz.
“Ha például érzékeny képekre van szükséged, használhatsz például a CSS és a kép / srcset média lekérdezéseit a HTML-ben, hogy a jobb oldali képet a nézetablakhoz hozzuk, anélkül, hogy a JavaScriptre támaszkodnánk.”
Válasszon aszinkron és késleltetett JavaScripteket a blokkolás és az inline scriptek között
A weboldalon számos módon lehet JavaScriptet végrehajtani, többek között:
Szkriptek blokkolása Szinkronak, ami azt jelenti, hogy azonnal és minden más előtt kell foglalkozni. Alapértelmezés szerint minden JavaScript az elemző blokkolása . Mivel a böngésző nem tudja, hogy a szkript mit fog végrehajtani az oldalra, mihelyt a JavaScript fájl letöltéséhez (a HTML-fájlban) megérkezik, a weblap elkészítését megszűnik, és a fájlok letöltözéséig nem folytatódik. végrehajtott.
Inline szkriptek Szintén leállítja az oldalépítést, de mivel szerepelnek a HTML-ben, nem kell külön letölteni őket. Ugyanakkor túl nagy vagy túl sok inline parancsfájl lefagy, és késleltetheti a HTML fájl kezdeti letöltését.
Asynchronous scriptek Lehetővé teszi a böngészőnek az elemzés folytatását (a kód elemzése és a weboldal felépítése), míg a JavaScript fájl letöltődik. Beleértve a Async attribútum A HTML-ben a böngésző azt mondja, hogy nem kell mindent tartani.
Halasztott JavaScript – a böngészőnek meg kell adnia a JS fájl végrehajtását addig, amíg a weblap elkészül, ezt jelzi a Defer attribútum .
A blokkoló szkriptek valaha is indokoltak?
Patrick Meenan:
“Ha a webhely funkcionalitása a kódra támaszkodik, azt blokkoló szkriptként kell futtatni, hogy készen álljon az oldal igényei előtt. Nagyon gyakori ez a címkekezelő és az A / B tesztelési platform, ahol a kód megváltoztatja az oldalt. Más esetekben a blokkolás akkor alkalmazható, ha több munkát fognak végrehajtani a funkciók aszinkron betöltésére. ”
A JavaScript fájlok méretének csökkentése
Milyen nagy a túl nagy? Hány kérés túl sok?
Ez mindig egy kiegyensúlyozó cselekmény lesz.
Patrick Meenan:
“Mivel a böngésző csak egyszerre tölti be a hat kérést minden domainre vonatkozóan, ha több van, akkor az elsőnek meg kell kérnie a többit, ami hosszabb időt eredményez a kérés / válasz késleltetése miatt.
“A nagyobb JavaScript fájlok hosszabb ideig is elemezhetők és futtathatók (1 ms minden egyes 1 KB uncompressed JS számára ésszerű becslés). Minden más egyenlő, ha ugyanolyan mennyiségű JS van egy csomó fájlban, sokkal több időt vesz igénybe a betöltés, mint ha ugyanannyi JS egy fájlban lenne. ”
A Google azt ajánlja minifikációs A JavaScript fájlok használatával UglifyJS vagy Záró fordító .

További információ a mobil webhely sebességének optimalizálásáról nézze meg az előző három részből álló sorozatot:
Andy Favell a Search Engine Watch újságírója a mobilon. London-alapú szabadúszó mobil / digitális tanácsadó, újságíró és webszerkesztő. Lépjen kapcsolatba vele LinkedIn , Vagy a Twitteren Andy_Favell .

Andy Favell a Search Engine Watch, web szerkesztő és mobil / digitális tanácsadó írója.

Szeretne maradni a legújabb keresési trendek tetején? A legfrissebb információkat és híreket a keresési szakértőktől kaphat.

Kapcsolódó olvasmány

A Google gyorsított mobil oldalai és a Facebook azonnali cikkei villámgyorsan vesznek el a mobil interneten. De a Google bemutatta néhány statisztikát az I / O fejlesztői konferenciáján, amely szerint a Google nyerheti meg a háborút.

A mobiltelefonokra küldött weboldalak mérete négy év alatt megnégyszereződött, ami komoly problémát okozott a webmestereknek és a mobilszolgáltatóknak optimalizálni kívánt SEO-k számára. Ez az oszlop megmutatja a mobil oldal sebességének késedelmét, és hogyan próbálja meg a weboldalakat a problémákra.

A hangalapú keresést a világ vezető technológiai szolgáltatói azonosítják, mint óriási lehetőséget a piaci részesedés megszerzésére a következő évtizedben. Jelenleg hiányzik az általános elfogadás – de mindez hosszú időn át változhat. Tehát ki van a vezető szerepet a hangkeresés “űrverseny” -ként?

A mai asszisztensek közelebb vannak, mint valaha a mindentudó számítógép sci-fi ideáljához, amelyet évtizedek óta álmodtunk. De az a mód, ahogyan a felhasználók kölcsönöznek velük, nem csak a hangalapú kereséssel foglalkozik – hangutasításokkal. Milyenek ezek a különbségek, és mit tehettek, hogy optimalizálják őket?

Ha tetszett, kérlek oszd meg barátaiddal!