публикувано на 28 януари 2020 г. | около 9 минути за четене

отслабване

През последните няколко месеца прекарах доста голяма част от времето, работейки за минимизиране на натоварването на страницата на моя уебсайт. Когато за първи път се преработих от Wordpress. Разбира се, предишният сайт беше масивен; Мисля, че бях натоварен някъде около 2 MB страница с всички скриптове и снимки с висока разделителна способност и други неща. Една от целите ми с преустройството в Hugo беше да го намаля, но не можах да го направя наведнъж - трябваше да направя няколко стъпки, за да стигна до мястото, където съм сега, и процесът със сигурност не беше без хълцане (най-любимо ми беше времето, когато качих 30 MB JPEG в един от публикациите си и изобщо не го оразмерявах). Независимо от това, мисля, че вероятно съм стигнал нещата до най-доброто място, на което могат да бъдат в този момент, като същевременно ми позволява да работя по начин, по който ми е удобно. В тази публикация бих искал да прегледам стъпките, които предприех, за да стигна до мястото, където съм днес.

Преоразмеряване на изображението в Hugo

Вероятно има много по-ефективни начини за това, но идеята беше да се дублират куп различни свойства от шорткода в евентуалния маркер на изображението. Longdesc единственият, който наистина се откроява като уникален; за това създадох ресурс в пакета на страницата, за да соча към текстов файл със същото име като изображението, за което се отнася. Не използвам това често, но понякога е необходимо (особено за колажи от снимки).

След внедряването на този къс код видях, че размерът на страницата ми - и по-важното - времето за зареждане на страницата ми - драстично спада - 50% или повече, на страници с изображения. Все още трябваше да свърша много работа.

Премахване на уеб шрифтове

От доста време обслужвах няколко шрифта на Google - Lora и Raleway - като част от всяко зареждане на страница. Правих това по съображения за дизайн, но в крайна сметка реших, че честотната лента не си заслужава и шрифтовете на браузъра така или иначе са добре, затова просто ги изпуснах от CSS и спрях да ги зареждам. Спести ми още две заявки и добра част от честотната лента.

По същия начин използвах Font Awesome - който е страхотен пакет с икони на уеб-шрифт - за икони на моя уебсайт. Премахвайки го и замествайки връзките с думи, почувствах, подобрих достъпността и наистина не нараних дизайна (погледнете долния колонтитул, както изглежда днес). Това беше още едно доста лесно решение - само няколко бързи промени в темата - и ми спести мегабайта на ден в честотна лента.

Умалете HTML

Това е много глупаво и много лесно. Току-що започнах да изграждам сайта си Hugo с hugo --minify вместо само с hugo и той премахна всички излишни интервали. Изобщо няма проблеми и е най-лесното нещо в света да го добавите в процеса на изграждане - просто модифициране на една команда.

Премахване на jQuery

Често използвам jQuery в моите проекти, защото знам как да го използвам и ми е удобно 3. jQuery е 29 KB, когато е gzipped и умален, което трябва да ви покаже колко далеч сме в заешката дупка тук - в десетките килобайта сега, вместо в мегабайтите, с които имах работа преди. И все пак това, заедно с моя CSS, беше най-големият двигател на честотната лента по времето, когато започнах да го разглеждам, така че беше следващият, който в крайна сметка беше малко по-голям асансьор. За щастие не използвах нито една от функциите на Javascript на Bootstrap, така че не трябваше да се притеснявам за това - но всички JavaScript на моя уебсайт бяха силно jQuerified, така че това означаваше пренаписване на системата ми за коментари и формата за контакт в чист JavaScript и след това парче тестване, за да се уверя, че не съм объркал нищо.

Умалете CSS

От самото начало на този сайт сме минифицирали и групирали CSS, използвайки вградените Hugo. Първата ми итерация изглеждаше по следния начин:

