Обсуждение статьи: «Проблемы ускорения работы веб-сайтов и их решения»

[Александр Сучков]

Сообщение от Александр Сучков

Опубликовали интересную на мой взгляд статью :
"Web saytlarni ishlashishini tezlashtirish muammolari va ularning yechimlari. “InfoCOM.UZ” saytining kamchiliklari va ularni bartaraf etish usullari"
http://uz.infocom.uz/2009/12/21/web-...artaraf-etish/
Muallif: Asror Zokirov

Чтобы статью могли прочитать и обсуждать специалисты на русском языке мы её бегло перевели (за ошибки не ругайте) и версию на русском можно скачать здесь http://infocom.uz/wp-content/files/zakirov.doc
Обсуждаем!
С уважением ко всем

Как мне кажется не обратили внимание на эту статью. Тимура Расулова, Виталия Фиоктистова, Азима Хикматова ... и других ребят программистов (!) очень попросил бы скачать данную статья на русском и дать своё мнение. А то ноутбук вручим , а окажется , что ...
С уважением ко всем

[Renat Akhtyamov]

Сообщение от Александр Сучков

Как мне кажется не обратили внимание на эту статью. Тимура Расулова, Виталия Фиоктистова, Азима Хикматова ... и других ребят программистов (!) очень попросил бы скачать данную статья на русском и дать своё мнение. А то ноутбук вручим , а окажется , что ...
С уважением ко всем

Не скажу, что я большой спец в области оптимизации сайтов, но автор провел неплохой обзор и дал толковые рекомендации. Вообщем-то, каждый веб-разработчик сталкивается с задачами ускорения сайтов и применяет описанные в статье методы для решения.
Статья актуальная, не спорю! Но описанные методы стандартные и широко рассмотрены в рунете.
А сайт infocom.uz действительно открывается не очень быстро. Давно заметил, но не испытывал комплексов по этому поводу.

[Алишер Ашуров]

Сообщение от Александр Сучков

Как мне кажется не обратили внимание на эту статью. Тимура Расулова, Виталия Фиоктистова, Азима Хикматова ... и других ребят программистов (!) очень попросил бы скачать данную статья на русском и дать своё мнение. А то ноутбук вручим , а окажется , что ...
С уважением ко всем

Прочитал статью с интересом. Не знал что можно так просто и быстро оптимизировать сайт. Могу сказать что с трудностями при открытии сайта инфоком.уз сталкиваюсь до сих пор. По моему при прежнем дизайне сайт грузился быстрее. Надеюсь после этой статьи сайт будет загружаться гораздо быстрее . Понравились иллюстрации к статье. Почти все находяться в нужном месте. Большое спасибо автору.

Есть некоторые претензии.
Это во первых: почему-то перечислены программы и плагины для оптимизации, но не даны прямые ссылки на них чтобы скачать.
Во вторых автор использует браузер Файрфокс и его плагины для нахождения некоторых ошибок в коде страниц. Но, например мне, удобно использовать Оперу. Но это так, для заметки.
И ещё, не подумайте занудой, на первый взгляд кажется что статья превышает лимит 20000 знаков в оригинале (на узбекском). Но это конечно не критично.

С уважением.

[Dolphin]

Сообщение от Александр Сучков

Как мне кажется не обратили внимание на эту статью. Тимура Расулова, Виталия Фиоктистова, Азима Хикматова ... и других ребят программистов (!) очень попросил бы скачать данную статья на русском и дать своё мнение. А то ноутбук вручим , а окажется , что ...

Ого! Во-первых, перевод на русский сделан чем-то вроде промта, местами очень труднопонимаемо, что имеется в виду.

Вступление - нормально, стандартная вода. Однако список сервисов, распространненных среди 40% пользователей, довольно странный, имхо.

За последние 5 лет средний объем web-страниц увеличился в 3 раза. А за последние полугодие увеличился в 1,5 раза.

Где пруф? Перечисленные причины - субъективно, и мягко говоря, неправда.

