Disaster Recovery Planning for Municipal Governments

Disaster can strike when you least expect it. Natural and cyber catastrophes, such as flooding, tornadoes, hurricanes, and malware infections, can decimate government systems, halting service delivery and putting valuable data at risk for corruption or loss.

Preparation for disaster is just as important as the recovery process. Municipal governments must ensure effective disaster recovery plans are in place to restore the functionality of critical systems.

  • Prioritized systems and processes for recovery
  • A comprehensive inventory of hardware and software
  • Defined tolerance for downtime and data loss
  • Identified backup personnel
  • A streamlined communication plan

Local governments, in particular, must have citizen information available at all times, which makes effective data backups invaluable. This includes backup copies of email data, which can be compromised in the event of a cyber attack or hard drive failure. Some experts recommend following a 3-2-1 backup rule, which dictates that organizations maintain three copies of data, two of which are backed up to different media (e.g., cloud, disk, or tape), and one of which is housed off site. Having multiple backups makes data recovery seamless and reliable.

In essence, well-constructed DRPs allow municipalities to have a sense of security, knowing that a formalized strategy is in place to abate the risk of service delays, streamline communication and decision-making, and minimize stress when disaster strikes.

Healthcare and Cybersecurity

Telemedicine, mobile applications, EHR’s and numerous other technologies are critical to the healthcare industry. While IoT has allowed healthcare to reach patients in new ways, connectivity to the internet has increased in devastating cyber attacks.

To help monitor cybersecurity risks, the Department of Health and Humans Services (HHS) has released the publication Health Industry Cybersecurity Practices (HICP): Managing Threats and Protecting Patients, a game changer that the industry has been awaiting for nearly two years.

The document looks into the current challenges and identifies healthcare-specific vulnerabilities, and details best practices for defending against advanced threats, such as ransomware, loss or theft of equipment or data, and internal malicious activity. Armed with this information, healthcare providers of all sizes are able to improve their approaches to cybersecurity with tried and true strategies encompassing the following areas:

  • E-mail protection systems
  • Endpoint protection systems
  • Access management
  • Data protection and loss prevention
  • Asset management
  • Network management
  • Vulnerability management
  • Incident response
  • Medical device security
  • Cybersecurity policies

Cybersecurity has become an essential part of healthcare in the modern age, when IT assets means protecting not only data, but also the physical well being of patients.

Use HTML Caching to Increase Page Speed
Heavy traffic to a website can result in performance problems, slower page speed, and fewer conversions.
Note the screenshot below from Macy’s. It shows the effect of Macys.com not caching the HTML of the home page in its content delivery network. This adds one second of page load time. Every other page resource will load after the HTML content is downloaded and parsed. The page took 16.84 seconds to load, which is slow.
The Gap launched a new website that caches HTML content in its CDN. The HTML request now adds just 78.91 milliseconds — the home page loads in 3.60 seconds, which is much better than the 15 to 20 seconds it took in March.
Caching HTML content on ecommerce websites — and dynamic websites in general — is tricky. It doesn’t happen by default in a CDN. Most normally cache just static page resources such as images, style sheets, and scripts.
Dynamic vs. Static Content
For sites with static page content — i.e., not personalized in any way — page caching creates no problems. But for sites with dynamic content that changes among users, caching HTML content could create errors.
For example, a visitor that adds products to his shopping cart changes the content on all pages to show the number of items in the cart. If an ecommerce merchant cached the pages of this user, other users would see an inaccurate number of items in their cart. This concept applies to any type of personalization.
There are at least two solutions to the problem.
  • Implement web page personalization in separate JavaScript files and don’t cache them, or cache them for a short period.
  • Cache HTML only for anonymous users — users that are not logged in or haven’t added any products to their cart.
