ezt az útmutatót David Fern készítette, Social Security Administration

JavaScript használat, CSS használat, kép-és erőforrás méretezés, gyorsítótár/hálózati használat és előugró ablakok. Ezek a legfontosabb gyakorlatok, amelyekre a leglátogatottabb kormányzati webhelyeknek összpontosítaniuk kell, hogy mobilbarátabbak legyenek. De hogyan dolgozhat ezeken a területeken annak biztosítása érdekében, hogy webhelye örömmel tartsa a mobil felhasználókat és visszatérjen?

hat hónapig, 22. szeptember 2017-től 22. Március 2018-ig a szövetségi Crowdsource mobil Tesztelési Program hét mobilbarát automatizált teszteszköz segítségével tesztelte az Egyesült Államok 26 szövetségi kormányzati webhelyét, amelyek a leglátogatottabbak a mobil eszközökön (okostelefonok és táblagépek). Az eredmények azt mutatták, hogy ezek azok a közös gyakorlatok, amelyek miatt ezek a webhelyek nem olyan mobilbarátak, mint amire a felhasználó számíthat vagy szeretne egy mobil élményben. Ezen területek többsége nem közvetlenül kapcsolódik a használhatóság kérdéseihez, hanem a webhely felépítésének módjára vonatkozik (ami gyenge teljesítményhez vezethet). A tesztek elvégzésével kapcsolatos további információkért lásd a módszertan részt a végén.

