Оптимізація веб-сайту: frontend і backend.

Відео: Як збільшити швидкість завантаження сайту (оптимізація фронтенда для Google PageSpeed)

Як то, я відвідав одну конференцію і це було досить цікаве і варте захід, що б його відвідати, а також це було дуже приємно побачити проблеми не виходячи за рамки Apache, PHP, Memcache і MySQL.На конференції було багато розмов зосереджено на тому, що називається "FrontEnd" .Смисл Frontend НЕ frontend веб-сервера, широко використовується в різних архітектурах, а скоріше, оптимізація на стороні клієнта - як зробити, щоб браузер не просив, зробити їх паралельно, знайти дані і виконати на стороні клієнта швидше.

Були згадані веб-сайти на Alexa 10, як правило, 80-90% сторінок відповідь приходить долгоі залежить від інших речей, ніж вибірка HTML-головної сторінки завантаження, CSS, javascript, зображення, що робить, одну річ, щоб зосередити свою увагу на оптимізації ПО.

Я з цим згоден в повному обсязі по ряду причин.



перше - багато людей зосереджені на Backend оптимізації по-перше, на моніторингу та графічних налаштуваннях, розміщених на головній HTML-сторінці, і це означає, що досить часто ми говоримо про сайти, які мають відносно добре оптимізовані механізми, але не витрачали час на frontend оптимізацію У цьому випадку не є великою несподіванкою, що є більш низько розташовані елементи на frontend частини. Ми часто зустрічаємося з людьми, з менш оптимізованим механізмом з деяких сторінок (пошук, звіти і т.д.) до хвилини для завантаження, що робить ці кілька секунд, які ви можете забрати на стороні клієнта.

Друге - ставки для backend оптимізації вище. Якщо ви не оптимізували ваш веб-сайт, Frontend у вас буде гірше з форумами
- користувачі можуть не займатися так активно, покинути ваш сайт швидше, чи не буде конверсіі.Ето дуже важно.Однако якщо ви не оптимізували досить backend, щоб обробити вашу навантаження, ваш веб-сайт може стати просто перевантажений і умрёт.Помніте всі ці "slashdotted "або" techcrunched "сайти, на які я пішов тому, що їх кінець просто був не готовий.

По-третє - навіть якщо ваші backend досить швидкий, то це говорять, що ви можете мати відповідно до 100 мс часу відгуку головною HTML-сторінки і є ще причини для оптимізації цього, особливо, для великомасштабних систем. Якщо ви можете прийти з ідеєю для забезпечення меншого часу на реакцію, тільки знизивши апаратні вимоги, ви можете заощадити на апаратних засобах, функціях і операціях, які є значними витратами на реалізацію великих проектів. Я б сказав, тут не ті ж правила, які застосовуються для оптимізації, якщо ви проводите 90% часу працюючи з PHP-кодом і тільки 10% вибіркою даних з бази даних MySQL, тоді не має сенсу, щоб зосередитися на MySQL оптімізація.Еслі 90 % йде на інші завдання, ніж подавати ваші HTML
сторінка все разом, ви, безсумнівно, повинні зосередитися на ній. Але Ви повинні отримати реальні цифри для вашого застосування, перш ніж прийняти рішення.

Треба сказати, що я буду тепер заходити і читати книгу Стіва, яку він люб`язно підписав для мене, щоб отримати більшу швидкість завантаження веб-сайту, починаючи з переднього кінця оптимізації.

Відео: Збирачі фронтенд проектів. Для чого це потрібно, і чому я цим не користуюся

P.P.S. Якщо у Вас є питання, бажання прокоментувати або поділитися досвідом, напишіть, будь ласка, в коментарях нижче.

Відео: WebCamp: Developer Day. Frontend. Ігор Шамілов `Оптимізації сайтів / додатків для моб. платформ`

Поділися в соц мережах:
Cхоже

Увага, тільки СЬОГОДНІ!