JavaScript narxi

Biz JavaScript-ga ko'proq tayanadigan saytlar qurganimiz sababli, ba'zida biz tushuna olmaydigan qilib yuborgan narsalarimiz uchun pul to'laymiz. Ushbu postda, agar sizning saytingizni mobil qurilmalarda tezkor ravishda interaktiv bo'lishini xohlasangiz, nima uchun ozgina tartib-intizom yordam berishi mumkinligini aytib o'taman.

tl; dr: kam kod = kamroq tahlil qilish / kompilyatsiya qilish + dekompressiyadan kamroq o'tkazish

Tarmoq

Ko'pgina ishlab chiquvchilar JavaScript-ning qiymati haqida o'ylashganda, ular yuklash va bajarish qiymati nuqtai nazaridan bu haqda o'ylashadi. Sim orqali JavaScript-ning ko'proq baytlarini yuborish foydalanuvchi ulanishini sekinlashtiradi.

Bu, hattoki dunyoning birinchi mamlakatlarida ham muammo tug'dirishi mumkin, chunki tarmoq ulanishining samarali turi aslida 3G, 4G yoki WiFi bo'lmasligi mumkin. Siz Wifi qahvaxonasida bo'lishingiz mumkin, ammo uyali ulanish nuqtasiga 2G tezligida ulanishingiz mumkin.

Siz tarmoqning uzatish narxini JavaScript orqali kamaytirishingiz mumkin:

  • Faqat foydalanuvchi kerak bo'lgan kodni etkazib berish. Kodni ajratish bu erda yordam berishi mumkin.
  • Miniting (ES5 uchun Uglify, ES2015 uchun babel-minify yoki uglify-es)
  • Uni qattiq siqish (Brotli ~ q11, Zopfli yoki gzip yordamida). Brotli siqilish nisbati bo'yicha gzipdan yuqori. Bu CertSimple-ga siqilgan JS baytlari hajmidan 17% va LinkedIn-ning yuklanish vaqtlarida 4% tejashga yordam berdi.
  • Foydalanilmagan kodni olib tashlash. DevTools kod qamrovi bilan aniqlang. Kodni ochish uchun Moment.js kabi kutubxonalar uchun daraxtlarni silkituvchi, Closed Compiler-ning takomillashtirilgan optimallashtirishlari va lodash-babel-plagin yoki Webpack-ning ContextReplacementPlugin kabi plaginlarini ko'ring. Zamonaviy brauzerlarda mavjud xususiyatlarni boshqa nusxaga o'tkazmaslik uchun babel-preset-env & brauzer ro'yxatidan foydalaning. Murakkab ishlab chiquvchilar o'zlarining Webpack to'plamlarini sinchkovlik bilan tahlil qilishlari keraksiz bog'liqliklarni kesish imkoniyatlarini aniqlashga yordam beradi.
  • Tarmoq safarlarini minimallashtirish uchun uni keshlash. O'zgarmas baytlarni o'tkazib yubormaslik uchun skriptlar (maksimal yosh) va ta'minotni tasdiqlash tokenlari (ETag) uchun optimal umrni aniqlang. Service Worker-ni keshlash sizning ilovalaringizni barqaror qiladi va V8-ning kod keshi kabi xususiyatlarga kirishga imkon beradi. Fayl nomini xeshlash bilan uzoq muddatli keshlash to'g'risida ma'lumot oling.
Sizga JavaScript-ni foydalanuvchilarga etkazib berishni kamaytirishning eng yaxshi usullari.

Qidiring / tuzing

Yuklab olingandan so'ng, JavaScript-ning eng katta xarajatlaridan biri bu kodni tahlil qilish / tuzish uchun JS dvigatelining vaqti. Chrome DevTools-da tahlil qilish va kompilyatsiya qilish Performance panelidagi sarg'ish "skript yozish" vaqtining bir qismidir.

Pastki-yuqoriga / qo'ng'iroq daraxti aniq tahlil / kompilyatsiya vaqtini ko'rishga imkon beradi:

