Разяснения за PageSpeed/PageSpeed Insights

@momcheto - напротив, орязване е, когато нещо не може да се оптимизира, тъй като е външно зареждан ресурс, в т.ч. тракинг кодове. Да, има заобикалящи начини с локално зареждане на такива ресурси (поне имаше, скоро не съм тествал новите кодове на GA), но струва ли си занимавката, реално да лъжеш собствените им инструменти.

Отделно - трябва ли да се чувствам принуден да не използвам jquery, защото не е окей за оценката - по мое мнение не.

Няма особен смисъл да чоплим емаг - 80% от трафика е мобилен към 20% десктоп. Конверсията в общия случай при mobile е по-висока (зависи от нишата).
 
Последно редактирано:
От какво да режем? Разкрах амен всичко гугълско, няма повече някъде
 
Но да се върнем на темата - emag имат оценка 38 mobile и 84 за desktop (за заглавната страница), но по-важното е, че въпреки тези бъгави оценки, сайтът зарежда за около 1.5 секунди (тест от чист браузър, през chrome). Аз също имам сайт с ниски оценки, който зарежда за малко повече от 1 секунда, и това е онлайн магазин.

За да се стигне висока оценка, трябва да се орежат неща, което вреди на UX. А ux е много по-важeн фактор и за бизнеса и за авторитета на сайта в google. Тука сега ще слагаме разни плъгинчета, да излъжем инструмента, и какъв е смисъла.. Такива сайтове с този нитропак точно в девета глуха се намират, мерси, ако смятате, че това ще избута сайта ви - успех :)
Твоето разбиране за "зареждане" вероятно се разминава с това на Гугъл.
За Г. са важни: First Contentful Paint, Largest Contentful Paint и Time to Interactive. Плюс разни други междинни случки м/у тях.

От тях зависи и UX-a, тъй че това "трябва да се орежат неща, което вреди на UX" няма особен смисъл. Добър UX не значи гледай бяла страница 1.5 секунди докато изведнъж всичко светне в пълния си блясък.

Пълното зареждане като цяло се игнорира - най-голямата картинка може и на 10-тата секунда да зареди и няма да ти смъкне от оценката заради тоя факт.
 
@momcheto - напротив, орязване е, когато нещо не може да се оптимизира, тъй като е външно зареждан ресурс, в т.ч. тракинг кодове. Да, има заобикалящи начини с локално зареждане на такива ресурси (поне имаше, скоро не съм тествал новите кодове на GA), но струва ли си занимавката, реално да лъжеш собствените им инструменти.

Отделно - трябва ли да се чувствам принуден да не използвам jquery, защото не е окей за оценката - по мое мнение не.

Няма особен смисъл да чоплим емаг - 80% от трафика е мобилен към 20% десктоп. Конверсията в общия случай при mobile е по-висока (зависи от нишата).

Да, има сайтове, които са така направени, че оптимизацията е невъзможна. Съгласен съм. Аз зареждам GA, jquery, bootstrap, както и реклами на всичките ми сайтове и пак постигам 100% на мобилно и десктоп. Всичко е в подхода при зареждането. Най-голям проблем са скриптовете, които зареждаш в <head> секцията, защото те блокират всичко, докато не се заредят.

Мобилен през браузър или през приложенията им в AppleStore/PlayStore. За приложенията не важи.
Конверсията не зависи толкова от устройството, а от потребителското усещане и предлаганите стоки или услуги. Ако ти е бъгав сайтЪТ на мобилно, естествено, че ще имаш по-голямо отпадане, отколкото на десктоп.

В момента си в процес на отричане на промените, но наистина успяват тези, които са адаптивни. Непрекъснато идват нови правила или стандарти, не можем да се правим, че не съществуват.
 
Да, има сайтове, които са така направени, че оптимизацията е невъзможна. Съгласен съм. Аз зареждам GA, jquery, bootstrap, както и реклами на всичките ми сайтове и пак постигам 100% на мобилно и десктоп. Всичко е в подхода при зареждането. Най-голям проблем са скриптовете, които зареждаш в <head> секцията, защото те блокират всичко, докато не се заредят.