Personalization in Scripts
The first option, implementing personalization in separate JavaScript files, is what The Gap is doing.
The Gap uses scripts for user personalization so it can still cache the page’s HTML.
(To confirm The Gap’s approach, I disabled JavaScript in my Chrome browser at View > Developer > Developer Tools. Then, I clicked on the three dots to the far right, and selected “Settings.” “Disable JavaScript” is under the “Debugger” preference.)
Implementing user personalization in scripts allows caching of the page’s HTML. Then the scripts can modify the page after loading asynchronously.
Beyond using JavaScript for personalization, The Gap is caching HTML. How do I know this? Gap.com sets the standard HTTP caching header — x-cache-status — to report the status of cache resources. In the image below, the caching status of home page’s HTML says “EXPIRED.”
The documentation for Nginx (Gap.com’s server) states that EXPIRED means: “The entry in the cache has expired. The response contains fresh content from the origin server.”


After refreshing the page, the x-cache-status changed to HIT.
Anonymous Users
The Gap launched a new website that utilized the latest technologies. If, however, you need to cache HTML on an existing ecommerce platform, the anonymous user option might work better.
This technique is known as “punching a hole” in the cache. It works in the following way.
The web server or CDN will cache every page but avoids caching any request that meets exclusion criteria. The most common is a session cookie that the application sets when users log in or add items to the cart. The cookie is necessary to track each user individually.
Here are some sample session cookies for popular ecommerce and content platforms.
Session Cookies (Wildcards * Mean Any Character)
Magento 1
Magento 2
admin| PHPSESSID|private_content_version
Again, these are cookies for users that have personalized content — such as those that log in or add items to their carts. Excluding their pages from the cache will not benefit them in terms of faster page speed. But they are likely a small percentage of total visitors. The rest will experience fast-loading pages.
Assume your site’s web server is Nginx, and Magento 2 powers your store. Here is the configuration setting to enable caching for anonymous users.
location /{ proxy_cache my_cache; proxy_cache_bypass $cookie_admin $cookie_PHPSESSID $cookie_private_content_version; # … }
Enabling this on a web server or load balancer will increase performance. But the greatest benefit would come from implementing this on the CDN layer.
Here is how to do this for popular CDNs. Be sure to confirm with the CDN, however.
Finally, for some sites it is not possible to find cookies to bypass. In those instances, we can explicitly cache key pages such as the home page, primary category pages, product listing pages, and product detail pages. A disadvantage of this approach is that the rules must be updated for new pages and categories.

Web Development Quotes

Paul Cookson
Websites promote you 24/7: No employee will do that.

Ethan Marcotte, Responsive Web Design
If you’re already a front-end developer, well, pretend you’re also wearing a pirate hat.

Read more

Using Alerts in Google Analytics For Slow Site Speeds

Site Speed Alerts

The “Custom Alerts” configuration section in Google Analytics is behind the gear icon in the lower left of any page and under the “View” column.

The “Custom Alerts” configuration section is behind the gear icon in the lower-left of any page and under the “View” column.

To create a new alert, click Custom Alerts > New Alert.

To create a new alert, click Custom Alerts > New Alert.

For this example, create an alert via email and text if the home page for mobile takes greater than 10 seconds to load, on average, on any day. Here are the steps.

  1. Assign a name to the custom alert.
  2. Apply the alert to one or more Google Analytics views.
  3. Select “Day” as the period, so it notifies for all days.
  4. Select to be notified by email, text, or both.

Google Analytics offers limited alert conditions by default. There’s no way to select multiple conditions, such as home page only and mobile only.

So, for this example, create an advanced segment to identify only the home page for the mobile version of my website. Save this Custom Alert for now — by selecting that this alert condition applies to “All Traffic” and to alert me when “Avg. Page Load Time > 10 seconds” — and edit it after you create the advanced segment.

Save this Custom Alert and edit it after creating the advanced segment. For now, select that this alert condition applies to “All Traffic” and notify when “Avg. Page Load Time > 10 seconds.”

Add advanced segments to the Custom Alerts by going to “Personal Tools & Assets” section in the same “View” column and clicking “Segments.” (I’ve explained how to create advanced segments.)

Add advanced segments by going to the same “View” column and clicking “Segments.”

Alternatively, any report in Google Analytics has the configuration area to create or apply advanced segments. From any report, click “All Users.”

Any report in Google Analytics has the configuration area to create or apply advanced segments by clicking “All Users.”

Then, click “New Segment.”

Click “New Segment” to create an advanced segment.

In this example, the mobile home page is distinct from desktop, so I need to enter the mobile home page URL.

Enter the mobile home page URL.

If the mobile and desktop had identical URLs, I would apply “Device Category” contains “mobile.”

Apply “Device Category” contains “mobile” if URLs are the same for desktop and mobile.

Return to the Custom Alert and update it to apply the advanced segment. Save the updated alert and you are set.

Apply the advanced segment to the Custom Alert. Save it, and the process is complete.

Continue the process for any pages to include in the alert and for any other segments, such as device, country, or source of traffic.

Google generally sends alerts around noon following the trigger date.

7 Reasons Why Your Mobile Site Isn’t Converting

7 Reasons for Poor Mobile Conversions

  • Internet connections are usually faster for desktops, which means web pages load quickly on home and office computers, especially for hardwired connections. Public Wi-Fi connections are on the rise, but so are the people who use them. And data carriers are still trying to figure out ways to serve those customers.
  • Bigger screens allow for more defined details on navigation, search, and menus. Most menus are, by default, collapsed on smartphones, which means shoppers have to tap to see all the categories and filters. This makes it easy to miss key menu items. Larger screens also make for better zooming.
  • More products per page on categories and search results help convert. The maximum number of products per row on a smartphone is two, typically. On desktops, web pages can typically display 4 to 6 products horizontally. The ability to display several products on a single screen increases the chance of a sale; if shoppers don’t like the first two items, they may see something else that interests him. On smartphones, this requires scrolling.
  • Desktop browsers have a more standardized way of fetching and delivering content. Smartphones manufacturers are trying to find the best ways to handle the content load. Some are better than others. For example, certain mobile devices require a cache dump for users to continue surfing their favorite websites or completing recurring tasks. This can be problematic if the user (i) doesn’t understand what’s wrong and (ii) doesn’t know how to clear the browser’s cache.
  • Mobile devices run out of space more frequently. According to Remo Software, a producer of tools for mobile devices, 90 percent of smartphones have no more than 32 GB of storage. More than half of them run out of space due, mainly, to photos and videos. The “out of space” interruption can prevent ecommerce sales.
  • Many mobile sites maintain a desktop-style design. Experienced website designers and developers have difficulty optimizing for mobile. Simply put, mobile site design is comparatively new. The transition from desktop to mobile has been cumbersome. (Contributor Charles Nicholls’ piece, “3 Ways to Narrow the Mobile Commerce Gap,” is a must-read.)
  • Mobile device users have more distractions. Smartphones make it easier to find information on-the-go. But they have distractions in the form of notifications, tone alerts, and text and other messages, such as from Snapchat.

While we cannot combat every issue that causes mobile shopping sessions to convert less, there are steps we can take to decrease the impact.

UX Priorities

  • Speed and performance. The best way to kill a potential sale is to serve up a slow site. Use proper tools to compress images, scripts, CSS, and HTML.

No matter the platform, every web page must load multiple server requests — text, media, scripts, processes, and third-party tools, such as shipping calculators and personalization platforms. The more requests, the more time it takes to load the page. Don’t let page size alone fool you. A heavier web page with fewer requests can load faster than a smaller one with more requests.

  • Optimize category and search results. Find ways to fit product thumbnails into two columns to minimize scrolling.
  • Allow for cross-device shopping and persistent carts. This allows shoppers to pick up where they left off on the same or different device.
  • Implement clear calls-to-action as well as user-verification actions. Confirming that a user has successfully added an item to the cart is as important as the add-to-cart button. Don’t leave a shopper guessing if the process worked.
How To Make Images Load Faster

Images impact the load time of a website. The faster the site, the better the user experience, leading to conversions and profits.

Eliminate Unnecessary Images

In 2019, a typical web page may request between 28 and 32 images when it loads, according to a report from the HTTP Archive. Those images may be necessary.

For example, one would expect numerous images to appear on a product category page of an ecommerce website. These pictures are usually critical.

The sorts of images that may be eliminated could include:

  • Pictures of text,
  • Decorative images,
  • Stock images that don’t communicate something.

There is also data that indicates having fewer images on a web page leads to more sales.

“On a typical retail page, graphic elements such as favicons, logos, and product images can easily comprise up to two-thirds (in other words, hundreds of kilobytes) of a page’s total weight,” wrote Daniel An and Pat Meenan in a 2016 Think with Google article. “The result: cumulatively slow page loads throughout a session. In fact, … sessions that converted users had 38 percent fewer images than sessions that didn’t convert.”

A report from 2016 indicates that relatively complex and slow pages (which often include lots of images) convert at a lower rate than faster pages with fewer images.

Load Lazy Images

When a typical web page loads, it requests every image listed in the page markup, even when many of those images are off screen and will only appear when or if the user swipes and scrolls down the page.

Lazy loading of images is the process of loading an image only when it is needed. When a web page first loads, it requests only those images that will be immediately visible on the screen. Subsequent images load when the user moves down.

The HTTP Archive reported that a mobile web page’s median kilobytes of image data transferred could drop from 843.5 KB to 426.7 KB when lazy loading off-screen images. This might reduce the initial page load time by 25 percent in some cases.

A variation of lazy-loading images injects a low-resolution version of an image initially and then updates it with a high-quality version after a user can see it. This approach also significantly reduces how long it takes a page to load.

Lazy loading typically requires JavaScript. A business could have its developers write a lazy-loading script tailored to the company’s needs or use any one of several available scripts.

In an article about shaving seconds from a site’s initial load time, contributor Hamlet Batista recommended Andrea Verlicchi’s LazyLoad script. Katie Hempenius, a software engineer at Google, recommends using Alexander Farkas’ Lazysizes script. Both of these solutions are examples of the many scripts for lazy loading.

Compress Images

Raster formats — such as .jpg, .png, .webp, and .gif — make up many of the images on a typical web page. In some cases, these images can be compressed to make them load more quickly without a noticeable difference in quality.

Compressed images can look nearly identical to much heavier uncompressed images. The image on the left is 169.5 KB. The image on the right is much smaller 39.5 KB but is similar in quality. Photo: Robert Bye.

One can compress images manually using software such as Adobe PhotoshopImageOptim, or Squoosh, to a name a few options. Or one could optimize automatically via a number of solutions, including content delivery networks, application programming interfaces, and scripts or packages.

This example from Imgix, an image-optimization CDN, shows an original 3.5 MB photo reduced to 26.36 KB.

In an article about image optimization, the Google Developers site recommended several solutions.

Image optimization CDNs:

Image optimization APIs:

Imagine optimization scripts, packages, and command line tools:


Load The Proper Size

Deliver the proper size image for a user’s screen. Wasted pixels add unnecessary weight.

A 100 x 100 pixel uncompressed raster image is 40,000 bytes (10,000 x 4). To convert bytes to kilobytes, divide by 1,024. So 40,000 bytes works out to be about 39 KB.

Imagine that you have an image that will be displayed on the screen at 360 x 200 pixels. At this size, the uncompressed raster image would be 72,000 pixels. Each of these pixels requires 4 bytes, for a total of 288,000 bytes or about 281 KB uncompressed.

An oversized image at, say, 396 x 220 pixels would be much heavier. Specifically, the 396 x 220 image would occupy 87,120 pixels. That is 15,120 extra pixels (87,120 – 72,000). Those wasted pixels still require 4 bytes each for a total of 60,480 bytes or 59 KB.

This example is for uncompressed raster images. And there are many ways to compress the image’s size in bytes without impacting its pixel resolution. Regardless, serve the proper size image whenever possible.


Paradox Inc Josephine B. AndersonThis guys are awesome! It is hard to find a web design company who can actually listen and understand what you need. I’m 100% satisfied with this guys.