Chrome DevTools ishlash paneli> Pastki-yuqoriga. V8-ning Runtime Call Statistikasi yoqilgan bo'lsa, biz tahlil qilish va Compile kabi bosqichlarda sarflangan vaqtni ko'rishimiz mumkin

Ammo, nega bu muhim?

Kodni tahlil qilish / tuzish uchun uzoq vaqt sarflash, foydalanuvchi saytingiz bilan qanchalik tez o'zaro aloqa qilishi mumkin. Qancha ko'p JavaScript yuborsangiz, saytingiz interfaol bo'lishidan oldin uni tahlil qilish va tuzish uchun ko'proq vaqt ketadi.

Byt-by-by-by-JavaScript brauzer uchun teng o'lchamdagi rasm yoki Internet-shriftga qaraganda ishlov berish uchun qimmatroq - Tom Deyl

JavaScript bilan taqqoslaganda, bir xil o'lchamdagi rasmlarni qayta ishlashga ko'plab xarajatlar talab etiladi (ular haligacha hal qilinishi kerak!), Ammo o'rtacha mobil qurilmalarda JS sahifaning interaktivligiga salbiy ta'sir ko'rsatishi mumkin.

JavaScript va rasm baytlari juda katta xarajatlarga ega. Rasmlar odatda asosiy ipni to'sib qo'ymaydi yoki interfeysni dekodlash va rastrlash paytida interfaol bo'lishiga to'sqinlik qilmaydi. Biroq, JS interaktivlikni tahlil qilish, tuzish va bajarish xarajatlari tufayli kechiktirishi mumkin.

Biz tahlil qilish va kompilyatsiya qilish haqida gaplashsak; kontekst juda muhim - biz bu erda o'rtacha mobil telefonlar haqida gapiramiz. O'rtacha foydalanuvchilarda sekin protsessor va GPU telefonlari, L2 / L3 keshi yo'q va hatto xotira buzilishi mumkin.

Tarmoq qobiliyati va qurilmaning imkoniyatlari har doim ham bir-biriga mos kelavermaydi. Ajoyib Fiber ulanishga ega foydalanuvchi, ularning qurilmalariga yuborilgan JavaScript-ni tahlil qilish va baholash uchun eng yaxshi protsessorga ega bo'lishi shart emas. Bu ham teskari, ham dahshatli tarmoq ulanishi bilan bog'liq, ammo tezkor protsessor. - Kristofer Baxter, LinkedIn

JavaScript Start-up Performance-da men past va yuqori darajadagi dasturiy ta'minotda ~ 1MB dekompressiyalangan (oddiy) JavaScript-ni tahlil qilish narxiga e'tibor qaratdim. Bozordagi eng tezkor telefonlar va o'rtacha telefonlar o'rtasida kodni tuzish / tuzish uchun vaqt oralig'ida 2-5 baravar farq bor.

Turli sinfdagi ish stoli va mobil qurilmalar uchun 1 MB to'plam uchun (~ 250KB gzipped) vaqtni tahlil qiling. Tekshirish narxini ko'rib chiqishda, e.g ~ 250KB gzipped JS dekompressiyasini ~ 1MB kod deb hisoblash kerak.

Haqiqiy CNN.com sayti haqida nima deyish mumkin?

Yuqori darajadagi iPhone 8-da o'rtacha telefon (Moto G4) uchun 13-ga nisbatan CNN-ning JS-ni tahlil qilish / tuzish uchun atigi 4 soniya kifoya qiladi. Bu foydalanuvchi ushbu sayt bilan to'liq aloqa o'rnatishga qanchalik tez ta'sir qilishi mumkin.

Apple'ning A11 Bionic chipining ishlashini Snapdragon 617 bilan o'rtacha Android qurilmalarida taqqoslang.

Bu shunchaki cho'ntagingizda bo'lishi mumkin bo'lgan telefon emas, balki o'rtacha qurilmalarda (Moto G4 kabi) sinab ko'rish muhimligini ta'kidlaydi. Ammo kontekst muhim: qurilmangiz va foydalanuvchilaringizning tarmoq sharoitlarini optimallashtiring.