Каждая web-страница на сайтах Uznet загружается вместе в среднем 40 объектами (рисунки, Multimedia файлы, JavaScript, CSS ), а это отрицательно сказывается на общем времени загрузки сайта.

Прямо-таки каждая?

Многие сайты Uznet красивые и богаты данными, но наряду с этим, они в определенном уровне, «тяжелые». Причиной этому считается написание пользователем в сторку адреса браузера (Opera, Firefox, Safari, IE) www.<sayt nomi>.uz до загрузки компьютера проходит много времени.

Телепаты на форуме есть? Отзовитесь... Я не улавливаю связи между адресной строкой, компьютером и сайтами...

Но для этого уточним то, как работают web-программы, использующие сушествующие на интернете TCP/IP, в том числе http,https протоколов и на какие аспекты необходимо обратить внимание для оптимизации сайта.

Понесло... При чем тут TCP (тем более, больше в тексте он не упоминается),

HTML страницы с помощью сервера (Apachi, Share Point yoki Nginx) динамично генерируются.

Я, может, чего-то не понимаю, но Share Point - не вебсервер, а nginx выдает только статику.

Создание несколько осложнено: для того, чтобы работала быстрее, необходимо использование программы типа “Web Developer” (PHP Designer, Adobe Dreamveawer, MS Visual Studio 2008 и т. д.).

Эти программы нужны чтобы быстрей работали скрипты, или чтобы быстрей эти скрипты накликать?

Пример хелловорлда неканоничен и без объяснений новичку абсолютно непонятен.

Только 5-10 процентов обшего времени на загрузку сайта приходится на сервер (на генерацию кода). Это составляет примерно 50-100 мс. А остальное время зависить, от архитектуры Клиента.

Во-первых, время генерации в десятую секунды - не факт, бывает и больше. При чем тут архитектура клиента? (Вообще статья пересыпана умными словечками, не вяжущимися с общим стилем изложения).

Согласно исследованиям если время загрузки сайта (со всеми элементами) привышает 8-10 минут и не появляется сообщение о процессе загрузки сайта (“Loading.. Please wait” kabi), то данная ситуация может отрицательно действовать на психику пользователя!

Согласно чьим исследованиям? Британских ученых?

Большинство пользователей обращают внимание на скорость загрузки web-порталов, таких как Google, Amazon, Flickr, Netflix, Яндекс, вКонтакте и Однокласники, MAIL.ru.

Сравнивать страницу гугла, фликр и одноклассников некорректно - абсолютно разные направления, контент и объем.

Ваши действия (вы пользователь простого Dial-Up или ADSL 128 кб/с):С помощью Call Back или напрямую отправляете запрос провайдеру и соединяеев с интернетом

???

Вы очень спешите, поэтому начинаете поиск информации на сайте который первым вспомнили.

А если я первым вспомню о сайте защитников белок в Уганде, то что я там найду?

B строку адреса браузера пишете название сайта, например: поиск.uz и ждете, когда появится необходимое сведение
Но ужас ! прошло 1 минута а сайта нет: на браузере пустой экран.

Вообще-то логично, зона .uz кириллицу пока не поддерживает.. Но смысл я уловил - все сайты, кроме яндекса - тормозят.

Вы нервничаете, не знаете, что делать, в конце концов, нервничая на строке адреса Brauzerа пишете Yandex.ru.
Сайт загрузился за 10 секунд и за 1 минуту нашел необходимое вам сведение и закончили работу.

Некорректно. Если яндекс загрузится за 10 секунд, не факт, что страницы, выданные в поиске, будут столь же быстры.

В компьютере установлены все необходимые программные обеспечения для web. По моему мнению опытный Web Designer для контроля работы и управления созданного им web сайта, исправления ошибок и создания широких возможностей выполнения разных операций пользуется следуюшими программами:

