Автор: Fenng | При перепечатке обязательно указывайте первоисточник и информацию об авторе статьи, а также заявление об авторских правах в виде гиперссылки: http://www.dbanotes.net/web/flickr_web_tech. .html
Кэл Хендерсон — один из разработчиков знаменитого сайта Flickr. В статье под названием «Быстрая поддержка JavaScript» он представил методы оптимизации приложений сайта Flickr. Я почувствовал, что ее прочтение принесло мне большую пользу. «Жуйте чужие плюшки», резюмируйте основное содержание статьи.
Flickr — представительный сайт Web 2.0. Помимо оптимизации контента, характерной для обычных веб-сайтов, сетевые проблемы также должны гибко справляться со сложностями развертывания и распространения, вызванными частыми изменениями в JavaScript и CSS.
Первый вопрос, который возникает при настройке стратегии размера файла: поместить весь JavaScript и CSS в один файл или разделить его на несколько файлов. С точки зрения сокращения сетевых запросов первый лучше, а второй хуже? Однако с параллельной точки зрения и IE, и Firefox по умолчанию могут запрашивать только два ресурса из одного домена одновременно. Во многих случаях это вызывает у пользователей неприятные ощущения — все файлы должны быть загружены. См. приличную страницу. использует компромисс — разбивает JavaScript и CSS на несколько подфайлов, сохраняя при этом количество файлов как можно меньшим. Это усложняет разработку, но выигрыш в производительности огромен.
Проблема оптимизации сжатия Нет сомнений в том, что сжатие содержимого сайта является относительно распространенным методом веб-оптимизации. Однако не всегда удается добиться желаемого эффекта. Причина в том, что модуль mod-gzip потребляет не только ресурсы ЦП на стороне сервера, но и ресурсы ЦП на стороне клиента. Более того, временные файлы, созданные после сжатия файлов mod_gzip, помещаются на диск, что также вызовет серьезные проблемы. для дискового ввода-вывода Flickr Используется модуль mod_deflate, поддерживаемый Httpd 2.x и более поздних версий. Все операции сжатия выполняются в памяти. mod_deflate недоступен в Httpd 1.x, но вы можете косвенно повысить производительность, создав RAM-диск.
Конечно, mod_gzip не бесполезен. Он по-прежнему полезен для предварительно сжатых файлов. Более того, при использовании сжатия также необходимо обращать внимание на стратегию. Нет необходимости сжимать файлы изображений (на Flickr и так много изображений).
сжатие не дает больших преимуществ). Flickr сжимает только JavaScript и CSS. Новые версии mod_gzip могут автоматически обрабатывать предварительно сжатые файлы, настроив параметр mod_gzip_update_static.Кэл
также отметил, что эта функция вызовет проблемы в некоторых старых версиях браузеров.
Сжатие Одним из основных средств является сжатие контента. Для JavaScript вы можете сделать это, уменьшая комментарии, объединяя пробелы, используя компактный синтаксис и другие приемы (все скрипты Google очень сложны для чтения и очень компактны, с похожими идеями). такая обработка в JavaScript может содержать множество круглых скобок, которые трудно проанализировать. Flickr использует Dojo Compressor для построения дерева синтаксического анализа. Dojo Compressor имеет очень низкие накладные расходы и прозрачен для конечных пользователей. Был введен метод обработки JavaScript, а обработка CSS относительно проста. Благодаря простой замене регулярных выражений (например, замене нескольких пробелов одним пробелом) вы можете встать. до 50% степени сжатия.
Оптимизация кэширования Разработчики Flickr в полной мере использовали механизмы Etag и Last-Modified, определенные спецификацией HTTP 1.1, для повышения эффективности кэширования. Стоит отметить, что Кэл представил трюк с e-Tag в условиях балансировки нагрузки. вы можете настроить Apache на получение E-Tag через время корректировки файла и размер файла. По умолчанию Apache получает e-Tag через файловый узел. Конечно, это не идеально, потому что это повлияет на if-modified-since.
Гибкое использование mod_rewrite Говорят, что приложение веб-сайта Flickr создается ежедневно (Daily Build). Это было бы немыслимо без гибкого механизма. Более того, на таких сайтах, как Flickr, синхронизация изменений контента является головной болью. Их оружие — гибкое использование mod_rewrite. Настроив правила перезаписи URL-адресов, можно легко переключаться на разные среды. Звучит очень просто, но насколько легко это сделать без определенных навыков в области веб-технологий?!
Благодаря применению этих основных методов мы увидели сказочный и высокопроизводительный Flickr.
Кстати: поскольку у Flickr нет сервера в Китае, скорость доступа для пользователей с материка не может быть упомянута :(
--Конец.
Эта статья [Советы по оптимизации веб-приложений для разработчиков Flickr] взята с dbanotes.net