If you’ve tried to use the Twitter API to display tweets on a website, you probably have come across a situation where tweets just didn’t display, especially if the Twitter account wasn’t regularly updated.
Solspace ran into this same problem:
Pretty quickly we learned that depending on Twitter’s search API creates a fragile system. The API limits requests per IP. If you are on a shared server then you may be sharing this limit. Additionally, Twitter’s API changes occasionally. These issues can potentially leave an empty spot on our site or even a page that won’t load. I’ve seen a situation on a client site where the client was displaying their own tweets, but they tweeted infrequently and the search API wouldn’t pull their older content, sometimes leaving the space on their site devoted to tweets empty.
and created a workaround by importing the tweets into the EE database. To follow along their tutorial you’ll need the Twitter Timeline plugin (free from EllisLab) and the Solspace Importer ($79).
The process is simple enough: create an XML feed using Twitter Timeline and then pull that in using the Importer module. You can also use DataGrab, if you prefer that add-on.
Read their tutorial: Importing Tweets Into ExpressionEngine for Reliability and Control
Aaron Gustafson of Easy! Designs posted how they handle serving up multiple asset files (CSS, javascript) in the most efficient way possible. They are particular about organizing their CSS and javascript into multiple templates but serving that up as a dozen individual files isn’t very efficient.
A while back, it was not uncommon for us to include each of these assets into the document separately, but, as website optimization and performance folks will tell you, all of that separation leads to a lot of additional overhead because the browser must request each of those files individually. In the interest of streamlining the download process, we decided to merge all of the stylesheets together at the template level before sending them over the wire.
I keep all of the assets of sites I build outside of EE templates, but I really like this way of leveraging EE templates. It’s almost slick enough for me to rethink my ways.
Read the whole article: Template-based Asset Munging in ExpressionEngine
Scott Robbin from Weightshift posted a spot-on article about how front-end developers can improve the performance of the websites they build. He has three basic concepts you should follow (fewer file requests, download files concurrently and keep cache as long as you can) and shows examples for each one. His write-up came out of his talk at WordCamp Chicago but the techniques apply to any CMS.
Though, the talk itself was WordPress-specific, the underlying concepts are applicable to any client site, whether it be coded in WordPress, Expression Engine, MovableType or none-of-the-above. At Weightshift, we have made performance tweaking a standard part of our development cycle on all projects. I’d like to take a moment to share our process, and some of the tools that we use.
It’s not just up to backend developers and server admins to make sites run faster. The performance concerns should be addressed throughout the entire project—from IA to design to development.
Read the whole article: Making Client Sites Faster
Those of us that have built high traffic websites on ExpressionEngine know that you can’t just build the site, put it up on a server and hope it doesn’t buckle under the crush of visitors. All of us, I assume, implement some kind of caching in EE along with lean templates, as a way to keep the site nimble and quick. Well, we now have another tool at our disposal.
In the latest EE build, Ellis Lab has included a new feature: Tracking Preferences. There are four preferences for disabling some of the tracking that EE does on every page load: Online User Tracking, Template Hit Tracking, Weblog Entry View tracking and Referrer Tracking.
Derek Jones from Ellis Lab explains why these new preferences are so important:
MySQL’s default storage engine (MyISAM) is designed for efficiency with reading, which is good since ExpressionEngine is a read-heavy application in terms of database usage, not write-heavy. When writes are made to tables with the MyISAM storage engine, it must establish a lock on the entire table for the write to occur. ExpressionEngine has a few things that it tracks to provide bits of information to the site owner. How many times a template has been accessed. How many users are currently online. Where inbound links are coming from. How many times a particular entry has been viewed. On high traffic sites, or under extreme and unusual traffic events (i.e. Digg), these normally innocuous bits of tracking suddenly become a problem, as you have thousands of visitors hitting the site simultaneously, and for each one of those visitors, MySQL is locking the associated table to try to write to it. Before you know it, there’s a queue of table locks and MySQL just can’t keep up.
Unless you need these tracking features, you should disable them. You will save one query per feature disabled per page load. And while that doesn’t sound like a lot, multiply those queries times a large surge in traffic and it could mean the difference between a site that is up and one that crashes and burns. I’m pretty sure we’ve all had sites that have crashed and burned.
In my day-to-day use of EE, I’ve never used Template Hit Tracking or had a client use it, so it will be the first thing I disable on every project. I will also disable Referrer Tracking (although I’m guessing just uninstalling the module will have the same effect) since I and my clients normally use a third party website statistics system.
Email
Comments
Post to Twitter
Post to Delicious