Longhorn он пользоваться не может, т.к. такой ос (в стабильном состоянии) не существует.
Web Developer Toolbar v4 - параллельный мир? Актуальна версия 1.1.8.
То же и Firebug - последняя версия - 1.4.5
FireFtp является довольно унылой примочкой, впрочем, на любителя.
PHP Designer и особенно DreamWeaver - скорей, для начинающих.

Для всестороннего анализа сайта http://infocom.uz воспользуемся выше указанными программами. Но по причине, что это очень сложный (даже опытному программисту!) и продолжительный процесс я сразу перейду к результатам анализа.

Нижеприведенный процесс сводится к нажатию в YSlow! кнопки Analyze. Как в анализе участвовали Fireftp, PHP Designer и DreamWeaver, остается только гадать.

HTML и его объем очень велики. (116 kb !!!)

116 кб - это далеко не много. Не каменный век, чай.

Для HTML файлов не использовано GZIP-aлгоритмы.

Верно.

Можно уменшить величину CSS-файлов.
Количество CSS-файлов больше одного.

Можно, но насколько это оправданно по трудозатратам и эффекту?

Не включено кэш функция для статик-файлов

А это что за функция? Заголовки кеширования?

Не включены ETag или Last-Modified заглавия для сайта

Покажите, кто это вообще делает. Если на это ругается YSlow, это не значит, что оно нам нужно.

Очень велики размеры JavaScript файлов (175 kb !!!)

Не велики, при учете единоразовой загрузки

Количество JavaScript файлов больше одного (аж 7 !!!)

Это нехорошо, верно.

На сервере повторяются дубликат-опросы, то есть один CSS или JS fayl введен более чем в двух местах (серьезная ошибка)

Серьезная ошибка - 500 Internal Error. А это - небольшой недочет.

Можно уменшить размер некоторых GIF-рисунков
Можно уменшить размер некоторых JPEG -рисунков
Можно уменшить размер некоторых PNG -рисунков

Примеры? Насколько это скажется на их качестве?

Для фона загружается более одного рисунка

И что теперь? Кому это когда мешало?

В качестве Javascript библиотеки (JS LIBRARY) использовано не эффективное “Prototype” . (121 kb)

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





Дальше начинается неконтролируемый поток кода, без комментариев, с плохим форматированием, зато с бессмысленными рисунками.
Первый огрызок, как я понял, отвечает за включение компрессии gzip.
Почему нельзя было просто включить компрессию с помощью ob_start('ob_gzhandler', 9), я не понял.

Далее кусок .htaccess с Expires. Грамотно настроенный сервер этого просто не требует.

Что делает последний код, извращающий css регуляркой, я не улавливаю. Но регулярка таких размеров будет тормозить, это точно.

Довольно много терминов в статье набрано с грамматическими ошибками.
Если в начале текст был немного осмысленным, то к концу он превратился в поток кода и картинок. Примеры и сравнения ориентированы на чайников, которым до веб-дизайна еще очень и очень далеко... Как руководство к действию крайне слабо.

[azim]

Оффтоп:

Тимур все сказал, добавить нечего...
BTW, кэширование на сайте ИнфоКОМа есть...

[netklon]

Сообщение от Timur Rasulov

Покажите, кто это вообще делает. Если на это ругается YSlow, это не значит, что оно нам нужно.

Для контентного сайта кстати эти заголовки просто must.

[Dolphin]

Сообщение от netklon

Для контентного сайта кстати эти заголовки просто must.

Last-Modified - согласен, а ETag? Он же дублирует last-modified, по сути..

[Vitaliy Fioktistov]

Сообщение от Timur Rasulov

Last-Modified - согласен, а ETag? Он же дублирует last-modified, по сути..

http://habrahabr.ru/blogs/client_sid...ization/77004/

[Алексей Шеин]

Решил также отписаться по поводу статьи "Проблемы ускорения работы web-сайтов и их решения. Недостатки сайта infoCOM.UZ и его ликвидация".

Стилистику статьи рассматривать вообще невозможно, так как перевод очень корявый, я буду обсуждать только содержание.

