For the past two years, companies like ZippyKid have been including and pushing for the use of Content Delivery Networks (CDNs) to reduce page load time. But, page load time will only decrease if the page weight decreases too. This increase in page weight is actually negating the use of CDNs. What’s a website owner to do now?
Introducing the ZippyKid PageSpeed service beta.
We partnered with the PageSpeed team at Google to develop a new service designed to dramatically reduce page load times. Best of all, you’ll see significant performance gains without changing a single line of code or installing a plugin.
PageSpeed for ZippyKid is the world’s first WordPress optimization service powered by ngx_pagespeed, designed to automatically apply web performance best practices to deliver fast WordPress sites. These best practices include:
Optimizing caching by leveraging browser caching and proxy caching techniques to dramatically reduce round-trip time and substantially reduce the total payload size of responses.
Minimizing request overhead
Minimizing payload size
Optimizing browser rendering
Compressing and optimizing images for mobile devices on the fly
Serving WEBP files when acceptable and appropriate
Combining and compressing CSS and Javascript
Together, these techniques deliver a significant increase in the speed of WordPress sites.
Speed is a feature. Our goal at the Make the Web Fast team at Google has been to help site owners speed up their sites without needing to become web optimization experts – our PageSpeed libraries do exactly that, offering over 40 web optimization filters. Our newest addition to the PageSpeed family is the ngx_pagespeed module for the popular Nginx server, and we’re excited to work the ZippyKid team to bring these optimizations to millions of WordPress users!
Ilya Grigorik – Google
How much faster will your websites run?
Our benchmarks indicate that PageSpeed for ZippyKid will deliver up to a 75% reduction in page sizes and a 50% improvement in page rendering speeds. These performance gains translate directly to better SEO performance and a dramatic improvement in user experience. All while delivering richer media to further differentiate you from your competition.
A dramatic reduction in the # of requests
The number of requests per page is reduced considerably with ngx_pagespeed
A dramatic reduction in Speed Index of websites
A dramatic reduction in the speed index with ngx_pagespeed
Web page size is reduced considerably with PageSpeed as well
page weight is almost cut in half with ngx_pagespeed
What’s Next?
There are some bugs, and we caution the roll out of this. We’re interested in existing customers who are willing to try this out with us, and help us make the offering 100% production ready. Sign up for the ZippyKid PageSpeed beta program.
Criteria for Beta
The criteria for acceptance on this beta program is as follows.
You must be an existing ZippyKid customer, if you aren’t you can sign up here
You must realize that support for this is limited, so we may not respond to issues with this service as fast as normal tickets.
You do not depend on ads for revenue. We know there is a problem with some ad networks and their code.
Thanks
This would not be possible without the following people.
A few months ago, we released a feature in the ZippyKid control panel called “Modes”. I wanted to take the time today to explain what this feature does, and why it exists. We built this feature based on usage patterns and questions being asked in our ticketing system.
Background
A website usually switches between two states, or modes in it’s life time. When it’s first launched on our systems, the developer needs to install plugins, install themes, and make changes. This can happen via the Admin interface, SFTP, or something like Git or Subversion. While this is happening, minor changes are made, that do not need the full horse power of the ZippyKid platform. This is also a good way to test if your site breaks when it’s served from more than one web server, and if it runs in a PHP 5.4.X environment. Once the customer is happy, a domain is attached to the site, and the site goes live, it is then in production mode. Where we automatically configure the caching of the website, the CDN, and other server side optimizations that we feel are necessary for the website.
In the past you needed to manually enable/disable these settings one by one. With ZippyKid, you just click one button.
Development Mode
This is the default mode sites start out in. We recommend you put the site in this mode when you are making frequent changes, especially frontend changes. It’ll speed up your workflow considerably, as you don’t need to purge the CDN after every change to a CSS file.
Production Mode
This mode is why you chose ZippyKid in the first place. This is when we turn on caching for your site, and configure it to use our content delivery network (CDN).
In Conclusion
These two modes give you the flexibility to work properly on our environment. You could have one site in Development mode 100% of the time, where you make your changes and test with the client. When you’re comfortable, you can apply those changes to your production site, manually or by using a version control system.
By now a lot of you have seen the news reports on TechCrunch, Sucuri and other news sources about the massive attack against WordPress sites. We’ve been working in the background to solve this problem on our systems dilligently. We were fortunate enough to not see the attacks come to us, until last night, and right now the attacks are going full force. In the past hour alone, we’ve stopped about 10,000 attempts.
There is a very small possibility that the system thinks of you or your users as an attacker, when that happens, you’ll see a message like the one below.
As the message says, just relax, and try again in a minute or so. We’re sorry about this, but we’ll make our detection algorithms better over time. I’d also like to personally thank Ben Welch Bolen, the CEO of Site 5 for keeping the back channels open during this crisis, and sharing critical information that helped us devise this plan.
Since November 2012, we’ve been testing SPDY protocol support in secret with our customers. Today, we’re making it public.
All sites that pay for SSL come with SPDY version 2 support.
What does that mean in english? Basically, if you enabled SSL on your site in the past 3 months, you are using technology that will be the basis of the next generation of the web. SPDY is a protocol designed initially at Google, that dramatically speeds up the page load time of a site by replacing the old HTTP 1.1 protocol, with something designed for today, and the future.
With SPDY, you don’t need to do things like add multiple hostnames for assets in your HTML, to get around the concurrent downloads problems. You can download most of the page in one connection, thus reducing overhead on your connection, and ours.
Does this make my site faster automatically?
Yes, if your visitors are using a browser that speaks SPDY (most new browsers do), then it’ll load the site faster. If they’re using an older browser, then it will fall back gracefully to the older protocol.
How do I know if my site is using SPDY?
Currently, if you’re using SSL, your site is using SPDY, we charge extra for SSL, so unless you use SSL, it won’t be enabled. If you’re using SSL, you can go to spdycheck.org and see if it’s enabled.
Special Thanks
We’d like to thank the team at Nginx and our investor Automattic, for funding the project, that allowed SPDY to be integrated with Nginx.
Summary
At ZippyKid, we’re building the most advanced hosting infrastructure, to help you get your branded message to your audience, with the least amount of friction. In order to do this, we’re looking towards what your website will need in the future, and providing you with that technology today. This is why we’re the only WordPress hosting partner of Rackspace (RAX).
On 30th April 2013, Posterous will be shutting down. This is a sad day for many bloggers, though ever since Posterous was acquired by Twitter, it’s not entirely surprising. What this does highlight, is the importance of owning your own data, and you can do just that with WordPress. This tutorial will walk you through the process of migrating from Posterous to WordPress. Let’s take a look at how it’s done.
1. Set up WordPress
To get started, you’ll need to have a WordPress website to import your information to. You can find a host and install manually, or you can sign up to ZippyKid and WordPress will be pre-installed (and super-fast) for you.
2. Install the Posterous Importer
Log in to your WordPress website, and navigate to Plugins > Add New.
Search for Posterous Importer. Install and activate the plugin.
3. Open the Importer
Navigate to Tools > Import.
Here you’ll find all the importers that are available for WordPress, and the Posterous Importer that you just installed.
Click on the Posterous importer.
4. Start the Posterous to WordPress importer
You’ll need the following information:
The email address associated with your Posterous account
Posterous password
Your subdomain
Enter all of the information and click submit.
Your content will be imported into WordPress, which makes you its owner – congratulations! You’ve now got access to thousands of themes, tens of thousands of plugins, and all of the goodness that WordPress has to offer.
The following is a guest blog post by a friend an SEO expert, in response to a rant I made on facebook a few months ago. It was related to a pre-sales question we see. “I need a dedicated ip address for better SEO, can you provide me with a dedicated ip address”?
Back in December my friend and ZippyKid owner, Vid Luther and I had an interesting discussion on Facebook regarding dedicated IPs and SEO.
The discussion stemmed from the original thought provoking post by Vid:
“Dear ‘SEO consultants’, Please stop telling people to put their sites on different IP’s. Every time I hear this, I tell our customers to find different SEO consultants.”
Being an SEO Consultant myself, I took offense to Vid’s post and wanted to clarify how SEO, & Dedicated IPs work together. From our conversation on Facebook, Vid invited me to share a few thoughts on the ZippyKid Blog.
Now, I respect the point Vid is making and it’s correct most of the time…BUT there are scenarios where a dedicated IP for hosting your website makes sense. These scenarios are what I want to highlight and review to help you make an informed decision before requesting a dedicated IP from your hosting provider.
Three Considerations of Hosting and IP addresses for your website.
The ip address that’s assigned to your website, depends on your hosting provider. Providers are assigned IP addresses by ARIN, and astute users can figure out where things are hosted by just looking at the ip addresses of some popular providers.
Performance & Speed
There is a good possibility that your website shares the ip address of another high traffic website. If you’re hosting your site on a shared hosting platform that does not do a good job of allocating resources, your site could be slow. You may ask, “Why does site speed even impact SEO?” Well, it’s because the speed of your site impacts your SERP (search engine ranking position) with Google. Keep in mind, a unique ip address does not mean your site will load faster.
Security
Your website could share the ip address with another site that has been marked as malware. Some network security programs will “null route” requests to those ip addresses, which would make your website unreachable. Some anti-virus software may mark any website with the same ip address as malware, this may raise false alarms against your website. Most modern browsers may display an alert which reads, “This site may harm your computer” next to every link for that website which appears in search results. You can learn more about what to do if you are infected on this Google answer.
SSL
SSL encrypts traffic to your site, it’s usually used by e-commerce sites, and sites where personal information is shared. The latest version of SSL doesn’t require a unique ip address, but due to older browsers ( mostly on Windows XP) not supporting this, it’s still safer/best practice to get a unique ip address. This doesn’t affect SEO directly, but is too large of a reason not to mention.
editors note: I recommend SSL on all sites, your password can be seen in clear text when you log in from a public wifi network. So, WordCamps, Starbucks, other conferences. There are also things done with SSL that make your website faster.
The Facts on SEO and Shared IP addresses
Now let’s assume you have gone with a reliable and trusted shared hosting provider for your site. You’re down to really one concern that you have to take into account: Google penalties due to links or malware.
So, first off let’s review a fact that Matt Cutts clarified back in 2006: “… there was recently a discussion on a NANOG (North American Network Operators Group) email list about virtual hosting vs. dedicated IP addresses. They were commenting on the misconception that having multiple sites hosted on the same IP address will in some way affect the PageRanks of those sites. There is no PageRank difference whatsoever between these two cases (virtual hosting vs. a dedicated IP).”
In 2010, Matt Cutts made a video which validates that shared hosting is still fine. But now there are situations where you could be at risk. In the event your site is hosted on a server with many sites that are considered “spammy,” then yes, your site could be negatively impacted. Here is the video Matt Cutts made that clarifies Google’s position on shared hosting:
Let’s put this new found knowledge to work in a practical example. Say you have a site named abc.com and it shares a host and IP with a large WordPress Multisite that is being used as a “link farm” to generate backlinks to “spammy” sites to try and gain position in the SERPs. In this scenario, your site is in jeopardy of being penalized for sharing the same IP as this “link farm” because of the poor quality and violations in which the other thousands of sites on the network have partaken.
In 2012, Google released their Penguin update which improved their search ranking algorithm and started to take into account sites participating in a link network. There is a great post on the YouMoz Blog by Ethan Lyon that covers how to check if you are part of a link network.
Bing also provides another trick to look at what sites are hosted with you. For example, in a Bing search enter “ip: 50.116.59” and you will see results of all the sites that are hosted alongside my personal site at another premium WordPress hosting company, WP Engine.
Monitor Google Webmaster Tools
Make sure you have your site added to Google Webmaster Tools and email alerts are turned on. This way you will be sure to be alerted by Google Webmaster Tools if they send you a warning. Search Engine Land has a nice example of what your warning from Google will look like if it does happen.
How To Resolve Link Warnings
In the event you discover a problem or are notified by Google in Google Webmaster Tools take the follow two steps:
Notify your host and ask to be moved to a new server with a new IP.
At the end of the day, most websites will not need to be concerned about shared hosting and not having a dedicated IP negatively affecting their SEO. There are exceptions to the rule, but in general, do not feel that you must have a dedicated IP address. Always be on the offense and protect your site frequently by checking Google Webmaster Tools and monitoring your co-hosted sites.
I reached out to one my most trusted SEO Expert friends: Scott Offord. In Scott’s expert opinion there are so many more things you should concern yourself with first before focusing on a dedicated IP address.
“Having a dedicated IP is not something to worry about in regards to SEO. There are other more important things to think about. Just take a look at Google’s Webmaster Guidelines for example.”
If you feel that having a dedicated IP address is a must have, make sure you understand WHY so that you and your hosting provider can work together to put a solution in place that works for you.
Keep in mind that if you’re reading this after the day it was written…something could have changed. SEO best practices are always changing. Feel free to reach out on twitter and let me know what’s going on.
-Mike
About Mike Zielonka
Mike Zielonka is the Director of Web Strategy and Co-Founder at Tuna Traffic and a Satisfied ZippyKid Customer. You can continue the conversion with Mike on twitter at @mikezielonka. He spends a significant portion of his time coaching Tuna Traffic customers on web strategy and building custom client web presences. Mike’s expertise is concentrated in Search Engine Optimization (SEO), Social Media and WordPress Development. In addition, he is well versed in the development of PageLines, a leading edge WordPress Theme Framework. One more thing…Mike LOVES pizza with extra cheese.
I’m really excited to share that I’ll be speaking at php[tek] 2013 in Chicago, this May. I’ll be doing a formal session discussing the ups and downs of building your business on public cloud networks like Amazon and Rackspace, versus building private clouds. This is the first time I’m giving this talk, as it’s based on things I’ve learnt at ZippyKid over the past 18 months. I’ll be sharing some very interesting numbers from my research of these public clouds, and how we came to the decisions that we did. The talk will be partly technical, and partly on the business side.
Apart from getting a chance to talk to me , if you look at the rest of the schedule, this conference has a lot to offer. If you’re involved with WordPress on a technical level, you owe it to yourself to attend. You’ll learn a lot about what’s new and what’s coming down the pipe in the PHP world, you’ll get a chance to network with professionals who are doing some really cool things with PHP. I’m confident that you’ll learn something at this conference that will make you a better WordPress developer. I’m personally interested in attending the following talks:
PHP 5.5 the new bits by Davey
The SOA Panel discussion
Derick’s Performance profiling talk
Stan Lemon’s Data security and encryption talk
What’s new in MySQL 5.6 and HA MySQL by Lig and Davey
C.R.E.A.M
The selenium unit testing one, except.. I’ll be speaking during it.
Caching and Tuning fun
This is the first time I’m speaking at this conference, I’ve always just attended it, so it’s pretty nerve wracking for me. All of the speakers are so smart, I feel like I’ve finally been asked to join the cool kids . Personally, I’m still slightly star struck, to be sharing the stage with people like Elizabeth, Sara, Davey, Derick, and others. I learnt so much by listening to them speak and reading their blogs. I’m really excited to hopefully give back to the PHP community at large.
We had a system wide failure this morning around 0400CST. I wanted to explain what happened.
What happened?
In a nutshell, some line of communication between our account manager and the DC ops team at Rackspace got messed up. We had scheduled a major maintenance window on February 22nd, but someone how DC ops thought it was today. So they took a bunch of stuff offline, that they shouldn’t have. These machines are still offline, and will probably take 2-3 hours to bring back online.
How did we fix it?
Since we were only 5 days away from this major maintenance, we had been testing some new technology that would’ve been turned on next week. Since all our tests had passed, we had scheduled the maintenance window to give everyone ample warning of the pending change. Due to the nature of the event that took place today, we turned it on today. The goal of this new technology and systems was to make our lives easier, and make your sites faster.
What’s the overall impact?
While your sites are back up and running, you may see minor issues.
The most obvious one being that some of your changes have reverted to 12 hours prior. This is because the newer system was 12 hours behind the production system. Once the older systems come back online, we’ll re-sync the changes.
New sites are not going to work, our deployment system is not yet talking to the new systems, so we’re working over the weekend to make that work.
Conclusion
I’m sorry this happened, fortunately we were able to identify the issue, and were able to execute on a plan ahead of schedule. We still need the maintenance window on the 22nd, to do one last thing. This was human error, we’re working with Rackspace to figure out what caused this to happen, but they’ve been awesome in responding to priority #1, which was to get everything back up and running.
A lot of our customers take advantage of our free test sites, where they can show their clients changes they’ve been working on, once the client approves the changes, they need to push those changes from the test site to the live site. This post will show you and them, how they can automate the process where files will go from Github to WordPress intelligently. Once this is setup, you’ll never have to manually remember what files changed, or push entire folders just to be sure.
Before I continue, I’m going to assume the following.
You have git configured and working locally
You have a two distinct test and production environments
You know how to push changes to your github repo
You know how to make branches in Git
You know how to merge pull requests with Github
Dog Fooding - A note about how this applies to us.
This is the workflow we use to push changes of our code from Github to WordPress. It makes it easy for non developers to test and vet out changes we’ve made to our presentation layer. This is not how we push content changes from test to production. That’s called content deployment, and there’s a very good plugin for that already.
1. Local Development - At first, changes are made locally on the developers machine, once the developer is happy with changes, he pushes to the “Staging” branch at github. 2. Deploy HQ – Deploy HQ deploys the code in the appropriate location. 3. UAT – The website owner, or customer looks at the website, is happy, and signs off on the work. 4. Pull Request – A Pull request is made on Github, and merged in with master. Deploy HQ deploys to the production site.
Configuring the test server at DeployHQ.
Configure GitHub to make a web hook call after a push
Please note, this process is independent of any hosting company. This will work whether you host with us, or elsewhere.
If you’re interested in becoming a high traffic customer of ZippyKid, you must pass a code audit.
What do we mean by code audit?
Your code must pass a basic set of heuristic checks and smells. Turn on debug mode, and look for notices and deprecated calls. If your site is throwing more than 5 notices, and more than 1 deprecated notice, your site will have a problem at scale. We recommend you fix these issues immediately, as it’ll allow you to take advantage of our high traffic plans.
If you’ve had custom functionality built for your website by a web development studio that we’ve never worked with in the past, make sure they follow step 1 above. Secondly, they should be willing to pay for a code audit, by an independent third party that we recognize. For starters, Covered Web Services, Range, 10Up, Human Made and of course W3-Edge. I’ve talked with all of them personally, I’ve seen their code on our production systems, and I trust them to do these audits. In other words, if they say it’s us, not the code, we’ll give you a month of free hosting, and we’ll fix the problem, or help you move elsewhere.
Your developers should learn how to use version control, and learn how to deploy to your test and production site, using post commit hooks, or deployment tools like DeployHQ. This is not a requirement, but it’s an industry best practice. For your own sake, we recommend you ask your developer to practice safe coding.
Why don’t you want my money, you ask?
We are very interested in hosting your high traffic website. It will load much faster on our stack, we have no doubt about that. But, we’re not miracle workers, we’ve seen our fair share of shoddy/sloppy code. There is no amount of caching magic that will make up for it. Sloppy code on high traffic websites compounds the problem at an exponential rate. Think about it: one page request that makes 1000 calls to the database, multiplied by 1000 requests. That’s a lot of database calls. While we can cache the result, sometimes when the cache isn’t primed, requests like these are impossible to get into the cache. More importantly, there is absolutely no good reason for a page to make that many calls to the database.
We want to make the web a faster place, we’re doing our part to make sure you don’t have to do the unsexy stuff like caching or making deals with CDN providers, but you need to take some pride and responsibility as well. Think of it as an investment in your future. If you can afford ~$5000/year for hosting, you can afford a one time fee of $3000 – $5000, to ensure your website code can actually scale, when you hit 10 million page views/month. Problems with sloppy code need to be fixed, there is no hosting company that can cache around this problem. Eventually, badly-written code catches up with you, either in a large hosting bill, or a non functional website. Anyone that tells you otherwise is lying, or is new to high performance hosting, and doesn’t know any better.
Security. Real world Example: A client and I spent close to 6 months debugging a weird issue on their website, where random posts would get deleted, I finally got Mark Jaquith of Covered Web Services involved, he did a quick scan of the code, and found vulnerabilities in less than 1 hour. The vulnerabilities were found in custom code written by the development agency, which was adamant that it was our infrastructure that was to blame. Let’s go back to the beginning, the customer, and I spent countless hours over 6 months trying to find the cause of this issue. We worked with the developers, combed through logs, and proposed possible vectors which seemed to trigger the situation. All to no avail. The company did an internal audit, and failed to come up with these vulnerabilities. Not because the developers are incompetent, but sometimes we all need a fresh pair of eyes to view the code. A $5000 audit is peanuts compared to the partnerships, income, and time lost by the client. Not to mention, my personal time. The CEO of the company personally spending 30 hours on a $399/month website is bad business. At my old consulting rate of $150/hr, we’re not going to make money on the website for 12 months. That’s a losing business strategy, and I will not take part in it any more.
Why don’t we ask this of all our price plans?
The higher price points with our system come with higher infrastructure and support costs, this does not mean we’ll jump through hoops for you. You need to show a commitment to your website from your side as well.
High traffic websites usually have more custom code that hasn’t been through the community vetting process on WordPress.org. Lower traffic sites usually use the higher rated plugins from the plugin repository.
Mike Zielonka is the Director of Web Strategy and Co-Founder at 
Recent Comments