что такое автономный веб сайт
Бесплатный сайт на WordPress.com или автономный сайт на WordPress: что выбрать
Когда я только начинал пользоваться WordPress, я был сильно смущен, какой из двух вариантов мне выбрать. До этого я создавал веб-сайты с нуля, пользуясь текстовым редактором и FTP-менеджером. Мир систем управления контентом был мне плохо знаком. И перед тем как идти дальше – еще до того, как у меня вообще сложилось какое-то понимание о WordPress – мне нужно было сделать свой выбор.
Если быть честным, я не думаю, что вообще получится адекватно сравнить WordPress.com и автономные сайты на WordPress. Мне кажется, что даже сравнение, приведенное на сайте WordPress.com, не является справедливым. Таким образом, я воспользуюсь возможностью, предоставленной мне, и расскажу вам свое мнение о различиях между WordPress.com и отдельными сайтами на WordPress, чтобы вы могли принять обоснованное решение, каким вариантом воспользоваться.
В чем состоит различие?
По моему мнению, основной вопрос выбора между двумя вариантами заключается в понимании структурных различий. Самая лучшая аналогия, которая мне пришла в голову – это аналогия с компьютерами. Свой собственный сайт на WordPress эквивалентен покупке своего компьютера. Вы можете делать с ним все, что захотите: добавлять компоненты, устанавливать программное обеспечение, неограниченно пользоваться интернетом – весь мир в ваших руках. В свою очередь, WordPress.com – эквивалент использования компьютера в библиотеке. Вы работает в управляемой среде. У вас нет такой свободы, как у тех, кто обладает своим компьютером.
Короче говоря, это и является основным различием. WordPress.com ограничен, в отличие от своих сайтов на WP.
Так зачем вообще беспокоиться о WordPress.com?
Если вы готовы работать со значительными ограничениями, то вы можете иметь свой сайт, запущенный абсолютно бесплатно – этого нельзя сказать про автономные сайты на WordPress. Правда, это не все – WordPress.com предлагает некоторые дополнительные функции, которые не являются стандартными для автономных сайтов на WP. Для людей, которые проявляют неосознанный или осторожный интерес к веб-публикациям, WordPress – прекрасная стартовая площадка. Зарегистрируйтесь, войдите в систему и публикуйте свои записи.
По моему скромному мнению, WordPress.com – не самое лучшее решение для людей, которые планируют вести свой ресурс длительное время. Скорее, этим можно удовлетворить свой случайный интерес к блоггингу.
За и против
Давайте перейдем к более внимательному рассмотрению всех за и против WordPress.com и автономных сайтов на WP. Прежде всего стоит заметить, что на макроуровне они аналогичны. Они используют одинаковое программное обеспечение. Однако автономная система WordPress позволяет вам совершать гораздо больше разных действий, нежели ограниченная среда WordPress.com.
Что может предложить WordPress.com:
Некоторые ограничения платформы WordPress.com:
Что могут предложить автономные сайты на WordPress:
Недостаток автономных сайтов:
Развеиваем мифы
В сети ходят несколько предвзятые мнения как по поводу WordPress.com, так и по поводу автономных сайтов на WP. Я хотел бы воспользоваться возможностью, чтобы развеять эти мифы.
1. WordPress.com – чистой воды альтруизм
WordPress.com – это коммерческая инициатива. Компания предлагает бесплатные сервисы в надежде, что вы воспользуетесь ее премиальными возможностями.
2. Чтобы запустить автономный блог, нужно быть гуру веб-разработки
Вам не нужно быть техническим гением, чтобы использовать автономные сайты на WP. Сравните два интерфейса:
В каком месте автономные сайты на WP сложнее сайтов на WordPress.com?
В действительности установка автономных сайтов ничуть не сложнее запуска бесплатного блога на wordpress.com. Купите домен и хостинг, установите WP с помощью одного клика, потратьте некоторое время на изучение панели администратора. Да, можно утверждать, что wordpress.com проще для новичков, однако разрыв между бесплатными блогами и автономными сайтами не такой уж большой.
Если сомневаетесь в этом, посмотрите видео от Pat Flynn, в котором весь процесс покупки домена, хостинга, установки WP и создания первой записи занимает всего 4 минуты!
3. Автономные сайты стоят денег
Автономные веб-приложения
Несмотря на обилие в HTML5 функций, которые не особо помогают нам в стремлении к адаптивности (например, API-интерфейс Geolocation), автономные вебприложения потенциально способны нам в этом помочь. Поскольку мы знаем, что количество мобильных пользователей, которые, вероятно, будут посещать наши сайты, постоянно растет, нужно обеспечить для них возможность просматривать содержимое сайтов даже при отсутствии подключения к Интернету. Автономные приложения HTML5 предназначены именно для этого.
Очевидно, что функциональность в виде возможности работы в автономном режиме как нельзя лучше подходит для веб-приложений. Представьте онлайновое веб-приложение для создания заметок. Пользователь может успеть написать только половину заметки до того, как разорвется соединение его мобильного телефона с Интернетом. Благодаря автономным веб-приложениям HTML5 пользователи, столкнувшиеся с такой ситуацией, смогут продолжить писать свои заметки, а данные можно будет отправить позднее, как только восстановится соединение с Интернетом.
Замечательная особенность автономных веб-приложений HTML5 состоит в том, что их легко конфигурировать и использовать. Здесь мы задействуем их общим путем — для создания автономной версии нашего сайта. Это значит, что если пользователь захочет взглянуть на сайт при отсутствии подключения к Интернету, то он сможет сделать это.
Вкратце об автономных веб-приложениях.
Автономные веб-приложения работают следующим образом: каждая страница, которая должна быть доступна в автономном режиме, указывает на текстовый файл с расширением. manifest. В нем содержится перечень всех ресурсов (HTML, изображения, JavaScript и т. д.), необходимых странице для того, чтобы она была доступна в автономном режиме. Браузеры с поддержкой автономных веб-приложений HTML5 (Firefox версии 3 и выше, Chrome версии 4 и выше, Safari версии 4 и выше, Opera версии 10.6 и выше, iOS версии 3.2 и выше, Opera Mobile версии 11 и выше, Android версии 2.1 и выше, Internet Explorer версии 10 и выше) считывают файл с расширением. manifest, загружают приведенные в нем ресурсы и кэшируют их локально на тот случай, если соединение с Интернетом будет разорвано. Все просто, не так ли? Сделаем это.
Делаем веб-страницы доступными в автономном режиме.
В открывающем теге мы указываем на файл с расширением. manifest:
Можете присвоить этому файлу любое имя по своему усмотрению, однако рекомендуется, чтобы у него было файловое расширение. manifest.
Вам потребуется добавить атрибут manifest=»/offline. mamfest» в тег каждой страницы, которая должна быть доступна в автономном режиме.
Если вашим веб-сервером является Apache, то вам, скорее всего, потребуется добавить в файл. htaccess следующую строку:
AddType text/cache-manifest. manifest
В результате этого файл получит корректный тип MIME, которым является text/cache-manifest.
Пока открыт файл. htaccess, добавьте в него следующие строки:
ExpiresActive On ExpiresDefault «access»
Этим вы сделаете так, что браузер больше не будет кэшировать кэш. Да, вы все правильно прочитали. Поскольку файл offline. manifest является статичным, браузер по умолчанию будет его кэшировать. Таким образом, предыдущий код дает команду серверу «сказать» браузеру, чтобы он этого не делал!
Теперь необходимо написать файл offline. manifest. Он будет информировать браузер о том, какие файлы следует сделать доступными в автономном режиме. Вот содержимое файла offline. manifest для сайта And the winner isn’t.:
CACHE MANIFEST #версия 1
Понятие файла манифеста
Файл манифеста должен начинаться с CACHE MANIFEST. Следующая строка представляет собой всего лишь комментарий, в котором указывается номер версии файла манифеста. Вскоре мы поговорим об этом подробнее.
В разделе CACHE: приводится перечень файлов, которые должны быть доступны в автономном режиме. Они должны соответствовать тем файлам, что упоминаются в offline. manifest, поэтому вам может потребоваться изменить пути в зависимости от того, какие ресурсы следует кэшировать. При необходимости также можно использовать абсолютные URL-адреса.
В разделе NETWORK: приводится список всех ресурсов, которые не должны кэшироваться. Считайте его «белым онлайн-списком». Все, что в нем перечислено, всегда будет проходить мимо кэша при наличии сетевого соединения. Если вы хотите сделать содержимое своего сайта доступным там, где возможно подключение к Интернету (вместо того чтобы обращаться исключительно к автономному кэшу), то в этом вам поможет символ *. Он называется подстановочным флагом белого онлайн-списка.
В разделе FALLBACK: для определения URL-шаблона используется символ /. По сути, здесь задается вопрос: «Эта страница в кэше?» Если выяснится, что страница там, то отлично — она будет отображена. В противном случае пользователь увидит указанный файл — offline. html.
Автоматическое добавление страниц в кэш.
В зависимости от обстоятельств возможно применение еще более легкого способа конфигурирования файла offline. manifest. Любая страница, указывающая на этот файл (как вы помните, для этого необходимо добавить manifest=»/offline. manifest» в открывающий тег ), будет автоматически добавляться в кэш, когда пользователь посетит ее. Благодаря такому подходу каждая страница вашего сайта, на которую заходит пользователь, будет добавляться в его кэш, чтобы он смог снова посетить ее в автономном режиме. Вот как должно выглядеть содержимое файла манифеста:
# Манифест кэша, версия 1 FALLBACK:
/ /offline. html NETWORK:
При выборе этого подхода следует иметь в виду, что загружаться и кэшироваться будет только HTML-код посещаемой страницы. Однако этого не будет происходить с изображениями/JavaScript-кодом и прочими ресурсами, которые она может содержать или с которыми может быть связана. Если они важны для вас, то укажите их в CACHE: как уже описывалось ранее в разделе «Понятие файла манифеста».
О комментарии с указанием номера версии.
При внесении изменений в сайт вам придется так или иначе изменить файл offline. manifest и заново выгрузить его. В результате этого сервер сможет предоставить новую версию файла браузеру, который затем извлечет новые версии других соответствующих файлов и снова начнет автономный процесс. Я следую примеру Ника Пилгрима (Nick Pilgrim) (из отличной книги Dive into HTML5 («Погружение в HTML5»)) и добавляю в верхнюю часть файла offl ine. manifest комментарий с указанием номера версии, который будет увеличиваться с каждым внесением изменений:
# Манифест кэша, версия 1
Просмотр сайта в автономном режиме.
Теперь пришло время протестировать наше творение. Откройте страницу в браузере, совместимом с автономными веб-приложениями (рисунок 4.10). Одни браузеры будут выдавать предупреждение насчет автономного режима (например, Firefox — обратите внимание на расположенную вверху строку), в то время как другие, к примеру Chrome, никак о нем не упомянут.
Страница сайта And the winner isn’t….
А теперь вырубите Интернет (ну, то есть отключите WiFi — просто это звучит не так драматично, как «вырубите») и обновите страницу в браузере. Следует надеяться, что после этого она будет выглядеть так же, как и при наличии соединения с Интернетом.
Устранение неполадок с автономными веб-приложениями.
Когда у меня возникают проблемы с тем, чтобы заставить сайты корректно работать в автономном режиме, для устранения неполадок я предпочитаю использовать браузер Chrome (рисунок 4.11). Встроенные в него инструменты разработчика включают удобный раздел Console (Консоль) (чтобы открыть его, щелкните на значке с изображением гаечного ключа справа от адресной строки, а затем выберите Tools > Developer Tools (Инструменты > Инструменты разработчика) и перейдите на вкладку Console (Консоль)). В этом разделе можно узнать об успехах и неудачах в работе автономного кэша и часто отмечается, что вы делаете неправильно. По своему опыту могу сказать, что обычно проблемы связаны с путями, например, для страниц не указано корректное местоположение файла манифеста.
Проверка работы сайта в браузере Chrome
Полную спецификацию автономных веб-приложений вы сможете отыскать по следующему адресу: http://dev. w3.org/html5/spec/Overview. html#offiine.
В этой главе мы рассмотрели все, начиная с основ создания страниц, которые смогут пройти валидацию на предмет соответствия требованиям HTML5, и заканчивая обеспечением работы страниц в автономном режиме, когда у пользователей нет возможности установить соединение с Интернетом. Кроме того, мы поговорили о вложении мультимедиа (в частности, видео) в разметку, а также о том, как адаптировать его к разным по размеру областям просмотра. Мы также рассмотрели особенности создания семантически насыщенного и значимого кода и способы оказания помощи пользователям, нуждающимся во вспомогательных технологиях. Однако наш сайт по-прежнему не лишен некоторых серьезных недостатков. Попросту говоря, он выглядит довольно захудало. Текст на нем не стилизован, и полностью отсутствуют такие элементы, как кнопки, которые были видимыми в оригинальной композиции. До сих пор мы совершенно обоснованно избегали использования изображений для решения этих проблем. Изображения нам просто не нужны! В последующих главах мы воспользуемся мощью и гибкостью CSS3 для создания быстро загружающегося и удобного в сопровождении адаптивного дизайна.
Как заставить ваши веб-приложения работать в автономном режиме
Сила JavaScript и браузерного API
Мир становится все более взаимосвязанным — число людей, имеющих доступ к Интернету, выросло до 4,5 миллиардов.
Но в этих данных не отражено количество людей, у которых медленное или неисправное интернет соединение. Даже в Соединенных Штатах 4,9 миллиона домов не могут получить проводной доступ к интернету скорость которого будет более 3 мегабит в секунду.
Остальной мир — те, кто имеет надежный доступ к Интернету — все еще подвержен потере соединения. Некоторые факторы, которые могут повлиять на качество сетевого подключения, включают в себя:
Статья переведена при поддержке компании EDISON Software, которая выполняет «на отлично» заказы из Южного Китая, а также разрабатывает веб-приложения и сайты.
Недавно у меня была возможность добавить автономность к существующему приложению, используя service workers, cache storage и IndexedDB. Техническая работа, необходимая для того, чтобы приложение работало в автономном режиме, сводилась к четырем отдельным задачам, о которых я расскажу в этом посте.
Service Workers
Приложения, созданные для работы в автономном режиме, не должны сильно зависеть от сети. Концептуально это возможно только в том случае, если в случае сбоя существуют запасные варианты.
При ошибке загрузки веб-приложения, мы должны где-то взять ресурсы для браузера(HTML/CSS/JavaScript). Откуда берутся эти ресурсы, если не из сетевого запроса? Как насчет кеша. Большинство людей согласятся с тем, что лучше предоставлять потенциально устаревший пользовательский интерфейс, чем пустую страницу.
Браузер постоянно делает запросы к данным. Служба кэширования данных в качестве запасного варианта все еще требует, чтобы мы каким-то образом перехватывали запросы браузера и писали правила кэширования. Здесь service workers вступают в игру — думайте о них как о посреднике.
Service worker — это просто файл JavaScript, в котором мы можем подписаться на события и написать свои собственные правила для кэширования и обработки сетевых сбоев.
Давайте начнем.
Обратите внимание: наше демо приложение
На протяжении всего этого поста мы будем добавлять автономные функции в демо приложение. Демо-приложение представляет собой простую страницу взятия/сдачи книг в библиотеке. Прогресс будет представлен в виде серии GIF-файлов, и использования офлайн симуляции Chrome DevTools.
Вот начальное состояние:
Задача 1 — Кэширование статических ресурсов
Статические ресурсы — это ресурсы, которые меняются не часто. HTML, CSS, JavaScript и изображения могут попадать в эту категорию. Браузер пытается загрузить статические ресурсы с помощью запросов, которые могут быть перехвачены service worker’ом.
Начнем с регистрации нашего service worker’a.
Service worker’ы являются web worker’ами под капотом и поэтому должны быть импортированы из отдельного файла JavaScript. Регистрация происходит с помощью метода register после загрузки сайта.
Теперь, когда у нас загружен service worker — давайте закешируем наши статические ресурсы.
Теперь, когда наш кэш заполнен самыми последними запрашиваемыми статическими ресурсами, давайте загружать эти ресурсы из кэша в случае сбоя запроса.
Событие fetch запускается каждый раз, когда браузер делает запрос. Наш новый обработчик события fetch теперь имеет дополнительную логику для возврата кэшированных ответов в случае сбоев сети.
Демо № 1
Наше демо-приложение теперь может обслуживать статические ресурсы в автономном режиме! Но где наши данные?
Задача 2 — Кэширование динамических ресурсов
Одностраничные приложения (SPA) обычно запрашивают данные постепенно после начальной загрузки страницы, и наше демо приложение не является исключением — список книг не загружается сразу. Эти данные обычно поступают из запросов XHR, которые возвращают ответы, которые часто меняются, чтобы предоставить новое состояние приложения — таким образом, они являются динамическими.
Кэширование динамических ресурсов на самом деле очень похоже на кэширование статических ресурсов — главное отличие состоит в том, что нам нужно обновлять кэш чаще. Генерировать полный список всех возможных динамических запросов XHR также довольно сложно, поэтому мы будем их кэшировать по мере их поступления, а не иметь заранее определенный список, как мы делали для статических ресурсов.
Посмотрим на наш обработчик fetch :
Мы можем настроить эту реализацию, добавив немного кода, который кэширует успешные запросы и ответы. Это гарантирует, что мы постоянно добавляем новые запросы в наш кеш и постоянно обновляем кэшированные данные.
Наш Cache Storage в настоящее время имеет несколько записей.
Демо № 2
Наше демо теперь выглядит одинаково при начальной загрузке, независимо от нашего статуса сети!
Отлично. Давайте теперь попробуем использовать наше приложение.
К сожалению — сообщения об ошибках везде. Похоже, все наши взаимодействия с интерфейсом не работают. Я не могу выбрать или сдать книгу! Что нужно исправить?
Задача 3 — Построить оптимистичный пользовательский интерфейс
На данный момент проблема с нашим приложением заключается в том, что наша логика сбора данных все еще сильно зависит от сетевых ответов. Действие check-in или check-out отправляет запрос на сервер и ожидает успешного ответа. Это отлично для согласованности данных, но плохо для нашего автономного опыта.
Чтобы эти взаимодействия работали в автономном режиме, нам нужно сделать наше приложение более оптимистичным. Оптимистичные взаимодействия не требуют ответа от сервера и охотно отображают обновленное представление данных. Обычная оптимистичная операция в большинстве веб-приложений это delete — почему бы не дать пользователю мгновенную обратную связь, если у нас уже есть вся необходимая информация?
Отключение нашего приложения от сети с использованием оптимистичного подхода является относительно простой в реализации.
Ключ — обрабатывать действия пользователя одинаково — независимо от того, успешен ли сетевой запрос или нет. Приведенный выше фрагмент кода взят из redux редюсера нашего приложения, SUCCESS и FAILURE запускается в зависимости от доступности сети. Независимо от того, как выполнен сетевой запрос, мы собираемся обновить наш список книг.
Демо № 3
Взаимодействие с пользователем теперь происходит онлайн (не буквально). Кнопки «check-in» и «check-out» обновляют интерфейс соответствующим образом, хотя по красным сообщениям консоли видно, что сетевые запросы не выполняются.
Хорошо! Есть только одна небольшая проблема с оптимистичным рендерингом в автономном режиме…
Разве мы не теряем наши изменения!?
Задача 4 — Собирать действия пользователя в очередь для синхронизации
Нам нужно отслеживать действия, совершенные пользователем, когда он был в автономном режиме, чтобы мы могли синхронизировать их с нашим сервером, когда пользователь вернется в сеть. В браузере есть несколько механизмов хранения, которые могут выступать в качестве очереди действий, и мы собираемся использовать IndexedDB. IndexedDB предоставляет несколько вещей, которые вы не получите от LocalStorage:
На этом этапе мы можем очистить очередь от всех запросов, которые мы успешно отправили на сервер.
Демо № 4
Финальное демо выглядит немного сложнее. Справа в темном терминальном окне регистрируется вся активность API. Демо предполагает выход в автономный режим, выбор нескольких книг и возврат в онлайн.
Ясно, что запросы сделанные в автономном режиме были поставлены в очередь и отправляются разом, когда пользователь возвращается в онлайн.
Этот подход «воспроизведения» немного наивный — например, нам, вероятно, не нужно делать два запроса, если мы берем и возвращаем одну и ту же книгу. Это также не будет работать, если несколько человек используют одно и то же приложение.
LiveInternetLiveInternet
—Видео
—Метки
—Рубрики
—Цитатник
Некоторые фильтры AAAfilter Bas relief CPK filter D.
Все полезности в одном посте! 🙂 Собственно пост удобной навигации по блогу:-) Все ссылки на сам.
—Поиск по дневнику
—Интересы
—Друзья
—Постоянные читатели
—Сообщества
—Статистика
Работа в автономном режиме
Допустим, Вы прочитали в Интернете интересный рассказ. Прошло несколько дней, и Вам захотелось перечитать этот рассказ. Но тут, как назло, отключили Интернет. Можно на время забыть о своем желании, а можно попробовать открыть рассказ в автономном режиме.
То есть фактически получается так: компьютер запоминает некоторые сайты, точнее, отдельные страницы сайтов, которые Вы посещали. И некоторые страницы можно открыть даже не находясь в Интернете. Но, увы, не все страницы, которые Вы посещали, откроются через автономный режим. Тут уж как повезет.
А теперь перейдем к практике. Мы научимся пользоваться автономным режимом в самых популярных браузерах: Internet Explorer, Opera, Mozilla Firefox. Изучите информацию, которая относится к Вашему браузеру, остальное можно пропустить:о)
Автономный режим в браузере Internet Explorer
Мы рассмотрим работу в автономном режиме на примере последней версии браузера Internet Explorer. На момент написания урока она 9-ая. Но вообще-то, разница между версиями браузера не такая уж и большая.
Отключитесь от Интернета и откройте браузер Internet Explorer. Вверху есть вот такая полоска.
Вот так Вы включили автономный режим. А теперь попробуем открыть какой-нибудь из тех сайтов, которые Вы уже открывали раньше.
Можно просто напечатать его название в адресной строке и нажать кнопку Enter на клавиатуре (или выбрать из списка).
Если появилось вот такое окошко с надписью «Эта веб-страница недоступна в автономном режиме», то, увы, данную страницу сайта открыть в автономном режиме не получится.
Это довольно частое явление. Поэтому лучше открывать страницы сайтов в автономном режиме другим способом – через «Журнал».
Журнал (История) – это то место, где можно посмотреть, какие сайты открывались на компьютере и когда это было. Можно сказать так: все, что Вы делаете в Интернете, сохраняется, и через «Журнал» можно посмотреть историю Ваших перемещений: на какие сайты ходите и что там делаете.
Для того чтобы открыть журнал, нужно нажать на кнопку со звездочкой, которая называется «Избранное» (крайняя слева вверху браузера).
Теперь вернемся к теме урока. Помните, мы включили автономный режим?
Кстати, проверить это можно, нажав на надпись «Файл» вверху браузера. Откроется список. Если Вы увидите птичку рядом с надписью «Работать автономно» (внизу), то это означает, что автономный режим включен.
Откройте во вкладке «Журнал» любой день и любой сайт. Вы увидите страницы выбранного сайта, которые когда-то просматривали на компьютере. Если какие-то страницы выглядят блеклыми, то это означает, что Вы НЕ сможете открыть их в автономном режиме.
Попробуйте нажать на одну из таких страниц – она должна открыться.
Не забудьте отключить автономный режим, когда закончите работу с ним. Выключается он точно так же, как и включается (Файл – Автономный режим).
Автономный режим в браузере Opera
Отключитесь от Интернета и откройте браузер Opera.
Нажмите на кнопку «Меню» вверху браузера Opera (слева) и из открывшегося списка выберите пункт «Настройки», а затем нажмите на надпись «Работать автономно».
Вот так Вы включили автономный режим. А теперь попробуем открыть какой-нибудь из тех сайтов, которые Вы уже открывали раньше.
Можно просто напечатать его название в адресной строке и нажать кнопку Enter на клавиатуре (или выбрать из списка).
Частенько бывает и такое 🙁
Проще открывать страницы сайтов в автономном режиме другим способом – через «Историю».
История (Журнал) – это то место, где можно посмотреть, какие сайты открывались на компьютере. Можно сказать так: все, что Вы делаете в Интернете, сохраняется, и через «Историю» можно посмотреть, какие сайты Вы открывали и что там делали.
Чтобы открыть «Историю», нужно нажать на кнопку «Меню» и выбрать из списка пункт «История».
Это и есть история Ваших перемещений по Интернету, отсортированная по времени. Нажав на нужный промежуток времени (сегодня, вчера, на этой неделе и т.д.), Вы увидите список сайтов, на которых были в эти дни.
Итак, мы включили автономный режим.
Кстати, проверить это можно, нажав на кнопку «Меню» и наведя курсор на пункт «Настройки». Появится небольшое дополнительное меню. Если в нем Вы увидите птичку рядом с надписью «Работать автономно» (внизу), то это означает, что автономный режим включен.
Откройте в «Истории» любой день или промежуток времени. Откроется список сайтов (страниц сайтов), которые Вы посетили в этот период времени. Если название написано черным жирным цветом, то этот сайт или страничка сайта откроется в автономном режиме.
Попробуйте открыть страницы сайтов и первого, и второго типа.
Не забудьте отключить автономный режим, когда закончите работу с ним. Выключается он точно так же, как и включается (Меню – Настройки – Работать автономно).
Автономный режим в браузере Mozilla Firefox
Вот так Вы включили автономный режим. А теперь попробуем открыть какой-нибудь из тех сайтов, которые Вы уже открывали раньше.
Можно просто напечатать его название в адресной строке и нажать кнопку Enter на клавиатуре (или выбрать из списка).
А еще можно открывать сайты в автономном режиме через «Журнал». Так даже проще.
На верхней полоске браузера Mozilla есть надпись «Журнал». Нажмите на нее. Откроется список. В этом списке показываются сайты, которые не так давно открывали через Mozill’у. Попробуйте открыть какой-нибудь сайт из этого списка.
Также можно выбрать пункт «Показать весь журнал».
В этом случае откроется новое окошко. Это история Ваших перемещений по Интернету, отсортированная по времени. Нажав на нужный промежуток времени (сегодня, вчера, последние 7 дн. и т.д.) появится список сайтов, на которых Вы были в эти дни.
Попробуйте открыть какой-нибудь из них. Если опять появится такая же надпись, то, увы, этот сайт (страница сайта) в автономном режиме не открывается.
Не забудьте отключить автономный режим, когда закончите работу с ним. Выключается он точно так же, как и включается (Файл – Автономный режим).
Итак, единственное условие работы в автономном режиме — наличие интересующей вас информации в кэше вашего браузера. К сожалению, трудно угадать, какие именно страницы ваш капризный браузер захочет сохранить, а какие безжалостно выкинет из памяти. И поэтому работа в автономном режиме похожа на русскую рулетку: в самый неожиданный момент вы видите сообщение о том, что страница в кэше не обнаружена и вам волей-неволей придется подключиться к Сети.
Поэтому, если вы часто хотите пользоваться автономным режимом, не забудьте увеличить размер вашего интернет-кэша. Напомню, что сделать это в Internet Explorer можно через меню «Сервис/Свойства обозревателя/Общие/Временные файлы Internet/Настройка».