Как да оптимизираме скоростта на зареждане на уеб-сайт
17 
Скорост на зареждане на уеб-сайт – това е един от основните критерии в техническото SEO . То се състои от две части – колко бързо съдържанието излиза на екрана при зареждане на страницата , което определя как потребителите ще гледат на сайта, ако се зарежда бавно, те могат да решат да не чакат и да напуснат, и как търсещите машини обхождат сайта ви. Важно е да обърнете внимание колко и какви ресурси се налага да използва паяка за да премине през сайта и да го оцени, която влияе на ранкинга на целия сайт.
Скоростта на зареждане влияе първо на потребителите.
Сайтът ви може да изглежда чудесно, да е пълен с много полезно съдържание, но ако един съвременен интернет потребител му се налага да чака повече от 3 – 4 секунди без да види нещо, което да му привлече вниманието, той започва да губи интерес. След 10 секунди, ако сайтът не се е заредил, най-вероятно той вече е в друг сайт.
Ето няколко основни съвета как да избегнете този момент
- Преценете къде се намира евентуалната аудитория, за която е предназначен сайтът ви и се постарайте сървъра, на който се хоства той да e максимално близко. Сайт, който трябва да се зареди от другата страна на света обикновено се зарежда по-бавно. Има няколко допълнителни фактора в тази връзка.
- Хостинг – Къде е се намират файловете на сайта ви – на каква машина е качен, какво натоварване може да поеме тя, до колко ресурсите на машина са достъпни за него, дали и как дели въпросните ресурси с други сайтове. Колко е добра връзката на въпросната машина с интернет и колко близо е тя до основните магистрали… Има много критерии които определят хостинга. Има компании, които предлагат такъв хостинг, ако не желаете да използвате собствена специализирана машина или се съмнявате в стабилността или качеството на интернета си. Има разбира се и cloud услуги, което може да реши доста от проблемите със скоростта.
- Обърнете внимание на структурата и размера на сайта си – колкото е по-голям толкова по-бавно се зарежда. Разбира се има и определени техники да се заобиколи (или поне да се намали влиянието на) този проблем.
Защо точно тези критерии?
Тези критерии имат и сериозно влияние над това как Гугъл и другите търсещи машини гледат на сайта Ви. Има редица софтуерни тулове (инструменти) , чрез които можете да видите подробно как става това. Както и доста препоръки как се справите с проблемите, които софтуерите, които симулират crawlers (ботовете на търсачките), намират по сайта Ви.
Вероятно и защото разработчиците им се надяват, че ще седнете и ще се опитате да направите нещо по въпроса – така паякът ще може да мине през сайта ви по-бързо и лесно и те ще изразходват по-малко ресурси да се занимават с него :). Такова поведение често се възнаграждава с подобрения в класирането по страниците на Гугъл.
Такива инструменти са например PageSpeed Insights на Гугъл. Както и GTMetrix. Те са безплатни и доста удобни. Има разбира се и други, често платени инструменти, които предлагат и по-задълбочен преглед на тези и други страни на сайта ви, например Semrush. Но понеже това е статия, разглеждаща основно скоростта (site speed testing), няма да се спираме на тях.
Доста от критериите на PageSpeed и GTMetrix се припокриват, затова да започем от PageSpeed .
Page Speed Testing – един от основните инструменти за тестване на скорост на зареждане на сайт
Намаляване на времето на реакция на сървъра
Колко бързо реагира сървърът, на който е качен сайта ви. Този критерий го покрихме по-горе – тази скорост зависи от разположението на машината, каква, с какви ресурси разполага и т.н. Гледайте по-възможност тази скорост да е до 0.20 секунди. Това е идеалният вариант.
Ако тази скорост е доста по-висока – над 1 секунда, няма да е лошо да преосмислите решението си къде да хоствате сайта си. Или поне да дискутирате изискванията и възможностите с доставчика си.
Имайте предвид, че тази стойност е доста варираща и зависи и от доста външни фактори, които той може и да не може да промени – например доколко е натоварена мрежата в момента на теста.
Избягване на пренасочвания от целевата страница
Постарайте се основните ви страници да нямат пренасочвания. Когато една страница се зарежда, браузърът се обръща към машината, осъществява се връзка, тегли се код и се използват ресурси. Когато имате пренасочвания тези ресурси за първото обръщение се прахосват – това забавя зареждането. Ако имате redirect chain (поредица от пренасочвания към URL) с повече от два редиректа е дори по-зле.
Оптимизирайте размера изображенията
Постарайте се изображенията, които се зареждат на сайта ви да минимални като размер, за да спестите възможно най-много KB. По-малък размер – по-бързо зареждане. Това се осъществява основно по два начина –
1. Компресирайте медия файловете (jpg,png и т.н) – често програмите за обработка на изображенията го имат някъде в опциите си. Ако не ви се занимава, има и външни инструменти – например TinyJPG. Просто прекарайте изображенията през тях преди да ги ъплоднете на сървъра (или заместете вече ъплоаднатите изображения, когато видите че гугъл се сърди). PageSpeed дава и собствени оптимизирани файлове, които можете да изтеглите при анализ на сайта си.
2. Постарайте се размерът на изображенията, които се визуализират да е сходен с размера на самите изображения – Ако имате картина, която се показва на екрана с размер 300х200 рх е добре да я визуализирате с файл с изображения с такива размери, а не с 900х600 например.
Разликата в размерите на файловете в KB е значителна. Може да се наложи да използвате доста варианти на една и съща снимка в сайта си, за да се справите с този проблем при Responsive дизайн. WordPress, а и повечето други системи често вършат част от тази работа автоматично.
Активирайте компресирането
Функция на сървъра. Има я често и като допълнителна опция в доста системи за разработка, в допълнителни плъгини, допълнения и т.н. Компресиран, сайтът ви е значително по-малък и компактен при изтегляне и това се оценява. Сървърът ви трябва да бъде обаче конфигуриран, така че да поддържа тази фунционалност.(mod_deflate, mod_gzip или друг модул при различните операционни системи ).
Пример:
## BEGIN Enable GZIP Compression ##
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript
AddOutputFilterByType DEFLATE application/x-httpd-php
AddOutputFilterByType DEFLATE application/x-httpd-fastphp
AddOutputFilterByType DEFLATE image/svg+xml
SetOutputFilter DEFLATE
</IfModule>
## END Enable GZIP Compression ##
Минимизирайте HTML, Минимизирайте CSS, Минимизирайте JavaScript
Целта е отново да се намали размера на ресурсите на сайта ви. Постарайте се да имате възможно най-малко излишни байтове в кода си – коментари, пояснения и т.н., които не извършват никаква полезна дейност. Ако уебсайтът ви е базиран на популярна CMS система, то има плъгини, допълнения и други инструменти, които могат да поемат тази част автоматично.
Или можете да използвате собствен код, ако не желаете да се натоварвате с такива опции. Оптимизирани копия на CSS и JS файловете могат да се изтеглят от страницата на PageSpeed анализа.
Възползвайте се от кеширането на браузъра
Браузерите , които използваме обикновено имат възможността за кеширане на статични файлове от сайтовете, които посещаваме, картинки, скриптове, стилове, цели страници. Така тези файлове се съхраняват на нашите устройства и при следващо посещение на сайта те може да не се свалят от него, а да се зареждат от самия кеш, намалявайки значително скоростта на зареждане на сайта.
Разбира се различните сайтове имат различни политики и изисквания при това кеширане – при един електронен магазин например продуктите му се актуализират постоянно, а не се показва кеширана версия от преди ден. Затова има възможност сайтът да дава на браузера ви указател кога кои от кешираните файлове са актуални и кога трябва да се изтеглят отново. Обикновено това се установява във файла .htaccess в основната папка на сайта ви. Необходимо е, обаче и сървърът да бъде конфигуриран да поддържа тази функционалност (mod_expires).
Пример ( общо взето универсално използване ) за влагане в .htaccess
EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>
## EXPIRES CACHING ##
Даденият код извършва следното: определя периода за изтичане на актуалността на някои основни видове статични файлове – jpg, png, gif, css, js и други. Друг сериозен проблем е, че не винаги имате възможността окажете дали един такъв файл може да се кешира или не.
Какво да правим с външните с ресурси?
Когато използвате външни ресурси – analytics, youtube, facebook за пример, тази опция я нямате – те са на съвсем друга машина и съответно не вие определяте дали са актуални или не. Понякога имате възможността, ако си поиграете да хостнете някои от тях на своята машина, но това не винаги е възможно, не и ако тези елементи поддържат връзка със сайта си и искате те да продължат да работят.
Даване на предимство на видимото съдържание
Постарайте се, ако е възможно кодът, представящ видимата част на екрана да се изтегля първи – HTML на видимата част, стиловете и ресурсите необходими за визуализирането му, а останалото след това. За да се постигне това, може да се наложи да разделите CSS стиловете си така, че само тези, необходими за извеждането на въпросната част да зареждат вложени в HTML в началото, а останалото по-късно. Скриптове, които не са необходими за това зареждане също може да е необходимо да се отложат за по-късно.
Премахване на блокиращите изобразяването JavaScript и CSS от съдържанието на видимата на екрана част от страницата
Eдин от най-сериозните проблеми при оптимизирането на един сайт и често един, който е доста трудно да отстрани, дори невъзможно в някои случаи. Проблемът се състои в следното – един сайт обикновено се състои много елементи скриптове, стилове. Колкото е по-голям и сложен е сайтът, толкова повече го съставляват обикновено.
Всеки допълнителен модул или елемент често си влачи свои допълнителни. Проблемът е, че всички те трябва да се заредят, а при традиционно влагане в php или HTML кода, при зареждане на сайта, когато машината стигне до тях, тя спира зареждането на кода си, изтегля си ги, изпълнява ги и чак тогава продължава нататък. Това забавя зареждането на сайта, особено ако всички тези скриптове не са необходими за първоначалното зареждане.
При CSS скриптовете , както споменахме по-горе стиловете на елементите във видимата част е добре да се вложат в кода в началото, останалото може да се зареди по-късно, дали вложено във футъра или отлагане на зареждане на CSS файлове , докато не се зареди основния код.
Някои примери
Пример е такъв вложен JS за зареждане на библиотеката font-awesome във футъра си, които решихме да хостваме на собствения си сървър, вместо да го теглим от техния сървър всеки път ( точка 6 ).
<script type="text/javascript">
function downloadAtOnload() {// Dynamically load CSS
var ls = document.createElement(„link“);
ls.rel=“stylesheet“; ls.href= „/font-awesome/css/font-awesome.min.css“; document.getElementsByTagName(„head“)[0].appendChild(ls); }if (window.addEventListener) window.addEventListener(„load“, downloadAtOnload, false);
else if (window.attachEvent) window.attachEvent(„onload“, downloadAtOnload);
else window.onload = downloadAtOnload;
</script>
Има много начини да се постигне такова отлагане на зареждането на не-критичните стилове, които могат да се намерят в мрежата. WORDPRESS и някои други подобни платформи имат много готови плъгини, модули или разширения които могат да свършат това вместо вас – Autoptimize, Total Cache, Speed Booster Pack и др. Въпросните плъгини (модули, разширения …) вървят и със възможността да направят и същото и за JS файловете. Това обаче често е проблем.
Да се погледнем въпросното отлагане. Обикновено това се осъществява с добавяне на код defer="defer" в скрипта, извикващ въпросния файл.
Пример :
<script src="script.js" type="text/javascript" defer="defer"></script>
Това, което се случва тук е, че когато стигне до този ред браузърът ви вижда, че трябва да зареди въпросния скрипт – script.js . Обикновено това би означавало да го изтегли, изпълни и чак тогава да поднови работата си. Чрез подаването на defer обаче му казваме, че искаме да започне да го тегли, но да продължи работата си и да го изпълни, когато е готов. Поради това, че се теглят много файлове едновременно това не е проблем. Проблем възниква, когато в сайта си имаме друг скрипт, чието изпълнение зависи от това дали горният скрипт вече е зареден, най-често понеже се използват функции, описани в него.
Типичен пример е jquery.js.
Тази библиотека се е утвърдила като основа на много скриптове, поради гъвкавостта си и много си полезни функции. Ако обаче имате скрипт, който я ползва и той се зареди преди нея, то можете да очаквате да получите съобщение за грешка и модулът, използващ въпросния скрипт или няма да тръгне или ще излезе повреден, проваляйки зареждането на сайта ви.
Типичен пример е и Revolution Slider на WordPress.
На теория хората, които го разработват, са се опитали да поправят проблема, но не винаги става. Често единствено решение в такъв случай е да оставите този скрипт да си бъде блокиращ. Ако обаче имате познанията, времето и ресурсите, можете да се опитате да пренапишете или поне да редактирате проблемните скриптове така , че те да не се зареждат докато тези, от които зависят не са готови. Отново – това не винаги е възможно или дори препоръчително, дори да е възможно, особено ако визуални елементи от сайта зависят от тяхното зареждане.
Иначе можете да ползвате и много функции , които да правят тактова отлагане, или просто да си го добавите ръчно, когато е необходимо.
Пример :
function defer_parsing_of_js ( $url ) {if ( FALSE === strpos( $url, ‘.js’ ) ) return $url;if ( strpos( $url, ‘jquery.js’ ) ) return $url;return „$url’ defer „;}add_filter( ‘clean_url’, ‘defer_parsing_of_js’, 11, 1 );
Този стандартен скрипт за WORDPRESS се слага във functions.php и слага defer на всеки js скрипт, който намери. В този случай обаче има сложено изключение за jquery.js (също стандартно).
Добре е да имате предвид и Google AMP, ако сайтът ви има имплементирана тази технология. За да работи AMP , то трябва да зареди своите стандартни скриптове, в противен случай генерира грешки. Като се има предвид, че при стандартно зареждане сайтът ви не се нуждае от тях, е задължително да добавите тези скриптове в изключенията си.
Както можете да прецените, постигането на резултат 100/100 в PageSpeed не е особено лесно за по-голям и сложен сайт, особено за мобилни устройства, където критериите са дори по-сурови. Препоръчваме ви поне да се опитате до го доведете до зелената зона.
GTMetrix
GTMetrix има доста повече критерии, но доста от основните се препокриват с тези на PageSpeed.
Някои изключения, които трябва да се споменат
- Serve resources from a consistent URL – Понякога се налага да използвате определен ресурс ( картинка или скрипт ) няколко пъти в един сайт. При по-голям сайт често е проблем да се помни къде сме го сложили или дали изобщо го зареждаме и го качваме повторно, на ново място. Тази грешка се появява в такъв момент, когато засече зареждане на два еднакви обекта от две различни места. Това се смята за излишни байтове, които трябва да се свалят и се препоръчва ресурсите да се съгласуват така че да се зареждат от един URL.
Enable Keep-Alive – позволява на една текуща сесия да получава и предава множесто HTTP заявки, намалявайки продължителността на зареждане на сайта ви. На теория Apache го зарежда по подразбиране, а и почти всички хостинг компании си го конфигурират да работи по подразбиране. Не би трябвало да е проблем за вас, освен ако не използвате собствен сървър.
Avoid bad requests – постарайте се да нямате лоши заявки – да не използвате линкове или ресурси, чието URL не съществува (грешка 404).
CSS Проблеми
Combine images using CSS sprites – Понякога в сайта си имате малки статични картинки – икони, знаци и т.н. Поради малката си големина се счита, че не е практично да се използват ресурсите, необходими за всяка индивидуална заявка за доставка на всяко от тези файлчета поотделно.
Смята се, че по-добре те да се обединят в един спрайт файл, който да се сваля като цяло, а подаването им в сайта ви би да се подава, чрез CSS, който да реже части от него за всяка картинка. Можете да се опитате да го направите и ръчно, но има готови и свободни инструменти, които могат да ви помогнат с това. Например: https://instantsprite.com/
- Inline small CSS и Inline small JavaScript – Вариант на горното, но за скриптове и стилове. Ако имате малки по размер такива файлове, не би било зле просто да ви вложите в HTML или PHP кода си и да си спестите допълнителните заявки.
В GTMetrix можете да забележите и колоната YSLOW, показваща допълнителни данни за скоростта на зареждането и съответните препоръки.
Use a Content Delivery Network (CDN) – Дали използвате CND кошница, която да хоства статичните ви файлове в мрежата, така че те да са еднакво достъпни от различни части на света. Ако сайтът ви или бизнесът ви е локален, или имате достатъчно добър доставчик, не му обръщайте внимание.
Make fewer HTTP requests и Reduce the number of DOM elements – Постарайте се да имате по-малко HTTP заявки. Всеки отделен файл на сайта ви, който се зарежда генерира заявка. Препоръчва се, когато е възможно – да обедините основните си CSS, скриптове и спрайтове в колкото се може по-малко файлове.
Reduce DNS lookups – Постарайте се да имате колко се може по-малко заявки за ресурси от външни източници – това са допълнителни връзки, заявки и байтове.
Use cookie-free domains – Предавайки статичните си ресурси от домейни без излишните кукита за такъв вид ресурси. Решение – или използвайте CDN, или просто укажете на сървъра си да премахва кукитата от такъв вид файлове. Total Cache го има като изрична опция, но мoжете и да го направите ръчно.
Секцията Page Details
В Page Details секцията можете да видите основните данни за сайта си – колко време е било необходимо за зареждането му, колко е голям целият сайт и колко заявки са били необходими за свалянето му. Както можете да прецените, колкото е по-голям сайтът ви и колкото повече заявки са необходими за свалянето на ресурсите му, толкова по-бавно се зарежда сайтът.
Имайте предвид , че един файл от 1 MB ще се свали в пъти по-бързо от десетина файла, чиято сборна големина е 1MB. Също така вземете под внимание и региона на тестовия сървър на GTMetrix. Сървър на другата страна на света ще достъпи сайта в по-бавно.
Можете да видите как точно се свалят и използват ресурсите на сайта в таблицата Waterfall. На база на тази графика евентуално можете да откриете и други неща, които можете да оптимизирате, за да подобрите скоростта си. Ако тествате сайт с външни ресурси като такъв, който има вградени YouTube видеa или Facebook блокове, ще забележите как те рязко забавят скоростта ви. Затова препоръката ни е, ако не смятате, че такива елементи не са наистина необходими на сайта ви, избягвайте ги, или поне ги ограничете само до страниците на които биха ви били от най-голяма ползва.
В заключение
Оптимизирането на скоростта на зареждане на сайт не винаги е лесно. Може би е добре да добавим, че е добре да помислите за скоростта още в процеса на на дизайн, планиране и изработката на сайта си. Много практики, които биха улеснили изработването му или биха го направили по-ефектен като изглед, практически създават огромни главоболия, ако след това решите да правите оптимизация и създават сериозни пречки на възможностите й. В WordPress за пример това са повечето билдъри, всякакви плъгини и теми, зависещи от jquery и т.н.
Постигането на перфектен резултат е почти невъзможно, но това не значи, че усилието ви в тази насока е излишно. Просто направете каквото е възможно и не се притеснявайте от пропуснатите проценти, за да си осигурите една или друга функционалност. В това се включва анализ на трафика през Google Analytics или удобството на Facebook Widget за блога ви, ако сте решили, че Ви е необходима.
