Оптимізація веб-сайту:FrontEnd і BackEnd. - все про комп'ютери



Як я відвідав одну конференцію і це було досить цікаве і вартісне захід,що б його відвідати,а також це було дуже приємно побачити проблеми не виходячи за рамки 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. Якщо у Вас є питання, бажання прокоментувати або поділитися досвідом, напишіть, будь ласка, в коментарях нижче.