Работи добре, но все още опаковах целия Bootstrap, когато наистина използвах само основния стил и това нямаше смисъл. Bootstrap не е малка CSS рамка, тъй като такива неща се измерват и като се има предвид колко малко от него използвах, наистина нямаше смисъл да обслужвам цялото това нещо, но със сигурност нямаше да вляза и изрязвам всички неща, които не съм използвал, особено ако в крайна сметка ще използвам стила в бъдеще.

От известно време търсих начини да направя това с помощта на Hugo Pipes и просто ми се стори наистина сложно. Накрая просто реших да захапя куршума и да се справя с него и настроих PostCSS и неговия плъгин purgecss като част от моя компилационен конвейер. Използвах нишка на форума на Hugo като моята точка на прескачане и действителното изпълнение в крайна сметка беше доста лесно. Всичко, което трябваше да направя, беше да инсталирам node и npm, да изградя config.json и да стартирам npm install - и след добавяне на подходящите файлове към моята тема Hugo, тя работи перфектно. Единственият основен проблем, с който се сблъсках, е, че трябваше да се уверя, че всеки клас на CSS, който зареждах динамично или директно препращам към публикация, беше изброен в моя бял списък purgecss в postcss.config.js:

Повечето от тях са стилизирани от системата за коментари - и без този бял списък никой от тях не би работил в публикувания сайт. След като това беше на място, актуализирах своя CSS код за изграждане:

Общата идея е, че щях да обединя всичко заедно, след това да стартирам всички неща от PostCSS, за да дедупликирам правилата и да извадя всичко, от което не се нуждаех - и се получи! Като цяло, мисля, че изпуснах около 90% от CSS на сайта си - просто куп неща, които изобщо не бяха използвани. Плюс това, оригиналният Bootstrap CSS файл все още присъства в темата - така че ако в крайна сметка използвам повече функции на Bootstrap по-късно, PostCSS автоматично ще актуализира моя CSS, за да включи тези функции.

Обобщавайки

Тук има много неща, които не изглежда да имат огромна разлика, нали? Например какви са 20 KB тук или там в голямата схема на нещата? Начинът, по който го гледам, обаче наистина започва да има значение, когато работите в мащаб. Икономиите от 20 KB, разпределени в хиляди или милиони зареждания на страници, наистина могат да започнат да се събират и затова мисля, че за натоварени уебсайтове и особено за ситуации, когато плащате за своята честотна лента, е изключително важно да намалите всеки ъгъл, който можете 4. Всички горепосочени промени в крайна сметка намалиха честотната лента с около 70% от стартирането на уебсайта ми. За мен това все още е цена, измерена в центове на месец, но за сайт с интензивен трафик, използващ CloudFront, може да е много по-голяма разлика. Вероятно най-важното обаче е потребителското изживяване; намалявайки заявките надолу и намалявайки размера на страницата, вие правите съдържанието си по-достъпно в целия спектър от потребители на интернет, от хора на гигабитово влакно до хората, които все още използват комутируема връзка. Бих казал, че моят сайт е доказателство, че е възможно да се направи това, без да се нарушава четливостта или философията на дизайна.

Отчетът за популярни обекти, намиращ се в конзолата CloudFront, е изключително полезен за това - можете да сортирате по общия брой обслужвани байтове, което намерих за много полезно. ↩︎

Един от тези дни бих искал да публикувам основна макара на някои от любимите ми снимки, които съм направил, но това е проект, който засега е на заден план. ↩︎

Голяма част от това за мен беше задвижвано от Bootstrap, използвайки го; Bootstrap е единствената CSS рамка, която всъщност знам как да използвам (да, знам, ужасно съм) и която пакетира jQuery, така че беше естествено продължение за мен просто да напиша всичко в jQuery. ↩︎

В рамките на разумното. Например не изрязвам изображенията напълно от уебсайта си, но взимам информирани решения за това как ги използвам и как се показват на сайта. ↩︎