Приведенный автором пример PHP-кода не очень удачен, в данном случае вполне можно было обойтись и без динамической генерации html и вывод хоть того же банального phpinfo() был бы интереснее. Ну да ладно, была просто показана простая демонстрация динамической генерации контента.

Только 5-10 процентов обшего времени на загрузку сайта приходится на сервер (на генерацию кода). Это составляет примерно 50-100 мс.

К большому сожалению, это далеко не всегда. 50-100 мс это очень хорошее время генерации страницы и далеко не всем сайтам удается его добиться.

Согласно исследованиям если время загрузки сайта (со всеми элементами) привышает 8-10 минут и не появляется сообщение о процессе загрузки сайта (“Loading.. Please wait” kabi), то данная ситуация может отрицательно действовать на психику пользователя!

Опять же непонятно откуда такие данные. Учитывая, что в большинстве браузеров таймаут соединения 30 секунд, то психика пользователя уже была повреждена заранее, раз он смотрит уже 8 минут на пустую страницу с сообщением об ошибке.

представте
Вы срочно должны получить сведения о SDH-технологии, применяемой в телекоммуникации. Ваши действия (вы пользователь простого Dial-Up или ADSL 128 кб/с):
 С помощью Call Back или напрямую отправляете запрос провайдеру и соединяеев с интернетом
 Запускаете Brauzer
 Вы очень спешите, поэтому начинаете поиск информации на сайте который первым вспомнили.
 B строку адреса браузера пишете название сайта, например: поиск.uz и ждете, когда появится необходимое сведение
 Но ужас ! прошло 1 минута а сайта нет: на браузере пустой экран.
 Вы нервничаете, не знаете, что делать, в конце концов, нервничая на строке адреса Brauzerа пишете Yandex.ru.
 Сайт загрузился за 10 секунд и за 1 минуту нашел необходимое вам сведение и закончили работу.
 Теперь если кто-нибудь вам скажет положительное мнение о сайте поиск.uz, вы изо всех сил будете возражать.
примечание: это только лишь мое представление!

"Коллбэк или напрямую" в данном случае детали несущественные, их можно было опустить, как и указанные выше для красного словца протоколы TCP/IP и http(s). Далее, как отметил Тимур Расулов выше, поиск.uz это некорректая ссылка и это проблема неграмотности пользователя, т.к. если он дальше введет яндекс.ru то и это его не спасет. Другое дело, многие не очень хорошо знакомые с компьютером пользователи так и открывают сайты, к примеру, пишут в адресной строке "одноклассники" - тот же любимый автором Firefox передаст этот запрос в поиск по умолчанию, например, Google, где первая ссылка в результатах поиска уже будет вести туда куда надо.

Далее идет обзор инструментария, стоит отметить, что указанные программы работают не только под Windows, но и, например, Linux, если постараться, то под линуксом и фотошоп можно запустить.

Наконец, определили используемые программы. Все эти программы необходимы при работе над web проектами любых сложностей. Для всестороннего анализа сайта http://infocom.uz воспользуемся выше указанными программами.

Инструменты для разработчика действительно нужные и полезные, но в данной статье они нужны не все, те же PHP Designer, FireFtp и дримвьювер в оценке загрузки сайта практически бесполезны.

Но по причине, что это очень сложный (даже опытному программисту!) и продолжительный процесс я сразу перейду к результатам анализа.

Здесь чистой воды лукавство. Чтобы получить эти данные, нужно нажать 1 кнопку в приведенном автором плагине YSlow или неприведенном PageSpeed и данные будут получены в считанные секунды.
Далее идут результаты работы YSlow, полезность которых трудно переоценить.

Я на сайте http://infocom.uz выявил следующие данные, влияющие на его скорость:

Вот эти мнимые "заслуги" раздражают. Было бы намного лучше, если бы автор описал процесс, например, так: "Любой может оценить свой сайт подобным образом, а именно: <сценарий установки и запуска>".

Такую ситуацию можно встретить на большинстве сайтов.
Как доказательство в 5 – разделе, проанализировав 3 самых известных сайта раскрою сушествующие недостатки!