Analitiklar sizning haqiqiy foydalanuvchilaringiz saytingizga kiradigan mobil qurilmalar sinflari haqida ma'lumot beradi. Bu ular bilan ishlayotgan CPU / GPU haqiqiy cheklovlarini tushunish uchun imkoniyat yaratishi mumkin.

Biz haqiqatdan ham juda ko'p JavaScript-ni yuborayapmizmi? Xatolik, ehtimol :)

Mobil Internetdagi JavaScript holatini tahlil qilish uchun HTTP Archive (top ~ 500K saytlar) dan foydalanib, 50% saytlar interfaol bo'lish uchun 14 sekunddan ko'proq vaqt ketishini ko'rishimiz mumkin. Ushbu saytlar JS-ni tahlil qilish va tuzish uchun 4 sekundgacha vaqt sarflashadi.

JS va boshqa manbalarni olish va qayta ishlash vaqtidagi omillar va sahifalarni ishlatishga tayyor bo'lishdan oldin foydalanuvchilarni biroz kutib turishlari ajablanarli emas. Bu erda albatta yaxshi ish qilishimiz mumkin.

Sizning sahifangizdan tanqidiy bo'lmagan JavaScript-ni olib tashlash, uzatish vaqtini kamaytiradi, protsessorni saralash va kompilyatsiya qilish va xotira sarfi. Bu shuningdek, sizning sahifalaringizni tezroq interaktivlashtirishga yordam beradi.

Bajarish vaqti

Bu shunchaki tahlil qilish va tuzish emas, balki qimmatga tushishi mumkin. JavaScript-ning bajarilishi (bir marta ishlangan kod sintaksiya qilingan / tuzilgan) asosiy ipda bajarilishi kerak bo'lgan operatsiyalardan biridir. Uzoq vaqt davomida ishlash, foydalanuvchi saytingiz bilan qanchalik tez o'zaro aloqa qilishi mumkin.

Agar skript 50 millimetrdan ko'proq vaqtni ishlasa, vaqtni interaktivlashtirish JS-ni yuklab olish, kompilyatsiya qilish va bajarish uchun qancha vaqt kerak bo'lsa, kechiktiriladi - Aleks Rassel

Ushbu muammoni hal qilish uchun JavaScript asosiy qismni blokirovka qilmaslik uchun kichik qismlarga bo'lgandan foyda oladi. Bajarish paytida qancha ish bajarilishini qisqartirish mumkinligini bilib oling.

JavaScript etkazib berish narxini pasaytirish usullari

JavaScript-ni sekinlashtirish uchun vaqtni tahlil qilish / kompilyatsiya qilish va tarmoq uzatish vaqtini saqlashga harakat qilsangiz, marshrutga asoslangan chunking yoki PRPL kabi yordam beradigan naqshlar mavjud.

PRPL - bu tajovuzkor kodni ajratish va keshlash orqali interaktivlikni optimallashtiradigan naqsh:

Qanday ta'sir ko'rsatishi mumkinligini tasavvur qilaylik.

Biz V8-ning Runtime Call Stats-dan foydalangan holda mashhur mobil saytlar va Progressive Web-ilovalarning yuklanish vaqtini tahlil qilamiz. Ko'rinib turibdiki, tahlil qilish vaqti (to'q sariq rangda ko'rsatilgan) ushbu saytlarning ko'p vaqtlarini sarflaydigan vaqtning muhim qismi:

Wego, PRPL-ni ishlatadigan sayt, o'zlarining yo'nalishlari uchun vaqtni tahlil qilish vaqtini tejashga imkon beradi va juda tez interaktiv bo'ladi. Yuqoridagi boshqa ko'plab saytlar o'zlarining JS narxlarini pasaytirishga harakat qilish uchun kodlarni ajratish va ishlash byudjetlarini qabul qildilar.

Boshqa xarajatlar