az itt található információk felvázolják az öt legfontosabb gyakorlatot, amelyeket ezeken a webhelyeken találtunk:

  1. JavaScript optimalizálása
  • JavaScript elhelyezés
  • JavaScript Minify
  • ne használjon Inline Javascriptet
  • optimalizálja a CSS-t
    • kerülje az abszolút dimenziókat és pozíciókat a CSS-irányelvekben
    • használjon külső stíluslapokat a CSS gyorsítótárazásának elválasztásához a Tartalomtól
    • kombinálja a CSS képelemeket Sprite fájlokká
  • képek optimalizálása
    • oldalméret és súly korlátozása
    • erőforrás-tömörítés engedélyezése
    • képek optimalizálása
    • képméret megadása
  • használja a gyorsítótárazást
    • használja a böngésző gyorsítótárazását
    • több fájl kombinálása A jobb teljesítmény érdekében
  • kerülje az előugró ablakokat
  • ne feledje, hogy ha egy webhelyet tartalomkezelő rendszerrel (CMS) vagy fejlesztési keretrendszerrel fejlesztettek ki, akkor ezek a beállítások nem konfigurálhatók. Javasoljuk azonban, hogy a fejlesztők kutassák meg a rendszer képességeit annak meghatározása érdekében, hogy lehetnek-e. Ezen ajánlások némelyike előfordulhat a webkiszolgáló rétegben, amely elkülönülhet a programkódtól.

    JavaScript optimalizálása

    a leggyakoribb probléma a JavaScript használata. A JavaScriptet számos asztali és mobil alkalmazásban használják, mert kiterjeszti a weboldalak funkcionalitását, viszonylag könnyen megtanulható és használható nyelv, és viszonylag gyorsan fut a kliens oldalon. Ha azonban a Javascriptet nem egy optimális helyről helyezik el és hajtják végre a kódban, nem minimalizálják vagy nem használják inline – ban, az negatívan befolyásolhatja az alkalmazás teljesítményét a hagyományosan minimális erőforrásokkal rendelkező mobil eszközökön.

    JavaScript elhelyezés

    probléma – a JavaScript csoportosítása az oldaljelölés végén optimális az oldal betöltéséhez. Ha a HTTP specifikáció a Javascriptet máshová helyezi az oldalon (például a tetején), ez a betöltés blokkolását eredményezheti a JavaScript fájlok letöltése közben. Ezenkívül, mielőtt a böngésző megjeleníthetne egy oldalt, fel kell építenie a DOM fát a HTML jelölés elemzésével. Amikor az elemző találkozik egy parancsfájllal, leállítja és végrehajtja a szkriptet, mielőtt folytatja az elemzést. Ez lelassítja az oldal betöltésének teljesítményét.

    megoldás – helyezze a szkripteket a <head> címkébe, és használja a async vagy defer attribútumokat, amelyek lehetővé teszik a szkriptek ASAP letöltését a böngésző blokkolása nélkül.

    a async attribútummal rendelkező szkriptek aszinkron módon kerülnek végrehajtásra. Ez azt jelenti, hogy a szkript a letöltés után azonnal végrehajtásra kerül—anélkül, hogy időközben blokkolná a böngészőt—, és hogy a második szkript letölthető és végrehajtható az első szkript előtt.

    a defer attribútummal rendelkező szkriptek sorrendben kerülnek végrehajtásra (azaz először az első szkript, majd a második szkript). Ez szintén nem blokkolja a böngészőt. A async parancsfájlokkal ellentétben az defer parancsfájlok csak a teljes dokumentum betöltése után kerülnek végrehajtásra.

    • Fixit-JavaScript elhelyezés| https://mobiforge.com/design-development/fixit-javascript-placement
    • távolítsa el a Render blokkoló Javascriptet| https://developers.google.com/speed/docs/insights/BlockingJS
    • csökkentse a méret a fenti a szeres tartalom| https://developers.google.com/speed/docs/insights/PrioritizeVisibleContent
    • hová tegyem a <script> címkéket a HTML jelölésbe? | http://stackoverflow.com/questions/436411/where-should-i-put-script-tags-in-html-markup

    JavaScript Minify

    probléma – a JavaScript fájlokat mindig minimalizálni kell az átviteli idő csökkentése és az oldal betöltésének felgyorsítása érdekében.

    megoldás – a Minifikáció eltávolítja a felesleges vagy redundáns adatokat anélkül, hogy befolyásolná az erőforrás böngésző általi feldolgozását. A webhely fejlesztéséhez használt integrált fejlesztői környezet (ide) eszköz tartalmazhat olyan funkciókat, amelyek kicsinyítik a JavaScriptet az építési folyamat során. Ezt a Google Closure eszközökkel is megteheti, beleértve a Closure Compiler-t, egy optimalizálót, amely átírja a kódot, és minimalizálja a Holt helyet, hogy gyorsabban töltse le. Jellemző, hogy a minify csak az éles környezetben történik, mivel a hibaelhárítás és a hibakeresés a fejlesztői környezetekben könnyebb lesz a nem minified JavaScript használatával.

    • erőforrások (HTML, CSS és JavaScript) kicsinyítése) | https://developers.google.com/speed/docs/insights/MinifyResources
    • hogyan lehet kicsinyíteni a weboldalak CSS, HTML & JavaScript| https://www.elegantthemes.com/blog/tips-tricks/how-to-minify-your-websites-css-html-javascript

    ne használjon Inline JavaScript

    Issue-Inline JavaScript kódot nem szabad használni, mert megköveteli, hogy a böngésző át JavaScript kód jelölést, amely lassítja a feldolgozást.

    megoldás – helyezze át az összes JavaScript kódot egyetlen tömörített fájlba, amely tiszta elválasztást biztosít a jelöléstől, a stílustól és a kódtól. Ezt úgy is el lehet érni, hogy engedélyezzük az “Inline JavaScript” szűrőt az Apache és Nginx webszerverekben.

    • Fixit-Inline JavaScript| https://mobiforge.com/design-development/fixit-inline-javascript
    • Inline JavaScript| https://modpagespeed.com/doc/filter-js-inline
    • miért Inline CSS és JavaScript kód olyan rossz dolog| https://dzone.com/articles/why-inline-css-and-javascript-

    források:

    • JavaScript: Előnyök és hátrányok http://www.jscripters.com/javascript-advantages-and-disadvantages/

    optimalizálja a CSS

    Cascading Style Sheets (CSS) leírja, hogy a HTML elemek hogyan jelenjenek meg a képernyőn, sok munkát takaríthat meg, és egyszerre több weboldal elrendezését is vezérelheti.

    a CSS azonban megnövelheti az alkalmazás betöltési idejét, ha a CSS direktívákban abszolút dimenziók és pozíciók vannak megadva, a külső stíluslapokat nem használják a CSS gyorsítótárazásának elválasztására a tartalomtól, a CSS képelemeket nem egyesítik Sprite fájlokká, és/vagy több H1 címke van oldalanként.

    kerülje az abszolút dimenziókat és pozíciókat a CSS irányelvekben

    kerülni kell a CSS irányelvekben szereplő pixeleket és abszolút dimenziókat és pozíciókat, mivel ezek nem teszik lehetővé a böngésző számára, hogy a tartalmat a kijelzőhöz illessze, vagy minden eszköztípuson helyesen jelenítse meg. Vannak azonban kivételek e szabály alól. Például, ha azt szeretné, hogy a képeket egy adott kijelzőhöz igazítsák, akkor értelmesebb a dimenziót pixelben megadni. Ezenkívül a pixelmérések megfelelőek lehetnek a margókhoz, a szegélyekhez és a kitöltéshez.

    megoldás-használjon olyan relatív mértékeket, mint em, ex, bolder, larger, thick lehetőség szerint. Például a betűtípus megadásakor használja a font-size: 1.5em értéket a font-size: 12pxhelyett.

    • Fixit-intézkedések| https://mobiforge.com/design-development/fixit-measures

    használjon külső stíluslapokat a CSS gyorsítótárazásának elválasztásához a

    tartalomtól kérdés – külső stíluslapokat kell használni a CSS utasítások elválasztására a HTML-től. Ez a CSS gyorsítótár egy webböngésző segítségével elkerüli az újabb utat a szerverre, és felgyorsítja az oldal betöltését.

    megoldás – a HTML <head> szakaszában használja a nyelvet a CSS fájl külső meghívására, a CSS utasításokat a HTML-től külön fájlban tartva (lásd alább).

    <link rel="stylesheet" type="text/css" href="https://mysite.com/main.css" media="screen" title="style (screen)" />

    figyelmeztetés: sok külső CSS stíluslap használata hátrányosan befolyásolhatja a teljesítményt, ezért azokat egyetlen külső CSS-be kell kombinálni.

    • belső vs külső CSS| http://infoheap.com/internal-vs-external-css/
    • optimalizálja a CSS kézbesítést| https://varvy.com/pagespeed/optimize-css-delivery.html

    kombinálja a CSS Képeszközöket Sprite fájlokba

    probléma – ha sok képet egymástól függetlenül használnak, akkor több hálózati kérést igényel mindegyik letöltéséhez. A CSS Spritek több képet egyesítenek egyetlen képfájlba, hogy egy webhelyen használhassák a kézbesítés és a betöltési idő felgyorsítását. A fájlt ezután CSS segítségével fel lehet vágni.

    megoldás – számos eszközt találhat a sprite lapok létrehozásához, beleértve az iránytűt, a limonádét, a SpriteMe-t, a Fireworks CS6-ot és a TexturePacker-t.

    • Fixit-kép sprintek| https://mobiforge.com/design-development/fixit-image-sprites
    • CSS Sprites: mik azok, miért klasszak, és hogyan kell használni őket| https://css-tricks.com/css-sprites/
    • CSS Sprite Sheets: legjobb gyakorlatok, eszközök és hasznos alkalmazások| https://webdesign.tutsplus.com/articles/css-sprite-sheets-best-practices-tools-and-helpful-applications–webdesign-8340

    források

    • mi a CSS? | https://www.w3schools.com/css/css_intro.asp

    optimalizálja a képeket

    az oldal súlya, más néven “a web gravitációja”, csökkenti az alkalmazás teljesítményét a betöltési idő növelésével és a hálózati adathasználat csökkentésével. Az oldal súlyának, az erőforrás-tömörítésnek, a képek optimalizálásának és a képméreteknek a megértése kritikus fontosságú a sikeres webes stratégia szempontjából.

    oldalméret és súly korlátozása

    probléma – az oldal teljes fájlmérete, beleértve a függő fájlokat is, befolyásolja a betöltési időt és azt az időt, ameddig egy mobil robot kiértékeli. A tiszta és könnyű oldalak a legjobbak a mobil SEO számára; a mobil keresőmotorok inkább rangsorolják ezeket az oldalakat. Törekedjen arra, hogy az összes mobil oldal fájlmérete 25 kilobájt alatt maradjon. Ez a maximális fájlméret, amelyet az iPhone gyorsítótáraz minden letöltött elemhez.

    megoldás – számos módja van az oldal súlyának csökkentésére, beleértve a képoptimalizálást, a gzip tömörítést, a Minifikációt, a gyorsítótárazást, a JavaScriptet és a CSS konszolidációt. Más megoldások közé tartozik a következők elkerülése: beágyazások és Beillesztések, JavaScript és CSS keretrendszerek, egyedi betűtípusok és felesleges oldal rendetlenség. A legjobb megoldás a webhely sajátosságaitól függ.

    • Fixit-oldalméret-korlát| https://mobiforge.com/design-development/fixit-page-size-limit
    • az oldal súlyának megértése| https://mobiforge.com/research-analysis/understanding-web-page-weight
    • az oldal súlyának csökkentése| https://mobiforge.com/design-development/reducing-page-weight

    erőforrás-tömörítés engedélyezése

    probléma-az erőforrások gzip vagy Deflate használatával történő tömörítése csökkentheti a hálózaton keresztül küldött bájtok számát.

    megoldás – a legtöbb szerver konfigurálható gzip tömörítésre. Például engedélyezheti a gzip tömörítést egy Apache szerveren a .htaccess konfigurációs fájl használatával. A mod_gzip használatával engedélyezheti a gzip tömörítést, a mod_deflate pedig a szerver kimenetét tömörítheti, mielőtt elküldené a látogatónak. Ha webhelyét Windows-kiszolgálón tárolja, engedélyezheti a tömörítést mind a statikus, mind a dinamikus fájlok számára az IIS (Internet Information Services) kezelő “statikus tömörítés engedélyezése” elemének kiválasztásával.

    • tömörítés engedélyezése| https://developers.google.com/speed/docs/insights/EnableCompression
    • a gzip tömörítés engedélyezése| https://varvy.com/pagespeed/enable-compression.html
    • a gzip tömörítés engedélyezése| https://www.giftofspeed.com/enable-gzip-compression/

    képek optimalizálása

    probléma – az oldalon lévő képeket úgy kell optimalizálni, hogy csökkentsék a fájlméretüket anélkül, hogy jelentősen befolyásolnák a vizuális minőségüket. A képek formázása és tömörítése sok bájtnyi adatot menthet.

    megoldás – használjon képtömörítő alkalmazásokat a képek fájlméretének egyszerű csökkentéséhez. Ezek az eszközök eltávolítják a rejtett adatokat a képfájlból, például további színprofilokat és metaadatokat (pl., a fénykép készítésének földrajzi helye), amelyekre nincs szükség. Gyors és egyszerű módja annak, hogy csökkentse a fájlok méretét anélkül, hogy elveszítené a képminőséget. A képtömörítő eszközök közé tartozik a TinyJPG, Compressor.io, Kraken, ImageOptimizer, Imageoptimim, Crush képek és Minifier (Shopify Alkalmazások).

    • képek optimalizálása| https://developers.google.com/speed/docs/insights/OptimizeImages
    • Fixit-Image Crunch| https://mobiforge.com/design-development/fixit-image-crunch
    • képek optimalizálása webre: Gyakorlati útmutató| https://www.abetterlemonadestand.com/optimizing-images-for-web/
    • hogyan lehet optimalizálni a képeket a WordPress webhelyéhez| https://www.elegantthemes.com/blog/tips-tricks/optimize-images-for-your-wordpress-website

    adja meg a képméreteket

    probléma-a képméreteket mindig szerepeltetni kell, és a képeket nem szabad újramintázni futási időben, mivel ez lassítja az oldal megjelenítését. Ha a képekre a jelölésen belül hivatkozik, fel kell sorolnia a böngésző megjelenítési méreteit. Az összes kép szélességének és magasságának megadása gyorsabb renderelést tesz lehetővé, mivel kiküszöböli a felesleges újrafestések és újrafestések szükségességét.

    megoldás – adja meg a kép szélességét és magasságát a width és height attribútumok megadásával a img elem használatakor (lásd alább).

    <img src="images/clown.jpg" width="50" height="50" />

    ha az tartalmazó dokumentumban nincs megadva méret, vagy ha a megadott méretek nem egyeznek a tényleges képek méreteivel, a böngésző a képek letöltése után újrafestést és újrafestést igényel. A visszafolyások elkerülése érdekében adja meg az összes kép szélességét és magasságát a HTML <img> címkében vagy a CSS-ben.

    • Fixit-képméret megadása| https://mobiforge.com/design-development/fixit-specify-image-sizes
    • adja meg a kép méreteit| https://gtmetrix.com/specify-image-dimensions.html

    gyorsítótár használata az alkalmazáskérések és az erőforrások feldolgozásának számának csökkentése javítja a betöltési időt és csökkenti a hálózati adatfelhasználást. Ezt kétféleképpen teheti meg: helyi gyorsítótárazás vagy a külső szkriptek és objektumok használatának minimalizálása.

    a böngésző gyorsítótárazásának kihasználása

    probléma – az erőforrások hálózaton keresztüli lekérése egyszerre lassú és költséges, és a letöltés többszöri körutazást igényelhet az ügyfél és a szerver között, ami késlelteti a feldolgozást és blokkolhatja az oldal tartalmának megjelenítését. Ez adatköltségeket is okozhat a látogató számára. Minden kiszolgálói válasznak meg kell adnia egy gyorsítótárazási házirendet, amely segít az ügyfélnek meghatározni, hogy újra felhasználhat-e egy korábban letöltött választ, és ha igen, mikor.

    megoldás – használja ki a böngésző gyorsítótárazását az erőforrások kérés fejlécének megváltoztatásával a gyorsítótár használatához. Hozzáadhat néhány kódot a webgazda/kiszolgáló .htaccess konfigurációs fájljához, vagy használhatja az alapvető Cache-Control HTTP fejlécet (lásd alább).

    Cache-Control: max-age=2592000, public
    • használja ki a böngésző gyorsítótárazását| https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
    • Fixit-gyorsítótár| https://mobiforge.com/design-development/fixit-caching
    • használja ki a böngésző gyorsítótárazását| https://varvy.com/pagespeed/leverage-browser-caching.html
    • mi az .htaccess? | http://www.htaccess-guide.com/
    • gyorsítótár-vezérlés| https://varvy.com/pagespeed/cache-control.html

    több fájl kombinálása A jobb teljesítmény érdekében

    probléma-minden oldalon letöltött külső objektumhoz külön domain name server (DNS) kérés szükséges. Ez nem jelent nagy problémát egy gyors kapcsolattal rendelkező hagyományos számítógépen, de lassabb mobilhálózatokon késleltetést okozhat. Ez árt az alkalmazás teljesítményének és a betöltési időnek.

    megoldás – csökkentse a webhelyhez szükséges erőforrások számát és méretét. Ha azonban ez nem lehetséges, egyesítse az összes külső CSS fájlt egyetlen stíluslapba vagy az összes JavaScript fájlt egy nagy fájlba, hogy csökkentse a böngészőbe irányuló hívások számát.

    • mobil webes alkalmazások bevált gyakorlatai-a külső erőforrások minimalizálása| https://varvy.com/pagespeed/cache-control.html
    • hogyan lehet csökkenteni a HTTP kéréseket a WordPress webhely felgyorsítása érdekében| https://yoast.com/reduce-http-requests-wordpress/
    • egyszerű lépések az oldal betöltési idejének javításához| http://www.peachpit.com/articles/article.aspx?p=1431494&seqNum=5

    kerülje az előugró ablakokat

    az előugró ablakok használata nem feltétlenül rossz az asztali alkalmazásban. Ha azonban az alkalmazás reszponzív dizájnt használ, vagy mobilalkalmazáson használják, az előugró ablakok gyakran akadályozzák és sértik a felhasználói élményt. Felhívják a felhasználó figyelmét az oldalról a felugró ablakra, és a kezdő felhasználó gyorsan összezavarodik és frusztrált lesz.

    előugró ablakok

    probléma-az előugró ablakok nem támogatottak sok mobil eszközön, és használatuk kiszámíthatatlan eredményekkel járhat

    megoldás – az előugró ablakoknak számos alternatívája van, amelyek a teljes ablak elfoglalása nélkül láthatók, például lightboxok, inline bővítés és helyhez kötött Szalaghirdetések.

    • Fixit-felugró ablakok| https://mobiforge.com/design-development/fixit-pop-windows
    • a mobil Pop-upok halála és mit tehet helyette| http://searchengineland.com/death-mobile-pop-ups-can-instead-263390
    • a Google visszaszorítja a tolakodó mobil előugró ablakokat: itt van, amit a marketingszakembereknek tudniuk kell| https://blog.hubspot.com/marketing/google-pop-up-mobile-marketing#sm.0000u10cf1u3gcsdyzz2qa1xm5ugf
    • melyik a legjobb alternatíva a Pop-up? | https://www.quora.com/Which-is-the-best-alternative-to-a-pop-up
    • 5 alapvető UX szabályok A párbeszédpanel tervezéséhez| https://uxplanet.org/5-essential-ux-rules-for-dialog-design-4de258c22116
    • 9 nem annyira tolakodó Alternatívák A felbukkanó hirdetések lebegtetésére| https://www.linkedin.com/pulse/9-not-so-intrusive-alternatives-hover-pop-up-ads-paula-agius

    módszertanunk ehhez a tanulmányhoz

    a következő lépéseket használtuk a vizsgálat elvégzéséhez:

    1. a Digital Analytics Program (DAP) statisztikáinak felhasználásával összegyűjtöttük az Egyesült Államok 26 legnépszerűbb szövetségi kormányzati webhelyét, amelyekhez mobil eszközök férnek hozzá.
    2. minden webhelyet hét mobilbarát automatizált teszteszköz segítségével teszteltünk:
      • Google mobilbarát teszt| https://www.google.com/webmasters/tools/mobile-friendly/
      • mobil Moxie| https://www.mobilemoxie.com/tools/site_analysis/
      • Mobi Kész| http://ready.mobi/
      • Page Insights| https://developers.google.com/speed/pagespeed/insights/
      • W3C mobilok ellenőrző| https://validator.w3.org/mobile/
      • Varvy SEO eszköz| https://varvy.com/
      • Gtmetrix – https://gtmetrix.com/
    3. miután megnéztük az egyes eszközök által jelentett sikertelen kritériumokat, az eredményeket egyetlen Microsoft Excel táblázatba állítottuk össze.
    4. a 15 vagy több webhelyen talált problémákat az ebben az útmutatóban szereplő öt kategóriába csoportosítottuk, amelyek a legtöbb előfordulás (JavaScript) és a legkevesebb előfordulás (előugró ablakok) sorrendjében vannak felsorolva.

    Articles

    Vélemény, hozzászólás?

    Az e-mail-címet nem tesszük közzé.