Искаш да кажеш, че зареждаш jquery във футъра и работи? Независимо дали е в хедъра или футъра, за google е все тая специално jquery, винаги го вади като блокиращ ресурс, ако е в отделна заявка.

Мога да набия всички ресурси в хедъра и да им дам отложено зареждане, да бъдат изпълнени едва когато страницата се парсне, така че няма никакво значение дали са в хедъра или футъра.

Повечето препоръки на Google относно скоростта са добри, в голяма степен са насочени към следното: да не се зареждат предварително ресурси, които към момента на отваряне на страницата не са нужни на потребителя и "блокират изобразяването". Това е окей за:

- css
- js
- изображения, които са извън видимата част на екрана (може да се постигне и с lazy load)

Не е окей за:

- външно jquery, което се зарежда
- шрифтове - при отложено зареждане на шрифтовете, какво вижда първо потребителя - текст без приложения шрифт, вече след това му се зарежда шрифта. За мен не е окей това, само и само да си вдигна оценката, или да ползвам локално хостван шрифт, който по принцип не ми е първи избор.

Също така новите формати на изображенията - голяма част от тях не се поддържат от някои браузъри, например safari. Е, реален ли е резултата от теста на google, при положение, че не се отчита факта, че въпреки, че използвам webp, потребителите със safari, които никак не са малко, реално не им се зарежда толкова бързо, колкото за тези със хром примерно.

А препоръчват ли да се комбинират малки изображения в едно (примерно иконки) и да се визуализират през css, да се обединят по възможност по-малко на брой файлове css и js с цел намаляване броя заявки - не мисля. Това също оказва влияние на скоростта, но не го отчитат особено. Гледат основно дали кодът е минифициран.

В момента си в процес на отричане на промените, но наистина успяват тези, които са адаптивни. Непрекъснато идват нови правила или стандарти, не можем да се правим, че не съществуват.

Не отричам нищо, просто не се водя по "новите правила", защото нито са нови, нито ще оказват толкова голямо влияние. Това е просто оценка. За мен е важно сайтът да се зарежда максимално бързо и добре, заради потребителя, а не заради оценката. Да, следя препоръките, просто защото винаги може да се пропусне нещо, но не търся чийтове, само и само да изкарам добра оценка. Ако сайтът ми зарежда за около 1-1.5 секунди, не мисля, че това е нужно, нито пък че ниската оценка ще ми навреди.
 
Твоето разбиране за "зареждане" вероятно се разминава с това на Гугъл.
За Г. са важни: First Contentful Paint, Largest Contentful Paint и Time to Interactive. Плюс разни други междинни случки м/у тях.

От тях зависи и UX-a, тъй че това "трябва да се орежат неща, което вреди на UX" няма особен смисъл. Добър UX не значи гледай бяла страница 1.5 секунди докато изведнъж всичко светне в пълния си блясък.

Пълното зареждане като цяло се игнорира - най-голямата картинка може и на 10-тата секунда да зареди и няма да ти смъкне от оценката заради тоя факт.

Къде съм казал, че първоначално някой гледа бяла страница? Да, за ux е важен FCP, но дали потребителя прави разлика няколко ms, ако всички важни неща си ги изпълнил. И да, орязване е, когато правиш компромис с неизползването на ресурси, които пречат на оценката - бяла страница ли виждате като отворите emag? Лош UX ли имат потребителите, заради зарежданите ресурси през : Akamai, GTM, GA, GDA, Google fonts и някои други.
 
Искаш да кажеш, че зареждаш jquery във футъра и работи? Независимо дали е в хедъра или футъра, за google е все тая специално jquery, винаги го вади като блокиращ ресурс, ако е в отделна заявка.

Мога да набия всички ресурси в хедъра и да им дам отложено зареждане, да бъдат изпълнени едва когато страницата се парсне, така че няма никакво значение дали са в хедъра или футъра.

