Оптимизация веб-сайта: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
страница все вместе,вы,несомненно, должны сосредоточиться на ней. Но  Вы должны получить реальные цифры для вашего приложения, прежде чем принять решение.

Надо сказать,что я буду теперь заходить и читать книгу Стива,которую он любезно подписал для меня,чтобы получить большую скорость загрузки веб-сайта,начиная  с переднего конца оптимизации.