5 раздела я так и не нашел, зато нашел в самом конце статьи 4 ссылки (торг, уфорум, зиенет, церт.уз) и 1 отчет YSlow по cert.uz. Видимо, это и имелось в виду. Ни анализа, ни раскрытия недостатков я так и не увидел.

Далее, автор приводит решения поставленных проблем и просит особого внимания на каждый пункт. И оно еще как понадобится, потому как дальше идут практически одни скриншоты вперемешку с PHP и HTML-кодом. Текстовых описаний дальше практически нет совсем, и это в самой интересной части статьи - чувствуется, что автор слишком устал и просто вывалил все результаты на пользователя. Авось кто-нибудь разберется и что-нибудь да пригодится.
Да, автор, привел, скорее всего, работающий пример сжатия на PHP и конфигурацию .htaccess, но без описания установки и использования данное решение абсолютно бесполезно.
Стоит также отметить, что использовать динамическое сжатие контента очень накладно даже с помощью Apache, не говоря уже о скрипте PHP, выполняющем эту работу. Оптимальным решением здесь является статическое сжатие файлов и последующая их отдача легким веб-сервером наподобие nginx, а сжатие на лету только для динамического контента средствами веб-сервера, а не php-скриптом.

Далее, автор приводит якобы разработанную им программу минимизации CSS-файлов. Однако, если присмотреться, то можно узнать не сильно замаскированный интерфейс CSSTidy.
Далее идет скриншот упаковщика яваскрипта Дена Эдвардса Packer без какого-либо описания и предупреждения, что несмотря на хорошую степень сжатия, данный упаковщик сильно потребляет ресурсы процессора при распаковке на клиенте.
Потом идут скриншоты CSS-спрайтов (я догадался, а вы?), кусок html-кода с применением технологии data:URI (никаких пояснений, все же и так это знают) и длинный кусок кода с регулярными выражениями, в котором я так и не смог разобраться.
Резюме: Теория сильно хромает, практика клиентской оптимизации более менее освоена, сама статья находится в состоянии примерно 20% завершения, несколько ошибок и наглое присвоение чужой работы (скорее всего эта программа сдается в качестве диплома или курсовой).

Можно было бы дать хотя бы ссылки на webo.in, их готовое решение http://www.web-optimizer.us/ru/, которое, кстати, поддерживает уже сегодня кучу цмсок и движков, блог клиентской оптимизации на habrahabr.ru, best practices yahoo, если уж совсем влом статью дописывать.
Незнание и ошибки можно простить, в конце концов, не ошибается только тот, кто ничего не делает, но вот за воровство и лень я ноутбук бы не дал.

[Алексей Шеин]

Сообщение от Timur Rasulov

116 кб - это далеко не много. Не каменный век, чай.

Ну на мой взгляд достаточно прилично
Немного - это jQuery сжатая в 15 кб.

Сообщение от Timur Rasulov

Можно, но насколько это оправданно по трудозатратам и эффекту?

Вообще-то, довольно оправданно при больших размерах css файлов, а сжимать, как я уже говорил, можно и заранее, а не на лету.

Сообщение от Timur Rasulov

А это что за функция? Заголовки кеширования?

Да, скорее всего имелись в виду заголовки кэширования, установленные "далеко в будущее" для статики.

Сообщение от Timur Rasulov

Серьезная ошибка - 500 Internal Error. А это - небольшой недочет.

Примеры? Насколько это скажется на их качестве?

И что теперь? Кому это когда мешало?

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

На оптимизации картинок также можно выиграть несколько килобайт, может даже и десятков при сильно запущенном случае. Причем качество не сильно страдает, можно использовать онлайн сервисы, такие как smushit или консольные утилиты типа pngcrush. Об этом уже много где писалось, так что я вас вряд ли чем-то удивлю.
Загрузка большого количества фоновых рисунков - опять же, большая трата http-запросов, следует слить их в один спрайт или раздавать прямо в css через data:uri.