Повечето препоръки на Google относно скоростта са добри, в голяма степен са насочени към следното: да не се зареждат предварително ресурси, които към момента на отваряне на страницата не са нужни на потребителя и "блокират изобразяването". Това е окей за:

- css
- js
- изображения, които са извън видимата част на екрана (може да се постигне и с lazy load)

Не е окей за:

- външно jquery, което се зарежда
- шрифтове - при отложено зареждане на шрифтовете, какво вижда първо потребителя - текст без приложения шрифт, вече след това му се зарежда шрифта. За мен не е окей това, само и само да си вдигна оценката, или да ползвам локално хостван шрифт, който по принцип не ми е първи избор.

Също така новите формати на изображенията - голяма част от тях не се поддържат от някои браузъри, например safari. Е, реален ли е резултата от теста на google, при положение, че не се отчита факта, че въпреки, че използвам webp, потребителите със safari, които никак не са малко, реално не им се зарежда толкова бързо, колкото за тези със хром примерно.

А препоръчват ли да се комбинират малки изображения в едно (примерно иконки) и да се визуализират през css, да се обединят по възможност по-малко на брой файлове css и js с цел намаляване броя заявки - не мисля. Това също оказва влияние на скоростта, но не го отчитат особено. Гледат основно дали кодът е минифициран.



Не отричам нищо, просто не се водя по "новите правила", защото нито са нови, нито ще оказват толкова голямо влияние. Това е просто оценка. За мен е важно сайтът да се зарежда максимално бързо и добре, заради потребителя, а не заради оценката. Да, следя препоръките, просто защото винаги може да се пропусне нещо, но не търся чийтове, само и само да изкарам добра оценка. Ако сайтът ми зарежда за около 1-1.5 секунди, не мисля, че това е нужно, нито пък че ниската оценка ще ми навреди.

E, значи не си съвсем извън тематиката. ДА, числата нямат значение, защото всичко зависи от Field Data, а тя се базира на реални данни. Ако потребителите посещават само от безплатни мрежи... нещата ще изглеждат много зле. Там зареждането винаги ще е бавно.

JS-а го бутам във футъра винаги. В моя сценарий е ОК. А ако го заредиш с отлагане въобще не го отчита като блокиращ ресурс. CSS не мога да го изключа, обаче, установих, че ползвам едва 15-20% от всички правила на темата и го редуцирах 6 пъти и само той показва, че забавя с 0.20 сек., но е с предупредителен знак, а оценката си е 100%.

За влиянието - предполагам, че няма да е критично. Все пак има много други фактори, но не се знае. Можем да спекулираме по темата, то и Гугъл сигурно не могат да гарантират. Ако сайтовете са локални е по-лесно. Но ако говорим за INTL сайтове, които не ползват CDN, но имат трафик от различни места... си е критично.
 
JS-а го бутам във футъра винаги. В моя сценарий е ОК.

Точно, че зависи според сценария. Ако ползваш готов cms, все някой от модулите може да ти забие Inline js, който няма да работи ако заредиш отложено файла или го сложиш във футъра. Същото важи и при нужда от някаква функционалност, при която се налага да сложиш inline js. в бодито. Друг е въпроса, че може и по-културно да си внедриш нужната функционалност, без да се слага inline, но не всеки има нужните познания, особено ако става дума за нещо по-сложно като реализация. Форумът е пълен със специалисти програмисти и оптимизатори, предполагам някой от тях ще даде съвет, евентуално за заобикаляне на този проблем.
 