JavaScript sahifa ishiga boshqa yo'llar bilan ta'sir qilishi mumkin:

  • Xotira. GC (axlat yig'ish) tufayli sahifalar tez-tez ko'rinib turishi yoki pauza qilishi mumkin. Brauzer xotirani talab qilganda, JS ijrosi to'xtatiladi, shuning uchun tez-tez axlat yig'adigan brauzer ishlashni biz xohlaganimizdan ko'ra ko'proq to'xtatib qo'yishi mumkin. Xotiralarni bo'shatish va sahifalarni bo'shatish uchun tez-tez gc pauzalarning oldini oling.
  • Ish paytida, uzoq vaqt ishlaydigan JavaScript asosiy javobni berkitadigan sahifalarni blokirovka qilishi mumkin. Ishni kichikroq qismlarga ajratish (rejalashtirish uchun requestAnimationFrame () yoki requestIdleCallback ()), javob berish muammolarini kamaytirishi mumkin.

Progressiv otish

Ko'pgina saytlar interaktivlikning qimmati sifatida tarkibiy ko'rinishni optimallashtiradi. Katta JavaScript to'plamlari mavjud bo'lganda, birinchi tez bo'yoqni olish uchun ishlab chiqaruvchilar ba'zan server tomon ko'rsatishni qo'llaydilar; keyin JavaScript nihoyat olinishi bilan voqea ishlov beruvchilarini biriktirish uchun uni "yangilang".

Ehtiyot bo'ling - bu o'z xarajatlariga ega. Siz 1) umuman olganda, bizning interaktivligimizga turtki beradigan kattaroq HTML javobini yuborasiz, 2) foydalanuvchini to'liq bo'lmagan vodiyda qoldirib ketishingiz mumkin, bu erda tajriba yarmi JavaScript qayta ishlanmaguncha interfaol bo'lolmaydi.

Progressive Bootstrapping yaxshiroq yondashuv bo'lishi mumkin. Minimal funktsional sahifani yuboring (faqat mavjud yo'nalish uchun zarur bo'lgan HTML / JS / CSS-dan iborat). Ko'proq resurslar kelishi bilan, ilova qo'shimcha funktsiyalarni yuklab olishi va qulfini ochishi mumkin.

Pol Lyuis tomonidan tasvirlangan progressiv bostraraping

Ko'rilganga mutanosib ravishda yuklash kodi bu muqaddas panjara. PRPL va Progressive Bootstrapping - bu bajarishga yordam beradigan naqshlar.

Xulosa

Transmissiya hajmi past tarmoqlarda juda muhimdir. CPU ulangan qurilmalar uchun tahlil qilish vaqti muhimdir. Bu past narsalarni saqlash.

Jamoalar JavaScript-ni uzatish va tahlil qilish / tuzish vaqtlarini past darajada ushlab turish uchun qat'iy byudjetlarni o'zlashtirishda muvaffaqiyat qozonishdi. Alex Rassellning mobil telefonlar uchun byudjetlari to'g'risida ma'lumot olish uchun "Siz bunga erisha olasizmi? Haqiqiy dunyo bo'ylab veb-ishlab chiqarish byudjetlari" ga qarang.

Qabul qilingan me'moriy qarorlar bizni

Agar siz mobil qurilmalarga mo'ljallangan sayt yaratayotgan bo'lsangiz, vakillik uskunalarida ishlab chiqishga harakat qiling, JavaScript-ni tahlil qilish / tuzish vaqtini kam saqlang va jamoangizning JavaScript xarajatlariga e'tibor berishini ta'minlash uchun Ishlash byudjetini qabul qiling.

Ko'proq ma'lumot olish

  • JavaScript-ni ishga tushirish
  • Veb-faoliyat krizisini hal qilish - Nolan Lawson
  • Sizga berolasizmi? Haqiqiy dunyodagi ishlash byudjetlari - Aleks Rassel
  • Veb-ramkalar va kutubxonalarni baholash - Kristofer Baxter
  • Cloudflare-ning Brotli bilan siqishni bo'yicha tajribasi natijalari (Brotli-ning yuqori sifatliligi yuqori dinamikasi boshlang'ich sahifani ko'rsatishni kechiktirishi mumkin.
  • Ishlash Fyuchers - Sam Sakkone

Nolan Lavson, Kristofer Baxter va Jeremi Vagnerga o'z mulohazalari uchun tashakkur.