{"id":1833,"date":"2016-05-23T07:53:31","date_gmt":"2016-05-23T13:53:31","guid":{"rendered":"https:\/\/nositeunseen.com\/?p=1833"},"modified":"2016-05-23T07:53:31","modified_gmt":"2016-05-23T13:53:31","slug":"the-network-security-and-speed","status":"publish","type":"post","link":"https:\/\/nositeunseen.com\/news\/the-network-security-and-speed\/","title":{"rendered":"The Network Security and Speed"},"content":{"rendered":"
Recent changes have been implemented across all networks to help boost security and improve resources use\u00a0which equates to improved website performance and function.<\/p>\n
<\/a>Our friends at Data49 Design<\/a> and TheTechPlex<\/a> have been busy coding and testing these changes and putting in some late hours to reduce the impact on the network. \u00a0However, some website operators and visitors noticed odd behaviour on a couple websites.<\/p>\n They have reported opening a specific page in their browser only to find it in disarray. \u00a0Pieces of that page were spread haphazardly across the screen instead of being neat and ordered like the other pages on the site they viewed.<\/p>\n The reason for this odd behaviour is from the page caching<\/strong> added to the network.<\/p>\n It takes a lot of work to have the network that “just works”.<\/p>\n<\/blockquote>\n Page caching is a shortcut to website content delivery. \u00a0Typically on a WordPress installation a viewer comes to the website and their\u00a0browser requests a page. \u00a0That request goes to the website hosting server which processes the included server code that tells it what to deliver, and further requests all associated information and content contained in the database. \u00a0The server compiles that information and returns it to the visitor’s browser as the page requested. The page returned contains no reference to the server requests, only the content requested – what’s called an html page.<\/p>\n A cached page is just a “snapshot” of that same returned page. \u00a0The next visitor to the page does not have to wait for the requests to be processed by the server and database, or the compiling and returning of that same page. \u00a0Instead they receive the already compiled snapshot. \u00a0Much quicker loading and fully functional.<\/p>\n That was just the way it played out, but<\/strong>, it is not something that happens often or repeatedly. \u00a0That particular page snapshot was of a page request that had several coincidental factors occur. \u00a0Take note that\u00a0any page of any website on the Internet can\u00a0deliver\u00a0scrambled\u00a0content at the\u00a0time they are requested. \u00a0A glitch on the server or a hiccup in the Internet, any number of factors can contribute to a messed up page because the content that gets delivered is incomplete. \u00a0Usually the way to fix that is to refresh the page in order to\u00a0request a new version from the server. \u00a0Cached pages, however, will continue to offer that broken page because that is what is in the content for delivery and that is\u00a0what the server delivers at every refresh request.<\/p>\n Any time a post or page is edited the cache for that specific page is cleared and a new one gets produced. \u00a0To fix a messed page just log into your site and re-save the page or post, then visit it in your browser to create a new cached version. \u00a0That new version is what all visitors will receive.<\/p>\n Take note that\u00a0any page of any website on the Internet can\u00a0deliver\u00a0scrambled\u00a0content at the\u00a0time they are requested.<\/p>\n<\/blockquote>\n Note:<\/strong> A cached page version does not expire.<\/p>\n The way to create a new version is to edit the page or post and\u00a0when\u00a0the content\u00a0looks proper in your browser it looks proper\u00a0for every visitor – always.<\/p>\n Performance. \u00a0That’s the short answer \ud83d\ude42 \u00a0<\/p>\n Page caching is just good business. \u00a0For the network and for every member website within. \u00a0There are other methods of caching but we selected this method primarily because it is very lightweight and substantially reduces the number of requests made to the server and database. \u00a0The visitor’s browser does the work for the exact same user experience … except faster \ud83d\ude09<\/p>\n Not every page is cached. \u00a0Websites using e-Commerce, for instance, require the requests to the database to be real time in order to successfully add items to the cart and complete purchases. \u00a0Those related pages are not cached, though they are still delivered to browsers using compression in order to increase delivery speed.<\/p>\n Pages and posts are cleared one at a time, but there is also a button in the admin tool bar that allows clearing the cache site wide. \u00a0Every page and post in the cache is cleared when using that button so be sure to browse all the pages afterwards to ensure the new cache contains properly formed content.<\/p>\n Page caching is just good business. \u00a0For the network and for every member website within.<\/p>\n<\/blockquote>\n Yes, and also after the entire cache is cleared it’s advisable to visit each page to ensure integrity. \u00a0At this time, though, it should be unnecessary for websites within any network. \u00a0Part of what Data49 and TheTechPlex have been doing is viewing every page on every website to create stable cache versions. \u00a0What is needed is already done and for website operators it’s business as usual. \u00a0It’s only been the odd one that has escaped the process and cached haphazard. \u00a0The solution for those is a simple re-save and view.<\/p>\n In regards to cached pages, a cached page cannot be hacked or have code injected to it. \u00a0Hacks are typically inserted in order to be processed by the server on the next load, but the next load of a cached page has already bypassed the server request stage and is a version that is not hacked anyway. \u00a0However, an already hacked page can be cached and that is where our securities come in to play to block hack attempts and to alert us of\u00a0any compromise.<\/p>\n It might be asked why we have changed our securities from the previous application. \u00a0It worked well for years and we are certainly pleased with its service, but what often happens with security programs is they become bloated in trying to address the multitude of issues and threats that can arise. \u00a0Often-times a re-write of the entire code base is the only way to trim down an application, instead of building upon it repeatedly, but if it isn’t addressed it becomes counter productive. \u00a0And there are new applications being developed all the time. \u00a0We have opted for a system that uses about 10% of the resources the previous application used but still delivers the securities we expect.<\/p>\n The Nositeunseen network is not\u00a0an application that once built just runs. \u00a0We are actively involved in its development and performance, and ensuring the best operator and user experience. \u00a0It takes a lot of work to have the network that “just works”.<\/p>\n\n
What is Page Caching?<\/h3>\n
Why Was the\u00a0Cached Page All Messed Up?<\/h3>\n
How Does a Messed Up Cached Page Get Fixed?<\/h3>\n
\n
Why Use Page Caching?<\/h3>\n
\n
Is Every Page Cached? and Only Cleared One at a Time?<\/h3>\n
\n
Does Every Page Need Checked\u00a0on Each Website?<\/h3>\n
A Word on Security<\/h3>\n