Къде съм казал, че първоначално някой гледа бяла страница? Да, за ux е важен FCP, но дали потребителя прави разлика няколко ms, ако всички важни неща си ги изпълнил. И да, орязване е, когато правиш компромис с неизползването на ресурси, които пречат на оценката - бяла страница ли виждате като отворите emag? Лош UX ли имат потребителите, заради зарежданите ресурси през : Akamai, GTM, GA, GDA, Google fonts и някои други.
Няколко пъти съм се улавял да затворя сайт ако не ми зареди за 2 секунди или е прекалено наспамен с попъпи. Особено на мобилно. Или такива дето имат твърде много shifts... ужасно е да ти се избутва съдържанието непрекъснато.
Точно, че зависи според сценария. Ако ползваш готов cms, все някой от модулите може да ти забие Inline js, който няма да работи ако заредиш отложено файла или го сложиш във футъра. Същото важи и при нужда от някаква функционалност, при която се налага да сложиш inline js. в бодито. Друг е въпроса, че може и по-културно да си внедриш нужната функционалност, без да се слага inline, но не всеки има нужните познания, особено ако става дума за нещо по-сложно като реализация. Форумът е пълен със специалисти програмисти и оптимизатори, предполагам някой от тях ще даде съвет, евентуално за заобикаляне на този проблем.

Да, по-нагоре написах, че CMS платформите са тегави за оптимизация, щото зареждат всякакви плъгини, теми, които в общия случай не отговарят на конкретни стандарти. Затова няма универсално решение.
 
За wp ще споделя малко опит след тест на тези 2 плъгина:

1. NitroPack (Free)

Плюсове:

+ Вдигна скора на сайта в https://developers.google.com/speed/pagespeed/insights/ от 20 до 55 за мобилно оранжево (средна стойност след 5 run-a), а за десктоп го направи зелено, но не си спомням колко беше преди това.
+ Не счупи нищо по сайта.

Минуси:
- Изисква регистрация.
- Слага един тъп бадж отдолу ако е фрее версията (премахва се от php кода на плъгина, но ако го ъпдейтнеш по някое време ще го върне.)
- Има някакъв лимит на трафика или на големината на сайта, така и не разбрах какво точно ти лимитира free версията (5gb лимит) за 2 дни тест бях стигнал до 1gb и нещо, не съм сигурен дали прогресивно щеше да нараства или след като ми е изтеглило файловете до там спира.
- Изисква да се правят CDN настройки (да си слагате акаунт логините и т.н)


2 - PageSpeed Ninja (Free)

Плюсове:

+ Вдигна скора на сайта в https://developers.google.com/speed/pagespeed/insights/ от 20 до 65 за мобилно - оранжево (средна стойност след 5 run-a), а за десктоп го направи зелено, при настройка "optimal" без да чупи нищо по сайта.
+ Елементарен за настройване, буквално ми отне 2 минути да го инсталирам и да цъкна настройката "optimal"

Минуси:
- При настройване ако изберете повече от "optimal" има голяма вероятност да ви счупи нещо по сайта, но се оправя като спрете плъгина.

---------------------------
Нямам идея дали просто манипулират скора в този тул или реално забързват сайта, аз лично не намирам разлика в зареждането. Зарежда си еднакво бързо.
 
Толкова ти разбира главата от бизнес, като 80% от членовете на форума..... като нямаш грам опит, просто не губи на другите времето със твоите глупости.

Към собственика на темата: Ако искаш сериозна оптимизация на Opencart/Wp/Magento или друга система, ние сме хората и ще получиш поддръжка 12 месеца горница да спиш спокойно, просто ако ще правиш бизнес няма да мислиш като всички тук, бързината е важна много, големите магазини залагат на дневен бюджет 10 хиляди лева за реклама на няколко канала, малкият бизнес не може да си позволи такива пари и заради това залага на изисквания, бързина, добър дизайн, обслужване.

Ако искаш бързина, трябва да е back-end и front-end. Много важно да следиш след оптимизация дали всичко е счупено ако се прави от непрофесионалист, иначе почват да не работят бутони, скролвания, рекламите да не се отчитат правилно и само проблеми и си скапваш бизнеса и нервите.

Поздрави,
Станимир И
Screenshot 2021-02-14 at 10.19.07.png

@Станимир И новото LSD явно е добро...
 
Очевидно 24/7 му е поддръжката за плащащи клиенти, не за потенциални клиенти.
 

Горе